Security at Alkimist
Alkimist orchestrates deployments to servers you own. That model shapes every security decision below.
Your code and images never leave your infrastructure
Application images are built on your own server and kept in a private image store available only on that server. Alkimist coordinates the build through an encrypted connection, so build artifacts, caches, and images stay on hardware you control.
A deploy key you can see, scope, and revoke
You authorize Alkimist by adding one public key to your server — we never ask for passwords and never connect uninvited. The install command scopes the key so it only works from Alkimist's orchestration server (from= restriction, no agent or X11 forwarding), and you can point Alkimist at a dedicated non-root user in the docker group instead of root. Revoking access is deleting one line from authorized_keys.
Secrets are encrypted at rest
GitHub and GitLab OAuth tokens, your projects' environment variables, and uploaded SSL private keys are encrypted in our database with Active Record encryption. A leaked backup exposes ciphertext, not credentials.
AI agent access is authenticated, hashed, and revocable
MCP access uses OAuth 2.1 with PKCE. Personal access tokens are stored as SHA-256 digests — we cannot read them back — and revoking an agent kills every token it holds immediately.
Webhooks are verified, endpoints are rate limited
Push-to-deploy requests must carry a valid HMAC signature (GitHub) or secret token (GitLab); unsigned requests are rejected. Sign-in, sign-up, contact, and deploy endpoints are rate limited.
Zero lock-in is a security feature
Everything Alkimist deploys uses standard containers on your own servers. If you cancel, your applications keep running and you keep full access—there is no lock-in.
Found a vulnerability?
We want to hear about it. Email [email protected] and we'll respond within 24 hours.