Security, in plain English.

The short version

• Your code runs in its own virtual machine, with its own kernel. It never shares one with another customer.
• Everything is private until you say otherwise. Databases are not on the internet, and services cannot talk to each other unless you connect them.
• Secrets are write-only. Once set, nobody can read them back: not you, not your AI, not us.
• We check your builds for leaked keys and stop a deploy that would put one in front of your visitors.
• Risky changes need a person. Agents cannot delete databases, expose data or raise spending without a human approving with a passkey.
• Your data stays in London, backed up to a second UK provider and restore-tested every day.

Your own virtual machine

Most platforms run customers' code in containers that share the same operating system kernel. A flaw in that kernel can let one customer reach another. Guv runs every service, and every build, inside a lightweight virtual machine (a microVM) with its own kernel, using hardware virtualisation. To reach another customer, an attacker would first need to break out of the virtual machine itself, a far harder and rarer kind of flaw.

On top of that:

• No service can run in privileged mode or reach the host's files.
• System calls are filtered, and the hosts are watched for unusual behaviour.
• Flaws that could allow an escape are patched within 72 hours.
• Each service has hard limits on CPU, memory, disk and network, so a noisy neighbour cannot slow you down.
• Customers with special-category data, such as health and care records, can run on hosts that run nobody else's code.

Private by default

Every environment has its own private network that refuses all traffic unless you allow it. Traffic between our machines is encrypted. Your services cannot reach Guv's own internal systems at all, and every one of those internal systems requires authentication anyway, even on the private network. That second lock matters: a well-known bank breach started with an app being tricked into calling an internal service that trusted it.

Databases are never reachable from the internet unless you explicitly make them so, and doing that needs a human approval and an IP allowlist. Outbound email on port 25 is blocked to protect everyone from spam.

Secrets you cannot leak by accident

A surprising number of breaches start with a key copied somewhere it should not be. Guv closes the usual routes:

• Write-only. Secrets are encrypted the moment they arrive and can never be read back through the dashboard, CLI or API.
• Scanned on every build. We look for keys in your repository, its history and, crucially, the code your app sends to browsers. A secret found there blocks the deploy.
• Redacted in logs. Values that look like secrets are masked before logs are stored.
• Recognisable tokens. Guv's own tokens have distinctive prefixes registered with secret scanners, so a leaked one is spotted and can be revoked quickly.
• Destroyed on deletion. When you delete your account, the keys that encrypt your data are destroyed, so any copies left on disk are unreadable.

Builds and supply chain

Your builds run in a throwaway virtual machine with no access to the host, using a builder that runs without root privileges. Each project has its own build cache, so nothing leaks from one customer's build to another's. Images are scanned and pinned by their exact fingerprint.

For our own code we use locked dependencies with a cooling-off period before new versions are adopted, pin the tools our pipelines use to exact versions, sign our commits, and never keep long-lived credentials in our build system. Policies and code that drive our AI operations are reviewed by two parties and signed before they can run.

Your account

• Passkeys. Sign-in uses passkeys, which cannot be phished the way passwords can. Every member of every workspace must have one. We do not offer SMS codes.
• Step-up checks. Viewing sensitive settings, deleting things and changing domains ask for your passkey again.
• You can see your sessions and sign out any device, and you are told about new sign-ins.
• Recovery needs proof. Account recovery needs a passkey or a recovery code. It is never handled by an AI on the strength of a convincing email.

AI agents, with guardrails

Guv is designed to be operated by AI, both your coding agents and our own operations team. That only works if the AI cannot do serious harm when it gets something wrong, or when someone tries to trick it.

• Agent tokens have limits: which projects and environments they can touch, what they can do, and how much they can add to your bill each day.
• Some actions always need a person, whatever the token says: deleting a database or volume, restoring over production, turning off backups, exposing a database, raising a spend cap.
• Approvals never hand over credentials. You approve on your phone with a passkey; the agent only learns the outcome.
• Untrusted content is labelled. Logs and web content passed to AI tools are marked as data, not instructions, to resist prompt injection.
• Our own AI has an off switch. A person can pause all automated operations instantly. Your apps keep serving while it is paused.
• No back door. There is no tool, for staff or AI, that simply shows customer data. Exceptional access is logged and visible to you.

Domains and phishing

Generated app addresses live on their own registrable domain, listed on the Public Suffix List, so a malicious app cannot set cookies for anyone else's. We watch for sites impersonating well-known UK brands such as banks, HMRC, the NHS and Royal Mail, and take confirmed phishing down within an hour.

Custom domains need proof of ownership, and a domain verified by one account can never be claimed by another, which prevents subdomain takeovers. Certificates are monitored in public transparency logs, and our own domains are locked at the registrar and the registry.

Backups and recovery

Every database is backed up from the moment it is created, with point-in-time recovery. Backups are encrypted with a key unique to each customer and stored with a separate UK provider under object lock, so they cannot be altered or deleted early, even by us. Restores are tested automatically every day.

Your apps are also designed to keep serving if Guv's control plane, or its AI, has a problem. Deploys and changes wait; traffic does not.

Keeping bad actors out

Free hosting attracts crypto-miners, spammers and phishers, which harms every legitimate customer. Guv needs a card to sign up and checks for fraud at the door. We watch for mining, scanning and spam patterns, and act on reports quickly. Decisions that affect you as a person, such as suspending an account, are always reviewed by a human if you ask, and you are told why.

How we look for problems

Security is a routine, not a project. This is what runs, and how often:

When something goes wrong

We plan for incidents before they happen, and rehearse the plan every quarter.

1. 1
   Detect. Monitoring or a customer report opens an incident with a severity.
2. 2
   Contain. Pre-approved actions: isolate the project, revoke tokens, rotate credentials, block traffic, freeze deploys.
3. 3
   Escalate. A person is paged at once for any confirmed breach, escape or key compromise.
4. 4
   Preserve. Evidence is captured to write-once storage, with a chain-of-custody record.
5. 5
   Notify. Affected customers without undue delay, within our 24 to 48 hour target. The ICO within 72 hours where we are the controller.
6. 6
   Learn. A blameless write-up, published. New detection, new runbook, new test.

Risks we accept, honestly

No platform is perfectly safe. These are the risks we know about and have chosen to manage rather than eliminate:

• Flaws in the virtualisation layer itself. Rare and valuable to attackers. We patch fast and offer dedicated hosts for sensitive data.
• Someone with full control of a physical host could, in principle, see data while it is being processed. Confidential computing will close this gap when it is mature enough.
• One London site. The UK has no multi-zone cloud regions of the kind found elsewhere. Backups are off-site and rebuilds are rehearsed, but losing the site would mean hours of downtime.
• A small team. We keep a contracted backup engineer, a documented succession plan, and break-glass instructions held by our solicitor.

Reporting a vulnerability

If you think you have found a security problem in Guv, please email security@guv.dev. Tell us what you found and how to reproduce it. We will acknowledge you quickly, keep you updated, and credit you if you would like. Please do not access other customers' data or disrupt the service while testing. Our contact details are also published in /.well-known/security.txt.

We aim to acknowledge every report within two working days and to give you our first assessment within five. If you act in good faith and within these rules, we will not pursue or support legal action against you for your research.

Looking for where data is stored, who processes it and our data protection terms? See Trust and data location.