Sixty-seven open-source business apps, two clicks each.

Organisations do not avoid open source because it is worse. They avoid it because of the hour after git clone — and that hour is the thing this catalogue removes.

Someone has to find a container image, work out which port it listens on, stand up a Postgres, invent a connection string, discover that this particular application halts on boot without a generated key, put a reverse proxy in front of it, and then own that arrangement forever. None of that is in the README, it is rarely budgeted, and it is why a team that would happily run an open-source helpdesk signs a SaaS contract instead.

The software was never the obstacle. The operational distance between the repository and a running instance was.

What two clicks actually means

The catalogue is not a list of links. Each entry carries what AppCrane needs to bring the application up correctly, and the platform does the parts a person would otherwise do by hand:

• You pick a version — the current upstream release, read live from GitHub and Docker Hub, or a tag you pin yourself.
• AppCrane provisions a database on a shared Postgres or MariaDB: one database and one login per app, isolated at the engine rather than by network rules.
• Connection details and any generated secrets are written into the app's encrypted environment before the first container starts.
• The container comes up on the port the image actually listens on, is health-checked at a path that application really serves, and gets a route behind your sign-in — or in front of it, if the app does its own.

Secrets are generated in your browser and never travel through the catalogue API. An entry declares that an application needs a 32-byte key under a given variable name. It never contains one.

Choosing what goes in

Entries are not accepted on popularity. An application earns a place by being genuinely self-hostable as a single service: a published image, a port it will admit to, and the ability to serve a page without a second container beside it. Several well-known projects were removed during review for failing that last test. An image that starts happily and can never answer a request is worse than an absent entry, because it fails after you have trusted it.

Where a port or a health path could not be established from the image's own registry metadata, the field is left empty rather than guessed. A wrong port fails the health check and destroys the container; an empty field just asks you.

The catalogue

Every project below is open source and independently maintained. AppCrane packages none of them, forks none of them, and takes nothing from them. Links go to each project's own home.

Why this is good for the projects

The usual way an organisation adopts software is by paying a vendor who has packaged someone else's work, or by paying a hosted service that happens to be open source at the core. Both routes put an intermediary between the organisation and the project.

Removing the setup hour changes which option wins on the day of the decision. An open-source helpdesk that takes two clicks and runs on your own machines competes on equal footing with a hosted product — and when it wins, the relationship that forms is between the organisation and the project. That is the relationship that turns into sponsorship, paid support, an enterprise licence, a bug report from someone running it at scale, or a contributor who first arrived as a user.

There is a second effect worth naming. Self-hosting keeps the data, the upgrade schedule and the exit path with the organisation. Teams who would have been talked out of open source on procurement grounds — residency, lock-in, per-seat pricing that scales the wrong way — have an answer that survives that conversation.

The catalogue does not monetise the applications in it. There is no marketplace fee, no revenue share, and no billing relationship between AppCrane and any project listed here.

If you build open-source software for organisations

We would like your project in the catalogue, and getting it there costs you nothing but the metadata. If your application is genuinely self-hostable, an entry is a small block of JSON in a pull request:

• A published container image on a public registry, and the source repository it is built from.
• The port the image listens on, and a path that returns 200 when the application is healthy.
• Which database engine it needs, if any, and the environment variable names it reads the connection details from.
• Any secret it must be given to boot — declared by name, length and encoding, never by value.

That is the whole contract. The upside for a maintainer is direct: your project becomes installable inside organisations that would otherwise never have reached the end of your setup guide, on their own machines, with no intermediary and no cut taken. Corrections are welcome on the same terms — if a port, a health path or a licence is wrong here, the fastest fix is a pull request from the person who knows.

Skiff — going further than running

A catalogue entry gets your application installed. It does not make it feel like part of the platform it is installed on — the user still signs into AppCrane, then signs into your app again, with a second set of accounts to administer and deprovision.

Skiff is the name for applications that integrate deeply enough to remove that seam. Every capability below ships in AppCrane today — none of it is waiting on us. The integration guide is SKIFF.md in the repository, and you can build against it this afternoon. The surfaces:

• Single sign-on. AppCrane authenticates the visitor at the edge and passes the caller's identity to the container as request headers. A certified application trusts that identity instead of running its own login — one account, one offboarding step.
• Roles the application defines itself. An app can declare the roles it cares about, and AppCrane delivers the caller's role alongside their identity, so authorisation is administered in one place rather than two.
• Platform services. Outbound email through AppCrane's own sender, so the application needs no SMTP credentials of its own.
• A health contract the platform understands, so monitoring, auto-restart and deploy validation report on your application the way they report on everything else.
• Managed data. A database provisioned per app, isolated at the engine, with credentials injected before your container starts.

The guide is written to be handed to a coding agent as much as read by a person. If you work with Claude Code, Cursor or anything else that takes a URL, point it here and describe what you want:

https://raw.githubusercontent.com/gitayg/appCrane/main/SKIFF.md

It states each contract exactly — header names, values, absence semantics, the endpoint shapes — so an agent has no room to guess an API that does not exist.

None of this requires giving up your own deployment story: an application can integrate with AppCrane and continue to ship exactly as it does everywhere else. Each surface stands alone, so you can take single sign-on and nothing else, and stop there.

What is not settled yet is the certification itself — the checklist, the review, and a mark that tells an organisation the integration was verified rather than claimed. We would rather define that with the first few maintainers than hand them a finished specification. If that interests you, get in touch: open an issue titled Skiff on the AppCrane repository and say which surface your application could use first. Details are on the Skiff page.