The enterprise AI applications platform — driven by your AI agent over MCP. Bring Claude Code, Cursor, Codex, or any MCP client. AppCrane handles deploy, env, GitHub branches, rollback, and per-user visibility on your own server.
No spam. Weekly changelog only.
A full deployment platform on your own machine. No monthly fees, no vendor lock-in, no cloud bill surprises.
No more in-portal coding sandbox. AppCrane exposes its operations as MCP tools — deploy, env, logs, rollback, branch, PR. Connect the agent you already use, keep your local context and your keys, and drive your fleet from one place.
Self-hosted without the trade-offs. Enterprise features without the SaaS bill.
| AppCrane | Railway | Coolify | |
|---|---|---|---|
| Price | Free (self-hosted) | $5–20 / app / mo | Free (self-hosted) |
| Data ownership | Your server | Railway cloud | Your server |
| Docker isolation | ✓ per app | ✓ | ✓ |
| Enterprise SSO | ✓ SAML / OIDC / SCIM | ✗ | ✗ |
| Agent control protocol | ✓ MCP — any client | ✗ | ✗ |
| Real-time presence | ✓ | ✗ | ✗ |
| Dual environments | ✓ built-in | Manual | Manual |
| Auto-HTTPS | ✓ Caddy | ✓ | ✓ Caddy |
| Zero-downtime deploy | ✓ | ✓ | Partial |
| Vendor lock-in | None | High | None |
| Open source | MIT | ✗ | Apache 2 |
From fresh Ubuntu server to running app in under ten minutes.
Platform Owner can never read app secrets — enforced at middleware, not by policy. The other three roles are app-scoped and configurable per app: App Owner decides exactly what App Admins and App Users can do inside their app.
/data/.env on disk and is never in the code path the Platform Owner controls. App Owner is the only role that grants access to secrets, and they grant it per-app, per-role, in the dashboard.
Docker isolation meets proven Linux tooling. No Kubernetes, no cloud sprawl — just a reliable stack running on your own server.
Yes. AppCrane is open source and free to self-host. You pay for your own server — typically $5–20/month on any VPS provider — and nothing else. There is no SaaS fee, no per-seat charge, and no usage billing.
Railway is a managed cloud platform — your code and data live on their infrastructure. AppCrane runs on your own server, so you own everything. Compared to Coolify, AppCrane adds enterprise SSO (SAML/OIDC/SCIM), an MCP server so any AI agent can drive deploys directly, and real-time team presence — features aimed at teams rather than solo developers.
No. AppCrane uses Docker for process isolation but abstracts it entirely — you never write a Dockerfile or manage containers directly. There is no Kubernetes, no Helm, no cluster to maintain. If you can SSH into a Ubuntu server, you can run AppCrane.
Yes — if it speaks MCP, it works. AppCrane runs an MCP server that exposes deploy, env, logs, rollback, branch, commit, push, and PR operations as tools. Connect Claude Code, Claude Desktop, Cursor, Codex CLI, or any MCP-compatible client by adding AppCrane's MCP endpoint and your user token. There is no in-portal coding sandbox to learn — your agent stays in the environment you already use.
Every MCP token is bound to a specific user. When an agent calls a tool, AppCrane records the user, the agent's client identifier, the app, the env, the action, and the result. The dashboard shows per-user activity in real time and per-user history in the audit log — so you always know which person was behind a deploy, even when an AI did the typing.
Agent edits go through real git, not a side channel. The MCP branch tool creates a feature branch (agent/{slug}-{name}); commit and push use your repo's normal credentials; open_pr opens a PR with a generated summary. Push to main still triggers the existing HMAC-verified webhook auto-deploy. AppCrane never bypasses GitHub — your reviews, branch protection rules, and CI all apply.
AppCrane supports SAML 2.0, OIDC, and SCIM provisioning. Connect it to Okta, Azure AD, Google Workspace, or any standards-compliant identity provider. SCIM handles automatic user provisioning and deprovisioning — when you remove someone from your IdP, their AppCrane access is revoked automatically.
No. Environment variables are AES-256-GCM encrypted at rest and the Platform Owner role is hard-walled from reading them at the middleware level — not by convention, not by policy. Only the App Owner (and the App Admins / App Users they explicitly grant via the per-app permission grid) can read or write app secrets. The hard wall holds even with shell access to the server: the encryption key lives in .env on disk, outside the Platform Owner's code path.
Platform Owner operates the server: creates/deletes apps, manages SSO, monitors hardware. Hard-walled from app data. App Owner owns one app end-to-end: assigns App Admins and App Users, configures the per-app permission grid, has full env / deploy / settings access. App Admin handles configuration inside the app: health checks, webhooks, metadata. App User is day-to-day developer access: deploy to sandbox, view logs. App Admin and App User capabilities are configurable per app — the App Owner decides exactly what each can do.
Yes. Every app has a Settings → Roles permission grid where the App Owner toggles which capabilities are granted to App Admins and App Users on that app — env var access, deploy targets, rollback, backup operations, and so on. Different apps in the same organization can run different policies. The only setting that can't be changed is the Platform Owner's middleware boundary — that's hard-walled in code.
One command. Your server. Your apps.