FAQ

General

What is it?

Synadia Platform is a bundled distribution of enterprise-grade components that augment the capabilities of NATS.io.

Beyond NATS itself, the core component of Synadia Platform is Control Plane which provides a user interface and API to securely and easily manage NATS accounts and users, observe and drill into NATS usage and connections, manage and visualize JetStream assets including streams, key-value buckets, and object stores, and more.

Synadia Platform also includes the HTTP Gateway, which provides an HTTP interface for interacting with key-value buckets, object stores, and general messaging over subjects.

Synadia Platform can be deployed and managed in an environment of your choosing. There is the managed deployment option, where Synadia will deploy and fully manage Synadia Platform as a service on your behalf or there is the self-hosted option where you deploy and manage it.

Try it out yourself with a free 14-day trial!

How does it relate to Synadia Cloud?

Synadia Cloud is a multi-tenant, multi-cloud, and multi-geo software-as-a-service (SaaS). Synadia Cloud and Synadia Platform share the same core set of components. From an end-user perspective, the experience of using Synadia Cloud versus an instance of Synadia Platform should be effectively the same barring differences in endpoints, cluster topology, and resources.

What are Synadia's security and operational practices?

See this page for more information.

Managed

How does the managed offering work?

A discovery call occurs to design and size an appropriate deployment of Synadia Platform for your needs.

A common deployment topology includes a NATS cluster of three servers spread across availability zones within a single region. However, depending on the use case, a custom topology can be designed to be multi-region and/or multi-cloud.

Once the topology and sizing is determined, Synadia will provision the environment, monitor it, and keep it updated for the duration of the contract. From the customer’s perspective, it should feel like their own private SaaS of Synadia Platform.

What are the customer's responsibilities?

In order for Synadia to provision the infrastructure and Synadia Platform components, the customer must provide administrative access to a fully isolated namespace within the customer’s cloud account.

This would be either:

• An "account" in AWS
• A "project" in Google Cloud
• A "subscription" in Azure

This is to ensure that all infrastructure and software provisioned and managed by Synadia does not overlap with any of the customer’s existing infrastructure.

Where applicable, VPC peering will be applied between this Synadia managed namespace and the customer’s other namespaces.

Once sufficient access is provided and a few questions have been answered regarding networking, Synadia moves forward to provision the stack.

What are Synadia's responsibilities?

Once the environment has been provisioned and deemed "production ready", the operational guarantees go into effect. These include:

• 99.99% uptime SLA
  • The minimum requirement is having a cluster of at least three servers across availability zones within a single region.
• 24h response time for security patching
  • This applies to critical CVEs that have been determined to impact the service.
  • Less severe security patching occurs on a routine basis of 30 days or 90 days.
• Scheduled, zero downtime upgrades
  • When software updates are available in Synadia Platform or the underlying operating system, an upgrade will be scheduled.
  • A rolling upgrade strategy is applied to ensure the applications connected to NATS and highly available (HA) JetStream assets are not impacted.
• Logging integration to the native cloud service By default, all logs emitted from Synadia Platform are sent to the cloud provider’s native logging service.

If there is any anticipated disruption to the service, Synadia’s on-call staff will be paged and remediate the environment without requiring the customer to get involved.

Which cloud providers are supported?

• AWS
• Google Cloud
• Azure

Additional providers will be supported in the future.

Does Synadia use of Kubernetes?

No, Synadia makes use of bare VMs. That said, NATS is a CNCF project, and can indeed be deployed using Kubernetes.

Deployment in Kubernetes has an edge on cost, as resource usage can be marginally optimized, lifecycle maintenance efforts are a bit lower, and security/secret management is more streamlined.

Many people opt for Kubernetes mostly because of consistency of management with other workloads.

The reason Synadia has chosen not to do this is because Kubernetes adds extra layers of abstraction that have a sizable impact on resource consumption and latencies. The NATS usage pattern is closer to a network appliance than to an end application. Typical end-to-end integrations will require several interactions with NATS, where the overhead of Kubernetes will have a multiplicative effect.

The Kubernetes network stack has been architected thinking on more traditional workloads (i.e. microservices, http/REST APIs and so on) with features that NATS already addresses in a more directed/optimized manner. Deployment of NATS outside of Kubernetes makes networking much simpler; traffic is easier to identify, there is no need for extra moving parts (i.e. load balancers), extending clusters globally and to the edge (superclusters and leaf nodes) is much simpler, managing availability zones is straightforward and overall the network performance is superior.

