Running Ubuntu for the site is not just about installing Nginx or Apache. The production server must have recoverable access, patch, firewall, TLS, runtime, database, backup, log and monitoring. If you change the DNS before testing this string, the first simple error may become definite and difficult to recover.
Quick answer:First, create an inventory and emergency access path, patch the system to the supported version, prepare the admin user with an SSH key and step firewall. Then install the web stack with minimum service, TLS and backup; measure the site with a test hostname and smoke test, and only move the DNS with a specified TTL and rollback.
Before the arrival.
- Supported Ubuntu version and validated image
- IP, provider console and network information
- Domain and DNS access
- Runtime, database and supported versions required
- The CPU, RAM, storage and traffic estimates
- RPO/RTO and independent backup destination
- Patch owner and incident response.
Just read the initial status.
lsb_release -a
uname -r
ip -br addr
ss -lntup
free -h
df -h
systemctl --failedThese commands display the status and do not change settings. Anonymous the public IP output, username and network information before publicly posting. An unknown service or open port must be checked before continuing.
Patch and Reboot
Get packages from a valid repository. A kernel update or critical library may require reboot or restart; you may have an emergency maintenance window and console. The major upgrade of the Ubuntu project is separate from the backup and compatibility test, not part of the daily installation.
The user interface and the minimum access
Do your daily work with a dedicated user and a controlled sudo. Build SSH keys on a secure device and do not copy private keys to a server or repository. Keep each person's account separate to allow revoke and audit. Shared root and shared password are not suitable for storing paths.
Secure the SSH without locking.
First, keep the login key open in the second session of the test and console. Then phase out the password/root login. Before reloading, check the syntax configuration with the same version tool. Changing port, firewall, and authentication simultaneously makes error detection difficult.
Firewall with minimal Allowlist
Open only HTTP/HTTPS ports and the necessary management. Before activating, verify the SSH rule of the management network and the path of the console. The database and Redis should not be on the Internet for no reason. Docker can also add a network rule; really test the packet path.
Time, hostname and DNS
Clock synchronization is critical for TLS, log, token, and cron. Set the display timezone wisely, but keep logs with a compatible basis. Enable A/AAAA record only when both paths respond correctly; IPv6 is semi-configured to make mistakes for some users.
Nginx or Apache.
Both can be production-friendly. Program compatibility, team experience, rewrite, and proxy architecture are more important than the fastest tag. Both generate errors on a single port.
Runtime program
PHP, Python, Node, or other runtime versions must be supported by programs and plugins. Do not add unknown repository. Configure process manager, worker, timeout, and memory with workload. Run the program with root or permission777The solution is not permission.
Do not make the database public.
Limit the database to the required interface and firewall and limit the user of the application. Do not leave the password in the public configuration, history or repository.
File ownership and deployment
Code, upload, and secret cycles vary. Keep releases copied and rollbackable and keep user files out of the code replacement path. Set permission based on the read/write process, not by opening them publicly.
TLS and Redirect
The certificate must have a real domain and a full chain. Control the automatic renewal with dry run and expiration alert. Enable HTTP redirect to HTTPS after verifying domain response. HSTS has a long-term effect and should not be rushed before sub-types are ready.
Proxy and real IP headers
If you have a CDN or reverse proxy, accept the actual scheme, host, and IP from only trusted proxies. Average trust in the user's sent header allows for IP forgery and bypassing the rate limit. Redirect loop and secure cookie often come from the incorrect detection of HTTPS behind the proxy.
Log and rotation
Access/error log specifies the web server, program, runtime, database and journal. Retention and rotation prevent the disk from filling. secret, cookie and payload payment should not be logged. Timestamp and common request ID facilitate error recovery.
Independent backup and restore test
From the database, the user file and the configuration copy are synchronized and kept outside the same server. Determine encryption, retention, and restore access. A snapshot of the same account is not enough for all scenarios.
Monitoring and Alert
- HTTP and TLS validity
- CPU, load, available RAM and OOM
- Disk space, inode and I/O latency
- Process and restart status
- Rate of 4xx/5xx and p95.
- Database, queue and recently backup.
The alert must be responsible and runbook. The CPU alert is without a detection path or alert after the full disk is loaded.
Control of the Brute Force.
The ban tool can reduce noise and brute force, but it does not replace key, firewall, and patch. Set up log source, threshold, and allowlist management correctly so that the administrator or proxy is not blocked incorrectly.
Preparing the site before DNS
Test the homepage, asset, login, upload, cron, email, and purchase path with a test hostname or controlled override. The host and HTTPS header should be the same as the production; the test does not cover only the IP, virtual host, and actual certificate.
DNS transmission with Rollback
- Reduce TTL by the appropriate distance.
- Make the final backup and sync of the data.
- Write the timing and order in the program.
- Change the records to the test destination.
- Monitor both the server and metrics.
- Returns the TTL after stabilization.
For the active site,A guide to moving WordPress from shared hosting to VPS.It complements the infrastructure criteria and the cutover program.
Hardening the services.
Run services with user-excluded, restricted filesystem access and secret out of code. Disable unused services after inventory. Do not blindly apply general template hardening; measure program requirements, update and rollback path.
After installation maintenance plan
Installation is not complete. Set up patch windows, access reviews, restore tests, TLS extensions, disk capacity and review alerts. Owner of any work and method of recording changes should be clear. Configuration drift between records and the incident server will prolong.
Final control of the reading.
ss -lntup
df -h
free -h
systemctl --failed
journalctl -p err -bThe final command shows current boot errors and may contain an old or unrelated message; check each case with the service and timestamp. Once installed, also control the port and HTTPS from outside the server.
Production delivery standard
- Access to the administrator and console recovery is tested.
- Only the necessary ports are open.
- HTTPS and certificate extension controlled
- The backup has been restored.
- Monitor and alert respond to the person.
- Rollback release and DNS is documented.
- The smoke test is a successful business operation.
Common Mistakes
- SSH shut down before the second session.
- Opening the DB/Redis on the Internet
- Use of
chmod 777 - Keeping a secret in the repository
- DNS before the Host/TLS test
- Backup without restore test
- A few web servers/firewalls without a map.
When do you need special assistance?
If you have a store site, a virtual migration or a limited network, an error in SSH, firewall, TLS or DNS will disconnect you.Install and configure the Linux serverIt can prepare the stack with backup, hardening, monitoring and rollback.
Common Questions
Ubuntu Server or Desktop?
The server is usually suitable without a graphical environment and with less service level; check the program and team requirements.
Is the SSH port change enough?
Noise reduces the scanning but does not replace key, access restrictions, patches and monitoring.
First DNS or SSL?
Depends on validation; design the destination before the cutover with the actual test host and the route of the release/extension.
Is the snapshot the same as the backup?
It's useful for some recovery, but independence, adaptability, retention and restore testing are still necessary.