On this page
What a production Ubuntu build means
Spinning up an Ubuntu server takes a minute. Making it ready for production takes care: removing what is not needed, securing access, setting the timezone, swap and limits correctly, enabling security updates and installing your stack in a way that can be repeated. Ubuntu server setup is that preparation, finished before any real traffic arrives.
We use the current Long Term Support (LTS) release unless your software needs something else, because LTS releases receive security updates for years and are what most tooling targets.
Who it’s for
- Teams launching a new application who want the base server done properly from the start.
- SaaS products adding a second or third server that must behave exactly like the first.
- Agencies that need a standard server template for client projects.
- Businesses replacing an old, end-of-life Ubuntu release that no longer receives updates.
A common trigger is realising a server is still on a release whose standard support has ended, meaning security fixes have quietly stopped.
What’s included in the build
- Minimal Ubuntu LTS install with unnecessary packages and services removed.
- Non-root admin user, key-only SSH and root login disabled.
- UFW firewall with only required ports open, plus fail2ban on SSH.
- Unattended security upgrades enabled and configured.
- Hostname, timezone, locale, NTP time sync, swap and file limits set deliberately.
- Your runtime and services installed: Nginx, PHP-FPM, Node.js, Python, PostgreSQL, MySQL, Redis or Docker as needed.
- A build script or Ansible playbook so the same server can be recreated.
- Documentation of every setting that differs from the default and why.
Our process
- Confirm the application’s requirements, versions and expected load.
- Provision the server with your chosen provider and apply the base hardening.
- Install and configure the stack, pinning versions where stability matters.
- Run checks: open ports from outside, SSH access, service restarts after reboot, time sync and updates.
- Hand over the documentation and the reproducible build script.
Tools and choices
The build runs on any mainstream provider, including DigitalOcean, Hetzner, Hostinger VPS, AWS, Google Cloud and Azure. For repeatability we use cloud-init or Ansible; where you manage many servers, Terraform can create the machines themselves. We decide between native packages and Docker based on how many applications share the server and how your team deploys.
What affects timeline and cost
A standard web stack on one server is quick. Time increases with the number of services, special requirements such as custom kernels or GPU drivers, and whether you want a fully automated build for future servers. Provider charges are billed to you directly and depend on size and region.
If you want a fully automated build for future servers, that adds some upfront time but pays off quickly: the second and third servers take a fraction of the effort, and rebuilding after a failure becomes a scripted, predictable job rather than a stressful afternoon.
Defaults we change, and why
A stock Ubuntu image is sensible for general use, but a production server benefits from a few deliberate decisions. These are the settings we review on every build, with the reasoning recorded in your documentation:
| Setting | Typical default | What we decide |
|---|---|---|
| SSH access | Password login often allowed | Key-only login for named users, root login disabled |
| Firewall | Installed but inactive | Enabled with only required ports open |
| Security updates | Varies by image | Unattended security upgrades enabled and checked |
| Swap | Often none on cloud images | Sized to the workload so memory spikes do not kill services |
| Timezone and time sync | UTC, sync usually on | Chosen deliberately and documented; sync verified |
| Open file and process limits | Generic values | Raised where databases or busy apps need them |
| Log retention | Generic rotation | Matched to disk size and how far back you need to look |
None of these changes is exotic. The value is in making them consistently, writing them down, and baking them into a script so every future server starts from the same known-good baseline instead of whatever the provider’s image happened to ship with that month.
Common mistakes to avoid
- Using an interim (non-LTS) release in production, which reaches end of life quickly.
- Leaving the server on UTC or the wrong timezone without deciding, then confusing log timestamps and scheduled jobs.
- No swap on a small server, so a memory spike kills the database instead of slowing briefly.
- Installing packages by hand with no record, so the second server never quite matches the first.
Related: Server Security Hardening, Nginx Configuration and Infrastructure Automation. See all Cloud & Server Management services, the cloud and server guide, or contact us.
Frequently asked questions
Which Ubuntu version do you use?
The current LTS release by default, unless your application requires a specific version. We avoid interim releases for production.
Can you upgrade our existing Ubuntu server instead?
Sometimes. For servers that are several releases behind, a fresh build with a planned migration is usually safer than an in-place upgrade.
Do I get the build script?
Yes. The script or playbook is yours, so you or anyone else can recreate the server without us.
Will you deploy our application too?
We can. The base build and the application deployment are often done together so everything is tested end to end.
Can the same build be used on different cloud providers?
Largely, yes. The base configuration is provider-neutral. Small differences, such as network interface names or provider firewall settings, are handled in the script so the resulting servers behave the same.
Talk to us about ubuntu server setup
Clean, secured Ubuntu builds prepared and tested for production workloads.