A catalogue entry gets an open-source application running on AppCrane. Skiff is for applications that go further and integrate with it: single sign-on at the edge, roles the app defines itself, platform email, a health contract, and a managed database. Every one of those surfaces ships in AppCrane today. The certification — the checklist, the review, and the mark — is what is being shaped now, with the first maintainers.
An application installed from the catalogue runs correctly and does nothing wrong. But the person using it signs into AppCrane, and then signs into the application again. That second login is not a small annoyance — it is a second set of accounts. Someone has to create them, keep them in step with the first set, and remember to remove them on the day a person leaves. The offboarding step that gets missed is almost always the one in the second system.
Skiff closes that gap by having the application trust the identity AppCrane already established, rather than establishing its own. One account, one place to administer it, one offboarding step. The same argument then repeats for roles, for outbound mail, for health checks, and for the database: each is something the organisation already runs once, and the application can inherit instead of duplicate.
These are separate. An application can take single sign-on and nothing else, and stop there.
Identity arrives as request headers the platform authenticated. The app runs no login of its own.
The app declares its own role vocabulary; AppCrane stores who holds what and hands it over without interpreting it.
Outbound mail through AppCrane's configured sender. The app carries no SMTP credentials.
A JSON endpoint that deploy validation, the monitor, and auto-restart already know how to read.
A database provisioned per app, isolated at the engine, with credentials injected before the container starts.
AppCrane authenticates the visitor at the edge — Caddy's forward_auth — and passes the caller's identity to the container as request headers:
X-AppCrane-User-Email: someone@example.com X-AppCrane-User-Id: 42 X-AppCrane-App-Role: admin X-AppCrane-Is-Admin: 1 X-AppCrane-Auth-Mode: authenticated # every proxied request
Caddy strips any client-supplied copy of those headers before the auth step runs, then writes the authenticated values itself — so a visitor cannot forge them, and the container only ever sees headers the platform wrote. X-AppCrane-Auth-Mode is present on every proxied request, which gives the application a reliable way to tell that it is running behind AppCrane at all.
The application reads the headers and treats the caller as signed in. No password store, no session table, no invite email, no forgotten-password flow — and no second account to deprovision.
An application declares the role vocabulary it actually cares about — approver, auditor, whatever the domain needs. AppCrane stores who holds which of those roles and delivers them alongside the identity:
X-AppCrane-App-Roles: approver,auditor
AppCrane never interprets them. It has no opinion about what approver means, and it does not consult the value when deciding anything of its own. AppCrane ships facts; the application enforces policy. The direct consequence is a boundary worth stating plainly: an app-defined role can never confer an AppCrane privilege. Granting someone approver in your application gives them nothing on the platform.
What the organisation gets is one place to administer authorisation instead of two.
Outbound mail goes through AppCrane's configured sender. The application carries no SMTP credentials of its own and inherits whatever the organisation already set up — the same sending domain, the same deliverability work, the same rotation when a credential changes. One fewer secret in the application's environment, and one fewer thing for the operator to configure per app.
The application exposes a JSON health endpoint returning at least status and version:
{ "status": "ok", "version": "1.4.2" }
Deploy validation, the monitor, and auto-restart all read that endpoint. The practical effect is that the application reports the way everything else on the box reports: a bad deploy is caught before it is promoted, a hung process is restarted, and the running version is a fact the platform can display rather than a guess.
AppCrane provisions a database per application, isolated at the engine rather than by network rules, and injects the credentials into the environment before the container starts. The application reads them like any other configuration and connects. Nothing to provision by hand, nothing to write down, and no shared database where one application's mistake is another application's problem.
Integrating with AppCrane does not ask a project to give up its own deployment story. An application can be certified on AppCrane and continue to ship exactly as it does everywhere else: the same install instructions, the same packages, the same containers, the same self-hosted setup for people who have never heard of AppCrane. The Skiff surfaces are things the application uses when they are present, and it falls back to its own login, its own mailer, and its own database when they are not.
The upside for a maintainer is that the project becomes installable inside organisations that would otherwise never have reached the end of the setup guide — on their own machines, with no intermediary and no cut taken.
Skiff is being shaped with the maintainers who show up first, so the checklist is still open to argument. If your project could use one of these surfaces, say which one.
Skiff on the AppCrane repository and name the surface your application would use first.The integration is. All five surfaces ship in AppCrane now, and you can build against them this afternoon. The certification programme — checklist, review, mark — is not defined yet; that is the part being worked out with the first maintainers.
No. Certification is additive. An application can be certified on AppCrane and continue to ship exactly as it does everywhere else, and each surface stands alone — take single sign-on and nothing else if that is all you want.
Caddy strips any client-supplied copy of the X-AppCrane-* headers before forward_auth runs, then writes the authenticated values itself. The container only ever sees headers the platform wrote.
No. AppCrane stores and delivers the role but never interprets it. An app-defined role has no meaning inside AppCrane and can never confer an AppCrane privilege.
No. They are independent. The most common starting point is single sign-on, because it is the one that removes the second set of accounts.
The catalogue gets an application installed; Skiff is about what happens after it is running. See the catalogue write-up for how entries are added.
Skiff on the AppCrane repository and say which surface your application could use first.