Security and governance

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.

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.

What your coding agent may do on your behalf is governed separately. Actions that can destroy data, take an application down, or change who can reach the code default to requiring a token carrying the administrator role, unless your organisation sets a different rule. The check fails closed if it cannot be evaluated. An agent can read that policy but never change it — only a person, from the dashboard, can loosen or tighten it.

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.

An application is only useful once it can reach the systems the work actually lives in: a mailbox, SharePoint, Teams, Stripe, an SAP OData service. The usual answer is a credential pasted into a repository by whoever had it to hand. That works until the person who pasted it leaves, the key expires, or the client asks who can see it and nobody knows.

This platform has one control for that instead. An administrator registers the organisation's credentials once, against connectors we author and maintain. From then on every use of them is requested, decided and recorded, and a grant can be revoked at any time without breaking anything else.

Trust in agent-written code should not rest on our word. Syntica runs ordinary code, so the analysis tools your organisation already trusts can judge it. Connect the SonarQube you run yourself, or SonarQube Cloud's free tier, and every deploy can be followed by a scan on your own server, judged by your own quality gate. You bring the subscription, and the verdict is produced by your infrastructure, not ours.

The platform is read-only against your server, the token you provide is encrypted and can never be read back out, and a scan never builds or executes the repository. No AI touches your code or findings on our side. The full mechanics are in the code quality guide.

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.

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.

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.

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.

• 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 info@syntica.io and we will work through it with you directly.

• We do not offer an availability SLA. Today the platform is built for building, validating and proving applications. Running applications at larger scale is on our roadmap.

• We do not scan or review your code ourselves. You can connect your own SonarQube and gate production on its verdict, but the analysis runs on your subscription, and responsibility for what your agent writes stays with you. 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.