Security

Security you can check, not badges you have to trust.

Your databases run in your own isolated container, reachable only over TLS 1.3, with backups we are structurally unable to leave you without. Here is exactly how.

We are a young company. We do not hold a SOC 2 report today. What we do have is a system built by people who have been burned, with the guarantees written into the code rather than into a policy document. Every claim on this page maps to something running in production right now, and the things we do not have are listed at the bottom rather than left for you to discover.

Encryption in transit

There is no unencrypted way in

Every connection to every database is encrypted, on every plan, with no downgrade path and nothing for you to configure.

TLS 1.3 only. Older TLS versions are not offered, not negotiable, and not a fallback. Cipher suites are restricted to modern AEAD suites.
On by default, not opt-in. Every connection string we hand you already has TLS turned on (sslmode=require, or the equivalent for your engine). You do not have to remember to switch it on.
For PostgreSQL, TLS is passed through end to end. Our routing layer speaks the PostgreSQL SSL negotiation and routes by hostname without ever terminating your session encryption. Most managed providers terminate TLS at a shared proxy fleet and re-encrypt behind it. We do not, for Postgres. Other engines terminate at our edge or use a dedicated TLS port, so treat passthrough as a PostgreSQL guarantee rather than a platform-wide one.
One hostname per database. Routing is by TLS server name, so your connection never touches another customer backend.
Ordinary public certificates. Certificates come from Let's Encrypt and validate against your operating system trust store. Nothing to install, nothing to pin.
The dashboard and API are hardened too. HSTS with preload, a strict Content-Security-Policy, frame denial, and no server banner on any response.

Isolation

Your own container, on your own private network

The question a skeptical engineer actually asks is what stops the customer next door from reaching your data. Here is our answer, in detail.

A container per customer. Every customer gets their own dedicated Linux container. Not a shared pool, not a schema inside someone else's database. Your databases live inside your container and nowhere else.
A private network per customer. That container sits on its own private network. There is no shared network segment between customers.
Database ports are not routable. They are published on the machine loopback interface only, never on an externally routable address. The only way in is through our TLS front door.
Kernel-level rules, reasserted on every boot. Firewall rules block container-to-container traffic and block containers from reaching the public listeners, independently of the container runtime's own controls. They are reasserted on boot rather than applied once by hand.
No shell and no code-execution surface. You reach us two ways: your database wire protocol, and our authenticated REST API. There is no exec endpoint, no script upload, and no compute tier. That removes the entire class of "a hostile neighbor runs code next to me" risk, because no customer is running code on our machines in the first place.
Unprivileged engine processes. Database engines run as an unprivileged user inside the container, under the container runtime's default seccomp profile. Where one engine needs an additional syscall, we add that specific syscall rather than disabling the profile.
Hard ceilings instead of overcommit. Each container has hard CPU and memory ceilings, and we stop placing new customers on a server before it runs out of headroom.

Want a whole machine to yourself? Dedicated single-tenant servers run only your databases.

Access control

Our staff cannot read your data by default

Layerbase staff can operate your databases. Reading what is inside them requires a grant you issue, and it expires.

Lifecycle-only by default. Our administrators can start, stop, and maintain a database without ever being able to read what is in it.
You issue the grant, and it expires. Reading your data requires an explicit, time-limited support-access grant that you issue and can revoke at any time.
The gate covers the whole data surface. Not just the obvious one: the query console, connection credentials, exports, backup downloads, restores, every import and deploy path, and certificate issuance. Partial gating is not gating.
Break-glass access is shown to you. Emergency access exists, because sometimes a customer needs help at 2am. It requires a written justification, it is flagged as break-glass, and the reason is surfaced to you rather than only filed internally.
Every privileged action is recorded. Who did it, from where, against what, and under which grant. We built that log after an incident where an action happened and the actor was not recorded anywhere. We would rather tell you that than pretend the log was always there.
We do not log your email address. A lint rule blocks email-shaped values from our logging and audit calls in CI, so the policy is enforced by the build rather than by memory.

Controls you hold

The strongest controls are the ones you turn on yourself

Every control below is self-serve, reversible, and scriptable with the same API key you already use.

