Overview
Start here
Getting started
Concepts
Team & ownership
Deployment regions
Security model
Your code and dataIsolation and regionsAccess controlSecretsNetwork and trafficOutside verificationBackups and recoveryLeaving
Guides
Code quality
Custom domains
Connecting a coding agent ↗Resources
Release notes ↗System status ↗Security & governance ↗Concept · Security
Security model
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.
Your code and data
We do not read your source code, and we never train models on it.
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.
Isolation and regions
Every application environment runs on its own dedicated instance. Not a shared runtime, not a multi-tenant process. Development, staging and production are separate instances with separate data.
Tenant secrets are namespaced per organisation and application. Node-to-platform communication runs over a mutually authenticated TLS tunnel, with the node's identity encoded in its client certificate. A connection presenting an identity outside that structure is closed.
Everything runs in eu-central-1 (Frankfurt), the only region we operate, so your data stays in the EU. There is no setting that moves it and no region to get wrong. Platform logging, build output and support access run on the same infrastructure, so none of that leaves the EU either. If residency outside the EU is a requirement, we cannot meet it today.
Processing in the EU falls under the GDPR: you are the data controller for what your application processes, and we act as the processor, only on your instructions.
Access control
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 role-based within an organisation (administrator, developer, viewer): every request carries a verified identity, resource access is checked against the owning organisation on each call, and an unrecognised role is denied rather than defaulted. The roles are described in team and ownership.
Secrets and configuration
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.
Network and traffic
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.
Outside verification
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.
Data protection and recovery
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:
A safety snapshot is taken and confirmed complete before anything is replaced.
The application must be cleanly stopped first.
A failed volume swap rolls back to the original.
Leaving
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.
What we do not do yet
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.
We use cookies
We use essential cookies to run the site and optional ones to understand usage. See our Privacy Policy.