Examples

Examples

Worked setups, in rough order of difficulty.

A static site from a folder on your Mac

The shortest useful thing. Stacks ▸ + ▸ Nginx + host folder, pick a folder, choose a port. Edit files in your editor, refresh the browser — the folder is bind-mounted, so there's no rebuild step.

Good for previewing a static site, or serving a build output directory while you work on it.

WordPress with its database

Stacks ▸ + ▸ WordPress + MariaDB, then Create. You get:

• mysite-db — MariaDB, data on volume mysite-dbdata, no published port
• mysite-web — WordPress on your chosen port, pointed at the database

Open in Browser lands on the install screen, already connected.

One thing to get right: during setup WordPress records its own site URL in the database. Give it http://localhost:<port>, not a container address — the published port survives restarts, the address doesn't.

Postgres for an app running on your Mac

Stacks ▸ + ▸ PostgreSQL. Published on a port, so your app connects to localhost:5432 like any local database. The data is on a volume, so deleting the stack doesn't lose it.

Add Adminer (the PostgreSQL + Adminer template) if you want a browser UI for it.

Gitea with a CI runner

A good example of adding something to a stack after the fact.

1. The server. Stacks ▸ + ▸ Gitea. Open it in the browser, complete first-run setup, and create a repository.

2. A runner alongside it. A runner is an extra container that has to reach Gitea and be managed with it. Containers ▸ +:

Field	Value
Name	gitea-runner
Image	docker.io/gitea/act_runner:latest
Stack	gitea

Choosing the stack puts the runner in the stack's group, starts and stops it with the stack, and joins the stack's network automatically.

3. Point it at the server. The runner needs Gitea's address. Two options:

• Use Stacks ▸ gitea ▸ Add Service… instead of Containers ▸ +, where you can write GITEA_INSTANCE_URL=http://${IP:gitea}:3000 and have the token substituted for you.
• Or use http://localhost:3000 if the port is published — that survives restarts, where a container address doesn't.

Worth knowing: the runner is deleted along with the stack, and it isn't in the stack's saved definition, so Re-create won't restore it. See adding an existing container to a stack.

Importing a compose file

Take any docker-compose.yml and use Stacks ▸ + ▸ Import Template….

Expect an alert afterwards listing what didn't carry over — that's the importer being honest, not a failure. The usual entries are restart:, healthcheck: and container_name:, none of which change what the stack does. The same list stays in the stack's Log.

Two things that genuinely need action:

• A service with build: is skipped. Build the image under Images ▸ Build Image…, then change the compose file to reference the tag with image:.
• ${VAR} references become fields on the create form. If there's a .env beside the compose file they're prefilled; otherwise fill them in, or use Import .env….

Nothing is created until you click Create, so importing a file to see what it makes of it costs nothing. See Importing docker-compose.

A whole GitOps lab

The examples above are single steps. Building a Fleet GitOps lab puts the lot together: Fleet imported from its own compose file, Gitea, a CI runner you build, and a pipeline that applies configuration to Fleet every time you push — no Docker involved anywhere.

A Linux workspace to build in

Not a container job — a machine.

Machines ▸ + with the alpine image (it has an init system; plain ubuntu doesn't). Your home directory is mounted at /Users/<you> inside it, so you can edit a repo on the Mac and compile it in Linux with no copy step. Use the Terminal tab in the detail pane.

For Ubuntu or Debian, build a machine-ready image first — see building a machine image.