Setting up your first Linux server means more than installing an operating system and getting a login prompt. The useful result is a machine you can reach reliably, administer safely, update without guesswork and recover when something goes wrong.
Start with one service on one server. A private file share, a small website or a development application is enough to learn the operating routine without creating several unrelated problems at once. This guide covers the base setup for Ubuntu Server LTS or Debian stable, with links to the task guides in our Linux servers and security section where a subject needs more detail.
Decide What the Server Will Do
Write down the server’s job before choosing hardware or installing packages. “Host a private application for two people” is a useful requirement. “Run everything that looks interesting” is how a learning project acquires a maintenance department.
Your first decision is whether the service needs to be available only on your local network, through private remote access or to the public internet. Treat those as separate operating models. Do not make a service public simply because a tutorial opens its ports.
For a first project, define who will use the service, what data it will hold and what happens if it stops. A disposable test website can tolerate a failed experiment. The only copy of your household documents cannot. Keep irreplaceable data elsewhere until you have tested the server’s backup and recovery process.
Set an initial success condition too. A useful example is: “After a reboot, I can sign in with my own account, the application starts automatically, only the intended users can reach it and yesterday’s data can be restored.” That gives you something concrete to test rather than a vague sense that the machine seems fine.
Choose Between a Virtual Machine, Home Server and VPS
Use the platform that makes mistakes easiest to reverse. There is no requirement to buy dedicated server hardware for a first installation.
| Platform | Good first use | What to plan before installation |
|---|---|---|
| Local virtual machine | Learning installation, administration and service recovery | Guest networking, host capacity and access to the virtual console |
| Spare computer or mini PC | Local file services and applications that stay at home | Storage condition, wired networking, power and physical access |
| Virtual private server | A service that needs public availability | Provider account security, network restrictions, billing and rescue access |
A local virtual machine is a sensible default for learning. Give yourself console access and practise rebuilding it before committing useful data. Our guide to running Linux virtual machines with KVM and QEMU covers that route separately.
For an uncomplicated learning VM, consider starting with two virtual CPUs, 4 GB of memory and about 30 GB of system storage. These are suggested learning allocations, not operating system minimums or promises about application capacity. Check your application’s requirements before assigning resources, and leave room for updates, logs and backups.
With a home server, prefer a wired connection for the initial setup. Keep a keyboard and display available until remote administration survives a reboot. On a VPS, locate the provider’s browser console and recovery controls before changing access settings. Protect the provider account with multifactor authentication and store its recovery information somewhere other than the server itself.
Pick a Supported Distribution, Not Just a Familiar Download
Ubuntu Server LTS and Debian stable are reasonable starting choices. Choose one and use instructions written for that distribution and release. Switching between unrelated guides halfway through network or authentication changes makes troubleshooting harder than it needs to be.
For Ubuntu, check the release and package coverage against Canonical’s Ubuntu support lifecycle. An LTS label does not mean every package from every repository receives identical maintenance. Record the release’s support deadline as part of your server notes rather than leaving it as a future discovery.
Debian identifies stable as its production release and recommends it for that role. Use the version listed on the Debian release status page, rather than selecting testing or unstable because an application has a newer version there.
Before deciding, check whether the application you want supports the distribution’s packaged dependencies. A server operating system is not useful if your first task requires replacing half its software from unrelated repositories. Prefer a supported installation path over a version number that looks more impressive.
The broader trade-offs belong in our guide to choosing a Linux distribution. For this setup, the practical requirement is simpler: use a maintained release, official installation media and documentation that matches what you installed.
Prepare the Installation and Storage
Protect Existing Data Before Touching Partitions
If you are reusing a computer, back up anything you want to retain and check that the backup opens on another device. Disconnect unrelated external drives where practical. There is little benefit in leaving your backup disk beside the installation target while choosing which disk to erase.
Identify the target drive by its capacity and model, not just its position in a list. Debian’s installer documentation warns that disk ordering can differ and that guided partitioning can destroy existing data. Review the proposed changes before accepting them; the Debian installation component reference also describes the differences between ordinary, LVM and encrypted guided layouts.
Download the installer from the distribution’s official release service. Follow its instructions for checking the image’s integrity and authenticity before using it. For physical hardware, our guide to creating a bootable Linux USB drive covers preparing the installation device.
Keep the Initial Disk Layout Manageable
For a small first server, prefer the installer’s straightforward storage layout unless you have a reason to change it. Separate partitions, logical volumes and extra disks can be useful, but each introduces capacity and recovery decisions. Do not create five small filesystems simply because an old tutorial did.
Plan space around the application’s data rather than the operating system alone. A small system disk may be adequate for the base installation but inappropriate for a photo library, database or collection of container images. Decide where growing data will live and how you will back it up.
Also decide whether disk encryption suits your operating routine. If your chosen setup requires a passphrase during startup, arrange a way to enter it after a power failure or remote reboot. Test the actual unlock process before relying on unattended restarts. Encryption and convenient recovery need to be planned together.
Keep a short storage record: disk identifiers, mount points, encryption recovery information and the location of application data. Our Linux filesystem and directory guide explains the distinction between system configuration, user files and service data without turning this installation into a partitioning exercise.
Work Through the Installer Deliberately
Exact screens differ, but use this sequence as a decision checklist rather than accepting every optional component:
- Confirm the installation target. Match the intended machine or virtual disk to your notes before approving storage changes.
- Set language, keyboard and location. Check the keyboard layout before entering passwords.
- Establish networking. Use the settings supplied by your network or provider, and record the assigned address.
- Create the administrator identity. Choose a recognisable account name and a strong, distinct password where password authentication is used.
- Select only the required software. Add remote administration if needed, but postpone unrelated application bundles.
- Complete installation and reboot. Remove or detach the installer media and verify that the installed system starts on its own.
A graphical desktop is not a requirement for this project. Leave it out unless a workload genuinely needs one. The aim is a base system whose installed software you can account for, not a collection of services you will investigate later.
Give the Server Predictable Network Access
Record the server’s address, subnet, default gateway and DNS settings. Automatic addressing and manual addressing are different configuration choices; manual configuration requires the correct accompanying network settings, not just an unused address. The distinction is illustrated in Red Hat’s Ethernet configuration reference, although the configuration interface on Ubuntu or Debian may differ.
For a home server, consider a DHCP reservation in the router rather than assigning an arbitrary static address inside Linux. Confirm how your router handles reservations and address pools first. The useful outcome is an address that stays predictable without conflicting with another device.
On a VPS, retain the provider’s supplied network configuration unless its documentation tells you otherwise. Do not replace it with a home-network example. Keep console access available before altering addresses, routes or network configuration files.
Choose a short, recognisable hostname, such as fileserver or labserver. Treat the machine’s hostname and a publicly resolvable domain name as separate settings. If you later attach a domain to a public application, document the DNS records and which service is meant to answer for them.
Test connectivity in layers. From your administration computer, establish that you can reach the intended server. From the server, check access to its network gateway, required external destinations and name resolution. If connections by address work but connections by name fail, investigate DNS before replacing application settings.
Keep the first installation private while you complete access controls. For a home setup, leave router port forwarding off unless the service actually needs public access. For a VPS, restrict the provider’s inbound rules during setup and widen them only for an identified requirement.
Finally, inspect both IPv4 and IPv6 where available. Your access plan should describe both rather than treating the second protocol as something to revisit after deployment.
Verify the Base System Before Adding Applications
After the first boot, sign in through the console and confirm the distribution release, hostname, network address and available storage. Check the clock, timezone and time synchronisation status. Record anything unexpected now, while the machine still has very few moving parts.
Refresh package information and apply the distribution’s supported updates before installing your workload. Review any prompts rather than accepting unfamiliar configuration replacements blindly. If an update calls for a reboot or service restart, complete that work while the server is still empty.
Use the package manager supplied with the distribution. Ubuntu and Debian administration commonly involves APT; do not mix package-management instructions from a different distribution. Our guide to APT, DNF and Pacman covers those differences and the distinction between refreshing package information and installing updates.
Keep an installation record outside the server. Include the distribution release, installation date, hostname, network details and any non-default choices. Do not put passwords or private keys into an ordinary setup document. Record where those secrets are stored securely instead.
Create an Administrator Account You Can Trust
Use a named account for administration rather than routinely signing in as root. Sudo policies can authorise a non-root user to perform administrative work, with permissions assigned to users or groups. The structure is documented in Red Hat’s sudo access reference; use your own distribution’s defaults when configuring the account.
Test the account before relying on it. Confirm that it can sign in through the intended route and perform an administrative task. An account that exists but cannot obtain the permissions you need is not yet a working replacement for the initial login.
If a cloud image starts with a provider-created administrator account, inspect its access arrangements before changing them. Establish your own working access first. Remove obsolete access only after checking whether deployment or recovery processes still depend on it.
Give each human administrator a separate account. Avoid shared credentials, even on a small server: they make departures, lost devices and access reviews unnecessarily awkward. Applications should also use appropriate service identities rather than borrowing a human administrator’s account.
Our guide to Linux users, groups and sudo access covers account creation and permission changes in detail. At this stage, the acceptance test is straightforward: your named administrator can log in and administer the machine without depending on direct remote root access.
Set Up SSH Without Locking Yourself Out
Before the first remote login, verify that you are connecting to the right server. OpenSSH presents a host-key fingerprint on an initial connection. Compare it with a fingerprint obtained through a trusted console or another independent route, following the OpenSSH host-key verification guidance. Clicking through an unfamiliar warning is not identity verification.
Prepare an SSH key on the administration device and install its public key for the intended server account. Keep the private key on trusted client devices and protect it appropriately. Do not upload the private half to the server as part of authorising a login.
Test a fresh connection with that account and key while retaining a working console or existing session. Confirm that the new session can perform administrative work too. Successful login and successful administration are separate checks.
Then review the server’s authentication policy. OpenSSH has separate controls for public-key authentication, password authentication, keyboard-interactive authentication and root login. Included configuration files can also affect the result. Use the OpenSSH server configuration reference to identify the controls, but inspect the effective settings on your installed system rather than assuming upstream defaults match your distribution.
For a first server using SSH keys, disable password-based remote login only after key access and recovery access both work. Do not disable an authentication method required by a deliberately configured multifactor setup. Validate configuration changes before applying them, and open another fresh session afterward.
The exact editing and validation steps belong in our guide to securing SSH with keys and access controls. Follow one change at a time. Combining a new SSH port, new keys, disabled passwords and a new firewall policy in one attempt produces an impressively efficient lockout.
Allow Only the Network Access the Service Needs
Write down the connections you intend to permit before configuring a firewall. Separate administration access from application access. A private file server and a public website should not receive the same inbound policy simply because both run Linux.
For each allowed connection, record the service, protocol, port and permitted clients. Restrict administration to a trusted network or private access path where practical. Keep databases and administrative dashboards private unless you have a clear requirement and an appropriate protection plan.
Use one supported firewall-management approach for the host. Do not combine unrelated UFW, firewalld and raw ruleset instructions without knowing which component owns the active policy. Our Linux firewall guide covering UFW, firewalld and nftables explains those choices separately.
Before enabling a restrictive policy remotely, preserve console access and explicitly allow your administration route. Test a new connection afterward. An already open session is not sufficient evidence that a new session will be accepted.
Check every network control between the client and the application: the host firewall, any provider firewall and any router forwarding rules you created. Test from a machine on the network where the intended user will connect. A service reachable from the server itself has not yet passed an external access test.
Do not forget required network-control traffic when reviewing IPv6 policy. The nftables project’s basic dual-stack example explicitly preserves neighbour-discovery traffic because blocking it breaks connectivity. Use a distribution-supported policy rather than improvising a blanket block of unfamiliar protocols.
Install One Service and Prove It Works
Choose a modest first workload and follow its supported installation method for your distribution. A private test application or simple website is easier to assess than a stack containing a database, reverse proxy, mail server and several dashboards.
Before installation, identify where the application will store configuration, persistent data and logs. Decide which account will run it and which directories it needs to write. Keep these decisions in your setup record so that backup selection does not become detective work later.
Avoid broad permission changes to solve an access error. If a service cannot read a file, inspect the service identity, directory access and ownership before making the file writable to everyone. Our guide to Linux file permissions and ownership covers the checks behind that decision.
Check Runtime State and Startup Behaviour Separately
On a systemd-based installation, starting a service and enabling its startup behaviour are different operations. Enabling a unit does not, by itself, start it. The distinction is documented in the systemctl unit-management reference.
Check the service’s current state, how it is activated and what happens after reboot. Do not enable every installed unit indiscriminately; some services are activated through dependencies, sockets or other mechanisms. Use our guide to managing services with systemd for the operating details.
Test the application locally, then from an intended client. Confirm that authentication works and that unauthorised access fails. For a public website, finish domain configuration and HTTPS before putting real credentials or private content into use; the deployment steps are covered in hosting a website with Nginx and HTTPS.
Treat Containers as Another Deployment Choice
If the application is distributed as a container, plan its persistent storage, update process and published ports before starting it. Use the concepts in our Docker and Podman guide, then follow the application’s server deployment documentation.
Recheck network exposure after publishing container ports. Docker creates firewall rules for bridge networking, and published traffic can bypass the filtering path used by UFW. This behaviour is documented in Docker’s packet-filtering and firewall reference. A reassuring host-firewall display is not a substitute for testing the deployed application from outside.
Establish an Update Routine Before You Need One
Decide which updates will run automatically, who will review failures and when restarts are acceptable. For a small server, a documented maintenance window is more useful than an optimistic promise to check it whenever you have time.
Ubuntu’s standard unattended-upgrades setup applies security updates automatically, but adding a repository does not automatically add it to the permitted update origins. Image customisation can also change the setup. Inspect the actual configuration and logs using the Ubuntu automatic-update documentation rather than assuming every installed application is covered.
Keep operating system package updates, application updates and container-image updates in your maintenance record as separate responsibilities. For each component, record how an update is applied and how you will verify that the service still works.
Do not make automatic reboots an accidental policy. Choose whether to permit them, arrange a suitable time and test that storage unlock, networking and application startup recover without intervention. Our guide to Linux security updates and automatic patching covers scheduling and review in more detail.
Record the distribution’s support deadline alongside recurring maintenance. A patched application does not remove the need to replace an operating system release when its maintenance coverage ends.
Monitor the Service and Practise Basic Troubleshooting
Begin with a small monitoring plan: whether the application is reachable, whether backups succeeded, how much storage remains and whether resource use has changed unexpectedly. Add checks because they answer an operating question, not because a dashboard has an empty panel.
Test availability from outside the application’s own process where possible. A running process is only one part of a working service. Include a simple user-level check, such as loading the intended page or reading a test file with an authorised account.
Record normal resource use after setup and compare it during ordinary use. Avoid treating a single CPU or memory reading as a diagnosis. Our guide to monitoring CPU, memory, disk and network usage covers the measurements and their interpretation.
When something fails, start with the last change and the relevant time period. On systemd systems, journalctl can retrieve journal entries and filter them by fields associated with services and other events. The filtering model is documented in the journalctl reference.
Use our service troubleshooting guide with journalctl to narrow the evidence. Capture the actual error before restarting repeatedly. Check configuration, permissions, storage and network access in a deliberate order, then change one thing and retest.
Send actionable alerts somewhere you will notice them, and test delivery. Document who responds and what the first check should be. A notification that nobody receives is decoration, not monitoring.
Create Backups You Can Restore
Before storing useful data, decide what you can afford to lose and how long recovery can take. A daily backup may suit a learning project; it may not suit an application that receives important changes throughout the day. Choose the schedule from the data’s value, not from a default checkbox.
Back up application data, required configuration and the information needed to rebuild the service. Keep at least one recovery copy outside the server’s own storage and protect it from deletion through a compromised server account. Offline encrypted backups and regular recovery tests are part of the CISA StopRansomware backup guidance.
Do not assume that copying a running database’s files produces a usable backup. PostgreSQL, for example, requires shutdown for an ordinary filesystem copy or an appropriate consistent-snapshot method. Its filesystem backup documentation describes those restrictions. Use the database’s supported backup process rather than treating active database storage like a folder of documents.
Separate short-term rollback from disaster recovery. A local snapshot may help undo a change, but your recovery plan should also survive losing access to the original machine or storage. Check the location, retention and access protections of every backup method you depend on.
Restore into a separate test location. Check that files open, permissions are suitable and the application can use the restored data. Record the steps and how long they take. Our guide to automated offsite backups and recovery testing covers building that routine.
Protect backup encryption keys and recovery credentials separately from the server. Test that you can obtain them during an outage. A sound backup plan should not require the failed machine to retrieve the secret needed to restore it.
Run a Final Acceptance Test
Before calling the server ready, perform a controlled reboot and repeat the checks that matter. Do this while the project is still small enough that a failed test is an inconvenience rather than an emergency.
- Your named administrator can open a fresh remote session and obtain the required privileges.
- Console or rescue access works independently of the normal remote login.
- Networking and any encrypted-storage unlock process recover as intended.
- The application starts through its intended activation mechanism and passes a user-level test.
- Allowed clients can connect, and access that should be blocked is blocked.
- Update status, backup status and alert delivery have been checked.
- A restore has succeeded without depending on the original application data.
Keep the operating notes with your recovery material, not only on the server. Include service purpose, storage locations, access arrangements, maintenance tasks and restore instructions.
Once those checks pass, leave the setup alone long enough to observe ordinary operation. Add the next service only when you can explain how the first one starts, updates, stores data and recovers. A dependable first Linux server is one whose behaviour you can verify—not one with the longest list of installed packages.