Someone on the family iPad wants Plex restarted. You do not want to explain SSH, sudo, or why docker compose is a sentence. You also do not want a generic "run any command" box on the internet. OliveTin is the boring middle: buttons you defined, arguments you validated, logs you can read later.
OliveTin (OliveTin/OliveTin, ~3.9k GitHub stars, AGPL-3.0, Go) gives a web UI for predefined shell commands. YAML config, touch-friendly dashboard, live output, execution history. Docs: docs.olivetin.app. The project states it plainly: no company owner, no pro tier, no telemetry, works without the internet.
What the buttons actually do
You write actions in config: a title, a shell command, optional argument fields (dropdowns, defaults, validation). The UI is just those actions as tiles. Examples from upstream:
podman restart plexfor people who should never see a terminal.backupScript.sh --folder {{ customerName }}with a dropdown of clients.- Open SSH on the firewall for 20 minutes, then let the timeout close it.
- Wake-on-LAN from a wall tablet.
dnf update -yfrom a phone. Recreate a named container with three docker commands glued together.
Dashboards can group actions by "entities" (servers, containers) so one template fans out into a row of buttons per thing. Logs show who ran what and whether it exited zero. The API is protobuf/Connect, so scripts and agents can hit the same actions without scraping HTML.
It is not a cron scheduler. GoCron and Cronmaster own the "run this every night" job. OliveTin is "run this now, safely, from a tap." Pair them if you want both.
Why self-host?
The commands are your infrastructure: docker sockets, firewall, backups. A SaaS "remote shell dashboard" would hold that blast radius. Self-hosting keeps the YAML, the logs, and the UID the process runs as on your VPS. AGPL-3.0 is fine for in-house use; if you offer OliveTin as a multi-tenant product over the network, understand copyleft.
"Safe" here means you decided the command and the allowed arguments, not that a web form can never be abused. If OliveTin runs as root and an action interpolates a free-text field into bash, you built a foot-gun. Prefer dropdowns and allow-lists. Put TLS and auth in front (OliveTin has ACL/auth options in the docs; an authenticating reverse proxy is still a good idea). Do not publish port 1337 naked.
Quick start
Images: docker.io/jamesread/olivetin or ghcr.io/olivetin/olivetin. Tags include latest (currently 3k line), latest-3k, and latest-2k if you are not ready to jump majors. There is a 2k-to-3k upgrade guide on the docs site.
docker run -d --name olivetin -p 1337:1337 \
-v /etc/OliveTin:/config \
ghcr.io/olivetin/olivetinThen edit config.yaml under that volume. Packages exist for Linux, plus notes for FreeBSD, Windows, and macOS. Resource use is a few MB of RAM; the cost is whatever the commands you expose can do to the host. If actions need Docker, mount the socket on purpose, knowing that is host-level container control.
Who it is for
Good fit: homelabs with non-technical family; MSPs giving juniors a form instead of root; wall tablets for WoL and scene scripts; anyone tired of texting "restart it" to the person with SSH.
Skip it: if you need scheduled DAGs (Kestra, Dagu, Airflow); if you want people to edit crontab in a browser (Cronmaster); if every command is a one-off you type yourself.
Hosting in Canada
OliveTin is tiny. A small CloudBox VPS can run it next to the stack it controls, or you run it on the same box as Docker. Canadian hosting matters because the logs are an audit of who restarted what. Back up config.yaml in git (without secrets). Keep the UI on a private hostname.
Bottom line
OliveTin is a remote control for commands you already trust, not a general-purpose shell. YAML in, buttons out, logs forever. That is the whole pitch, and it is a good one if you are the person everyone pings at 11 p.m.
Talk with Swift Host if you want OliveTin on a Canadian VPS with TLS and sensible auth. We are in St. Albert and actually answer the phone.
