OliveTin

A self-hosted button panel for your server — honestly reviewed. No marketing fluff, just what you get.

TL;DR

• What it is: A lightweight web interface that wraps predefined Linux shell commands in buttons. You define the commands in YAML; your family, your junior admin, or your phone presses the button [2][README].
• Who it’s for: Homelab owners who want to hand off routine server tasks to non-technical people without handing them a terminal. Also useful for solo admins who want a touchscreen-friendly operations panel [1][2].
• Cost: Free. $0. No cloud tier, no premium version, no SaaS. You run it yourself on hardware you already own [website].
• Key strength: The premise is so narrow and so well-executed that there’s almost nothing to complain about. It does one thing — put a web button in front of a shell command — and it does it with almost no overhead [README][2].
• Key weakness: It’s a button panel, not an automation engine. If you want triggers, schedules, conditionals, or multi-step workflows, you’re looking at the wrong tool. It also requires you to know what shell commands you want to expose — it doesn’t help you figure that out [1][5].

---

What is OliveTin

OliveTin is a Go web server that reads a YAML config file and renders a dashboard of buttons. Each button maps to a shell command. Press the button, the command runs on the machine running OliveTin. That’s the entire product.

The GitHub description is refreshingly blunt: “OliveTin gives safe and simple access to predefined shell commands from a web interface.” [README] The word “safe” is load-bearing here — the safety comes not from any sandboxing or permissions model, but from the fact that users can only run the exact commands you’ve pre-defined. They can’t type arbitrary commands. They get buttons.

A minimal config looks like this:

listenAddressSingleHTTPFrontend: 0.0.0.0:1337
actions:
  - title: Restart Plex
    icon: restart
    shell: docker restart plex

  - title: Ping host
    shell: ping {{ host }} -c {{ count }}
    arguments:
      - name: host
        type: ascii_identifier
        default: example.com
      - name: count
        type: int
        default: 1

That’s a functional OliveTin deployment. The dashboard shows two buttons — one that restarts Plex, one that pings a host with a dropdown for the target. [website]

The project is genuinely independent: no company funds it, it has 3,483 GitHub stars, and the maintainer explicitly says donations are not accepted. The AGPL-3.0 license means it’s fully open source, and unlike n8n’s “Fair-code” licensing, there are no commercial restrictions buried in fine print. There is no premium tier. There is no enterprise version. The version you download is the only version [website][README].

---

Why people choose it

The XDA Developers review [2] tells the story directly: the author runs a Raspberry Pi 4B serving Jellyfin, Navidrome, and Audiobookshelf for his family. When something stops working and he’s not home, he can’t expect his mom to SSH into the server and restart a systemd service. He tried walking family members through a terminal over the phone. It didn’t work.

OliveTin solved that. A bookmarked URL on a phone, a few taps, problem handled. The review specifically notes he considered Script-Server and RunDesk but ruled them out as more complex than needed [2].

The LinuxLinks review [1] frames it the same way: the audience is people who need to run commands but shouldn’t be expected to know how. Junior admins, family members on shared homelab infrastructure, anyone running services on hardware that’s physically inconvenient to reach.

The Homelab Wiki [3] treats it matter-of-factly as a standard piece of homelab infrastructure — a solved problem you deploy once and forget about.

What’s conspicuously absent from all the coverage is anyone complaining that it does too much or that it’s overcomplicated. That’s diagnostic: the tool is in tight alignment with its stated purpose.

---

Features

The full feature set from the README and website, without editorial inflation:

Core:

• YAML config file — define actions as shell commands [README]
• Parameterized commands — users can fill in dropdowns or text fields for specific argument types (ascii_identifier, int, etc.) [website][2]
• Responsive, touch-friendly UI — works on phones and wall-mounted tablets [README]
• Auto light/dark mode [website]
• REST/Connect RPC API — the backend is a gRPC service with a web frontend talking to it [README]
• Accessible — passes Firefox accessibility checks [README]

Deployment:

• Linux packages (.deb, .rpm) for direct installation [2]
• Docker / Podman / docker-compose / Kubernetes support [README][5]
• Cross-platform: Linux, Windows, macOS, FreeBSD [2]
• Very low resource usage — a few MB of RAM, minimal CPU, written in Go [README]

What it doesn’t have:

• Scheduling / cron triggers
• Webhooks as triggers
• Conditional logic or branching
• Any kind of automation workflow beyond “button → command”
• User authentication built-in (you front it with a reverse proxy)
• Multi-user management or RBAC

