If you are using an AI coding assistant to build and run a site, the biggest security risk is usually not some exotic exploit. It is the boring stuff: a public .env file, overly broad file permissions, an open admin endpoint, or a server that never gets patched. This guide walks through a how to secure an AI-built Linux site before launch checklist that is realistic for solo builders and small teams.
The goal is not to turn your project into a fortress. It is to reduce the easy wins for attackers and make recovery straightforward when something breaks. That matters even more when an AI agent is helping you ship changes quickly. Fast iteration is great; fast iteration with guardrails is better.
How to secure an AI-built Linux site before launch
Before you publish your site, make sure you have answered five questions:
- Are secrets stored outside the repo?
- Can the web server only read what it needs?
- Are remote logins locked down?
- Do you have backups you can actually restore?
- Can you update the box without guessing?
If you cannot answer those confidently, pause the launch and fix them first.
1) Keep secrets out of the codebase
This is the most common mistake on AI-built projects. API keys, database URLs, admin passwords, and OAuth tokens should live in environment variables or a secrets manager, not in committed source files.
Use this rule of thumb: if it would be embarrassing to paste into a public GitHub issue, it does not belong in the repository.
- Store secrets in
.envfiles that are excluded by.gitignore. - Use separate secrets for development, staging, and production.
- Rotate any secret that was ever committed, even briefly.
- Check generated files too; AI tools sometimes create config files with placeholders that later become real credentials.
Quick test: search your repo for words like key, secret, token, password, and bearer. If you see anything live, fix it before launch.
2) Harden SSH access
SSH is still one of the first doors attackers try. The simplest protection is to make that door harder to open.
- Disable password login and use SSH keys only.
- Block direct root login over SSH.
- Use a non-root account for normal admin work.
- Restrict access by IP if your workflow allows it.
On a Linux host, that usually means editing /etc/ssh/sshd_config, then restarting the SSH service and testing a second session before closing the first one. Do not lock yourself out on a Friday night.
If your AI assistant is making system changes, make sure it is doing so through a controlled account. Vibesies, for example, gives each site its own sandboxed Linux environment, which is the right idea: isolate changes so a mistake in one project does not spill into another.
3) Run the web app with least privilege
Many security incidents start because the app can read, write, or execute more than it should. Your web process should only have access to the directories and services it actually needs.
Check the basics:
- Static assets are readable by the web server.
- Uploads are not executable.
- The app process does not own the whole filesystem.
- Database credentials only work for the app, not for every service on the box.
A practical target is to keep application code owned by a deployment user and writable only where necessary, such as logs, caches, or upload directories. If your framework needs write access to a specific path, give it that one path, not the entire project tree.
4) Lock down nginx or your reverse proxy
Whether you use nginx, Caddy, or another proxy, it should do more than pass traffic through. It should help reduce exposure.
- Force HTTPS.
- Set security headers where appropriate.
- Block access to hidden files like
.env,.git, and backup archives. - Limit upload sizes to something reasonable.
- Return clear 404s for internal paths rather than exposing directory listings.
For many small sites, a few sensible headers go a long way: Strict-Transport-Security, X-Content-Type-Options, and a cautious Content-Security-Policy. The CSP can be annoying to tune, but it is worth doing if your site renders custom HTML or accepts user content.
5) Update the operating system and packages
AI tools are good at writing features and mediocre at remembering routine maintenance. That is how servers drift into dangerous territory. Before launch, make a plan for updates.
- Apply OS security updates.
- Update Python, Node, Ruby, PHP, or other runtime packages.
- Pin dependency versions where stability matters.
- Review changelogs before major version jumps.
If you are not sure what is installed, inventory it. A small site with a known package list is far easier to secure than a mystery box with six orphaned services and one forgotten cron job.
6) Make backups boring and automatic
Backups are not real until you have restored one successfully. A surprising number of people assume their backups work because the backup job exits cleanly. That is not enough.
Your backup plan should include:
- Database dumps
- Uploaded files and media
- Configuration files
- Secrets stored securely outside the main app tree
Use at least one off-host backup location. If the server dies, gets encrypted, or is accidentally wiped, local-only backups are not useful. For production sites, schedule backups often enough that restoring from the previous snapshot is acceptable for your business.
Best practice: run a restore test before launch and again after any major schema change.
7) Protect admin routes and dashboards
AI-built sites often ship with a powerful admin panel that was easy to create and easy to forget. Those routes deserve extra attention.
- Require strong authentication.
- Add multi-factor authentication where possible.
- Use a separate admin domain or path if it reduces accidental exposure.
- Restrict by IP for internal tools.
- Make sure default credentials are gone.
Also check whether the admin UI leaks useful information. Stack traces, environment variables, database names, and internal hostnames all help an attacker. Error pages should be helpful to you and boring to everyone else.
8) Set up logging and alerts before launch
You cannot respond to incidents if you cannot see them. At minimum, log authentication events, application errors, and changes to sensitive settings.
- Keep logs somewhere persistent.
- Rotate logs so they do not fill the disk.
- Alert on repeated login failures and 5xx spikes.
- Watch disk usage, memory pressure, and certificate expiry.
A useful rule: if a problem would wake you up at 2 a.m., it should probably generate an alert before 2 a.m. The alerting system does not need to be fancy. It just needs to be reliable enough to tell you when something changes materially.
9) Review AI-generated code like a contractor would
When an AI agent writes code quickly, the risks are often in the edges: unsafe file handling, sloppy input validation, weak auth checks, or assumptions about trust boundaries. Treat generated code the same way you would treat work from a junior contractor who is moving fast and learning the codebase.
Before launch, review for:
- Input validation on forms, query strings, and uploads
- Authentication checks on every protected route
- Authorization so users only see their own data
- SQL injection risks in raw queries
- Command injection risks in shell calls
- Path traversal in file download or upload endpoints
If you see the AI shelling out to system commands, ask whether the same task can be done with a library call or a safer API. The fewer times user input crosses into the shell, the better.
10) Have a rollback plan
Security is part of deployment. If a release goes wrong, your response should be predictable.
Your rollback plan should answer:
- How do you restore the previous app version?
- How do you revert the last database migration?
- How do you disable a bad feature flag?
- Who gets notified if the rollback fails?
One of the quiet advantages of working in a managed environment is that the infrastructure can stay consistent while the app changes. That consistency makes rollback less painful. It is also why a platform like Vibesies can be useful for people who want a real Linux stack without assembling every guardrail by hand.
A practical pre-launch security checklist
Use this as a final pass before you point DNS at production:
- Secrets removed from the repo and rotated if needed
- SSH keys only, no password login
- Root login disabled over SSH
- Web app runs with least privilege
- nginx blocks sensitive files and forces HTTPS
- OS and package updates applied
- Backups configured and restore-tested
- Admin routes protected with strong auth
- Logs and alerts working
- Rollback plan documented
If you want, print this list and walk through it line by line. A thirty-minute review before launch can save you a weekend later.
Common mistakes that cause real incidents
Most security problems on small AI-built sites come from a few repeat offenders:
- Leaving debug mode enabled
- Serving the repository root directly
- Using the same password everywhere
- Assuming cloud defaults are secure enough
- Letting an AI agent edit system files without review
- Skipping restore tests because the backup job looked fine
None of those require advanced attackers. They only require a busy founder and a deadline.
Closing thoughts
The best way to secure an AI-built Linux site before launch is to make the safe path the easy path. Store secrets correctly, restrict access, keep the web layer narrow, and test your backups. That gives your AI coding workflow room to move quickly without turning every deploy into a gamble.
If you are building with an AI assistant in a real Linux environment, that workflow is easier to manage when the host itself is structured well from the start. And if you want a place where each site lives in its own sandboxed container, Vibesies is one option worth looking at while you plan your deployment and security process.