IP allowlisting, enforced in the kernel. Restrict a database to specific addresses or CIDR ranges. It is enforced at the network layer on the host, not checked in application code, and changes take effect within seconds. Available on every plan, including Free. Read the guide.
Fully scriptable. The allowlist is managed with the same API key you query with, including an endpoint that tells you your own egress address, so dynamic-IP and serverless platforms can self-register.
Client certificate (mTLS) authentication for PostgreSQL. Each database gets its own certificate authority, so a certificate issued for one database is worthless against any other. The certificate stacks on top of the password, so neither credential alone gets in. Private keys are generated inside your container and returned once; we never store them. Rotating the CA instantly invalidates every certificate previously issued. PostgreSQL, on Pro. Read the guide.
API keys are hashed at rest and shown once. We keep a hash and a short prefix for display. If you lose a key you rotate it, because we genuinely cannot recover it.
Keys can be scoped to a single database. The scope is enforced at the API boundary: a database-scoped key that reaches for anything else gets a 403. Revoke is instant, and rotate mints a replacement with the same name and scope while killing the old secret in the same operation.
Strong credentials by default. Every database gets its own 24-character password generated from a cryptographic source with rejection sampling, so there is no bias in the output and no shared or derived credentials between databases.

Durability

We are structurally unable to leave you without a copy

For every database, at least one backup always exists. That is enforced in code, not in policy.

Backup before delete, on every destructive path. If we cannot secure a final backup first, the deletion is refused and nothing is torn down. Not logged and continued: refused.
We never prune your last backup. Retention windows, plan limits, and cleanup jobs all skip the most recent copy unconditionally. Exactly one thing can remove it: an explicit, verified erasure request from you.
Restores are checksum-verified and non-destructive. Every backup records a SHA-256 at write time and we re-verify it on the way back down, so a corrupt backup can never silently overwrite good data. We also do not drop your database and hope the restore lands.
We re-prove restore every night. An automated drill round-trips real databases across nine engines end to end (create, write, back up, ship offsite, destroy, restore, verify) against our staging environment, on live connection poolers. We have also run full disaster-recovery wargames: the last one recovered every tracer row across three engines with zero manual intervention, end to end in about 55 seconds.
Backups live off the server. They are stored with a separate provider, Cloudflare R2, so losing a machine does not lose your data. R2 encrypts objects at rest.
Cadence and retention you can plan around. Automatic backups run every 12 hours per database on paid plans, with 7-day rolling retention on Solo and 30-day on Pro, plus manual backup slots on every plan, including Free.
When you hit a limit, we lock, we do not delete. Over a storage quota, your database goes read-only and stays fully readable. Downgrade past your plan limits and databases are frozen with data intact, still downloadable. Free databases that go idle are archived after 14 days and have their live resources reclaimed after 90 days archived, and the most recent backup is kept and restorable in one click throughout. How the lifecycle works.

Deletion and privacy

Recoverable by default, erasable on request

Deletion is one of the few places where the safe default and the private default disagree. We picked recoverable, and we tell you which is which.

Deleting your account is recoverable by default. Live resources are torn down and your backups are retained, so support can reinstate you. We would rather answer an email than tell you your data is gone.
A real erasure path exists. On a verified request we remove every retained copy, including the last backup. It is the only thing in the system that can remove a last backup, and it requires explicit confirmation.
You can choose that erasure yourself, at delete time. The delete dialog carries an opt-in, unchecked by default and gated behind a second typed confirmation on top of typing your email, that runs the erasure path instead of the recoverable one. Choosing it removes every backup we hold for you, including the last copy, rather than retaining them. Nobody can bring those back afterward, including us.
Retained backups can be erased later, by asking us. If your account was already deleted the recoverable way and you now want the retained copies gone, email ops@layerbase.com and we will run the full erasure once we have verified the request. It is deliberately a verified, human-confirmed path rather than an automatic one, because it is the one action nothing else in the system can undo.
Even our deletion records hold no plaintext personal data. What survives an account purge is a pseudonymous identifier and a salted hash of the email address, never the address itself.
Deletion is server-side and idempotent. It completes whether or not you keep the tab open, and re-running it is safe. Billing is revoked first and independently, so a failure downstream cannot leave you paying for something we tore down.
Throwaway databases are genuinely thrown away. A database created with a time-to-live is destroyed at expiry with no retained backup, because that is what you asked for.

We publish where your data lives, and what we do not offer yet, on our data residency page rather than burying it. The mechanics of closing an account are in the account deletion docs.

Application security

The control plane is defended as carefully as the databases

