HomeDock OS, a browser desktop that installs your self-hosted apps

A desktop shell that treats containers as applications

HomeDock OS is presented as a self-hosted cloud OS for a home server, and the pitch in the README is specific: 800+ self-hosted apps, a real desktop in your browser, and every file you own a double click away, free, private, and running on whatever hardware you already have.

The framing is what makes it interesting. Instead of asking you to learn the admin interface of every service you run, it puts a desktop metaphor over the whole set. The screenshot sequence shows a Start menu search, Jellyfin presented as an on-screen app, a spreadsheet, a PDF viewer and a writer, an image viewer, video and music with a live spectrum, Quick View, the App Store, and a terminal application called Packet Snake. The apps you install are still the Docker containers you already know, but they are reachable through one interface.

The numbers in the README are worth taking at face value only as claims of the project's own scope. It lists 800+ apps, of which 180+ are curated in the official App Store and six more community stores are one click away. It claims 80+ file types open directly in the browser, covering photos, camera RAWs, PSDs, spreadsheets, Word documents, PDFs, code, music and video, with zero plugins to install because the office suite, the codecs and the image editor all ship inside the system. And it claims three operating systems on four architectures, Linux, macOS and Windows on x86, x86_64, ARM and ARM64, down to a Raspberry Pi Zero.

None of that is the hard part. The hard part is what the container needs from your machine to make it work.

Deployment is a compose file with seven mounts

The Docker Compose file in the repository is the clearest statement of what HomeDock OS actually is, a single container that manages other containers. The published image is bansheetech/homedock-os:latest, the container is named homedock-os, and it restarts unless stopped:

services:
  homedock:
    image: bansheetech/homedock-os:latest
    container_name: homedock-os
    restart: unless-stopped
    ports:
      - "13370:80"
      # - "13371:443" # Enable for Let's Encrypt SSL
    volumes:
      - ./homedock-data/DATA:/DATA
      - ./homedock-data/config:/homedock/config
      - ./homedock-data/compose:/homedock/compose-link
      - ./homedock-data/packages:/homedock/_user_packages
      - ./homedock-data/dropzone:/homedock/dropzone
      - ./homedock-data/logs:/homedock/logs
      - /var/run/docker.sock:/var/run/docker.sock

The volume list explains the data model. The DATA directory is the storage your apps see, config holds the server configuration files, compose-link is where the generated compose projects for installed apps live, _user_packages holds user-installed packages, dropzone is the inbox for files you drag in, and logs collects the service output. Every path is under a single homedock-data folder on the host, so the whole state of the system is one directory you can back up.

The Dockerfile adds the rest of the shape. The base image is python:3.12-alpine, the working directory is /homedock, the entry point is entrypoint.sh, and the container exposes ports 80 and 443. The image installs bash, curl, jq, shadow, docker-cli and docker-cli-compose, then installs the Python requirements and removes the build dependencies in the same layer.

A Flask service under a Vue 3 front end

The repository is a two-part application, and the file layout says so. homedock-ui/ holds the front end, built with Vite and Vue 3, and homedock.py plus the pymodules/ directory hold the Python service that talks to Docker. The package.json scripts are the front end's own: dev runs vite, build runs vite build, preview runs vite preview, typecheck runs vue-tsc, and test runs vitest.

The Python dependency list is where the interesting capabilities show up:

Flask==3.1.3
Flask-Login==0.6.3
docker==7.2.0
python-on-whales==0.81.0
requests==2.34.2
PyYAML==6.0.3
bcrypt==5.0.0
cryptography==48.0.1
zeroconf==0.151.5
pyotp==2.10.0
Hypercorn==0.17.3
aiohttp==3.14.4
Pillow==12.3.0

The docker and python-on-whales entries are how the system talks to the Docker daemon, the official SDK and a Compose-oriented wrapper. bcrypt and cryptography cover credential hashing and transport security, and Flask-Login covers the session model for the desktop itself. pyotp is a two-factor token library, which tells you the system handles authenticator-style secrets. zeroconf is for service discovery on the local network, and Pillow is for the image handling behind the picture and RAW viewing.

The front end dependencies tell the same story from the other side. CodeMirror provides the code editor, the docx-editor and fortune-sheet packages provide the Word and spreadsheet surfaces, xterm provides the terminal, zip.js handles archives, and ant-design-vue is the component library. That is a desktop built in the browser rather than a set of embedded web apps.

One certificate for every app you install

The claim that stands out technically is the single certificate. The README says one automatic Let's Encrypt wildcard covers every app you install, without opening a port for it. The compose file has the matching hook, a commented mapping of port 13371 to 443 with the note to enable it for Let's Encrypt SSL.

