Your Own Machines

Enrol hardware you already own — a spare desktop, a home server, a VPS you pay for anyway — and run HostStack dev boxes and live services on it. Same dashboard, same deploys, same logs and terminal. You supply the CPU and the memory, so there is no compute charge.

Enrolling a machine

Go to Machines in the dashboard and add one. Give it a name and you get a one-line command carrying a single-use pairing token, good for 15 minutes. Run it on the machine:

bash

curl -fsSL https://hoststack.dev/api/agents/install.sh | sudo HOSTSTACK_PAIRING_TOKEN=… bash

On Windows, the Machines page also gives you a PowerShell command that drives Docker Desktop directly and needs no WSL distro.

What the installer changes

It checks the machine over before touching anything and reports every problem at once, then prints back exactly what it did. Concretely:

Docker, if the machine does not have it, via Docker's own installer at get.docker.com. Set HOSTSTACK_NO_DOCKER_INSTALL=1 to skip that and install it yourself. If Docker is present but stopped, the installer starts and enables it rather than giving up.
One container, named hoststack-agent, set to restart with the machine.
One credential file, mode 0600, under /var/lib/hoststack-agent.

Undo all of it with:

bash

docker rm -f hoststack-agent && sudo rm -rf /var/lib/hoststack-agent

The agent is privileged and mounts the Docker socket. That is root-equivalent on the machine — the Docker socket alone already is. The agent needs it to create your containers and to set their CPU priority. Enrol machines you are willing to grant that on, and note that anyone who can enrol a machine into your team can also read what runs on it; enrolment requires the admin role for that reason.

How traffic reaches it

The agent dials out to HostStack and everything rides that connection. Nothing on the machine listens for us, so there is no port to forward, no fixed IP to have, and no firewall change to make. Requests arrive at our edge, keep their HTTPS certificate there, and are carried down to your machine — which is why a dev box on a laptop still has a working public URL, and why a custom domain on a service running at home still works.

Bind your process to 0.0.0.0 rather than localhost, or nothing outside the container can reach it.

When the machine is off

This is the trade, and it differs by workload:

Dev boxes wait. Their files live on that machine's disk and are still there when it comes back. Volume backups are on by default for BYO precisely because one consumer SSD replaces replicated storage.
Live services go down with it, and come back on their own when the machine returns. If that is not acceptable, run them on HostStack compute — that is what it is for.
Databases go down with it too, and take whatever reads from them down as well. The data is on that machine's disk and is not lost; the most recent nightly backup is held off-site with us regardless.
No alert fires when your machine goes offline. A laptop lid closing is not an incident, and paging on it would make the offline alert worthless for the machines where it matters.

Databases on your machine

A managed database can be created on one of your machines the same way a service can — pick it under Where it runs. Postgres, MySQL, MariaDB, MongoDB and Redis all work, and everything you would normally do with a managed database still works: the dashboard, logs, metrics, the query console, user management, backups and restores.

One rule comes with it, and it is worth reading before you build on it: a database on your machine is reachable only from that same machine. A project's network is local to the host it runs on, so a service in our datacentre has no route to a database in your office. We refuse to link the two rather than let the service deploy, pass its health check, and then fail on its first query. Put the app on the same machine, or keep the database with us.

Backups still leave the building. The nightly dump is taken on your machine and uploaded to our off-site storage, so it survives the machine itself — a copy on the disk you are protecting is not a backup. Your machine is never given a storage credential: the control plane signs a URL for that one file, for that one upload.
A missed night is caught up. The schedule runs at 02:00 UTC and a machine that is off then obviously cannot take one — so the backup is taken shortly after it next connects instead, rather than being skipped until the following night. The database's Backups page shows when the last one actually happened, and you can take one on demand whenever the machine is up.
No external connections. Publishing a database means handing out an address at our edge, and your hardware is not behind it. Connect from the machine, or expose it yourself on your own network.
No high availability. An HA cluster is three nodes that must not fail together, and one desktop cannot be that. Databases here are always single-node.
A single backup upload is capped at 5 GB compressed by the storage API. That is a very large dump — but if you exceed it the Backups page says so by name rather than failing quietly.
There is no charge at all: no size price, and no per-environment fee (that one is charged per service).

Agent updates

HostStack offers the machine each new agent build when it connects and every 15 minutes after, and the agent swaps itself over once nothing is running on it. You should not need to re-run the installer. The Machines page shows what build each machine is on; press Update now if you would rather not wait.

An agent built from a local source checkout is never replaced automatically — that would discard whatever is in the tree. Those show as Running from source rather than as up to date, because we cannot tell what is in them.

What it costs. €3/month per environment — dev boxes and services alike — with your first one free. No size price, because the size buys CPU and memory from us and here it does not. Bandwidth we carry is metered at our edge, at the same rate and against the same free allowance as everywhere else — traffic on your own LAN is not counted.

Requirements and limits

Linux on x86-64, with cgroup v2. WSL2 counts. The agent image is amd64 only, so Apple Silicon and ARM boards (a Raspberry Pi, for instance) are not supported.
Windows works through Docker Desktop in Linux-container mode; on macOS, run it inside a Linux VM.
A database on your machine is reachable only from that machine, and cannot run as an HA cluster or accept external connections. See above.
Your machine is never a placement target for anyone else's workload. It is excluded from the scheduler structurally, not by a setting.
Removing a machine is refused while anything is pinned to it. Move or delete those first.