Linux Server Setup Checklist for New App Deployments

Overview

A good linux server setup checklist is less about memorizing commands and more about reducing avoidable risk. New app deployments usually fail for ordinary reasons: the wrong user is running the app, the firewall blocks a dependency, DNS points to the wrong IP, TLS is incomplete, backups were never tested, or a server was provisioned without clear ownership.

This article focuses on production server basics for a new Linux host, especially Ubuntu-style environments, though most items apply to other distributions with small adjustments. The goal is not to prescribe one stack. Instead, it gives you a practical sequence you can use whether you deploy directly on the host, through Docker, or behind a reverse proxy.

Before you start, define four things in writing:

• Purpose: What exactly will run on this server: app, database, proxy, queue worker, CI runner, or mixed roles?
• Owner: Who is responsible for operating system maintenance, deploys, DNS, and incident response?
• Access path: How will admins connect, and how will your CI/CD system deploy code?
• Recovery plan: If the host fails, what is the expected recovery process and recovery time?

If those answers are unclear, setup decisions become inconsistent very quickly.

As a working baseline, this checklist assumes you want a server setup for web app deployments that is secure enough for routine production use, simple enough for a small team to maintain, and documented enough that another engineer can understand it later.

Checklist by scenario

Use this section as the core reusable checklist. The exact commands will vary by provider and distribution, but the order matters.

1. Base operating system setup

• Start with a supported distribution and current image. Avoid inheriting old snapshots unless you know what is installed on them.
• Set hostname and timezone. Consistent names make monitoring, logs, and SSH sessions easier to read.
• Update packages immediately. Run package index refresh and security updates before installing app dependencies.
• Create a non-root administrative user. Use sudo instead of logging in as root for routine work.
• Disable password SSH if possible. Prefer key-based authentication from day one.
• Record the server's private and public IPs. You will need them for DNS, reverse proxy rules, firewalls, and service binding decisions.

2. Access and hardening baseline

• Restrict SSH access. Consider changing default SSH exposure with firewall rules, allowed users, or source IP restrictions where practical.
• Disable direct root login. This reduces one of the most common attack paths.
• Enable a basic firewall. Allow only the ports you need, typically SSH, HTTP, and HTTPS. Open database ports only if there is a clear operational reason.
• Install intrusion prevention or rate limiting if it fits your environment. Keep the setup simple enough to maintain.
• Enable automatic security updates if your team accepts that tradeoff. If not, define a patch schedule and owner.
• Set correct file permissions. Deployment directories, environment files, and SSH keys should not be world-readable.

This is the part many teams mean when they search for a new server hardening checklist. Hardening does not need to be elaborate to be useful. The important thing is to remove defaults you do not intend to keep.

3. Users, secrets, and deployment access

• Create service-specific users where appropriate. Your app process should not run as your personal login user.
• Decide how secrets will be stored. Environment files, secret managers, and CI-injected runtime variables all work if used consistently.
• Keep production secrets off the shell history. Do not paste credentials into commands that end up in logs or history files.
• Separate human access from automation access. CI deploy keys and administrator SSH keys should be managed independently.
• Document key rotation. You do not want the first rotation attempt to happen during an incident.

4. Storage, swap, and filesystem planning

• Check disk layout before deploying. Confirm root volume size, attached data volumes, and expected growth.
• Set up swap intentionally. Some small app servers benefit from modest swap; others may prefer none. Decide rather than inheriting provider defaults blindly.
• Separate application data from disposable code where possible. This makes deploys and recovery cleaner.
• Verify log growth expectations. Unbounded logs can quietly fill a server.
• Test write permissions for runtime directories. Temporary storage, uploads, and cache paths often fail only after traffic arrives.

5. Runtime and dependency installation

• Install only what the host needs. Fewer packages mean less maintenance.
• Pin major runtime versions. Whether you use Node.js, Python, PHP, Java, or Go, make version choice explicit.
• Install process supervision. Use a service manager so your app restarts predictably after reboot or failure.
• Confirm the app binds to the intended interface and port. Local-only binding is common when using a reverse proxy.
• Standardize environment file locations and service names. Naming drift creates avoidable confusion later.

6. Web server or reverse proxy setup

• Choose whether your app is exposed directly or through a proxy. Most production setups benefit from a reverse proxy.
• Configure HTTP to HTTPS behavior deliberately. Redirect once TLS is working, not before.
• Set upstream timeouts and header forwarding correctly. This matters for APIs, websockets, and long-running requests.
• Serve health checks and static assets in a predictable way. Make it easy for load balancers and uptime checks to validate the service.
• Keep site configuration under version control if possible. It reduces drift between hosts.

If you are using Nginx in front of the app, pair this checklist with the site’s Nginx reverse proxy setup guide.

7. DNS, domain, and TLS preparation

• Point the domain to the correct public endpoint. Confirm whether you need an A record, AAAA record, CNAME, or provider-managed load balancer target.
• Lower TTL before planned cutovers if you control the timing. This can make rollbacks easier during migrations.
• Verify authoritative nameservers before troubleshooting propagation. Many DNS mistakes start with editing the wrong zone.
• Issue and install TLS certificates. Make sure renewal is automated or clearly scheduled.
• Test HTTPS from the public domain, not just localhost. DNS and certificate name mismatches only show up end to end.

For domain pointing basics, see How to Point a Domain to a Server. If the app is not reachable after changes, use dig, nslookup, and whois to troubleshoot domain problems.

8. Deployment workflow setup

