Builds
Setups you can load
A Build is a whole lab arrangement in one small file: which applications, which standing jobs, which of your own compose files. Download one, open it in Ultralab, and the lab is set up that way.
Loading a Build starts nothing and stops nothing. It changes what your lab means to run — everything in it becomes chosen, and anything not in it becomes unchosen. You still press Install on the Apps page, and anything currently running that the new setup does not include is named and left alone rather than torn down.
Starting points
Three arrangements that work, for three sizes of machine. Each one is tested against the catalogue on every change to this project, so a Build here cannot quietly come to name an application that no longer exists.
First shelf 8 GB
The smallest lab worth having. Films and music on the shelf, the folder shared to every machine in the house, and a backup job watching it.
Jellyfin · Samba · Duplicati
Asks you for: nothing.
Photo vault 16 GB
Phone photos land here instead of a cloud plan. Immich with the database and cache it actually needs, plus a backup job pointed at it.
Immich · Samba · Duplicati
Asks you for: nothing. Immich's database password is generated.
Quiet network Pi-sized
DNS the household controls, so the adverts stop on every device without installing anything on any of them. Plus a VPN door in, and something watching that both are up.
AdGuard Home · Unbound · wg-easy · Uptime Kuma
Asks you for: ULTRALAB_WG_HOST, ULTRALAB_WG_ADMIN_HASH.
How to use one
- Download the file. It is small, readable JSON — open it in a text editor if you want to see exactly what it will do.
- In Ultralab, go to Builds.
- Either drop the file into the
builds/folder under your data root, or paste its contents into the box and press Read it and keep it. - Press Load to make the lab mean that setup, or Try in Sandbox to queue the whole thing in the trial plane beside whatever you already have.
- Go to Apps and install what it chose.
Why downloading one of these is safe
You are downloading a description, not a program. A Build cannot:
- Start anything. Loading one records intent. Every install is still a button you press.
- Carry anybody's secrets. No passwords, no keys, no tokens, no logins. If a Build needs a value only you could have, it names it and carries none of it — and if somebody hand-edits a key into one, the receiving lab refuses that key and says so.
- Reach outside your lab. Any compose file travelling in a Build has the author's paths replaced by a token, and your own paths substituted back before your lab's guard reads it. A mount that leaves your data root is refused, exactly as it would be if you had typed it yourself.
- Touch your files. A Build describes the shape of a lab. It contains none of your photographs and cannot delete any.
Read chapter 5 of the manual for the full account of what a Build carries and what it never carries.
Publishing your own
Get your lab working the way you want, then Builds → Save this setup. The
file appears in builds/ under your data root. That file is the whole thing:
send it to somebody, or add it here.
To add one to this page:
- Drop the
.ultralab.jsonintosite/builds/in the repository. - Add a card to this page saying what it is for and what machine it suits.
- Run the tests.
PublishedBuildTestschecks that every published Build loads against the current catalogue, carries no values, and that the list of things it says it will ask for is actually true.
Open the file before you publish it. Ultralab does not put secrets in a Build and refuses to load one that carries them — but it is your file, on your website, and it takes ten seconds to read.