Your code
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. Credentials are 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.
Your code lives in an ordinary git repository. You can clone it, mirror it, or take it elsewhere at any time, without asking us.
The technical controls
Isolation
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). Today that is 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. If we add a region, we will say so here before it is available. If residency outside the EU is a requirement, we cannot meet it today.
That guarantee covers your tenant data volume. Platform logging, deploy build output, and the access we use to support you all run on the same infrastructure, in the same region: none of it leaves the EU either.
Because processing happens in the EU, it falls under the GDPR: you are the data controller for what your application processes, and we act as the processor, only on your instructions. See our Privacy Policy for that relationship in full.
Access control
Authentication is by email one-time code, with optional TOTP multi-factor. Sessions are held server-side: the browser never receives a token.
Authorisation is role-based within an organisation: administrator, developer, viewer. Every request carries a verified identity, and resource access is checked against the owning organisation on each call. An unrecognised role is denied rather than defaulted.
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 in AWS Systems Manager Parameter Store as encrypted parameters under a per-tenant path, and injected at deploy time.
Network and traffic
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 is guarded: a safety snapshot is taken and confirmed complete before anything is replaced, the application must be cleanly stopped first, and 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
Single sign-on is not available. It is in development. Today, access is by email one-time code with optional TOTP.
We do not hold SOC 2, ISO 27001 or equivalent certification. We will say so plainly rather than imply otherwise.
We do not have a Data Processing Agreement template ready to sign yet. It is in development. If your organisation needs one in place, email privacy@syntica.io and we will work through it with you directly.
We do not offer an availability SLA. The platform is built for prototyping, validating and proving applications, not for running systems that require high availability. Applications needing that should graduate to a platform built for it, and we help with that move.
We do not perform automated security scanning of the code you deploy. You are responsible for what your agent writes. We are responsible for the platform it runs on.
A deploy can be re-pointed at an earlier commit, so a rollback is a redeployment of the last good build rather than a restore. What we do not have is zero-downtime deploy: any deploy, including that one, briefly interrupts the running application.