The REST API enables integration with external tools — you can trigger OliveTin actions programmatically — but this is documented as a capability, not a focus [README].

---

Pricing: SaaS vs self-hosted math

There is no SaaS version of OliveTin. There is no pricing to compare. The software is AGPL-3.0, free to download and run, and the maintainer explicitly refuses donations. The project page lists this under “No Nonsense”:

No SaaS service or “special cloud version”. No “anonymous data collection”, usage tracking, user tracking, telemetry or email address collection. [website]

What it costs to run:

• If you already have a Raspberry Pi or home server running other services: effectively $0/month additional (resource usage is negligible)
• If you’re spinning up a dedicated VPS to run only OliveTin: $4–6/month on Hetzner or similar — though this would be unusual since OliveTin runs alongside other services

There’s no comparable SaaS product to benchmark against. The closest commercial equivalent would be something like a hosted runbook tool or a PagerDuty automation action, but those are enterprise products priced for engineering teams, not homelab operators. OliveTin fills a gap that doesn’t have a direct SaaS equivalent at the consumer level.

---

Deployment reality check

The XDA Developers review [2] is the most useful practical account, because the author walked through actual installation on a Raspberry Pi 4B running Pi OS Lite. He explicitly chose the .deb package route over Docker, with a clear reason: newcomers to containers frequently run into bind-mount and file permission problems. If you’re not comfortable with Docker volume syntax, a native package install is less friction [2][5].

Install steps for the direct method:

wget https://github.com/OliveTin/OliveTin/releases/latest/download/OliveTin_linux_arm64.deb
dpkg -i OliveTin_linux_arm64.deb

Then open http://hostname:1337 in a browser. That’s the install.

The OliveTin documentation [5] addresses a common gotcha for Docker installs: if your actions need to access the host filesystem (running scripts, reading config files), you need to bind-mount those paths into the container. This works, but if you’re new to containers, a direct install is simpler. The docs recommend SSH as an alternative: run OliveTin in a container but have your actions SSH back to the host. Inelegant but functional [5].

What can trip you up:

1. Authentication is not built in. OliveTin doesn’t ship with a login screen. You expose it on a port and anyone on the network can press the buttons. For a homelab on a private LAN, this is often fine. If you want authentication, you need a reverse proxy (Nginx, Caddy, Traefik) with basic auth or SSO in front of it.

2. The config is YAML, not a GUI. There’s no admin interface for adding actions — you edit the config file and restart the service. This is fine for technical users; it’s a limitation for purely non-technical self-hosters who wanted a point-and-click setup.

3. No audit logging by default. You can see command output in the web UI, but persistent logs depend on your system logging setup. For compliance-sensitive environments, this requires extra work.

4. Container-vs-service friction is real but documented [5]. The docs page on this topic is unusually helpful — it actually tells you when not to use Docker.

Realistic setup time for a technical user who’s done a Linux service install before: 15–30 minutes. For someone new to Linux servers: 1–2 hours, mostly getting the reverse proxy and YAML syntax right.

---

Pros and cons

Pros

• No cost, ever. Not freemium. Not open-core. No tier that gates features behind payment. AGPL-3.0 with no commercial restrictions on self-hosting [website].
• Extremely lightweight. A few MB of RAM, near-zero CPU at rest. Runs comfortably alongside other services on a Raspberry Pi 4B [README][2].
• YAML config is version-controllable. Your entire OliveTin deployment lives in one file you can commit to git and restore instantly.
• Cross-platform binaries. Linux, Windows, macOS, FreeBSD — unusually broad support for a homelab tool [2].
• Works on mobile and tablets. The responsive UI is actively maintained and passes accessibility checks. The author of the XDA review notes his family bookmarked it on their phones and that’s how they troubleshoot now [2][README].
• No telemetry, no tracking, no internet dependency. The website lists this explicitly. Versions prior to 2024.06.02 had update-check pings; those were removed [website].
• Clear, honest documentation. The install documentation actively steers users away from the Docker path when a direct install is more appropriate [5]. That’s a sign of a maintainer who cares about users having a good experience rather than looking impressive.

Cons