Kubernetes also adds an additional layer of update dependencies: worker node updates and cloud provider lifecycles can potentially impact availability and performance under scenarios of high load.

Due to all this, for managed installations the Synadia team has streamlined direct deployment without Kubernetes.

What operating system is used?

Our deployments are currently done on Ubuntu 22.04 LTS. In the future we will be moving to Ubuntu 24.04 LTS, and intend to always remain on an Ubuntu LTS release no older than 4 years.

How is data backed up and stored? How is that data protected?

NATS JetStream data is stored on a separate, encrypted, persistent cloud volume that is maintained even when the instance itself is regularly rebuilt for updates or configuration changes. Like other disk images, this is done using the cloud provider’s disk encryption and key management.

Backing up stream data is the responsibility of the customer, since Synadia has no visibility into that data or any way to validate the consistency of backups.

How is the system monitored and logged? Who has access to this data and what protocols are in place to protect access?

The managed Prometheus host monitors all systems in the platform. This data is then queried by Grafana Cloud, which is what the Synadia Operations team uses internally to monitor systems. We can also grant customers access to Prometheus.

We do not ship logs anywhere externally unless requested by the customer. When we do aggregate logs, we use a logging solution that exists in the customer-owned cloud account. (Google Stackdriver, for example)

What authentication methods are supported for the environment?

Synadia’s Operations team uses SSH via bastion hosts within the cloud environment to access the virtual machines. SSH is run on a non-standard port on the hosts, and only allows for key-based authentication.

Access to the Synadia Control Plane is customer-only; credentials are created when the system is set up, then given to the customer with instructions to change the password so that Synadia does not have access. Username/password logins and authentication via OIDC are both supported for this access, and use of OIDC would depend on the customer’s available authentication methods.

How is data encrypted?

Encrypted storage is done via cloud vendor key management, and is typically the default used by each cloud provider. This is currently AES-256-GCM for AWS, Google Cloud, and Azure.

Data in transit is encrypted via TLS for client, route, and monitoring connections.

Which ports are exposed and for what?

• External clients connect in using nats native protocol: nats://4222 or tls://4222
• Local monitoring of nats servers connects to http://8222
• Local monitoring of host metrics connects to http://9100 from prometheus
• Intra-cluster communications: nats-route://6222
• Port 443 for HTTPS is accessible on the Grafana / Prometheus hosts and is User / Password protected
• Grafana cloud connects to the Prometheus instance as a datasource
• Alerts sent from Prometheus host connect to https://alertmanager-us-central1.grafana.net

What is the high-level tech stack for the environment?

• Operating systems: Ubuntu Linux 22.04 LTS
• Cloud Services: AWS, Google Cloud, Azure, Grafana, Tailscale
• Operational software: Grafana, Prometheus, Docker, Harbor, OpenSSH
• Platform dependencies: PostgreSQL
• Platform components: NATS, Synadia Control Plane, Synadia HTTP Gateway

Is it possible to enforce regional data placement for data localization? As an example, for GDPR can it be enforced that data stays in Europe?

Managed Synadia Platform can be built in whichever cloud region the customer wants, subject only to the limitations of what regions are offered by our cloud providers. For multi-region clusters, data localization can be achieved with JetStream placement tags.

Self-hosted

What deployment options are available for self-hosted?

This varies by component, so refer to the components section for more details.

Synadia Server Deprecation

What is Synadia Server and why is it being deprecated?

Synadia Server is a distribution of the NATS server which includes an embedded agent that establishes outbound connections to Control Plane. In addition, it applies some configuration checks to ensure compatibility.

The intention behind providing it was to improve the user experience while setting up Control Plane. However, we heard quite a bit of feedback on the friction of needing to swap out the NATS server with Synadia Server, especially in environments with existing production deployments of NATS. Additionally, having a separate server that lags the NATS release schedule was not ideal.

Control Plane 1.4.0 introduced native support for the NATS server. Synadia Private Link can be used in instances where Control Plane cannot directly connect to NATS Servers.

How do I switch from Synadia Server to NATS Server

Ensure that you follow these steps in-order for a smooth transition:

1. Install Control Plane 1.4.0 or higher

2. Go to the System Settings page in Control Plane and select NATS. Follow the steps to reconfigure your System to either correct to NATS directly or through Synadia Private Link.

3. Replace synadia-server artifacts in your deployment with nats-server artifacts: