Deploying Without Logging Users Out: A Release Checklist for Small Business Apps
Picture a cashier halfway through entering the day's sales when the app suddenly returns to the login screen. The entry is gone, the cashier is annoyed, and the owner starts to wonder whether the new system can be trusted. Often the cause is not a bug at all. It is a routine update.
This post explains why updates log people out, how to prevent it, and the checklist I follow for every release of a business app.
Why updates log users out
When someone logs in, the server creates a session that remembers who they are. Many apps keep sessions in the server's memory by default. Deploying an update restarts the app, memory is cleared, and every session disappears. Everyone is logged out at once.
The fix: a persistent session store
Store sessions somewhere that survives a restart: a database or a file-backed store. For the Sales Monitoring System I wrote a custom SQLite session store, so staff at both branches stay logged in through every redeploy. It is a small piece of code with a big effect on how reliable the app feels.
My release checklist
Before the release
- Back up the database and confirm the backup file exists and is not empty.
- Review database migrations. Know exactly what each migration changes and how you would undo it.
- Build and test locally against realistic data, not just an empty database.
- Note the current number of active sessions so you can compare it after the release.
During the release
- Deploy the code, run migrations, and restart the app with the process manager (I use PM2).
- Leave the web server configuration alone unless the release needs it. Change one thing at a time.
After the release
- Check the session count again. It should match. If it dropped to zero, users were logged out.
- Click through the key screens that staff use every day.
- Watch the error logs for the first few minutes.
Backups you have actually tested
Automatic nightly backups are the minimum for any app that holds business data. But a backup you have never restored is only a hope. Restore one to a test copy from time to time and confirm the data is complete.
Always have a rollback plan
Before every release, know how to go back: the previous version of the code, the backup taken just before, and the steps to reverse any migration. Most releases never need it. The one that does will be a short inconvenience instead of a crisis.
Why this matters for small businesses
Staff trust a system when it behaves the same way every day. Updates that silently log people out, or that occasionally lose data, teach them to keep a paper backup, and then you are back to typing everything twice, the problem described in from spreadsheets to a system. The same care matters even more for payroll, where one bad release can affect everyone's pay, as covered in how attendance-based payroll works.
Safe releases are part of how I work on every project and part of my hosting and upkeep service. If you want an app that stays online through updates, let's talk.