Security and trust

The short version

• Your application runtime and the resources created for it live in the cloud account you connect. The Deployer runs a control plane that analyzes repositories and coordinates deployments.
• Connections currently use long-lived keys or tokens that you create at your provider. We recommend a dedicated cloud account or project for The Deployer, so its access cannot reach unrelated production resources.
• Provider credentials are used by the deployment engine and are not placed in AI prompts. The project copilot can run commands on your app server when you use it; see section 2.
• Stored credentials are encrypted before storage. Viewing or replacing one needs your account password.
• No service can promise that a breach or software defect is impossible. We publish our limits so you can decide what to trust.

1. Your application runtime stays in your cloud

The Deployer operates a control plane that analyzes repositories and coordinates deployments. Your application runtime and the cloud resources created for it live in the cloud account you connect.

What the control plane holds: your account details, encrypted connection credentials, encrypted environment values you enter, a working copy of each project's repository, and deployment records and logs. What it does not hold: your application's running processes or its database. If you stop using The Deployer, what it created stays in your account.

Brownfield projects are an exception to "everything is tagged". When you adopt resources that already exist in your account, The Deployer works with them without tagging them, so that removing a project from The Deployer never tears down infrastructure it didn't create.

2. AI can propose. It is not the authorization layer.

AI is used to interpret repositories, explain architecture options, diagnose failed deployments and draft code or configuration changes. Here is where it stops.

• Deployment steps are defined by the engine. The engine provisions resources through provider SDKs and runs its own step definitions. The model does not write the scripts that create your infrastructure.
• Secrets travel as references. Deployment plans carry references such as secret://name instead of values. The engine resolves them in memory at the moment of use, and deployment logs are redacted for known secret values.
• Environment advice uses names only. When the environment assistant decides which service needs which setting, it sees the setting names, not their values.
• You start deployments. The AI guide cannot launch a deployment, commit to your repository, change DNS or connect accounts on its own; those need your click.
• Copilot changes are proposals. When the project copilot wants to change something (attach a service, resize, redeploy), it shows a proposal and runs it only after you confirm.

The limits, stated plainly. The project copilot and the recovery agent can run commands on servers The Deployer created for you, over SSH with administrator rights, to diagnose and fix problems. Those commands are checked against a list of blocked destructive patterns (such as wiping disks or shutting the machine down), and command output is redacted for known secret values and credential-shaped strings before the model sees it. This is a pattern list, not a full policy engine, and redaction can miss a secret it does not recognise. If that is not acceptable for a project, don't use the copilot's server tools on it.

AI output can be wrong. Code changes are committed to your repository where you can review them, and the platform's checks do not guarantee that every deployment is correct or secure.

3. Credentials today

This is the current credential model for each connection. It is not yet least-privilege or short-lived; section 9 says what we are changing.

Permissions. A deployment touches compute, networking, DNS, certificates, storage and, depending on the architecture, managed databases and IAM roles for the services it creates. We do not yet publish a least-privilege policy per architecture, so a narrowly scoped key is the most common cause of a deploy stopping halfway. Broad permissions are what make deploys finish reliably today. That is why we recommend giving The Deployer its own cloud account, project or subscription, with a key used for nothing else, rather than a key into an account that holds unrelated production systems. Details per provider are on the cloud permissions page.

What The Deployer can do with a broad key. Anything the key allows. The engine creates, changes and deletes the resources for the projects you set up, tags what it creates, and does not change billing or account security settings as part of a deployment. That is a statement about how the software is written, not a technical limit on the key, which is why the dedicated-account recommendation matters.

Removing access. Delete the key at your provider to cut access immediately, then delete the connection in The Deployer. Removing a connection stops future management actions; it does not delete resources already created in your account.

4. Encryption and secrets

• Connection credentials and secret environment values are encrypted before they are stored, and decrypted only when an operation needs them.
• Connection cards show a masked hint, not the full key.
• Stored credentials can currently be revealed in full by the account owner after re-entering the account password. Attempts are rate limited and each reveal is written to the audit log. We plan to make stored credentials write-only; until then, prefer creating a new key at your provider over revealing an old one.
• Replacing a credential tests the new key first and keeps the old one if the new one fails.
• Each project gets its own SSH key for the servers created for it; your personal keys are never requested.
• Repository scans that find committed credentials show a masked preview only. A credential that was ever committed should be rotated, not just removed from the current file.

5. Where your code is built

Most application images are built on the servers created in your account, or by your provider's build service for managed architectures. Two things run on The Deployer's control plane:

• A build check that runs docker compose build on your repository before any cloud resources are created, to catch broken builds early. It uses Docker's standard build isolation.
• Static-site builds (for example npm ci and npm run build) for sites served from object storage or a CDN. These run as a separate low-priority process with a minimal environment that contains no Deployer secrets, one at a time, with a time limit. They do not yet run in a network-restricted sandbox.

Project working copies are kept on the control plane until you delete the project. Public repository checks use a temporary folder that is deleted when the check ends.

6. Approvals and records

• What needs your action: the first deployment of a project, choosing the architecture, connecting accounts, copilot proposals, and destructive operations such as teardown.
• What runs without a per-action confirmation: redeploys triggered by a push when you have turned on deploy on push, redeploys you request through an API key or the MCP server, automated recovery retries inside a deployment you started, and scheduled start, stop or resize operations you set up.
• Deployment history: every deployment, redeploy, resize and power action is listed in the project with its logs.
• Audit log: account-sensitive actions are written to an audit log with the user, time and target, including connection create, verify, rotate, reveal and delete, API key changes, password changes, billing events, environment changes, DNS changes, teardown and scaling. There is not yet a view of this log in the app; ask hello@thedploy.com for your account's entries.

7. Your account

• Sign-in requires a verified email address. Passwords are stored as salted hashes.
• Changing or resetting your password signs out every session.
• Sessions last up to 24 hours. The sign-in token is currently kept in your browser's local storage; moving it to a secure, HttpOnly cookie is on the list below.
• API keys (for the MCP server) need your password to create, are stored as one-way hashes, can be revoked individually, and are revoked together when you change your password.
• Multi-factor authentication is not available yet.
• Workspace members act under their own accounts; only the workspace owner can view or replace connection credentials.

8. Shared responsibility

These Terms reference this table.

9. What we are changing

These are planned, not available. We will update this page as each one ships.

• AWS access through a role in your account with temporary STS credentials and an external ID, instead of IAM user keys.
• Generated least-privilege policies per provider and architecture, with bootstrap access separated from day-to-day deployment access.
• Google Cloud Workload Identity Federation instead of service-account keys, and federated or certificate credentials on Azure.
• A GitHub App with access to the repositories you select, instead of broad OAuth or personal-token scopes.
• Write-only stored credentials: masked identifier, last used, replace and revoke, but no reveal.
• Multi-factor authentication, a list of active sessions, and an audit log you can read in the app.
• Sign-in sessions in secure, HttpOnly cookies.
• Static-site builds in an isolated, network-restricted sandbox.
• Private-by-default public repository check results, with an explicit share link and expiry.

10. Current assurance

We do not hold SOC 2, ISO 27001 or similar certifications, and we don't display badges for them.

• Public security architecture: this page.
• Documented cloud permission model: the cloud permissions page and permissions docs.
• Vulnerability disclosure process: disclosure policy and security.txt.
• Independent penetration test: not yet completed.

11. Reporting a vulnerability

Found a security issue? Please report it privately so we can investigate before it is publicly disclosed. Good-faith security research that follows our disclosure policy is welcome.

Email hello@thedploy.com.