What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
The dependable production layout is a Rust Actix Web binary listening on 127.0.0.1:8080, a service manager keeping it alive, a firewall exposing only required public ports, and a reverse proxy terminating HTTPS on ports 80 and 443. This guide takes you from a fresh Ubuntu VPS to a tested domain, with an alternative for terminating TLS directly in Actix.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
What you need before deploying
Prepare these items before opening an SSH session:
- An Ubuntu VPS with a public IPv4 address (and IPv6 if you intend to publish it).
- A sudo-capable account. Avoid running the application as root.
- A domain name that you control, ready to point at the VPS.
- An SSH client. Ubuntu documents installing
openssh-serverand using key-based authorization for administration. - At least the toolchain required by Actix Web: its getting-started guide currently lists Rust 1.72 as the minimum supported Rust version and uses the stable channel.
The examples use the application name hello-actix, the Unix user hello-actix, and the hostname example.com. Substitute your own values consistently.
As an Amazon Associate I earn from qualifying purchases.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Choose how the VPS will expose Actix
Actix can serve HTTP directly or sit behind another HTTP server. Decide this before configuring bindings and the firewall.
| Decision | Actix on loopback with a reverse proxy | Actix exposed directly |
|---|---|---|
| Application bind address | 127.0.0.1:8080 |
0.0.0.0:8080 (or a specific public interface) |
| Public ports | The proxy owns 80 and 443; port 8080 remains private | Actix owns the public HTTP/TLS port you configure |
| Certificates | Usually managed by the proxy and Certbot | Loaded by Actix with rustls and renewed by your operational process |
| Several websites or services | Simple host/path routing at one 80/443 listener | Each service needs its own exposure or an additional front end |
| Proxy features | Convenient forwarded headers, access logging, redirects, and TLS policy | You implement equivalent behavior in the application or another component |
For a normal single-site VPS, the loopback-plus-proxy arrangement is the safer default: an internet client cannot reach the Actix port directly, and the proxy can share 80/443 with other virtual hosts.
Provision the Ubuntu host and connect over SSH
Create an administrative path
Use your provider’s console to create or select a sudo-capable account, add your SSH public key, and disable password authentication only after key login has been verified. If the image does not include an SSH server, install and start it from the provider console:
sudo apt update
sudo apt install openssh-server
sudo systemctl enable --now sshFrom your workstation, connect with the account supplied by the image:
Free tools Windows power users keep installed
One-click scans. No signup required.
ssh your-user@example-vps-addressKeep the current SSH session open while you change firewall rules; opening a second session first gives you a recovery path if a rule is wrong.
Update Ubuntu and install the Rust build prerequisites
Refresh package metadata, apply available updates, and install a compiler toolchain plus pkg-config:
sudo apt update
sudo apt upgrade
sudo apt install build-essential pkg-configInstall Rust with rustup, then refresh the toolchain:
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
rustup update
source "$HOME/.cargo/env"
rustc --version
cargo --versionConfirm that rustc is at least 1.72. If your distribution image already includes Rust, rustup still provides a predictable, independently updated toolchain for the application.
Create a minimal Actix Web application
Generate the Cargo project
cargo new hello-actix
cd hello-actixReplace the dependency section in Cargo.toml with:
[dependencies]
actix-web = "4"Add a route and an HTTP server
Put this in src/main.rs:
use actix_web::{get, App, HttpServer, Responder};
#[get("/")]
async fn index() -> impl Responder {
"Hello from Actix on a VPS"
}
#[actix_web::main]
async fn main() -> std::io::Result<()> {
HttpServer::new(|| App::new().service(index))
.bind(("127.0.0.1", 8080))?
.run()
.await
}The handler is registered on an App. HttpServer creates the workers, binds the socket, starts the server with run(), and the asynchronous main function waits for it with await. Binding to loopback is deliberate when a reverse proxy will be the only public entry point.
When to use 0.0.0.0
Change the bind tuple to ("0.0.0.0", 8080) only when direct external access to Actix is intentional. That makes the port reachable on every IPv4 interface, so the firewall and the application itself become responsible for limiting exposure. Do not switch to this address merely because a proxy cannot connect; a proxy on the same VPS can reach 127.0.0.1:8080.
Compile and smoke-test before making the service public
Build the optimized binary:
cargo build --releaseStart it in the foreground for a first check:
./target/release/hello-actixFrom another SSH session on the VPS, request the loopback endpoint:
curl -i http://127.0.0.1:8080/You should receive an HTTP success response containing Hello from Actix on a VPS. Stop the foreground process with Ctrl+C. Leaving it attached to SSH is not a production process model: it ends when the session closes and provides no boot or crash recovery.
Run Actix under systemd
Create a dedicated service account and install directory
sudo useradd --system --home /opt/hello-actix --shell /usr/sbin/nologin hello-actix
sudo install -d -o hello-actix -g hello-actix /opt/hello-actix
sudo install -o hello-actix -g hello-actix -m 0755 target/release/hello-actix /opt/hello-actix/hello-actixThe service account has no interactive shell and owns only the application directory. Keep configuration secrets outside the binary and grant the account only the files it must read.
Create the unit file
Create /etc/systemd/system/hello-actix.service:
[Unit]
Description=Hello Actix Web service
After=network-online.target
Wants=network-online.target
[Service]
User=hello-actix
WorkingDirectory=/opt/hello-actix
ExecStart=/opt/hello-actix/hello-actix
Restart=on-failure
Environment=RUST_LOG=info
[Install]
WantedBy=multi-user.targetLoad the unit, enable it at boot, start it now, and inspect its state:
sudo systemctl daemon-reload
sudo systemctl enable --now hello-actix
sudo systemctl status hello-actix
journalctl -u hello-actix -fHttpServer is designed to run until shutdown; systemd supplies the missing lifecycle behavior by starting it after boot and restarting it after a failure. The journalctl command follows the service’s standard output and error, which is the first place to look for a bind, permission, or panic message.
Deploying a later build
Build on the VPS or in a controlled build environment, replace the binary atomically, and restart:
cargo build --release
sudo install -o hello-actix -g hello-actix -m 0755 target/release/hello-actix /opt/hello-actix/hello-actix
sudo systemctl restart hello-actix
sudo systemctl status hello-actixRun the loopback curl check after every replacement. If the new binary fails immediately, use journalctl -u hello-actix -n 100 --no-pager and restore the last known-good binary.
Configure a minimal UFW firewall
Ubuntu’s default firewall frontend is UFW, and it is initially disabled. Preserve SSH before enabling it:
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verboseThese rules allow administration and the two proxy ports. Do not open 8080 when Actix is bound to loopback. If you intentionally bind Actix to a public interface, add only the exact port and source ranges your design requires; a broad 8080 rule defeats the private-port topology.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchInstall a reverse proxy in front of Actix
Install and start Nginx
sudo apt install nginx
sudo systemctl enable --now nginxCreate a server block for your hostname. The following HTTP configuration forwards requests to the private Actix listener and preserves the information applications commonly need:
server {
listen 80;
server_name example.com www.example.com;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}Enable the site using the layout supplied by your Ubuntu image, then validate before reloading:
sudo nginx -t
sudo systemctl reload nginxAt this stage, an HTTP request to the hostname should travel through Nginx to Actix. If the proxy returns a gateway error, test curl -i http://127.0.0.1:8080/ first; a failing private request means the problem is the Actix process or its bind address, not the proxy.
Point DNS at the VPS and issue HTTPS
Prepare the ACME challenge
Create an address record for example.com (and, if used, www.example.com) pointing to the VPS public address. Wait until public DNS resolvers return that address. Keep TCP port 80 reachable: the HTTP-01 challenge used by the standard Ubuntu Certbot path needs it.
Obtain and install the certificate with Certbot
Ubuntu documents this snap-based installation and Nginx integration:
sudo snap install --classic certbot
sudo certbot --nginx -d example.com -d www.example.comCertbot can edit the Nginx server block to serve TLS and can offer an HTTP-to-HTTPS redirect. Choose the redirect if every request should use HTTPS. Let’s Encrypt certificates are valid for 90 days; the Certbot package installs a systemd timer that attempts renewal twice daily.
Verify automatic renewal
sudo systemctl status snap.certbot.renew.timer
sudo certbot renew --dry-runA dry run exercises the renewal path without replacing the live certificate. Keep port 80 available for future HTTP-01 validations even when normal visitors are redirected to HTTPS.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Direct TLS in Actix: when it is appropriate
Actix also supports terminating TLS itself. Its documentation recommends rustls for new applications and provides a bind_rustls_0_23 method for the corresponding rustls API. You enable the appropriate rustls feature in actix-web, load PEM-encoded certificate and private-key files, and bind the server with that method instead of plain bind. Match the feature and method to the rustls API version selected by your dependency lockfile; these names are version-sensitive.
Direct termination can be reasonable for a single service when you already have a secure certificate-distribution and renewal workflow. Protect the private-key file with restrictive ownership and permissions, and do not give it to more accounts than necessary. TLS configuration enables HTTP/2 support in Actix, but you must still configure certificates, renewal, redirects, and logging yourself.
| Operational concern | TLS in Nginx | TLS in Actix |
|---|---|---|
| Certificate renewal | Certbot can modify the proxy and its timer handles repeated attempts | Your deployment must load renewed files and restart or reload Actix safely |
| Application exposure | Actix stays on loopback; only 80/443 are public | The Actix TLS listener is public unless another firewall or proxy limits it |
| HTTP/2 and edge policy | Centralized at the proxy for all sites | Handled in the Actix TLS configuration for that service |
| Multiple services | One proxy can route several hostnames on 80/443 | Port sharing requires an additional front end or separate addresses |
| Logs and client IPs | Proxy access logs and forwarded headers are available centrally | You implement equivalent collection and trusted-proxy handling |
Verify the complete public path
Run the checks in this order so that each layer is isolated:
curl -i http://127.0.0.1:8080/— confirms the Actix process and local bind.curl -I http://example.com/— confirms DNS, port 80, and proxy routing. Check whether the response redirects according to your policy.curl -I https://example.com/— confirms TLS negotiation, certificate selection, and HTTPS routing.sudo systemctl status hello-actix nginx— confirms both supervisors report healthy units.sudo ufw status verbose— confirms that only intended ports are exposed.journalctl -u hello-actix -n 100 --no-pager— checks for bind, permission, or runtime errors after the public request.
Inspect the HTTPS certificate presented for the intended hostname, not merely whether a connection succeeds. If you configured a redirect, verify that the final HTTPS response serves the application content rather than a proxy default page.
Troubleshoot the failures you are most likely to see
| Symptom | Likely cause | Action |
|---|---|---|
curl 127.0.0.1:8080 reports connection refused |
The service is stopped, crashed, or bound to another address | Run systemctl status hello-actix, inspect journalctl, and confirm the tuple in main.rs. |
| Systemd reports “permission denied” | The binary or working directory is not readable/executable by hello-actix |
Check ownership and mode on /opt/hello-actix and reinstall the binary with the service account as owner. |
| Nginx returns 502 Bad Gateway | Actix is down, listening on a different port, or the proxy target is wrong | Test the loopback URL, compare it with proxy_pass, then reload Nginx after nginx -t succeeds. |
| SSH disconnects after enabling UFW | The SSH rule was omitted or the wrong profile/port was allowed | Use the provider console to restore an SSH rule, then add it before enabling UFW again. |
| Certbot cannot complete HTTP-01 | DNS still points elsewhere, port 80 is blocked, or Nginx is not serving the hostname | Check public DNS, ufw status verbose, the port-80 server block, and an HTTP request from outside the VPS. |
| HTTPS shows the wrong certificate | The hostname reaches a different server block, address, or VPS | Verify DNS records and the Nginx server_name entries, then reload after correcting them. |
| The application port is visible from the internet | Actix is bound to 0.0.0.0 or a firewall rule exposes 8080 |
Use 127.0.0.1 for the proxy topology and remove the unnecessary UFW allowance. |
Ongoing operating checklist
- Keep the Actix binary under systemd rather than an SSH terminal.
- Review
journalctl -u hello-actixand Nginx logs when deploying changes. - Apply Ubuntu security updates and refresh the Rust toolchain deliberately, testing a release build after updates.
- Run
certbot renew --dry-runperiodically and monitor the renewal timer. - Back up Nginx configuration, systemd units, DNS settings, and certificate-renewal instructions; do not back up private keys into world-readable locations.
- After changing a bind address, proxy target, firewall rule, or certificate, repeat the layered verification sequence instead of testing only the browser.
Version-sensitive details to recheck
Actix Web’s stated minimum Rust version, rustls feature names, and the bind_rustls_0_23 API can change between releases. Ubuntu’s package and Certbot instructions can also vary with the distribution image. Before a production rollout, compare your selected Actix, Rust, Ubuntu, rustls, Nginx, and Certbot versions with their current documentation and test the exact unit and renewal commands on a non-production VPS.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
