Skip to content
LayerbaseLayerbase

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. Every claim on this page maps to something running in production right now, and each one comes with the mechanism behind it.

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 onlyOlder TLS versions are not offered, not negotiable, and not a fallback. Cipher suites are restricted to modern AEAD suites.
  • On by default, not opt-inEvery 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 endOur 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 databaseRouting is by TLS server name, so your connection never touches another customer backend.
  • Ordinary public certificatesCertificates 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 tooHSTS 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 customerEvery 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 customerThat container sits on its own private network. There is no shared network segment between customers.
  • Database ports are not routableThey 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 bootFirewall 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 surfaceYou 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 processesDatabase 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 overcommitEach 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 defaultOur administrators can start, stop, and maintain a database without ever being able to read what is in it.
  • You issue the grant, and it expiresReading 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 surfaceNot 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 youEmergency 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 recordedWho 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 addressA 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 kernelRestrict 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 scriptableThe 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 PostgreSQLEach 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 onceWe 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 databaseThe 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 defaultEvery 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 pathIf 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 backupRetention 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-destructiveEvery 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 nightAn 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 serverThey 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 aroundAutomatic 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 deleteOver 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 defaultLive 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 existsOn 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 timeThe 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 usIf 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 dataWhat 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 idempotentIt 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 awayA 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-onlyIt 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 responseStrict 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 productionPassword 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 downSession 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 verifiedVerification 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 themWe 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 edgeStandard 429 and Retry-After responses, with denials recorded.
  • Infrastructure secrets are encrypted at rest in our repositoryThey 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 encryptionThey 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 serverIt 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 imageWe 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 certificatesRenewal 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 continuouslyNot just the host it runs on. Unreachability alerts a human.
  • Alert rules are provisioned as codeThey 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 ourselvesEvery 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 closedIf a database cannot be brought up safely, we drop the connection. We never forward you somewhere else, and archived databases refuse to silently resurrect.

Questions we get asked

Including the ones with an uncomfortable answer

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

Are you SOC 2 certified?

No. We hold no SOC 2, ISO 27001, or HIPAA attestation today, and we would rather tell you that plainly than imply otherwise. We are a young company. What we have instead 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 answered here rather than left for you to discover.

Has an outside firm penetration tested Layerbase?

Not yet. There is no third-party penetration test report to hand you today. Reports from independent researchers are welcome, we read every one, and the controls we do run are described mechanism by mechanism above rather than summarized as a badge.

Is my data encrypted at rest?

In transit, always: TLS 1.3 on every connection, on every plan, with no downgrade path. At rest, the honest scope is narrower. Backups are stored with a separate provider, Cloudflare R2, which encrypts objects at rest. Live database volumes get whatever our infrastructure provider does at the disk layer and nothing beyond it: we add no application-level encryption, we hold no customer-specific keys, and we do not claim zero knowledge. There are no customer-managed keys and no bring-your-own-bucket option today.

Can Layerbase staff read my data?

Not by default. Our administrators can start, stop, and maintain a database without ever being able to read what is in it. Reading your data requires an explicit, time-limited support-access grant that you issue and can revoke at any time, and that gate covers the whole data surface: query console, connection credentials, exports, backup downloads, restores, every import and deploy path, and certificate issuance. Emergency break-glass access exists, requires a written justification, and the reason is surfaced to you rather than only filed internally.

Where is my data hosted, and can I choose a region?

We are US-primary and say so. There is no region selection and no EU-only hosting today. We publish where your data lives, and what we do not offer yet, rather than burying it.

Read the data residency page
Do you offer VPC peering or private connectivity?

No. There is no VPC peering and no private link today. What we do offer for network control is IP allowlisting enforced in the kernel, on every plan including Free, and client-certificate (mTLS) authentication for PostgreSQL on Pro. Database ports are never published on an externally routable address, so the only way in is through our TLS front door.

Read the IP allowlisting guide
Can I get an audit log of activity on my account?

Not as a product you can query today. The audit trail itself is real: every privileged action is recorded with who did it, from where, against what, and under which grant, and break-glass access is surfaced to you directly. But it is internal, and there is no customer-facing audit log to export yet.

Does Layerbase support MFA on my account?

Not at the Layerbase account level. Sign-in is OAuth only in production and delegated to Google or GitHub, so whatever MFA you enforce with that identity provider applies to Layerbase. We do not add a second factor of our own on top of it.

What is your DDoS protection and uptime SLA?

We run no DDoS scrubbing service and publish no uptime SLA document today. What is in place is per-source rate limiting at our HTTPS edge with standard 429 and Retry-After responses, a default-deny firewall on every server, and continuous probing of every customer database so that unreachability alerts a human.

What happens to my data if I delete my account?

Deleting your account is recoverable by default: live resources are torn down and your backups are retained, so support can reinstate you. A real erasure path also exists. You can opt into it at delete time, unchecked by default and behind a second typed confirmation, or ask us for it later at ops@layerbase.com, and on a verified request we remove every retained copy including the last backup. Nobody can bring those back afterward, including us.

Read the account deletion docs
How do I report a vulnerability?

Email ops@layerbase.com. Our machine-readable contact details are published at /.well-known/security.txt. We read every report and will acknowledge yours, and we ask for a reasonable window to ship a fix before public disclosure. 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, and we will credit you if you want the credit.

View our security.txt
Can you answer our security questionnaire?

Yes. Send it over and we will answer it honestly, including the places where the answer is not yet. If any gap on this page is a blocker for your evaluation, tell us and we will tell you exactly where it sits.

Ask us a security question

Still evaluating

Ask us the awkward question

If something here is a blocker for your review, tell us and we will tell you honestly where it sits. Security reports go straight to ops@layerbase.com, and our machine-readable contact details are published in our security.txt.

Ask us a security questionSee plans