Most breaches do not start at the database. They start at the dashboard, the webhook, or the token nobody rotated.

Our Content-Security-Policy is enforcing in production, not report-only. It carries no unsafe-eval. We removed the one place in our own product that needed dynamic evaluation specifically so we could keep it out of the policy. Violations are reported back to us and streamed into our logging pipeline, so we find out when something breaks the rules rather than hoping nobody notices.
A full security header set on every response. Strict transport security with preload, frame protection, no content-type sniffing, a restrictive permissions policy, and a tightened referrer policy on the OAuth callback so your identity provider never rides through a redirect.
Sign-in is OAuth only in production. Password login is structurally impossible outside development and pre-production, gated by a tested function with no environment variable that can switch it on.
Sessions are locked down. Session cookies are host-locked, HTTP-only, secure-prefixed, and same-site restricted, and OAuth flows use PKCE, state, and nonce, each with its own short-lived cookie.
Every webhook we accept is cryptographically verified. Verification runs against the raw request body, and the routes fail to start rather than run unverified if a signing secret is missing.
Webhook destinations you supply are checked before we call them. We resolve every DNS answer immediately before the request and block internal address ranges, private ranges, and cloud metadata endpoints. It fails closed.
Per-source rate limiting at our HTTPS edge. Standard 429 and Retry-After responses, with denials recorded.
Infrastructure secrets are encrypted at rest in our repository. They are asymmetrically encrypted and decrypted only on the target machine at deploy time. No plaintext secret has ever been committed.
Integration tokens we hold for you are encrypted with authenticated encryption. They are decrypted only at the moment of use, never logged, and never readable back through any API path. One integration stores no durable token at all.

How we run it

The unglamorous work is where incidents actually come from

So we automate it, and then we watch the automation. Several of the controls below exist because something failed on us first.

Default-deny firewall on every server. It is asserted in our image build pipeline rather than trusted, and administrative access is key-based with automated brute-force banning.
Every server is built from a verified, content-addressed image. We provision a throwaway canary from each new image and assert its state before that image is ever used for a customer.
We monitor our own certificates. Renewal is automated with a reconciler, and a separate watchdog pages a human 21 days before any certificate expires. We built that watchdog because automated renewal without a watcher failed us once, silently. We also prove the renewal path works before a customer certificate ever needs renewing, with a scheduled dry run against the certificate authority's staging environment on every newly provisioned machine.
We probe every customer database continuously. Not just the host it runs on. Unreachability alerts a human.
Alert rules are provisioned as code. They include detection of destructive-operation bursts and abnormal signup waves, and alerts fan out to two independent channels so one broken integration cannot silence us. Backup health is checked fleet-wide on a schedule and alerts on any unhealthy verdict.
We build the database binaries ourselves. Every engine we offer is built from source or repackaged by us and served from infrastructure we control. We never pull a database binary from a third party at runtime.
We fail closed. If a database cannot be brought up safely, we drop the connection. We never forward you somewhere else, and archived databases refuse to silently resurrect.

What we do not have yet

Here is the list, from us, before you have to ask

Every page like this one lists wins. This is the other half, and it is the reason you can believe the rest.

No SOC 2, ISO 27001, or HIPAA attestation today.
No third-party penetration test yet.
No encryption of live database volumes at rest beyond what our infrastructure provider does. Backups sit in storage that encrypts objects at rest, but we hold no customer-specific keys and we do not claim zero knowledge.
No customer-managed keys and no bring-your-own-bucket.
No VPC peering or private connectivity.
No customer-facing audit log product. The audit trail is real, and it is internal.
No account-level MFA on Layerbase itself. Sign-in is delegated to Google or GitHub, so whatever MFA you enforce there applies.
No region selection and no EU-only hosting. We are US-primary and say so.
No DDoS scrubbing service and no uptime SLA document.

If any of these is a blocker for your evaluation, tell us. We will tell you honestly where it sits.

Reporting a vulnerability

Found something? Tell us directly.

Email ops@layerbase.com. Our machine-readable contact details are published at /.well-known/security.txt.

We read every report and will acknowledge yours. Please give us a reasonable window to ship a fix before disclosing publicly.
While testing, do not access, modify, or delete data that is not yours, and do not run anything that degrades service for other customers.
We do not run a paid bounty program today. We will credit you if you want the credit.

See plans Ask us a security question