Live
VPS operations: nginx, systemd, Podman, certs, firewall, backups
This site's apps run on one VPS behind Cloudflare. The firewall admits only Cloudflare's address ranges, and certificates renew themselves. [Linux VPS, systemd, UFW, Certbot]
How the live demos on this site run, and what stops them.
For technical reviewers: each weather run starts a fresh container with 256 MB, half a CPU, 64 processes and a 15 s limit, and the run timings are a live count.
- Memory per run
- 256 MB
- CPU per run
- half a CPU
- Processes per run
- 64
- Time limit per run
- 15 s
- Runs at once
- Waiting queue
- Sandbox image built
Checked The live runner
Recorded runs on this server: median 1.63 s, and 95 in 100 under 2.08 s.
The request path
You press Run in your browser, and the server does the work. Your browser reaches Cloudflare first, then the web server. The web server returns a static page or hands the request to one small demo service. That service starts a fresh container or reads a small database. [Cloudflare, nginx, Node service, Podman, SQLite]
The code runner sends back the log as the script runs. You change the supplied settings, and only the fixed script runs.
$ curl -sI https://www.fullstack-freelancer.dev/ # every answer comes back through Cloudflare
server: cloudflare
cf-cache-status: DYNAMIC
x-content-type-options: nosniff
Each demo uses public data differently. A weather run reads the forecast and labels each day. The integration example cleans public feed records and removes repeats. It saves the result in a small tool for keeping leads and customers. [SQLite CRM]
See the stack for the technology list, or open the demos to inspect the examples. A forecast run shows its log as it happens, so you can follow the work behind the button.
- Your browserYou press Run.
- CloudflareDNS and the proxy in front of the server.
- Web serverReturns a static page, or hands /api requests on.
- Demo serviceOne small service with a cap on every run.
- Sandbox or databaseA fresh container for a weather run, or a small SQLite database.
Status you can read
The status beside a Run button tells you the demo's state. Anyone can read the same status with a plain GET request. The live code runner also shows how long each run took. [GET /api/health, GET /api/demos]
Live
Live demo API and runner sandbox
The status check shows the runner, registry scrape and integration showpiece live. Chat, voice, call and checkout run with you on a booked run-through.
- 3 live Live demos: runner, scrape, showpiece Demo status read [GET /api/demos] Checked
- 4 on request Run-through demos: chat, voice, call, checkout Demo status read [GET /api/demos] Checked
- 33, median 1.63 s Runs recorded by the runner Runner stats [GET /api/runner/stats] Counted
- 11/11 Runner sandbox checks passed Runner self-test Checked
We set up status reads like these for your own service, with limits that match the work each request does.
- Live code runner Live
- Scrape to CRM Live
- Integration showpiece Live
- Rules chat bot On request
- Browser voice demo On request
- Phone call demo On request
- Stripe test checkout On request
Checked curl -s https://demos.fullstack-freelancer.dev/api/demos
Caps and kill switches per demo
Each run needs a stopping point, whether it fetches a forecast or accepts a message.
The chat and voice demos have daily limits written into their code. Voice and calls have kill switches, and checkout runs on Stripe test cards.
Live
Live code runner
This is a live run. Each weather run gets 256 MB, half a CPU, 64 processes and a 15 s limit. It can reach only the weather service.
Live
Scrape to CRM, live
An interactive example: the registry scrape has a 45-second limit, and it never requests registered-agent names.
Live
Live API-to-CRM integration showpiece
An interactive example: the integration demo accepts messages signed by their sender. It refuses forgeries and ignores repeats.
Live run-throughs: chat, voice, calls, checkout
Chat, browser voice, phone calls and checkout spend real model calls and real phone minutes, so we run them live with you on a booked run-through. Their guards are written into the code.
Chat checks that a visitor is human and screens replies for leaks. It allows 10 messages per visitor a day, within a shared daily limit. [Cloudflare Turnstile]
Browser voice asks for microphone consent and allows up to 2 minutes per call. The service key stays on the server.
Phone calls open by saying the speaker is an AI. Checkout runs in Stripe test mode.
Where it runs
Apps run in containers, and the server's service manager controls how they start. The setup also includes a web server, certificate renewal and a firewall. [Podman, systemd, nginx, Certbot, UFW]
Cloudflare sits in front of the server as the proxy. Rules prevent app services from gaining extra privileges and limit changes to system files. [Linux VPS, NoNewPrivileges, ProtectSystem=strict]
The firewall includes a tool for updating the proxy's address ranges. Certificate renewals run at staggered times. The setup also includes a tool that blocks repeated failed access attempts. [UFW, Certbot, fail2ban]
The service manager runs site analytics in a group of containers, with automatic rollback. [Umami, Podman, systemd]
Describe the apps you need to move and the services they depend on through website hosting migration.
Backups
A saved database needs a check that it can be restored. The documented routine sends full copies and copies of changes to remote storage, then reads every upload back. [Cloudflare R2]
Each saved copy has a file fingerprint for comparison when the tool reads the upload back. The backup tool also includes its own self-test. [Checksums]
Every week, the routine restores databases into a throwaway database and compares row counts. Five databases restored cleanly in the documented drill. [Postgres]
The documented schedule saves a changes-only copy every 3 days. It saves a full copy every 30 days. These checks cover database backups and restores.
We plan backup checks around your app's records and choose which databases to restore in a practice run. The plan says what to compare before treating a saved copy as usable.
Tell us what you would change
Describe what you want a visitor to run. Name the tools it needs to reach and where you want it to stop.