Huly's Hosted Shutdown: The Complete Self-Host Migration for Your Project Data

Your project tracker just sent you a shutdown notice. Not a pricing change, not a rebrand — a date. Huly's hosted service at huly.app wound down around July 20, 2026, with upstream stating plainly that hosting is no longer funded. If your team's issues, docs, and chat history lived there, the service holding them is going away while the software itself is fine: the Docker images are still published, the self-host repository is still maintained, and the version your workspace ran on is reproducible container by container.

That combination — dead host, living software — makes this the rare SaaS shutdown with a genuine exit door instead of an export button and a condolence email. Here is the whole migration on one checklist, with the rest of this post substantiating every line:

That table is the whole article in miniature. What follows is what each step actually takes — including the parts that bite after the import looks green.

What you are actually moving: a 30-container stack, not an app​

The first surprise of self-hosting Huly is scope. This is not a single container with a Postgres sidecar. The v7 stack is roughly thirty containers in two layers, and knowing which layer holds state is the entire migration plan:

Two numbers set expectations. First, the minimum box: upstream's own self-host readme calls Huly "quite resource-heavy" and recommends 2 vCPUs with 4 GB of RAM, with less RAM explicitly discouraged. That is a small VPS — the class of box that rents for a few euros a month — not a cluster. Second, the image count: community blueprints track around 31 Huly images, all published under a single Docker Hub organization (hardcoreeng), currently at platform version v0.7.426. Single-org publishing is convenient until it is a single point of failure, which is why step 5 exists.

Pick your database variant before you deploy. The official compose lineage uses CockroachDB; the community maintains a Postgres variant it marks recommended, on the reasonable theory that one fewer distributed database is one fewer 3 a.m. page. Either works — but the backup you exported has to restore into the variant you chose, so decide once.

The migration, end to end​

Step 1: export from huly.app while it still answers. In your workspace settings there is a backup panel showing the "Last backup" time. Generate a fresh backup and copy the backup URL. This URL plus your workspace identity is everything the import side needs: the data backup and the blob payload. Do this first, before provisioning anything, because the hosted side is the only part of this plan on someone else's deadline. If your workspace still resolves, export today; do not assume the wind-down left a grace period.

Step 2: provision the box. Any 2-vCPU/4-GB VPS with Docker and 40+ GB of disk will do — size disk at two to three times your day-one data, because MinIO blobs and Mongo only grow. Open ports 80/443 — the default web path is standard HTTPS through the bundled nginx.

Step 3: deploy the stack, choosing one of three doors into the same rooms. The underlying compose topology is identical; what differs is who operates the lifecycle:

• Bare compose / Portainer / Dockge: clone the official hcengineering/huly-selfhost repo, set your env, docker compose up -d. Volumes live in Docker's volume store on that machine — back up /var/lib/docker/volumes or, better, put the three stateful data paths on named volumes you snapshot. Maximum control, maximum yours-to-operate.
• Dokploy blueprint: the community huly-dokploy project ships versioned blueprints (including the Postgres variant) where named volumes are declared in the template — after deploying, verify in the Dokploy UI that the mongo, minio, and account-database volumes survive a redeploy before you trust them with the restore.
• Coolify compose directory: point Coolify at the repo as a Git source and set the compose-file location to the provided directory. Named volumes persist across redeploys, but keep the project name stable — renaming the project orphans the old volume set, a common way teams lose data on compose-based PaaS panels.

Whichever door, the env file carries the same load-bearing lines:

HULY_VERSION=v0.7.426
HULY_BACKEND=redis
HULY_REDIS_MODE=direct
HULY_REDIS_URLS=redis://redis:6379
DISABLE_SIGNUP=true

Two notes on that snippet. Pin HULY_VERSION to the same platform version your backup came from — restoring a backup across versions is where cryptic transactor errors come from. And set a registry mirror sooner rather than later: all ~31 images resolve to one Docker Hub org today, so mirror them to a registry you control and override the image prefix (the community blueprints expose this as an image-prefix variable) so a future upstream rename, rate limit, or org change cannot break your next pull.

Step 4: run the import. The community import wizard takes the backup URL from step 1, downloads the backup plus blobs, creates the workspace on your instance, and restores the data into it. The official backup-and-restore guide documents the underlying export/import mechanics if you prefer to drive them by hand. Either way, the restore lands into MongoDB (documents), MinIO (attachments), and the account database (users, workspace registry) — the three volumes from the state table above.

Step 5: verify like you do not trust it. Log in. Open a project with attachments and confirm images and files actually load — skip that check and you get a green import with a broken workspace. Re-create user accounts, confirm live collaboration syncs (the transactor), and run one search to confirm the fulltext service indexed. Then close the open doors: DISABLE_SIGNUP=true so your tracker is not a public registration form, and note that self-host disables cloud-only UI features (auto-translate, mailboxes) — they depend on hosted services that no longer exist for you, not on a flag you forgot.

Upgrades from here are a three-line ritual — pull the repo, set HULY_VERSION to the new tag, docker compose pull && docker compose up -d — against a backup you took first. Every time. No exceptions for patch versions.

Two gotchas and the real monthly bill​

Gotcha one: the whole stack pulls from one org. Thirty-one images, one Docker Hub namespace. Today that org publishes reliably; the hosted shutdown is exactly the kind of event that teaches you to price "what if it stops." The mirror-plus-prefix setup from step 3 costs an hour once and converts an upstream disappearance from a resurrection project into a non-event. Community blueprints added exactly this protection within days of the shutdown announcement, which tells you how seriously the people running Huly in production took it.

Gotcha two: you are the release engineering team now. Cloud-only features stay off. Every platform release is your pull-recreate-verify cycle, on your evening, with your rollback plan (the backup from before the upgrade). This is the honest price of the exit door, and it is denominated in attention more than money.

So what is the money? The infra bill is one small VPS plus backups — pocket change next to any per-seat SaaS. The real line items: disk growth (blobs and documents grow monotonically — watch MinIO volume usage, not just CPU graphs), a backup cron covering the three stateful volumes with periodic restore tests (an untested backup is a rumor), and the upgrade burden per release. For a team of five to fifty, that totals an afternoon a month. Price that against re-platforming your entire project history onto a new tracker — data migration, retraining, broken links in every old commit message — and the VPS usually wins comfortably.

The real story: a shutdown with an exit strategy​

Most SaaS shutdowns give you thirty days and a CSV export. Huly's gave its users something structurally different, and it is worth naming the four components so you can demand them from every hosted platform before the notice arrives:

1. Scriptable full backup, blobs included. Not an export API that omits attachments, not a CSV of issue titles — a workspace backup plus blob payload that a script can download. Huly had this.
2. A maintained self-host path with version parity. The self-host repo tracks platform releases, so the version you restore is the version you ran — no "community edition, eighteen months behind." Huly had this.
3. Pinnable, mirrorable images. Every release is a tag you can pin and copy to your own registry. Huly had this (with the single-org caveat above, which mirroring solves).
4. A documented import path. An official backup-restore guide plus a community wizard that turns the backup URL into a working workspace. Huly had this.

Score your own vendors against that list this week, while nobody is shutting down. The ones that fail all four are the ones whose shutdown notice will be a data-loss event with a deadline. One footnote for completeness: third-party Huly hosts exist for teams that truly do not want to operate the stack — but moving from one hosted dependency to another re-creates the exact exposure this migration just eliminated, which is why "self-host is the only option" means running it yourself.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.