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.
You are told, once, if the machine was running a live service or a database when it stopped answering — in the dashboard and on whatever notification channels you have set up, with the all-clear when it comes back. A machine holding only dev boxes goes quiet in silence: a laptop lid closing at six is not an incident, and a nightly outage notice is how a channel gets muted.
Our own oncall is deliberately not paged for it. Your hardware being off is not our outage, and alerting on it would make the same alert worthless for the machines where it does mean something is wrong.

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.
Large dumps go up in parts. The storage API refuses a single upload over 5 GB, so anything bigger is split and reassembled on our side, up to 32 GB compressed. You do not have to do anything, and past that 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.

A swap is only kept if the new agent comes up and passes its own healthcheck. If it does not, the machine is put back on the build it had — nothing on it is stopped and no data is touched — and the Machines page says what went wrong, in the words the machine itself reported. That is the reason to read rather than re-running the installer on a hunch.

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.

If the bill goes unpaid

Own-hardware environments past the free allowance are charged like anything else, so they are also dunned like anything else: a notice, then seven days, and only then does anything change. What changes is different, though, and worth knowing before it happens.

We do not stop anything on your machine. We stop carrying the traffic and we pause the terminal — which is the part the fee pays for. Your container keeps running, your data is untouched, and anything on your own network still reaches it exactly as before. Visitors get a page saying the service is not being served rather than a broken connection. Add a payment method and it starts being served again within seconds, with nothing to redeploy.

Requirements and limits

Linux on x86-64 with cgroup v2. WSL2 counts, and Docker is installed for you if the machine does not have it.
Windows has its own installer: a PowerShell line that drives Docker Desktop in Linux-container mode directly, with no WSL distro to set up.
On macOS you run the Linux one inside a Linux VM — the Machines dialog hands you the multipass commands that create it.
Apple Silicon and ARM boards (a Raspberry Pi, for instance) are not supported: the agent image is amd64 only.
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 — you can do that while the machine is off, and the containers are cleaned up the next time it connects.