Security overview

Last updated 7 October 2026. Source: sheptra.core/docs/decision_records/hosting.md §1, §5, §6, §9, §12, §14 · sheptra.core/authentication.md · sheptra.vantage/src/pages/docs/support-access.md

How Sheptra is built and run, written from the engine’s own hosting record and restated for a security review. Everything on this page is what the estate does today or is marked as planned; where this page and the estate disagree, the page is the bug and we want to hear about it.

Sheptra is pre-launch. The estate described here is the staging environment — the one every beta workspace will run on. Production is the same topology under a reviewer gate and the apex hostnames, and has not been provisioned yet. Where a control exists in code but is not yet switched on, this page says so.

What Sheptra is#

Sheptra is a service we operate, never a download: a managed BPMN engine (Greyson), a browser-based modeler, and an operations console. There is no self-managed or on-premises edition. Your process definitions, running instances and their history live in our estate; your workers — the code that does the work — stay in your own services and reach the engine over HTTPS with credentials your organization issues.

The unit of deployment is a cell: one managed Postgres server, one engine service, one scheduler, one hostname. Today there is one shared cell, and every beta workspace runs on it. A dedicated cell is the same unit provisioned for one customer — see Tenant isolation below for what exists and what is planned.

Who hosts it#

Compute, the databases and the container registry are on DigitalOcean (App Platform, Managed PostgreSQL 17). Cloudflare is the edge for every host — DNS, TLS and DDoS protection — and hosts the Drive and Modeler applications, the execution-history archive, and the notify list. WorkOS is identity. Grafana Cloud is telemetry. The marketing site you are reading is on Vercel. Each one is on the sub-processor list with what it handles and where; the regions are on data residency.

Every piece of that infrastructure is Terraform in a repository, planned on every pull request and applied on merge through a reviewed pipeline. Nothing is configured by hand in a dashboard, and the exceptions (a provider that insists on a click) are listed as such in that repository.

Identity and access#

Sign-in is WorkOS AuthKit. Your organization brings its own identity provider through SSO (SAML or OIDC) and can keep membership in step with your directory through SCIM; both are WorkOS features, available on the plans that include them. Members hold roles your administrators assign, and every operator action on the API is guarded by a named permission rather than a role — deploying a definition, starting an instance, cancelling one, resolving an incident and completing another person’s task are each a separate grant.

Workers do not share human credentials. Each worker credential is an OAuth 2.0 client-credentials application that belongs to your organization; the worker exchanges it for a one-hour signed token that the engine verifies offline against the identity provider’s published keys. The engine only ever verifies tokens — it holds no key that could mint one. A token always names its organization, and a request without one is refused before it reaches any data.

Tenant isolation#

The organization is the security boundary. On the shared cell every organization-scoped table carries the organization’s id and is protected by Postgres row-level security: the policy reads the organization from the session, the application role cannot bypass it, and the scheduler’s cross-organization sweeps run under a second role admitted by its own policies. No database role holds the attribute that would let it skip the policy.

That is a candid answer rather than a complete one. Row-level security defends against a forgotten predicate in our own code, which is the realistic failure in a growing codebase. It does not defend against a compromised application process, because that process is what sets the session the policy reads. The answer to that question is a dedicated cell, and the ladder is:

Encryption#

At rest: every managed Postgres cluster’s disk and backups, the container registry and the archive bucket are encrypted with the provider’s keys. In transit: TLS everywhere — Cloudflare terminates the certificate you see, the platform issues one per host behind it, and the database connection is TLS by requirement, not by default.

There is no per-customer key on this host and we do not sell one. Customer-managed keys and private connectivity are what rung 4 is for, where your own cloud account holds both; we would rather say that plainly than approximate it with a key that lives in our account.

Network#