• Choose a deployment method. Git pull on server, artifact upload, container image pull, or CI-driven remote deploy all work if they are documented.
• Make deploys repeatable. A shell script or pipeline is usually better than a memory-based process.
• Define rollback steps before first release. Rolling back code, config, and database changes may require different actions.
• Store deployment logs somewhere accessible. You want to know what happened without logging back into three systems.
• Run a smoke test after deploy. Check health endpoint, app homepage, login path, and one key API call.

Teams using CI/CD should also review the site’s GitHub Actions deployment guide. If you deploy with containers, the Docker deployment tutorial for small production apps is a useful companion.

9. Logging, monitoring, and alerting

• Confirm where application logs go. File logs, journaling, and centralized logging each have tradeoffs. Pick one on purpose.
• Monitor basic host signals. CPU, memory, disk, load, and restart counts are enough for an initial baseline.
• Add uptime checks from outside the server. Internal health alone does not prove the app is reachable.
• Define at least one alert path. Email, chat, or incident tooling is fine; silence is not.
• Log rotation should be enabled and tested. This is easy to forget on fresh hosts.

10. Backups and recovery readiness

• Decide what needs backup. Code often does not; databases, uploads, config, and secrets references usually do.
• Automate backups. Manual backups are often skipped right when they matter most.
• Test restore steps. A backup without a restore drill is only a partial control.
• Document rebuild steps for the host. Assume at some point you will need to recreate the server from scratch.
• Keep infrastructure definitions where possible. If your DNS or host setup can be expressed as code, future rebuilds are much cleaner. See Terraform DNS Records Guide for the DNS side.

11. Scenario-specific notes

For a simple single-server app: keep roles clear, use a reverse proxy, avoid exposing the database publicly, and document one clean rollback path.

For a Docker-based host: decide where persistent volumes live, how containers restart after reboot, who rotates images, and how container logs are collected.

For an internal API or tool: network restrictions may matter more than public TLS marketing checkboxes. Focus on access control, auditability, and predictable DNS.

For a staging environment: keep it similar enough to production that deploy tests are meaningful, but clearly separate secrets, domains, and notification channels.

What to double-check

These are the items most likely to look fine during setup and then cause trouble later.

• DNS points where you think it points. Confirm the record type, value, and nameserver authority. If traffic is failing after a cutover, also review how to fix DNS_PROBE_FINISHED_NXDOMAIN.
• The app listens on the expected port and interface. A healthy local process does not guarantee external reachability.
• Firewall rules match the real architecture. It is common to allow 80 and 443 but forget SSH source restrictions, internal service ports, or IPv6 behavior.
• Service restarts survive reboot. Reboot the host once before calling setup complete.
• TLS certificate names match the final domain. Certificate issuance during temporary setup sometimes gets left behind.
• Environment variables are loaded by the service manager, not just your shell. A deploy can work manually and fail under system startup for this reason.
• Time synchronization is working. Bad clock drift can affect logs, tokens, and TLS.
• Disk alerts account for logs and temporary files. A server can appear healthy until the first burst of traffic or a failed job loop.
• Backups are scoped correctly. Teams often back up code they can reproduce and miss user-generated data they cannot.
• Ownership is explicit. If an alert fires, someone should know whether it belongs to app engineering, ops, platform, or a shared on-call rotation.

If you hit a release issue even after this review, the site’s deployment troubleshooting checklist can help narrow the failure path.

Common mistakes

Most server setup problems are not exotic. They come from skipped basics, especially when a team is under time pressure.

• Treating the first successful deploy as the end of setup. A deploy proves only that one path worked once.
• Using root for everything. It is convenient early and costly later.
• Skipping documentation because the setup feels small. Small setups change hands too.
• Mixing roles on one host without clear boundaries. Running app, database, queue, and unrelated jobs on the same server can be acceptable for small systems, but only if the tradeoffs are understood.
• Leaving defaults in place. Default SSH exposure, default package sets, and default web server pages create noise and risk.
• Changing DNS without a rollback plan. Domain changes are easy to make and often slower to verify than application changes.
• Forgetting IPv6. If your provider enables it, test it. If you do not use it, understand whether it should be disabled or explicitly managed.
• Not separating staging from production. Shared secrets, copied configs, and reused domains lead to avoidable incidents.
• Assuming backups work because jobs say they ran. Restoration is the real test.
• Neglecting SSL checks after DNS or hosting changes. If browsers start failing after a move, review how to fix ERR_SSL_PROTOCOL_ERROR.

One more practical mistake is overcomplicating the first version of the host. A reliable baseline with simple monitoring, clear DNS, clean service management, and tested recovery is usually better than a more advanced setup nobody is confident operating.

When to revisit

This checklist is most useful when you treat it as a living operating document rather than a one-time launch note. Revisit it in these situations:

• Before a new app deployment. Even if the server pattern is familiar, small differences in domains, ports, or secrets often matter.
• When your workflow changes. Moving from manual deploys to CI/CD, or from direct host deploys to containers, should trigger a checklist review.
• When traffic or criticality changes. A side project host and a revenue-impacting production host should not necessarily share the same assumptions.
• Before seasonal planning cycles. This is a good time to review patching, backup scope, DNS ownership, and alert routing.
• After an incident. Add the missed check to the checklist while the failure is still fresh.
• When providers, DNS, or certificate tooling change. Infrastructure changes often break old operational habits more than the technology itself.

For a practical next step, turn this article into your team’s own ubuntu server deployment checklist or Linux baseline document. Keep it in version control, add environment-specific items, and include links to the exact DNS zone, repository, CI workflow, and recovery docs you use. The best checklist is not the most comprehensive one. It is the one your team can actually return to before every new server goes live.

If your deployments regularly involve domain cutovers, compare providers in Best DNS Providers for Developers and keep a separate DNS change checklist alongside your server checklist. That simple split usually makes hosting changes easier to reason about and faster to troubleshoot.