← All posts
Kristijan Lukačin28 April 20265 min read

Environment Actions: stop SSH-ing in to clear a cache

The small operational tasks every project needs but nobody wants to document. v1.4 turned them into buttons in the dashboard.

Every project we have ever shipped has the same dusty drawer of operational tasks. Clear the application cache. Reindex the search engine. Dump the staging database. Rotate that one secret that nobody remembers how to rotate.

For years, the answer was the same: SSH in, find the right script, hope you are on the right server, run it, copy the output, paste it somewhere, log out. Five minutes of glamour-free work that nobody wants to do, and which gets done at 22:00 on a Friday because that is when someone notices the cache is stale.

v1.4 fixed this. Sort of. We can not make the work itself glamorous, but we can stop making it harder than it needs to be.

Define an action, get a button

Add an actions block to your .nebion.yml:

.nebion.ymlyaml
actions:
  clear-cache:
    label: "Clear application cache"
    command: "php artisan cache:clear"
    service: app

  reindex-search:
    label: "Reindex search"
    command: "bin/reindex.sh"
    service: app
    confirm: true

  db-dump:
    label: "Download database dump"
    command: "pg_dump $DATABASE_URL | gzip"
    result: file
    filename: "dump-$NEBION_ENV_IDENTIFIER-$(date +%Y%m%d).sql.gz"

Push the change. On the next deploy, the actions sync to the environment automatically — that is the bit we added in v1.4. Open the environment in the dashboard, hit the Actions tab, and there are your buttons. Click. Wait. Done.

How sync works
Sync is automatic. Add an action, push, deploy. Remove an action, push, deploy. The dashboard reflects whatever is in your repo on the latest deploy. No second source of truth.

File actions: the killer feature

The thing we did not expect to be most popular is result: file.

Mark an action as a file action and Nebion captures whatever it writes to $NEBION_ACTION_OUTPUT (or to stdout, your choice) and serves it back through a lightweight artifact server. The user clicks the action, watches the progress, and gets a download link.

What people use it for, in roughly the order we see: database dumps, log archives, config exports, and one-off CSV reports. Files are retained for seven days, then garbage-collected. If you need something kept longer than that, store it somewhere designed for storage — that is not us.

Why it took us so long

Two reasons. First, we kept thinking actions were just a webhook plus a UI — and they are, except all the interesting work is in the plus-a-UI part. Live progress, exit codes, log streaming, file downloads, confirmation dialogs, permissions on who is allowed to push the big red button. Each of those is a small thing. Together they are the difference between we shipped a feature and people actually use it.

Second, every CI/CD platform on the market has a version of this and most of them are bad. The button is buried six clicks deep, the logs scroll off, the file download times out. We wanted ours to be the version we'd actually use. Took a few iterations.

Keep reading
Manual recipes: deploying things that do not want to be Docker
Read post →
Block types: code, callout, cta, image, mascot
Read post →
Why we built Nebion (the short, honest version)
Read post →