• No authentication built in. This is the most commonly noted limitation. You need a reverse proxy for any auth. For LAN-only deployments it’s fine; for anything internet-facing it’s a required extra step [1].
• No scheduling or triggers. OliveTin responds to button presses, full stop. If you want a command to run on a cron schedule or in response to a webhook, you’re using the wrong tool.
• Config-file-only setup. Adding or changing actions requires editing YAML and restarting. There’s no admin UI. This is acceptable for technical users but rules out purely non-technical self-hosters configuring it themselves.
• Small GitHub footprint. 3,483 stars is respectable but not large. The project has no organizational backing, no commercial entity behind it. Long-term continuity depends on the maintainer’s continued interest [README].
• AGPL-3.0 restriction. If you’re building a commercial product that embeds OliveTin, you’d need to comply with AGPL copyleft requirements (release your modifications). For homelab use this doesn’t matter at all, but it’s worth noting for anyone considering embedding it in a product.

---

Who should use this / who shouldn’t

Use OliveTin if:

• You have a homelab and non-technical family members or housemates who occasionally need to restart a service.
• You want a touchscreen “operations panel” on a wall-mounted tablet for your home server.
• You’re a junior-admin-friendly organization that wants to give limited, predefined access to server operations without full SSH access.
• You want a web-accessible button to run a command from your phone when you’re away from home.
• You already have a VPS or Pi running and just want to add one more lightweight service.

Skip it if:

• You need any kind of automation beyond a single button triggering a single command chain — use n8n, Activepieces, or Node-RED instead.
• You need built-in authentication — you’ll need to layer a reverse proxy regardless, so evaluate whether that extra step is acceptable.
• You want a GUI for configuring commands — the YAML-only config is a non-starter for purely non-technical users setting it up themselves.
• Your use case is monitoring or dashboarding rather than action-triggering — Grafana, Uptime Kuma, or Netdata fit that need better.

---

Alternatives worth considering

• Script-Server — similar concept, closer to a web UI for running scripts with more complex execution logging. The XDA review author considered and rejected it as more complex than needed for his use case [2].
• RunDesk — another shell-command web UI, also ruled out in the XDA review for being more complex than necessary [2].
• n8n — full workflow automation engine. Correct choice if you need triggers, scheduling, conditionals, and multi-step flows. Massive increase in complexity and resource usage compared to OliveTin.
• Activepieces — Zapier-style automation, MIT-licensed. Same category as n8n — far more powerful, far more complex.
• Node-RED — flow-based programming environment, popular in the homelab community for IoT and home automation. Good if you want visual flow editing.
• Home Assistant automations — if you’re already running Home Assistant, its automation engine and dashboard can accomplish many of the same button-press-triggers-action patterns without adding another service. The XDA author specifically notes his family was comfortable with a Home Assistant dashboard, which is what led him to OliveTin as the analogous tool for server commands [2].
• Just cron + a shell script — if no one else needs to run the command, schedule it yourself.

---

Bottom line

OliveTin is a solved problem packaged cleanly. The scope is deliberately minimal — a web button that runs a shell command — and everything in the project reflects that intentionality: the YAML config, the lack of a premium tier, the documentation that steers you toward the simpler install method, the explicit list of things the project refuses to do (telemetry, SaaS, donations). If your problem is “I need a non-technical person to restart Jellyfin without touching a terminal,” OliveTin is the correct answer and you’ll have it running in under an hour. If your problem is anything more complex than that, OliveTin is the wrong tool, and you’ll know immediately.

The AGPL-3.0 license, zero ongoing cost, and resource footprint that won’t register on a Raspberry Pi make this a no-risk addition to any homelab stack. The main question isn’t whether to use it — it’s whether your use case fits inside the very narrow problem space it’s designed to solve.

---

Sources

1. LinuxLinks — “OliveTin - give safe and simple access to predefined shell commands from a web interface”. https://www.linuxlinks.com/olivetin-simple-access-predefined-shell-commands-web-interface/
2. Samir Makwana, XDA Developers — “I made my family run shell commands from a web interface and they loved it” (Jun 4, 2025). https://www.xda-developers.com/made-family-run-shell-commands-from-web-interface/
3. The Homelab Wiki — “OliveTin — Linux Shell Web Interface”. https://thehomelab.wiki/pages/recently-updated?page=3
4. Ethan Sholly, selfh.st — “This Week in Self-Hosted (18 October 2024)”. https://selfh.st/weekly/2024-10-18/
5. OliveTin Documentation — “Containers vs Services”. https://docs.olivetin.app/install/container_vs_service.html

Primary sources:

• GitHub repository and README: https://github.com/OliveTin/OliveTin (3,483 stars, AGPL-3.0)
• Official website: https://www.olivetin.app
• Official documentation: https://docs.olivetin.app