Platform
Security
Running other people's code next to each other is the core job of a hosting platform. This page explains how ForkDeploy keeps projects apart and data safe, in plain language.
Why this matters
A deploy platform holds three sensitive things: your source code, your secrets, and your running services. On a multi-tenant platform, all of that lives near other people's projects. The honest question is not whether the platform has security features, but whether tenants are isolated by default and whether secrets are treated as radioactive. Both are design decisions made at the foundation here, not features bolted on later.
What follows is the how, kept at the level of guarantees rather than internals. Publishing a blueprint of the exact setup would help exactly one audience, and it is not you.
The layers
Every project is isolated
Each project runs in its own isolated slice of the cluster. Network policies block traffic between projects by default: your services can talk to each other, and to nothing else. Another tenant cannot reach your database, even from inside the platform.
Builds run in a sandbox
Container images are built by an isolated, unprivileged builder. Build steps never get access to the host machine, the container runtime, or other projects. A malicious Dockerfile stays inside its box.
Secrets are encrypted at rest
Secrets are encrypted with a strong key before they touch a disk, and decrypted only when injected into the services you explicitly chose. They never appear in build logs, deploy logs, or the API in plain text.
TLS everywhere
Every public URL gets an automatically provisioned and renewed certificate. Traffic between your visitors and your services is encrypted, including on custom domains.
Resource limits protect neighbours
Each project has CPU and memory quotas, and requests are rate- and size-limited at the edge. A runaway process or a flood of traffic in one project cannot starve another or take the platform down for everyone else.
Committed secrets never reach your image
The build always excludes .env files (and junk like node_modules) from the image, so a password accidentally committed to your repo is never baked into a shipped container. If ForkDeploy spots a committed .env, it warns you, set the real values as dashboard secrets instead.
Hardened in the browser
Every page ships a strict Content-Security-Policy, HSTS, and locked-down framing and browser-permission headers. That closes off the common web attacks, script injection, clickjacking, and downgrade to plain HTTP, before they start.
Only vetted images run as-is
Prebuilt services are limited to an allowlist of trusted databases and caches; anything else has to be built from your own source. Databases can run fully internal, reachable only by your own services and never from a public URL.
Small surface, EU-hosted
The platform runs on a small number of servers in the EU with a deliberately minimal setup. Fewer moving parts means fewer places for things to go wrong, and your data stays under EU jurisdiction.
Your part of the deal
The platform isolates and encrypts, but a few habits stay with you:
- ✓ Keep passwords and tokens out of forkdeploy.yaml and out of your repo. Add them as secrets in the dashboard instead.
- ✓ Only share a secret with the services that actually need it.
- ✓ Keep your dashboard account safe: use a strong password, and sign in through GitHub if you prefer.
- ✓ Report anything that looks off. A beta platform with honest users gets safer faster.