Subprocessors & data flow
A subprocessor is a third-party service deploymill sends data to in order to do its job — host your app, store your database, keep your source, send an invite email, and so on. This page names every subprocessor in deploymill's default managed stack, what data each one receives, and why.
It exists so you (and your auditors) can see exactly where customer data goes. If you're assembling a vendor-management list for SOC 2, or a subprocessor appendix for a DPA / GDPR Article 28 agreement, this is the source of truth for the default deployment.
Two honesty caveats up front:
- This reflects the default managed stack. deploymill's primitives —
compute, database, domain, secrets, source, object storage — are provider-neutral interfaces with swappable backends. The vendors below are today's backends, not a permanent contract. If a backend is swapped (a different compute target, a different object store), this list changes, and this page will change with it.
- It's deployment-dependent. Several subprocessors are only engaged if the
operator running deploymill has configured them. An operator can run with email, SSO, or object storage left unconfigured — in which case that subprocessor receives nothing at all. Each row notes when this applies.
The data-flow inventory
| Subprocessor | Data categories received | Purpose | Notes / region |
|---|---|---|---|
| Dokploy (compute backend) | App build context (source pulled for the build); the app's full environment-variable blob — including secret values and DATABASE_URL written in plaintext (the container needs them at runtime) | Builds, runs, and health-gates your deployed apps and previews | The compute primitive. Secrets are encrypted at rest in deploymill's own store, but binding a secret into an app writes the plaintext into Dokploy's env blob — encryption at rest protects the source of truth and keeps values out of agent transcripts, not from the host that runs your container. Region/hosting is operator-determined. |
| Neon (managed Postgres) | Whatever your deployed app writes to its database — i.e. your application's own data | Managed Postgres database + connection string | One Neon project per organization (deploymill-<orgSlug>), one database per app; previews get a copy-on-write branch. Only engaged when a project declares a managed database. Engaged only if the operator configured a Neon API key. |
| GitHub (source backend) | Repository source code and file contents (commits made via push_files, repos created by start_project) | Source / version control — where your project's code and .deploymill/project.json live | The source primitive. deploymill authenticates as a GitHub App installation (or a shared token). Region/hosting is GitHub's. |
| Cloudflare R2 (object storage) | Objects/blobs your app uploads (media, user uploads, datasets) | S3-compatible object storage | One bucket per app with bucket-scoped credentials minted per app. Only engaged when a project declares object storage, and only if the operator configured Cloudflare R2 credentials. |
| Linear (support backend) | Support-ticket content filed from the web app — the subject, body, and context you type; secrets are redacted before the ticket is created | Receiving and tracking support tickets | Support is the one web-first surface (/account/support, no MCP tool). Each ticket is mapped to your org in deploymill's own database, so a Linear issue id is never trusted directly (tenancy/IDOR guard). Only engaged if the operator configured a Linear API key + team. |
| Resend (transactional email) | Recipient email address + the invite / transactional email content | Sending organization invites and transactional email | Email is not a core primitive but follows the same swappable-backend posture (a different provider can slot in behind EMAIL_PROVIDER). Processes PII (email addresses). Only engaged if the operator configured email — otherwise no invite emails are sent and nothing reaches Resend. |
| Google (OAuth sign-in) | The OAuth sign-in handshake for "Continue with Google" — the identity assertion for the signing-in user (e.g. email, name) | Identity provider for optional Google sign-in | Identity only — Google receives no application data, no source, no secrets, no database content. Only engaged if the operator configured Google OAuth client credentials, and only for users who choose "Continue with Google." |
What deploymill itself holds
Separate from the subprocessors above, deploymill stores in its own Postgres database: your account and organization records, org-scoped secrets (encrypted at rest with AES-256-GCM), app/preview metadata, the audit trail, and the org↔support-ticket mapping. Secret values are never returned to MCP clients and never echoed into an agent transcript — they enter only through a single-use browser hand-off and leave only when injected server-side into an app's environment (which is what hands them to the compute backend, above).
Keeping this honest
Because the primitives are provider-neutral, the interfaces are stable but the vendors can change. When a backend is added or swapped — or when an operator turns a previously-unconfigured subprocessor on — this page is the document that must be updated to stay accurate. Treat it as a maintained list, not a one-time snapshot.