Security

Workload isolation

Every project runs in its own Kubernetes namespace, and every application container runs under gVisor (runsc) — a user-space kernel between your code and the host. A process that escapes its container still talks to gVisor, not to the machine your neighbours run on.

The network is fenced the same way: a cluster-wide policy (Cilium) lets tenant workloads talk only to DNS and the public internet on ports 80/443. Private address space is unreachable — one customer's application cannot connect to another's, or to the platform's internals — and outbound port 25 is closed, so the platform cannot be used to send spam.

Build and image safety

Applications are built from your source in isolated build jobs and pushed to a private registry that only the platform can reach. Every pushed image is automatically scanned for known vulnerabilities (Trivy) on arrival.

Transport encryption

• All traffic is HTTPS. Plain HTTP is answered only with a redirect (and the certificate-issuance challenge).
• Platform hosts send HTTP Strict Transport Security, subdomains included.
• Custom domains get their own Let's Encrypt certificate, issued and renewed automatically.
• A custom domain is served only after you prove you own it with a DNS TXT record — nobody can point our edge at a domain that is not theirs.

Secrets

• Environment variable values are encrypted at rest (AES-256-GCM) before they are written to the database. The key lives in a secrets manager (OpenBao), not next to the data.
• Each encrypted value is cryptographically bound to its own project and key name — a copied database row cannot be replayed into another project.
• The platform's own credentials (database, registry, mail) come from the secrets manager too, not from files in the repository.

Accounts and access

• Passwords are stored and verified by the identity service (Keycloak). They are never written to the platform database.
• Team roles (owner, admin, member, viewer) are enforced on the server for every API call — not just hidden in the interface.
• Access tokens are stored as SHA-256 hashes; the platform cannot show you a token twice. Revocation takes effect on the next request, and a token's rights follow your live team role — leave a team and its tokens stop working there.
• Sign-in and registration endpoints are rate-limited per source address. Your application's own traffic is never rate-limited by us.

Payments

Card payments are processed by the bank's 3D Secure virtual POS. Card numbers never reach our servers — we store only the bank's payment reference and the last four digits, so your invoice can say which card was charged.

Your data

• Customer applications and data run in Türkiye (İstanbul), on infrastructure operated by NESNET.
• Managed databases are backed up nightly; each plan states how many backups are kept.
• Deleting a database-backed addon never drops the data at the moment of the click — the database is first fenced off and kept as a tombstone, so a mistaken deletion is recoverable.
• You can export everything the platform holds about your account as a single archive, and you can close the account yourself. Both are in the console and the CLI, documented on the account page.

Sub-processors

Parties that touch customer data as part of running the service:

• NESNET (Türkiye) — hosting and network infrastructure.
• GitHub — only if you connect a repository: source checkout and webhook delivery.
• Let's Encrypt — certificate issuance; sees domain names only.
• E-mail relay — delivery of transactional mail (notifications, invitations).

Reporting a vulnerability

Write to nesly@nesly.net. We read every report and reply; if you wish, we credit you when the fix ships. Machine-readable details are at /.well-known/security.txt (RFC 9116). There is no bug bounty programme today — we say so rather than imply one.

What we do not claim

A security page you can trust also says what is not there yet:

• No SOC 2 or ISO 27001 certification yet.
• One region. If the İstanbul site is down, the platform is down — there is no second region to fail over to.
• Two-factor authentication is not yet enforceable per team; it depends on the identity service's policy.