Secure your application

View Markdown

Use this page to understand the security controls your deployment receives by default and the controls your Team still owns. These controls are not a certification and do not replace security inside your application.

Control access to the platform

Access to the platform is authenticated and scoped to a Team. Built-in roles separate owners, contributors, operators, auditors, viewers, and billing users; roles can be narrowed to a Project or Environment class. Private Net access is granted to a person, so enrolling another device does not require you to repeat every application grant.

Read Manage Team access to invite a coworker and apply these roles and scopes.

Applications remain responsible for their own end-user authentication and authorization. A public route does not inherit console or Team access control.

Isolate workloads

Each Environment has its own Kubernetes namespace. Tenant containers cannot choose or weaken their runtime security context:

stateless components run inside the gVisor userspace-kernel sandbox;
components with durable volumes, or those requesting microvm isolation, run in a Kata Containers microVM;
privilege escalation is disabled, the runtime-default seccomp profile is applied, and Linux capabilities are dropped except for a bounded set needed by the selected runtime; and
service-account tokens are not mounted into ordinary tenant workloads.

Images pushed to the deliberate. registry are scanned for known vulnerabilities. Findings and fixed versions are visible from the image view and through deliberate images vulns. Scanning informs you about known issues; it does not currently block a deployment.

Limit network access

Inbound workload traffic is deny-by-default. The platform permits traffic from the application gateway and creates specific paths for declared component, database, bucket, and Blueprint dependencies. Public outbound traffic is generally permitted, while private address ranges, cloud-metadata addresses, and common abuse ports are blocked.

Outbound SMTP submission on ports 465 and 587 is available on Pro plans. Port 25 remains blocked on every plan. SSH, Telnet, RDP, and SMB egress ports are also blocked by the Environment baseline.

Public platform-generated HTTPS routes use platform-issued TLS certificates and pass through the origin WAF. Private routes require an enrolled device and an explicit Team-member grant, and the device-to-platform tunnel is encrypted with WireGuard. Traffic between Cilium-managed endpoints on different cluster nodes is also transparently encrypted with WireGuard. Same-node traffic does not enter that tunnel; it remains protected by the workload sandbox and network policy boundaries described above. See Web traffic protection for the WAF’s coverage and current custom-domain limitation.

The WAF is only a safety net for common, recognizable attack patterns. Neither WAF coverage nor a Private Net route makes an application secure: your Team still owns application authentication, authorization, validation, patching, rate limiting, abuse controls, and application-specific monitoring.

Protect data and secrets

Tenant durable storage is placed on encrypted storage classes in the deployed platform infrastructure. Protected PostgreSQL and FerretDB backups add client-side archive encryption before the archive reaches encrypted object storage. Secrets use OpenBao as their source of record and are materialized only into the Environment and component that consumes them.

These mechanisms and the differences between database and volume backups are covered in Data protection.

Review Team activity

The Team Activity view records successful resource changes and selected sensitive actions, including secret reveals, database-credential reads, shell and proxy sessions, access changes, and Private Net changes. Denied permission checks are recorded as well. Filter the history in the console or export it through the CLI:

deliberate activity --project my-app --env production
deliberate activity --since 2026-07-01T00:00:00Z --json

Audit events retain the actor, action, time, resource, and selected structured details; secret values and bearer tokens are not included. The current default retention is 365 days. Reads and lists are generally not recorded, audit writes are best-effort, and long-term archival is not currently provided. Treat the Activity view as an operational history, not as an immutable compliance log.

Your responsibilities

Your Team controls application code, dependencies, end-user access, secret contents, route visibility, and who receives platform roles. You also decide whether the documented retention and recovery behavior satisfies your legal and business requirements. Contact deliberate. before relying on a platform default as a formal compliance control.