Sanket.Chat
Security: deployment and resilience

Secure messaging deployment and resilience, from cloud to air-gap

SANKET (Sanket.Chat) by Tosh Defence deploys as a dedicated installation in the topology each organisation needs: a sovereign cloud of its choice, a dedicated hosted installation, its own premises or a fully air-gapped enclave. Every mode can run as a single host or as a multi-host high-availability installation with second-site recovery, and calls connect over HTTPS on TCP 443 in restrictive networks.

Communications matter most when other systems are under stress. SANKET is engineered to keep running, through outages, network restrictions, upgrades and site loss.

Four ways to deploy, one security design

Every SANKET installation is dedicated to one customer, and the security design is identical in every mode. What changes is who owns and operates the infrastructure and how connected it is.

  • Cloud: Sanket.Work in any region, on any cloud the customer chooses
  • Dedicated hosted: Sanket.Work on Tosh Defence hosting
  • On-premise: Sanket.Enterprise on customer servers
  • Air-gapped: Sanket.Enterprise in an isolated enclave

High availability with second-site recovery

The high-availability profile runs on several hosts: two edge hosts behind a shared address or the customer's load balancer, more than one application, real-time and media node, replicated databases with fenced failover so a former primary can never accept writes, distributed object storage and a clustered secrets service.

Databases, storage and secrets replicate asynchronously to a second site. Drill tooling fences the primary, promotes the second site, switches the service names and later fails back, and each drill records the recovery it actually achieved.

Calls that connect in restrictive networks

Many hotel, ministry and mobile networks allow only outbound HTTPS on TCP 443. On an internet-facing installation, a single TCP 443 port carries both HTTPS and the call relay, separated at the edge without decrypting anything. The relay hop uses TLS 1.3 with AES-256-GCM only, and inside it the media keeps its end-to-end AES-256-GCM frame encryption.

Calls are engineered for 3G and congested 4G links, adapting audio and video to keep voice intelligible.

Upgrades and backups without drama

Upgrades take a protected, encrypted restore point first. Where a release allows it, the new application server starts beside the old one and takes over only once it is healthy; any failure rolls back automatically.

Backups are encrypted per component with AES-256-GCM, described by a signed manifest and verified before a restore changes anything. Destinations include local or network storage, S3-compatible object storage or SFTP, with an optional second copy.

Resilient when identity systems are not

Everyday sign-in on an existing device, messaging and calls never contact the organisation's directory, so field devices keep working through an identity-provider outage, and at least one local administrator always remains able to sign in.

Technical proof

Read the detail in the SANKET whitepaper

Every statement on this page is set out in full in the public SANKET Technical Security and Architecture Whitepaper, free to read without registration.

FAQ

Frequently asked questions

Ask our team a question

How can SANKET be deployed?

As a dedicated installation in a cloud the customer chooses, on Tosh Defence hosting (Sanket.Work), on the customer's own premises or in a fully air-gapped enclave (Sanket.Enterprise). The security design is the same in every mode.

Is SANKET highly available?

Yes. The multi-host high-availability profile provides two edge hosts, redundant application and media nodes, replicated databases with fenced failover, distributed storage and a clustered secrets service.

Does SANKET support disaster recovery to a second site?

Yes. Databases, storage and secrets replicate asynchronously to a second site, with drill tooling to fence, promote, switch and fail back.

Do SANKET calls work when only port 443 is open?

Yes. Where a network allows only HTTPS on TCP 443, calls connect through that port with TLS 1.3 and AES-256-GCM, and the media stays end-to-end encrypted inside.

Is there downtime during upgrades?

Upgrades are designed to preserve service. Where a release allows it, the new version takes over only once healthy; other releases are applied in a planned maintenance window. Any failure rolls back automatically.

How are backups protected?

Each backup component is encrypted with its own AES-256-GCM key and listed in a signed manifest that is verified, with every artefact, before a restore changes anything.

Design the right SANKET topology for your organisation

From a single site to high availability with second-site recovery, Tosh Defence helps you plan deployment, resilience and rollout.