Security
Security
Dockify runs as root-equivalent on your server, so we treat its own code as the biggest risk. Here is how it is built and how to tell us when we got it wrong.
Report a vulnerability
Please do not open a public issue.
GitHub private reporting
On the repository's Security tab, choose Report a vulnerability. Only the maintainers see it.
What happens next
Step 1. You report it privately.
Through GitHub private vulnerability reporting. Please do not open a public issue.Step 2. We reply within 3 working days.
We confirm what we can reproduce and ask what we need.Step 3. We agree a fix date with you.
You know when the fix ships before anyone else does.Step 4. We credit you in the release notes, if you want.
We ask for 90 days before public disclosure, or less once a fix ships.
Scope
The control plane (api, worker, agent, web), the installer and the release pipeline. Apps you deploy are yours.
How Dockify is built
No shell from your input
No shell commands are built from your input. Containers are created through one checked builder.
A policy on every route
Every API route has a declared policy. A test fails if one is missing.
Locked-down containers
Your containers run with capabilities dropped, no privileged mode, no host network and no host folders.
Private databases
Databases are never published on a host port.
Sealed secrets
Each secret is encrypted on its own. Changing an app's settings or variables, or stopping, restarting or deleting it, asks you to confirm it is you again: your authenticator code when two-factor is on, otherwise your password.
No inbound ports for Dockify
In tunnel mode Dockify opens no inbound port; only SSH stays open. Releases are signed and checked before install.
Supported versions
- Latest minor release
- Gets security fixes.
- Older releases
- No fixes. Update to the latest minor release first.
- Before 1.0
- Not supported. No release has shipped yet.
How updates are signed
From the release feed to your server, every Dockify image is checked before it runs. The first signed release is 1.0.0.
Step 1. Each release is a manifest signed with minisign.
Ed25519. The signed comment must name the manifest's own version, so a release cannot be relabelled.Step 2. The installer checks it against a pinned public key.
Then it pulls the Dockify images by digest, never by a tag that can move.Step 3. The updater checks the signature again.
It fetches the feed over HTTPS only, and refuses a feed that resolves to a private address.Step 4. It dumps Dockify's own database before it changes anything.
The new images are pulled first, while everything keeps running. Then the api and worker stop briefly for the dump.Step 5. If the update fails, it rolls back on its own.
A failed migration, restart or health check restores the dump and the previous images.
# Check a release by hand. From 1.0 on, the public key is in deploy/release.pub, installer/install.sh and the GitHub Release.
curl -fsSLO https://raw.githubusercontent.com/kedarpixels/Dockify/releases/releases/stable.json
curl -fsSLO https://raw.githubusercontent.com/kedarpixels/Dockify/releases/releases/stable.json.minisig
minisign -Vm stable.json -P <public key>