The First 24 Hours on an Ubuntu VPS

Setting up a virtual private server may seem like a straightforward procedure. An IP address and log-in details are provided by the supplier, the terminal comes to life, and it seems that everything is already set up. However, a newly set up Ubuntu VPS requires some basic adjustments before being able to serve an application securely. The initial days of using the server are the best period to create a reliable basis, since the process of correcting errors is much more difficult when users, databases, scripts, and other things have been added.

It is usual for developers to choose Ubuntu VPS hosting in order to create a versatile environment for web sites, APIs, development tools, or even internal services. It is known and extensively documented, and there are a huge number of programs supporting Ubuntu. Nevertheless, the operating system itself is unaware of how the server will be utilized. For example, a VPS set up for a personal Git service should be configured differently from the VPS working as a web application.

Start with access and identity

The first login usually happens through the root account. Root has permission to change every part of the system, which makes it useful during setup and risky during daily work. One accidental command can delete important files or change permissions across the whole server.

Create a separate user for administration and give that account access to sudo. This allows important commands to run with elevated privileges while keeping normal activity under a regular user identity.

A typical setup may include:

• creating a new user with a clear name
• adding the user to the sudo group
• copying the existing SSH key to the new account
• testing the new login in a second terminal window
• keeping the original session open until access is confirmed

Key-based SSH is a more secure and more convenient method than using password to log into the system. The public key remains on the server, while the private key is stored on the system of the developer. Only then will access be granted if these two pieces match.

Once key access works, password authentication can usually be disabled. Root login through SSH can also be restricted. These small changes block many automated login attempts that constantly scan public IP addresses.

It is also useful to change the server hostname. A name such as api-staging-01 or store-production gives more context than a random provider label. This becomes relevant when multiple terminals are opened simultaneously. The hostname will help ensure that the command is not run on the wrong terminal.

Update before installing tools

A new VPS image may have been created weeks before the server was launched. Packages included in that image can already have security updates available. Running the system update must therefore precede the installation of a web server, database, runtime environment, or control panel.

The Ubuntu Linux system uses the APT packaging system. The package lists must first be updated, followed by upgrading the already installed software. In case of major upgrades, make sure you know if the server requires rebooting.

Do not install all your familiar utilities immediately. Extra packages will only increase your maintenance load and add new items to update later. Start with utilities with clearly defined functions like a text editor, Git, curl, unzip, and some kind of monitor.

The auto-update feature for system security can also be activated. It works well in small projects where there is no daily login. However, this does not replace the necessity of maintenance itself; it just lowers the probability of having a vulnerability exposed for several months.

Time settings deserve attention as well. Set the correct timezone or keep the server on UTC and document that choice. Consistent time makes application logs, database records, backups, and deployment history much easier to compare.

Build a narrow firewall

The public virtual private server can start receiving network traffic immediately after getting online. Most of this traffic is harmless port scans, but each open port means one more way into the server.

One of the most popular distributions of Linux – Ubuntu – makes use of UFW as a firewall utility. It works by allowing only those ports that the server actually requires. One of the first ports that is allowed is SSH port.

For a standard application server, the public ports may include:

• port 22 for SSH
• port 80 for regular web traffic
• port 443 for encrypted web traffic

The port for the database is rarely opened to the entire world-wide web. Such databases as PostgreSQL, MySQL, Redis and other services often listen only to the local interface. Applications running on the same computer would be able to communicate with them even in a private mode.

Before enabling the firewall, confirm that the SSH rule is present. Locking out the only administrative connection is one of the easiest VPS setup mistakes. Some hosting providers offer a browser console that can recover access, though relying on it creates unnecessary work.

The same narrow approach should apply to installed services. If a process is unused, stop it and disable automatic startup. A quiet server with a small number of active services is easier to understand than a machine filled with background processes left by old experiments.

Prepare deployment and recovery

Many developers focus on getting an application online and leave recovery planning for later. The better time to think about failure is before the first real deployment.

Start by deciding where application files will live. Keep projects in predictable directories and avoid placing working files across several unrelated locations. Separate application code, uploaded content, logs, and secrets. This makes permissions clearer and backups more reliable.

The environment variables and secrets should not be stored in the public repository. The passwords to the database, API keys and other secrets are supposed to be stored in encrypted configuration files or secret management systems. Permissions should be assigned to the file in such a way that only the needed user or service gets access to the file.

Deployment has to be repeatable as well. An execution script or docker-compose.yml file is a better choice than remembering a very long manual sequence of actions. It becomes especially critical when the server requires a rebuild because of some mistake. Backup location should not coincide with backup creation location. The backups located on the same disk will be lost together with the server. Critical data should be moved to the object storage, to another server or to a special backup system. Backups should contain databases, uploaded data by users, configuration files and other data which cannot be recreated using the source code.

Otherwise, it would not work at all. Try restoring your backup using a smaller database or a file. Document the commands and the expected outcome. Normally, the simplest test of this kind would do the trick to spot permission issues, partial archive backups, lack of keys, and more.

Simple monitoring must be put in place before anything else. Monitoring disk utilization, memory stress, CPU load, number of failed SSH logins, and other issues can help you detect problems early on. You also have to perform log rotation so that a debug file would not fill up the whole disk.

By the end of the first day, an Ubuntu VPS does not need to be perfect. It should have controlled access, current packages, a limited network surface, a clear deployment structure, and a working recovery plan. These steps create a server that is easier to operate when the project becomes busier and more complex.