agentleFS
Sign inStart free
ldaumeldaume/agentic-engineering-harness/skills/infrastructure/secure-linux-web-hosting/SKILL.md

secure-linux-web-hosting

Skill3 starsChanged 3 months agoMITView on GitHub

Guides secure setup and review of Linux web servers for self-hosted apps, static sites, reverse proxies, SSH, firewalls, TLS, backups, updates, logs, and basic hardening. Use when provisioning a VPS, hardening a server, configuring Nginx/Caddy/Traefik, deploying web apps, or reviewing self-hosting security.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

12 rules. About 0 are common, 11 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈11

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this for pragmatic server hardening and web hosting operations.

    line 8
  2. Distinctive:

    Before changing a server:

    line 12
  3. Distinctive:

    Read existing runbooks, compose files, systemd units, proxy configs, and DNS records.

    line 16
  4. Distinctive:

    Prefer reversible changes and snapshot/backup before risky operations.

    line 19
  5. Distinctive:

    Do not lock down SSH or firewall rules until a second access path is known.

    line 20
  6. Distinctive:

    Keep hostnames, upstreams, TLS, redirects, and security headers explicit.

    line 34
  7. Distinctive:

    Do not expose admin dashboards publicly without auth and rate limiting.

    line 35
  8. Distinctive:

    Document whether the proxy terminates TLS or forwards to another layer.

    line 38
  9. Distinctive:

    Keep secrets outside git and out of shell history.

    line 42
  10. Distinctive:

    Use systemd, Docker Compose, or orchestrator units consistently.

    line 43
  11. Distinctive:

    Prefer health checks and rollback notes for app deployments.

    line 44
  12. Very specific:

    Keep docker exec non-interactive inside a script piped to a remote shell (ssh host bash -s).

    line 46

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Secure Linux Web Hosting

Use this for pragmatic server hardening and web hosting operations.

Project Fit Check

Before changing a server:

  1. Identify provider, OS, access path, services, firewall, reverse proxy, backup policy, and deployment process.
  2. Read existing runbooks, compose files, systemd units, proxy configs, and DNS records.
  3. Confirm whether the server is production, staging, or experimental.
  4. Prefer reversible changes and snapshot/backup before risky operations.
  5. Do not lock down SSH or firewall rules until a second access path is known.

Baseline

  • Key-based SSH; disable password login when operationally safe.
  • Dedicated deploy/user accounts; avoid routine root login.
  • Firewall allows only required ports.
  • Automatic security updates or a documented patch cadence.
  • TLS via the chosen proxy or certificate automation.
  • Backups for stateful data, tested restore path, and retention policy.
  • Logs available for auth, proxy, app, and system failures.

Reverse Proxy Rules

  • Keep hostnames, upstreams, TLS, redirects, and security headers explicit.
  • Do not expose admin dashboards publicly without auth and rate limiting.
  • Set request/body limits according to app needs.
  • Preserve WebSocket/SSE headers for realtime apps.
  • Document whether the proxy terminates TLS or forwards to another layer.

Deployment Rules

  • Keep secrets outside git and out of shell history.
  • Use systemd, Docker Compose, or orchestrator units consistently.
  • Prefer health checks and rollback notes for app deployments.
  • Monitor disk, memory, certificates, and failed services.
  • Keep docker exec non-interactive inside a script piped to a remote shell (ssh host bash -s). With -i the exec inherits that pipe and consumes the rest of the script, so every later command silently never runs and the shell still exits 0 - a remote check that cannot fail.

Red Flags

  • public SSH password login
  • firewall disabled because "the app works"
  • untested backups
  • admin UI exposed on the public internet
  • wildcard proxy routes with no auth boundary
  • manual server changes that bypass the documented deployment path
  • remote verification that reports success without having run

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free