Security at deployshed

What we hold, how to check it, and how to cut us off. Updated 2 November 2026.

We prefer not to hold your keys

A connection to your AWS, Google Cloud, Azure, Vault or MinIO stores no password, key or token. You set up a trust in your own account; deployshed signs a short-lived token for your organization alone, and your account accepts only that.

GitHub, GitLab and Bitbucket connect through an app or OAuth you authorize, so nobody pastes a personal token.

You can check this. In the console, Settings → Stored keys lists every connection your organization made, how deployshed signs in, what it keeps, and how to revoke it. Anyone in your organization can read it.

You can cut us off yourself

• Your cloud: delete the role or trust in your own account. Nothing here can stop you.
• Your cluster: apps can run in a Kubernetes cluster you run, through an agent that connects out. deployshed holds no credential for it, and you can read the agent's role in your cluster. Delete the agent and access ends.
• Your git host: uninstall the app or revoke the authorization there.

Apps are kept apart

• Each app has its own namespace, with a network policy that admits only the gateway, and the apps you allowed to call it.
• Apps on our cluster run under gVisor, a separate user-space kernel per pod.
• Apps cannot reach our internal services or private networks.
• Each organization's images are in a private registry project of its own.
• Builds run rootless, with no cluster credential.

Who can open an app

• By default, only people signed in to your organization. Narrow it to named people, or give an outsider a guest link that expires.
• Sign-in with a password and two-factor, Google, GitHub, or on Enterprise your own identity provider, with SCIM and IP allowlists.
• The audit log records who changed what. On Enterprise, export it as CSV or JSON Lines.

What is checked before it ships

• Every build is scanned for leaked secrets, risky code and vulnerable packages (Gitleaks, Semgrep, Trivy), and its package list (SBOM) is kept for download. You choose whether findings warn or stop a deploy.
• A secret key in a variable a frontend build would publish is refused, when saved and again when built.
• Supabase tables anyone can read are found after each build.

When we do store something

Secret values you enter are encrypted before they reach our database. Values in your own Vault or cloud secret store stay there. Database backups are encrypted before leaving our servers.

Where your data is

On our servers in Bengaluru, India, with encrypted nightly backups held off-site. We use Razorpay (payments), Brevo (email), Cloudflare (DNS and encrypted backups), Google Cloud (the network edge traffic passes through), and Google or your identity provider when you sign in with them. See the privacy policy.

What we do not claim

deployshed is in invite-only beta. It has no SOC 2 or ISO 27001 certification, and it runs in one location, with no promise of uptime. See the status page. If you need any of those, ask us before you depend on it.

Found a problem?

Tell us at support@deployshed.com. We read every report, and will not take action against anyone reporting in good faith.