CSSTEP 01Secure access without locking yourself out
Use a non-root SSH account and keys. Verify a second key-based connection before changing authentication rules. Keep a provider console or recovery route available. Validate sshd configuration before reload. Never disable an access method until its replacement works.
STEP 02Expose only what serves a purpose
A public web service usually needs the proxy’s HTTP/HTTPS ports and a controlled SSH route. Databases and internal APIs should stay private. Check listening sockets and your container port mappings. Docker-published ports can bypass UFW; understand the actual packet path.
ss -ltn
docker ps --format "table {{.Names}} {{.Ports}}"STEP 03Treat secrets as separate runtime data
Keep production values out of Git, Docker image layers, browser code and AI prompts. Give each app separate database credentials and minimal permissions. Rotate exposed credentials; deleting the file from the latest commit does not revoke a leaked key.
STEP 04Updates and backups are recurring work
Use supported releases, plan security updates and test them. Back up data to a separate protected location, monitor failures and test restoration. Application logs should avoid credentials and personal payloads. Monitor disk space as well as whether the process runs.
STEP 05Use the smallest responsible next step
Ask AI to explain the effect of commands before running them. Avoid chmod 777, disabling the firewall, password-based root login or publishing PostgreSQL as shortcut fixes. A tutorial can show a pattern; you still need to adapt it to the server you actually operate.
COPY → YOUR AI
Take the next step to your AI.
A safe starting prompt for this guide. No secrets. Works with ChatGPT, Claude and other assistants.
Sources and technical documentation
Ubuntu OpenSSH ↗Docker firewall behavior ↗This recipe is a pattern for the stated prerequisites. Verify project compatibility and your actual server configuration before applying it to a live service.