Bring your own app: paste a Docker link, get a running app

Every catalog has an edge, and the app you actually want is usually just past it. It lives in a GitHub README as a docker-compose block, or on Docker Hub as an image a few thousand people run and no hosting company supports. Running it yourself means a VPS, a reverse proxy, TLS certificates, and a backup script you will write later and never write. So it stays a bookmark. Bring your own app removes the edge -- paste the link, and if it can run here, it runs here, with everything a catalog app gets.

Paste a link, get a real configuration

In the deploy wizard, paste a public Docker Hub or ghcr.io image link. Or paste an entire docker-compose file -- app, database, cache, worker, all of it. The platform reads the image's real metadata: the ports it exposes, the volumes it writes to, the environment it expects. From that it writes a complete deployment configuration, including generated passwords for anything that needs one.

This matters because a compose file found in the wild is a sketch, not a deployment. It assumes a machine that looks like the author's. It leaves ports unpublished or published wide open, mounts paths that exist nowhere but the author's laptop, and expects environment variables the README mentions in passing. Reading the actual image metadata -- not guessing from the name -- is how the platform turns that sketch into something that can run on shared infrastructure with the network and storage rules it actually has.

The Deploy button means it already ran

Here is the part that makes this different from a compose importer. Before anything is offered to you, the platform boots the app for real, on our infrastructure. Not a lint pass over the YAML. Not a registry ping to confirm the image exists. An actual boot, with the configuration it just wrote, watched until the app comes up healthy or fails.

If that first test boot fails, an AI repair pass reads what went wrong, corrects the configuration, and boots it again. A missing environment variable, a port the image actually listens on that the compose file never mentioned, a volume the app cannot start without -- the repair pass fixes the configuration and proves the fix the same way, by running it.

You only ever see a Deploy button on something that actually ran. That is the whole contract. There is no "deployed successfully" email followed by a crash-looping container, because a configuration that crash-loops never becomes a Deploy button in the first place.

Pasted secrets never survive

Compose files in the wild come with credentials baked in. POSTGRES_PASSWORD=changeme, an admin password in plain text, a token the author pasted for their own setup and forgot. Deploying that file as-is means running the same password as everyone else who copied the same README.

The platform replaces hardcoded secrets with generated ones -- automatically, and consistently. Consistently is the word that matters: when three services in the same file reference the same password, all three get the same generated replacement, so your database and your app still agree on the credential without either of them shipping the one from the README. You do not audit the file for leftover defaults. There are none left over.

Brought apps are first-class

A deployed BYO app is not a second tier. It gets everything a catalog app gets:

• HTTPS and custom domains. Your app gets a working HTTPS address, and custom domains ride behind Cloudflare.
• Backups and snapshots. The same snapshot machinery catalog apps use, off-host, restorable.
• SFTP and a browser terminal. Direct access to your app's files, and a shell in the browser when you need one.
• Logs and region choice. Live logs from the panel, and your pick of region at deploy time.

And because a brought app has no vendor behind it, it gets one thing extra: a built-in AI fixer. When something breaks after deploy, the fixer reads the logs, adjusts the configuration, redeploys, and verifies the result -- the same run-it-and-check discipline as the first boot, applied to a live app. Free fixer sessions are included per app. After those, a session is $2, charged from your credit, and automatically refunded if no fix is found. You pay for fixes, not for attempts.

Updates get the same treatment the first boot did. When upstream publishes a new build, it is booted in a sandbox and verified before it is ever offered to you -- that mechanism is worth its own post, and it has one.

An honest no, and a path into the catalog

Some apps cannot run on shared hosting, and the worst thing a platform can do is let you find that out three hours in. A VPN server needs to own the network. A container manager like Portainer needs access to the host itself, which on shared infrastructure would mean access to everyone. When you paste one of these, you get a decline with the specific reason -- what the app needs, and why shared hosting cannot give it -- never a vague error that leaves you retrying variations of the same link.

The other direction is more interesting. Apps the community proves out can graduate. A brought app that boot-verified cleanly, is run by multiple owners, and has stayed healthy for a week can move into a public Community section of the catalog -- so the link you pasted becomes something the next person just clicks. The catalog stops being a list we curate alone and starts being a record of what demonstrably works here.

Try it

Bring your own app is in beta. You can run three compatibility checks before buying any subscription -- paste the links you have bookmarked and see what comes back before a dollar changes hands. When one passes, deploy it on a capacity subscription. Apps deploy in minutes, with HTTPS, backups, SFTP and a browser terminal included.