Preparing a VPS, DNS, Ports, and TLS
A production VPS needs a maintained operating system, restricted administrative access, a firewall, DNS, and a TLS-terminating reverse proxy. Application ports should be exposed only where the architecture requires them.
What You Will Be Able to Decide
- Explain the role of preparing a vps, dns, ports, and tls in a self-hosted system.
- Apply the procedure to a real open-source deployment.
- Recognise unsafe defaults and verify the resulting control.
- Record enough evidence for another operator to repeat or recover the work.
A VPS is a remote computer with a public network identity. That makes it flexible and inexpensive, but it also means every exposed service must be deliberate.
Ports are numbered network doors. DNS points a human-readable name at the server, while a reverse proxy receives web traffic and forwards it to the correct container. TLS protects the connection between a user and that public entry point.
The goal is not to memorise every command. It is to draw the path from a browser to a process and know which component owns each boundary.
Technical term
Published port
A mapping from a host address and port to a container port, such as host port 8080 forwarding to port 3000 inside a container.
A building directory maps a public reception desk to the correct internal room; the room number and street entrance do not need to match.
The Working Model
Use a supported Linux release and create a non-root administrative user. Prefer SSH keys over passwords, retain a tested recovery route through the VPS provider, and apply security updates before installing an application platform.
For a typical web service, public traffic should enter on TCP 80 and 443 through a reverse proxy. Databases, queues, and internal application ports usually belong on a private Docker network, not on every internet-facing interface.
Docker-managed port publishing can interact with host firewall rules in surprising ways. Treat a published container port as an exposure decision, verify it from outside the server, and avoid assuming that a simple UFW rule is the complete boundary.
Implementation Procedure
- Provision a supported Ubuntu LTS VPS and record its public IPv4 or IPv6 address.
- Create a non-root sudo user, install an SSH public key, test a second login, and only then restrict password and root login.
- Apply updates, enable time synchronisation, and configure the provider firewall plus the host firewall.
- Create an A or AAAA DNS record for a deployment subdomain and wait for it to resolve.
- Reserve public ports 80 and 443 for the reverse proxy; document every additional port and its reason.
# Inspect listening sockets on the VPS
sudo ss -tulpn
# Resolve the deployment hostname
dig +short app.example.com
# Test the public TLS endpoint after deployment
curl -I https://app.example.comControlled Practice and Fragile Practice
Verification and Recovery Evidence
- A port scan from outside shows only the intended public services.
- The hostname resolves to the server and the TLS certificate matches it.
- The provider console can recover access if SSH configuration fails.
Warning Signs
- Administrative panels are exposed without an access restriction.
- Several containers publish default database or cache ports publicly.
- Nobody can explain which service owns a listening port.
Questions to Ask a Consultant
- Which ports must be public, which must be private, and why?
- Where does TLS terminate and how is the certificate renewed?
- What recovery access remains if an SSH change locks out the operator?
Key takeaway
Key Takeaway
A secure network boundary is a documented traffic path. Publish only the ports the path requires and verify the result externally.