By the Onsites AI team · Last updated · 5-minute read
The managed cloud updates itself on our release cadence, and nobody's Friday evening is involved. Self-hosting moves that calendar to you, and how you run it decides whether "self-hosted" feels like control or like a second job. The good news: the update pipeline is four small, boring steps that compound into years of calm — read, stage, snapshot, upgrade in a window — and this guide fills in the judgment around each: what cadence to hold, which releases to jump on, and how to make rollback a formality instead of a prayer.
Three release classes, three clocks. Security releases: apply within days, staged if the window allows, directly if the risk grade says so — security patches are the one category where "waiting for monthly" is itself the finding in an audit. Feature releases: collect them into a monthly or six-weekly upgrade window; most desk teams run a Tuesday or Wednesday morning slot, because a quiet support afternoon is the natural maintenance lane and the rest of the week is your safety margin. Major versions: read the notes twice, plan once — schema migrations and new services deserve a full staging pass and a named rollback point. Whatever the class, the window gets a minute-taker: the person upgrading logs the image versions in, timings and verification ticks in the runbook, because an update history you can read is half an incident review, and the only thing worse than an upgrade is proving to an auditor that upgrades happened. The unifying rule that prevents most horror stories: never upgrade the production desk on a Friday, because the weekend will be long and the ticket queue will be patient with everything except support software that does not start.
An upgrade untested on a copy of your real data is a bet, and the house does not win as often as the changelog implies. Stage properly: duplicate the production stack to a staging VM (the compose file makes this a config copy plus volume paths), load a recent backup, run the upgrade there, and exercise the fifteen minutes that matter — sign in, open a live-looking thread, check that inbound email connects, render an invoice, glance at the views and tags that drive your reporting. Real data is what surfaces real breakage: a migration that trips on a message from 2019 with an odd attachment, a renamed setting key your runbook references. Fifteen minutes of staging replaces two hours of production archaeology; this exchange rate is the entire argument for the staging step.
The upgrade window opens with a snapshot and closes by verifying — the steps before and after the compose pull are the difference between an upgrade and a gamble. On a VM: checkpoint or image the host. On plain Docker: the deployment guide's backup scripts produce a restorable dump plus attachments in minutes; run them as the literal first line of the window. Tag the image you are leaving (`onsites:current-good` beats `latest` as a discipline), note the compose diff, and keep the last two known-good images on disk, because rollback sometimes needs the one before the last. If verification fails, restore-first-debug-later applies here in miniature: roll back to the snapshot, let the desk run, and debug the staging copy at leisure — production availability is the metric the customers see.
Ten minutes of note-triage saves the window from surprises, and it is a skill with three fast questions. What changed in schema or services? Anything touching the database, storage layout or new containers means snapshot staging first and a longer window. What changed in features my team touches daily? New inbox behaviors, changed SLA mechanics, updated AI actions — these go into the ops note that tells the team what will look different after Wednesday. What is deprecated? Deprecations are next quarter's migration; book them into the update calendar now rather than meeting them as a failed startup in month nine. The notes exist to be skimmed for these three; the changelog is not homework, it is a two-minute pre-flight.
Make the abstract concrete with the script of a real monthly window on a mid-sized deployment. Monday: skim notes, flag the schema diffs, announce to the team ("desk upgrades Wednesday 09:30, expect ten minutes of read-only"). Tuesday: refresh staging from the last production backup, run the upgrade on the copy, verify the checklist, note any rough edges in the ops note. Wednesday 09:15: snapshot production, tag the running image, post the internal go. Wednesday 09:30: pull, compose up, migrations run; 09:34 sign in, open a thread, confirm email flow, check one invoice and one view; 09:40 announce done, watch the first hour's conversations for oddities, leave the snapshot intact for a week. Total hands-on time under thirty minutes. Next Wednesday: discard last week's snapshot — the grace period expired cleanly — and file the window's timings in the runbook; drift between plan and reality is your capacity signal for next month. Ten minutes of downtime during a chosen morning, verified before the coffee cools, is the entire price of staying current on software you otherwise own outright.
How much of this to automate is a decision about the team, not technology. A solo admin: scheduled dump jobs, a manual monthly window, a checklist file — perfectly respectable. A platform team: CI pulls images, a staging pipeline runs the migration against a restored snapshot, promotion is a merge. Both defensible; the failure mode is accidental automation — cron upgrading production unattended — and the opposite error, no automation at all, which lets security releases age into findings. The honest middle: automated backups nightly, automated staging refresh monthly, and the human decision (read, approve, upgrade, verify) stays a named person's Tuesday. Licensing note for the spreadsheet: updates are included in the license — no additional maintenance fee — so the only real cost of this pipeline is the hour a month you already owe any infrastructure you own.
How often should we update a self-hosted help desk?
Apply security releases within days; batch feature releases into a monthly or six-weekly upgrade window on a quiet weekday morning; treat major versions as planned projects with full staging. Never upgrade production on a Friday.
Do we need to test updates before applying them?
Yes — stage every upgrade against a copy of real data, then verify sign-in, live threads, inbound email, invoice rendering and reporting views before promoting. Fifteen staging minutes reliably replace two hours of production debugging, and migrations that trip on old data are found safely there.
What is the safest rollback method?
Take a snapshot as the first line of every upgrade window: a VM checkpoint, or the deployment guide's backup scripts producing a restorable dump plus attachments. Tag the currently running image as known-good, keep the last two, and roll back first and debug later if verification fails.
What should we look for in release notes?
Three things: schema or service changes (they lengthen the window and require staging), changes to features your team uses daily (they go in the ops note to the team), and deprecations (they go on the update calendar now, not in month nine).
Does self-hosted Onsites AI charge extra for updates?
No — software updates are included in the self-hosted license; there is no maintenance fee. The cost of updating is operational only: your staging time and the upgrade window itself.