Deployment
Run Sentisec hosted at api.sentisec.ch, or inside your own boundary — what each shape gives you, and how to choose.
There are two real decisions. Who runs Sentisec, and — if you do — how isolated it needs to be. Everything else follows.
Start hosted. It is the same software, the same integrity engine, and the same evidence records; moving to your own infrastructure later does not change the API your agents call or the base URL shape they use.
Hosted
The fastest path, and the right default unless a specific requirement rules it out.
Sign up at app.sentisec.ch.
Store a provider key under Settings → Providers, in Provider keys. It travels over HTTPS to the dashboard server, which encrypts it before storage. Credential read endpoints never return the plaintext key.
Mint a workspace API key and point your agent at
https://api.sentisec.ch/ws/<your-workspace-id>.
Nothing to install, nothing to patch, nothing to keep running. Your prompts pass through in flight; what is retained afterwards is a workspace setting, down to metadata-only with no bodies stored at all.
Self-managed
You run the software yourself. Sentisec never sees your traffic, your verdicts, or your evidence records — there is no telemetry channel back to us.
Three shapes, in increasing order of isolation:
| Shape | What it means | Typical driver |
|---|---|---|
| Self-hosted | Your infrastructure, your network egress, your database and object store. | Data residency, procurement policy |
| In-VPC | The same, inside a specific cloud boundary, with provider traffic on private networking rather than the public internet. | Regulated industries — healthcare, financial services, government |
| Disconnected | No dependency on any external service, including for sign-in. Authentication runs against your own identity provider. | Defence, classified environments |
All three run the same components: the API, the dashboard, this documentation, a Postgres database, a cache, and an object store for evidence records. What changes between them is the network posture around it, not the software.
Self-managed deployment comes with an engagement: images, a configuration reference, the deployment runbooks, and a named contact. Request access →
In-VPC deployment
What runs inside your boundary, what has to be reachable from it, and the provisioning checklist to hand your platform team.
Sign-in with no external dependency
Authenticate a self-managed install against your own OIDC provider, with nothing of ours in the sign-in path.
Choosing
| Concern | Hosted | Self-hosted | In-VPC | Disconnected |
|---|---|---|---|---|
| Time to first verdict | minutes | same day | with your platform team | with your platform team |
| Who operates it | Sentisec | you | you | you |
| Where prompts are processed | our region | your infrastructure | your VPC | your facility |
| Provider traffic | public internet | your egress rules | private networking | your controlled egress |
| Key management | managed for you | your secrets store | your KMS | your KMS |
| Sign-in | our managed identity layer | either | either | your provider only |
The row that usually decides it is the third. If your policy says prompts may not leave your boundary, you are self-managed; if it does not, hosted is less work with no loss of capability.
Related
- Quickstart — fastest path on hosted
- Enterprise — SSO, SCIM, roles, exports
- Security — posture and certifications
Updates / contradictions
2026-09-09 — Corrected the earlier browser-encryption claim: provider keys are encrypted server-side after the dashboard receives them over HTTPS.