Websoft9: a private app store inside one Docker container

A single container bundles four components under supervisord

Websoft9 ships as one Docker container with four open source pieces inside it. AppHub, written in Python with FastAPI, is the business API and owns the app catalog, the application lifecycle, authentication and settings. The Console, a React and TypeScript interface, is what you actually click. Portainer handles container and stack orchestration. Nginx Proxy Manager sits in front for reverse proxying, domain binding and TLS certificates. One supervisord process supervises all four inside that container, and the architecture notes frame this as simple to deploy and easy to upgrade.

That shape has consequences worth knowing before you commit. The container, not the individual service, is the unit you upgrade, and the installer's --version <tag> flag defaults to latest, so a rebuild can pull an image newer than the one you first installed. Because supervisord owns four processes in one namespace, restarting the container takes the API, the web console and the reverse proxy down in the same moment, and none of the four scales on its own. Fewer moving parts on the host is what you buy, and less granular control during an incident is what you pay.

The installer fetches install.sh from a first-party artifact host

Installation is one download and one root shell on any Linux server that already has Docker.

# Install on any Linux server with Docker
wget -O install.sh https://artifact.websoft9.com/websoft9/release/install.sh && sudo bash install.sh

Two things are worth noticing. The script does not come from GitHub. It comes from artifact.websoft9.com and is piped straight into a root shell, so what runs is whatever that endpoint serves at the moment you run it, not a copy you can read first. The installer also takes options before it changes anything. --console-port <port> sets the web console port, defaulting to 9000. --version <tag> pins the image tag, and its default of latest means an unpinned install. --path <dir> sets the installation directory, defaulting to /opt/websoft9. --yes skips confirmation prompts. --dry-run runs pre-flight checks only and changes nothing. --force is narrower than it sounds: it skips non-destructive pre-flight checks, which means it still writes to the server and still runs whatever checks are destructive. On a machine you care about, --dry-run is the one to try first.

Port 9000 opens a wizard, and the demo console is public

Once the installer finishes, you open the server address on port 9000 in a browser and follow the setup wizard. Two details are easy to skim past. The quick start links the console over plain http rather than https, while the feature list puts free Let's Encrypt certificates under Proxy & SSL, which covers application domains fronted by Nginx Proxy Manager. How the console's own port 9000 receives a certificate is not documented, so on an internet facing server that first screen is unencrypted until you handle it yourself.

A demo instance is linked from the same place, and its credentials are printed in plain text: user demo, password Websoft9@. That is genuinely useful for looking at the interface before installing anything, and it also means anyone can walk that console. The demo is a separate host from your own install, so nothing you do there reaches your server, though it is worth knowing what state a shared demo holds before treating its screens as a preview of your data.

Portainer bundled inside the panel leaves two admin surfaces

Portainer is not a separate product you install alongside Websoft9. It ships inside the container and handles container and stack orchestration, which makes it the obvious comparison point. Portainer on its own manages Docker through containers and compose projects, and stops there. Websoft9 keeps that layer and adds three things above it: a catalog of 300+ applications built from templates in the docker-library repository, a Compose interface for custom stacks, and a domain and certificate layer through Nginx Proxy Manager. The unit of management is the real difference. In Portainer a stack is what you wrote in a compose file. In Websoft9 a stack is an application template you pick from a catalog, and My Apps then gives you start, stop, restart, redeploy, log viewing, file management and volume management per application.

What the quick start does not say is how Portainer's own interface is reached or ported once it lives inside Websoft9, or how its access is separated from the console's role based user accounts. Two admin surfaces over the same Docker engine is the arrangement to check before you hand access to a team.

Two uninstall modes, and only one of them keeps your volumes

The uninstall block offers two modes and the difference between them is total.

# Standard uninstall (keeps data volumes)
sudo bash uninstall.sh

# Purge uninstall (removes everything including data)
sudo bash uninstall.sh --purge

Run plain, the script removes the panel and keeps data volumes. Add --purge and it removes everything, data included. Neither command carries a path, so it has to be run from wherever the installer left it, which by default is the /opt/websoft9 installation directory. No way back is documented once the purge variant has run.

That is the one irreversible step in an otherwise reversible panel. Scheduled local backups for applications and databases are listed as a feature, so before running either form, confirm that a backup job has actually executed against the applications you care about rather than assuming the feature means the data is safe.

Cloud marketplace images carry a publishing restriction

Websoft9 is listed on the Azure, AWS, Alibaba Cloud, Huawei Cloud and Aliyun marketplaces with business support, and the deployment guide for those environments sits in docs/deployment.md. Underneath that commercial packaging there is an awkward detail. The licence field on the project page reads Other, a custom licence GitHub cannot classify, while the same page's readme states LGPL-3.0 and adds that publishing free or paid images based on this repository to any cloud platform marketplace without authorization is prohibited. The badge near the top renders the plain label LGPL v3 and carries no marketplace clause at all.

Read together, the practical meaning is narrow. The code is offered under LGPL-3.0, and the same readme forbids the redistribution that the marketplace listings sell. If your plan is to build an internal image and share it through a private registry, that clause is the part to read first, because the readme does not define who counts as authorized or how to request it.

Repository topics promise Kubernetes, the quick start says none is needed

The repository tags itself with kubernetes, cloud-native, iaas, portainer and paas, and the quick start promises a single server with no Kubernetes required. Those tags read like catalogue keywords for discoverability rather than a dependency claim. Portainer is the one that names something the container actually bundles. The declared primary language is TypeScript, which matches the React Console and quietly leaves out the Python AppHub that carries the catalog, the lifecycle and authentication.

The root listing is where the gaps sit. Alongside .github/, apphub/, console/, docker/, install/, scripts/ and docs/ there sit version.json and mirrors.json, yet none of the six linked documents, from docs/user.md through docs/api-reference.md, come with any content here. REST endpoint shapes, the upgrade path for an existing install, the resource floor and the supported distribution list all sit outside what can be confirmed. The install line says only any Linux server with Docker, with no minimum RAM, CPU or disk figure attached. The last push was on 2026-09-28, and the release tags recorded are 2.4.0 on 2026-08-28, 2.4.1 on 2026-09-08 and 2.4.2 on 2026-09-23. Pin a tag with --version rather than leaving the default of latest if that cadence is not what you want to track.

Editorial conclusion

Adopt Websoft9 when you want curated application templates instead of raw Docker control, and when replacing one container in a single move matters more than giving each service its own lifecycle. Stay with Portainer alone if you already own your compose files and your domains and want no catalogue in the way. Before installing, run the script with --dry-run on a spare machine, decide whether plain http on port 9000 is acceptable on day one, and read the marketplace publishing clause before you build and share your own image.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. Websoft9/websoft9 on GitHub