Can I vibecode n8n Cloud?

Build me a robust, production-ready, self-hosted n8n setup to replace n8n Cloud. The goal isn't to write a new workflow engine—n8n is already source-available—but to provision a complete, secure infrastructure stack on my own VPS using Docker Compose.

Requirements:
- Architecture: Provide a comprehensive `docker-compose.yml` that uses the official n8n image. Use SQLite for storage (which is perfectly fine for personal scale) rather than introducing the complexity of PostgreSQL. Configure a named volume for `/home/node/.n8n` to ensure data persistence across restarts. Set the restart policy to `unless-stopped`.
- Networking & Security: n8n must bind to `127.0.0.1` only, so it isn't directly exposed to the internet. Assume it will be published through an existing reverse proxy (like Traefik, Caddy, or Nginx) on an HTTPS subdomain. Rely on n8n's built-in user management to guard the editor interface.
- Configuration: Provide a `.env` template. Crucially, explicitly set the `N8N_ENCRYPTION_KEY` in the `.env` file. Include prominent comments explaining that losing this key will orphan every stored credential and connection in the database, making backups essential. Also set `WEBHOOK_URL` to the public subdomain so external services can correctly resolve webhook endpoints.
- Backup Strategy: Write a nightly backup bash script (`backup.sh`). It should use the n8n CLI to export workflows and credentials as JSON files, and then copy the entire SQLite data volume to a `backups/YYYY-MM-DD/` folder. The script should automatically prune backups older than 14 days.
- Update Routine: Write a safe update script (`update.sh`) that pins a specific version tag. It must run the backup script first, pull the specified new image tag, and then recreate the containers. Do not use `:latest` blindly; explain why pinning versions prevents unexpected breakage.

Testing & Documentation:
- Provide two starter workflows exported as JSON to be used as smoke tests:
  1. An RSS-to-email digest.
  2. A webhook-to-Telegram alert.
- Exclude multi-user team features or high-availability scaling (like Redis queues or worker nodes). This is explicitly a single-person automation box.
- Create a thorough README. It must include first-boot instructions (setting up the owner account), a mandatory drill for restoring from a backup, and the standard update routine. Treat the operational setup as the "product" being built.