Cloudflare’s proxy is the only way in, for people and for worker fleets alike: there is no separate worker network path. Behind it, each cell’s database admits exactly one source — that cell’s own application — on its firewall, and a dedicated cell’s database cannot be reached by the shared cell’s application by construction, because they are different servers with different firewalls. Nobody has standing database access from a laptop; the deployment pipeline is admitted for the length of a role bootstrap and removed again.

Two things this platform does not give, stated as-is for a questionnaire: there is no private network between the application and its database (it is TLS on a hostname, admitted by source), and there is no egress allow-list. There is also no WAF ruleset written yet — Cloudflare’s DDoS protection and TLS are on every host, and a ruleset is added when a review asks for a specific one.

Secrets#

Every credential follows one path: a secret on the deployment pipeline, into a sensitive Terraform variable, into a platform-managed secret on the one component that needs it. The engine service holds only its own database role and the control-plane key; the identity provider’s API key exists on the management host alone; the archive writer holds a token scoped to one bucket. Rotation is a pipeline run, never a dashboard edit, and no applying credential exists on a laptop. Provider-generated secrets are never typed anywhere by a person.

Who at Sheptra can see your data#

Our fleet console shows Sheptra’s own data about the fleet — which cell an organization is on, its plan, its environments, its administrative trail. It does not show your runtime data, and an operator’s own session cannot read your rows.

Looking inside your organization is an impersonated session, and only with a named administrator’s written agreement, as the least-privileged user who can see the problem. The session is visible to you three ways: the token names the impersonator, every audit row written during it names the impersonator beside the user, and the console shows a banner for the whole session. Two actions are refused outright while impersonating — creating an API credential and changing a member’s role — so a support session cannot mint anything that outlives it. Where impersonation is not available, the fallback is a time-boxed membership your administrator grants and the trail records.

Audit trails#

Three trails, all append-only by database grant — the retention sweep cannot touch them and neither can an operator: what operators did to running instances (cancel, modify, resolve, assign, every variable write with before and after), administrative changes to your organization (members, roles, credentials, environments), and changes to modeler content. Each row names its actor, and an impersonated actor is named as such. The trails are readable from Drive and over the API, and they survive offboarding, because your record of what Sheptra did to you is part of them.

Backups and recovery#

Every cell’s database has daily backups and a seven-day point-in-time window, with nothing to configure. A restore is a fork — the platform rebuilds the cluster at the second we name, and the cell is re-pointed at it — so the original is never rewound in place. The restore drill is scripted to run quarterly and append its measured recovery time to a record; until its first row exists, RPO and RTO are unmeasured, and we will publish them from the drill’s rows rather than promise them from this page.

Change management#

Every change to the service is a pull request. Infrastructure is planned on the PR and applied on merge; engine images are built by CI only from a green main branch, pinned by digest, and deployed by a commit that the same pipeline applies. Database migrations run as a pre-deploy job that blocks the rollout if it fails. The engine’s images are built on a minimal (chiseled) base. A fleet rollout verifies each cell after moving it and reverts the images in the same run if the checks go red. Software bills of materials and image signing are planned and not yet in the pipeline.

Monitoring and incidents#

Every component pushes traces, logs and metrics to one telemetry stack; each alert rule has a runbook. How detection, response and customer notice work — and what is not yet switched on — is its own page: incident response.

What is not in place yet#

So a questionnaire gets the same answer we would give in a call:

• SOC 2 Type II — planned; no audit has started.
• Independent penetration test — planned; none has been commissioned.
• Data processing agreement — a draft exists and is with counsel; the sub-processor list is published.
• Dedicated cells (isolation rungs 2 and up) — the first is being provisioned.
• WAF ruleset, egress allow-list, private database path — not on this host; see Network.
• Status page and uptime SLA — none in the beta; enterprise uptime terms are agreed per contract.
• Measured RPO and RTO — pending the first restore drill.
• SBOM and image signing — planned.

Asking us more#

Send a questionnaire or a question to contact@sheptracloud.com. We answer from the same records this page is written from, and if the honest answer is “not yet”, that is the answer you will get.