Concept · Security

How the platform protects your work, control by control. Written for whoever reviews a new platform before their client or company is allowed near it: what holds today, stated plainly, including what we do not do yet.

What we collect is platform telemetry, usage patterns, and the shape of an application: which base images, how many services, whether a database is present. Never its contents. Build and deployment output is captured for support and kept for seven days, with credentials scrubbed from git error output. Reading a customer's repository happens only with explicit, specific, written consent, for a named purpose. It is not covered by acceptance of our terms.

Authentication is by email one-time code, with optional TOTP multi-factor. Sessions are held server-side and the browser never receives a token. Authorisation is per app and per environment. Each person holds a role on an app and an environment, for example Developer on dev and Viewer on production, given directly or through a group. Every request carries a verified identity and is checked on each call. An app someone has no access to is invisible to them, and if the check cannot be made, the answer is no. Roles and groups are described in team and ownership.

Actions an agent takes on your behalf carry a second check on top of that role. A per-organisation policy covers the application-level actions that destroy data, cause downtime or change where an application's code comes from. These are deleting an application or its configuration, running write queries, stopping, restarting, replacing or resizing a machine, and pointing an application at a different repository. By default, in every environment, those proceed only when the agent is acting for someone with the "approve dangerous agent actions" permission on that environment, until someone who manages policies loosens that. It fails closed. If the policy cannot be read, the action is refused rather than allowed. An agent can read the policy but never change it. Account-level actions such as inviting members are governed by organisation permissions rather than by this policy.

Secrets are write-only through the API. Once stored, no interface (web, agent or API) returns the value. In production they are held as encrypted parameters in a managed parameter store under a per-tenant path, and injected at deploy time. They never enter the repository or its history.

That is the route for an application’s own configuration. For a credential to somebody else’s system (a mailbox, Stripe, Slack, a database, an AI provider) the route is a connector, and the difference matters for anyone reviewing what an agent can reach.

An organisation administrator grants a connection to one application in one environment. The platform injects it at deploy time as environment variables, and a grant in development does not imply one in production. What a developer or an agent can read is the names of those variables and nothing else. The describe call is defined never to return a credential, so code is written against the variable the platform will set rather than against a value anybody has seen.

An agent that needs a system it has not been granted cannot be handed a key to get on with it. It asks. The request names a connector and a reason, the administrator decides which of their connections satisfies it, and the agent proceeds only once that is granted. So an API token for a third-party service is never pasted into a chat, a repository or an agent’s context, and the person who owns the credential stays the person who decides where it goes.

Public traffic terminates at a TLS-terminating ingress layer with managed certificates. Per-application controls include request rate limits, per-IP limits, IP allow-lists, request body size limits and maintenance mode. Outbound traffic from tenant applications is metered.

Syntica runs ordinary code, so the industry's standard analysis tools can judge it. Connect your own SonarQube and every deploy can be followed by a scan on your server, with an optional quality gate on production. The whole mechanism has its own page: code quality with your own SonarQube.

Tenant data volumes are backed up by snapshot on a schedule determined by the application's tier, with retention per tier. Restore is deliberately destructive and in-place, and it is guarded:

There is no exit process to negotiate. Your application is ordinary code with an ordinary compose file: clone it and take it anywhere, without asking us. A packaged handover, with a secrets manifest and a runbook, is in development.

The honest list (no SSO yet, no SOC 2 or ISO 27001 certification, no availability SLA, no zero-downtime deploys) lives on the security and governance page and is kept current there.