The problem this solves is the one every self-hoster hits. Each app you install normally wants its own hostname and its own certificate, which means asking for a certificate per app, opening ports per app, and either renewing them or letting them expire. A wildcard certificate covers a whole domain, so every app can be published under a subdomain of that domain and ride the same renewal.

The cost is that a wildcard certificate is issued for a domain, not for an app, and the certificate has to be issued by whoever controls that domain's DNS. The README does not document how the domain and the challenge are wired up for you, so that part is on the operator to arrange.

The zero plugin claim is the other thing that makes the desktop coherent. Rather than asking you to install an office suite, video codecs or an image editor to make the file viewer work, the system ships those capabilities inside itself, which is why 80+ file types are claimed to open directly in the browser.

The Docker socket mount is the security decision

Look again at that last volume line. The compose file mounts /var/run/docker.sock into the container, and the file also sets the label HDDockerInDocker=true and adds host.docker.internal to extra_hosts so containers it launches can reach the host.

That socket is the Docker daemon's control socket. Anything holding it can start containers, which in practice means root on the host for anyone who can talk to the daemon. The HomeDock container needs it, because the whole product is about installing and managing other containers on your machine, but the consequence is that a compromise of the web interface, or of the Python service behind it, is a compromise of the host rather than of one app.

This is a normal trade-off for a container management interface, and it is not a criticism of the project, but it is a decision the operator has to make knowingly. The exposure is the desktop itself, reachable on port 13370 on the host by default. The README does not document a hardened deployment with an authenticating reverse proxy in front of it, so anyone running this on a home network should think about what else can reach that port.

Two smaller details sit in the same file. The timezone is set to Europe/Madrid, matching the project's Spanish origins, and the compose file sets PYTHONUNBUFFERED=1 so that container logs are not buffered.

PolyForm Strict means source available, not open source

The licence is the thing to read before anything else. The package.json declares PolyForm Strict License 1.0.0, the Dockerfile header points at LICENSE.md and at the polyformproject.org strict licence page, and the repository's own metadata lists a custom licence that GitHub cannot classify. The project is therefore source-available under a restrictive grant rather than open source.

PolyForm Strict is designed for non-competing use. You can run the software, and you can use it commercially inside your own organisation, but the grant is conditional on the software not being used to compete with the licensor, and it does not grant the rights of an open source licence such as the right to modify and redistribute freely. For a homelab user running it on their own hardware, that distinction is academic. For a company that intends to fork it, rebrand it, or offer it as part of a product, it is decisive.

The project is otherwise pitched as free forever, with the README stating a price of zero, no trial, no account and no strings attached, and the full desktop free. Those are statements about cost, not about permission, and the two should not be read as the same thing.

The rest of the supporting material is in place for a project at version 2.6.2.104: a CHANGELOG.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md, a SECURITY.md for responsible disclosure, documentation at docs.homedock.cloud, and uninstall.sh and update_requirements.py for maintenance tasks. The last push to the repository was on 2026-10-08, and there are no GitHub releases, so the changelog is where version history lives.

Running compose stacks yourself is the alternative

The alternative to HomeDock OS is to skip the desktop and run your apps as compose projects yourself, with a reverse proxy in front for hostnames and certificates, and a file manager or a terminal over SSH for the rest. The difference in approach is that you own every layer instead of getting a curated front end.

What you gain by going it alone is control over the compose files, the network layout, the certificate lifecycle and the exposed ports, and you can pick any reverse proxy you like. What you give up is the single interface, the app catalogue that installs an app and its compose file in one step, and the in-browser file viewing with 80+ formats.

The honest framing is that these are two different layers of the same stack. HomeDock OS does not replace Docker, it drives Docker through a web interface on top of it, and an experienced homelab operator will end up dropping to the compose files anyway when something breaks. The value it adds is for the operator who has a dozen services and does not want to remember twelve URLs and twelve sets of credentials.

If the domain and certificate arrangement is what worries you, that is also the part to test first, because the desktop, the app store and the file viewer are the parts that are easy to try and hard to replicate.

Editorial conclusion

HomeDock OS fits a homelab owner who wants a single desktop for a stack of self-hosted apps and is willing to give a container the Docker socket of the host. It does not fit a team that needs a permissively licensed codebase to modify and redistribute, because PolyForm Strict is a source-available licence with use restrictions, or anyone who will not accept that level of host access. Before you deploy it, read LICENSE.md, check the compose file's port mapping and volume list against your own setup, and decide whether the single wildcard certificate model matches the domains you actually serve.

Frequently asked questions

Official sources

1. BansheeTech/HomeDockOS on GitHub
2. Issues
3. Project website
4. README