Production servers built properly and watched continuously

What a properly configured server actually includes

A working application on a server is not the same as a production deployment. The difference is everything that handles the situations nobody plans for, and it is why the same application can run flawlessly for years in one environment and collapse repeatedly in another.

Our standard build puts NGINX at the front handling incoming connections, static files, compression and certificates. Gunicorn runs the application behind it with a worker count matched to the machine rather than left at a default. Systemd supervises the services so they restart automatically after a failure or a reboot. Redis provides caching and Celery workers handle background jobs, each running under supervision rather than in a terminal somebody started once and forgot.

Around that sits the operational layer. A firewall permitting only what is needed. Automatic certificate renewal, so nobody discovers the problem when customers do. Log rotation, because full disks cause more outages than hardware failures. Limits on repeated login attempts. Separate accounts with appropriate privileges rather than everything running as the administrator. Scheduled backups stored away from the server they came from, and tested by restoring them.

Monitoring that tells us before it tells your customers

Monitoring is the difference between a brief interruption and a bad afternoon. We watch whether the site responds, how long it takes, whether error rates are climbing, whether disk space and memory are heading somewhere unhelpful, whether background workers are still processing, whether backups completed and whether certificates are approaching expiry.

Alerts go to us. For clients on a management arrangement, the work has often started before anybody at the company notices, which is exactly the arrangement most business owners want. Nobody should learn that their website is down from a customer telephone call.

Deployments that do not frighten anyone

Updating a live system should be routine. We script deployments so they run identically every time, apply database migrations in a controlled order, and keep the previous version available so a problem can be reversed quickly rather than debugged under pressure while the business waits.

Where a system justifies it, we maintain a separate staging environment matching production, so changes are exercised somewhere safe first. Configuration is documented and reproducible, meaning a server can be rebuilt from notes rather than reconstructed from memory by whoever happens to remember what was installed.

Taking over servers nobody understands

A frequent enquiry begins with a company that has a running system and no idea how it works, because the person who built it has gone. We are comfortable with that. We document what is actually there, identify the risks in plain language, deal with the urgent items such as expiring certificates, absent backups and unpatched software, then agree a plan for anything larger. You get a clear picture before you commit to anything beyond the assessment.