Ubuntu VPS Server: From First Login to a Working Deployment

Prepare access and a way back in

Save the server address and initial account details in a password manager. Locate the recovery console in the hosting panel and confirm how to open it. A console matters when an incorrect firewall rule makes SSH unavailable. Choose a supported Ubuntu LTS image that your application actually supports.

Keep a short deployment record: image version, region, allocated resources and the services you intend to expose. This makes a rebuild less dependent on remembering what you clicked during setup.

Inspect the machine before installing services

Connect using the account specified by your provider. The address below is reserved for documentation; replace it with your server address. Verify the SSH host fingerprint against a trusted console before accepting it.

ssh [email protected]
cat /etc/os-release
free -h
df -h

Compare the installed image, available memory and disk with your order. Resolve any mismatch before deploying. The default login may be different from ubuntu; do not assume a failed login means the server is unavailable.

Update packages and create an administrator

On a new machine, review available updates and apply them before installing your stack. Read the package changes before confirming. If a reboot is required, schedule it while the server is still empty.

sudo apt update
sudo apt upgrade
sudo adduser deploy
sudo usermod -aG sudo deploy

Set up your public SSH key for the new account, then verify a second login and sudo access. Keep your original session open. Do not disable an existing authentication method until its replacement works.

Open only the ports your application needs

Check both the provider firewall and the guest firewall. For a fresh server using SSH on the default port, the following permits SSH before enabling UFW. If you changed the SSH port, allow that actual port first.

sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status verbose

A public website normally also needs its HTTP and HTTPS ports allowed. A database used only by the local application should not be publicly reachable. Check externally after changing rules; a local connection does not prove that internet access works.

Deploy with an explicit start and restart process

Give the application its own service account and configuration. Keep secrets outside the source repository. Decide how it starts after reboot, where logs go and how a failed deployment is rolled back. A process running in your SSH terminal is not a reliable production service.

For a website, point the domain at the correct address, configure the web server and obtain a valid TLS certificate. Test the final HTTPS hostname, redirects and application health endpoint before sending real traffic.

Make recovery a tested procedure

Store copies of application data and configuration outside the server. Back up databases using a method that preserves consistency; copying active database files blindly can produce an unusable backup. Restore into a separate environment and record how long the procedure takes.

Monitor disk space, memory pressure, service errors and availability. Choose who receives alerts and who applies updates. A small server can work well when routine maintenance is explicit; extra CPU does not fix missing backups.

Before you publish

• A fresh SSH session works with the intended administrator account.
• Recovery console access is available independently of SSH.
• Only necessary services are reachable from the internet.
• The application survives a planned restart.
• A backup has been restored successfully in a separate environment.
• Someone owns monitoring, updates and incident response.

If the application runs out of memory during a realistic test, revisit the hosting and resource guide before increasing traffic.

Questions and answers