5 server and deploy problems you can fix in 60 seconds

Most server and deploy problems aren't hard. They're just confusing the first time you hit them. Here are five we see constantly, each with the cause, the fix and a way to check it worked.

1. Your firewall blocks port 8080, but Docker opens it anyway

Why it happens: when you publish a port with -p 8080:80, Docker rewrites the traffic to the container's IP. The packet then goes through the FORWARD chain, where Docker's own rules accept it. UFW mostly manages INPUT, so ufw deny 8080 never sees it.

The fix: if only your reverse proxy needs the port, bind it to localhost in compose.yaml:

ports: - "127.0.0.1:8080:80" 

Check it: run docker ps. You want 127.0.0.1:8080->80/tcp, not 0.0.0.0:8080. Then test from another machine with nc -zv your.server.ip 8080. It should fail.

2. Works locally, blank page when deployed (Vite, React, Lovable exports)

Why it happens: the built index.html loads its JS and CSS from paths that don't exist on the server. Open the browser console and you'll see 404s for /assets/index-*.js. The usual cause is a base setting that doesn't match where the app lives.

The fix: set base in vite.config.ts to the path the app is served from: '/' at the domain root, or '/app/' if it lives under a sub-path.

export default defineConfig({ base: '/', }) 

Check it: run npm run build, upload the whole dist/ folder (not the project folder), and hard-refresh. The console should show no 404s.

3. /dashboard works until you hit refresh. Then 404.

Why it happens: single-page apps handle routes in the browser. On refresh, the server looks for a real file called /dashboard, doesn't find one and returns 404.

The fix: send unknown paths to index.html. In Caddy:

app.example.com { root * /var/www/app try_files {path} /index.html file_server } 

In Nginx, the same idea is one line inside location /: try_files $uri /index.html;

Check it: open a deep link like /dashboard in a new tab. It should load the app, not a 404.

4. Disk full, and Docker logs did it

Why it happens: Docker's default json-file log driver doesn't rotate logs. A chatty container can write gigabytes until the disk fills up and everything on the server stops.

The fix: cap the log size in /etc/docker/daemon.json:

{ "log-driver": "local", "log-opts": { "max-size": "10m", "max-file": "3" } } 

Check it: run sudo systemctl restart docker, then docker compose up -d --force-recreate. The setting only applies to new containers, so recreate them. docker system df and du -sh /var/lib/docker/containers show where your space went.

5. Bots are guessing your SSH password right now

Why it happens: every public server gets brute-force login attempts within hours of going online. Check sudo journalctl -u ssh | grep -c "Failed password" on yours. Keys can't be guessed. Passwords can.

The fix: first add your SSH key and confirm you can log in with it in a second terminal. Then create /etc/ssh/sshd_config.d/01-no-passwords.conf:

PasswordAuthentication no KbdInteractiveAuthentication no 

The 01- prefix matters. sshd uses the first value it reads, and cloud images often ship 50-cloud-init.conf with PasswordAuthentication yes, which would win over a file that sorts after it.

Check it: run sudo systemctl reload ssh, then sudo sshd -T | grep -i passwordauth. It should say passwordauthentication no. Keep your existing session open until a new key login works.

More fixes

For longer guides on running apps on your own server, see the VeloxaHost blog, and for AI-built sites, the Veloxa Build guides.

Disclosure: we run VeloxaHost, a hosting and VPS provider. Everything above works on any Linux server.