There is one AppCrane: a self-hosted platform that runs the apps a team builds with an AI agent, on a server that team owns. What changes between these three pages is not the product but the question the reader arrived with. An IT manager is asking who can reach what and what the audit trail says. A forward-deployed engineer is asking what happens when the engagement ends. A developer is asking how the code gets from a branch to a URL. Same install, same repository, same licence.
You inherited the apps the business built without you. Single sign-on enforced at the proxy, per-app roles, an audit log that tells an agent from a person, per-app memory and CPU ceilings, and a scan of what each deploy actually shipped.
You build with your agent and it has to run inside the customer's perimeter. One command on their Ubuntu box, then a handoff their own team can operate after you leave — with no vendor account to transfer.
You want a URL, a database, a log tail and a way back to the last good release — without becoming the person who runs the server. Sandbox and production per app, a gated promote, and a rollback that restarts the image it already built.
These are properties of the platform, not of a page. Each one is the same whichever seat you are reading from.
forward_auth asks AppCrane who the caller is and whether they hold a role on that app; the container is only reached once the answer is yes./api/mcp exposes 59 appcrane_* tools — create, deploy, roll back, read logs, grant access, scan. Each connection sees the subset its role allows.human or agent, so "what did the agents change here last week" is one question rather than a reconstruction.| IT manager | Forward-deployed engineer | App developer | |
|---|---|---|---|
| Whose server is it | Yours, in your estate | The customer's | Someone else's problem |
| The question that matters | Who can reach what, and what did they do | What survives after I leave | How do I ship and how do I undo it |
| The surface you live in | Dashboard, audit log, fleet reports | Install script, then the handoff | Your agent, over MCP |
| What you are handed | SSO, roles, scans, backups, limits | A platform the client owns outright | Sandbox, production, promote, rollback |
No. One AppCrane, one repository, one install. The pages differ in which parts of it the reader needs first.
No. Single sign-on, SCIM provisioning, per-app roles and the audit log are in the AGPL-3.0 build with nothing to activate. A commercial licence is offered separately for running private modifications as a service — that is a licensing question, not a feature gate.
An Ubuntu 22.04 or newer server you control, and a domain whose DNS points at it. Caddy provisions TLS on the first request.
Yes, over MCP — 59 tools at /api/mcp, role-filtered per connection, every call audited as an agent action. Deploy from Claude and Cursor walks through it.