48-Hour Test on a Free Server: The Process Stays Alive, But State Quietly Disappears

A Deliberately Small Experiment

What happens when you move a webhook receiver from your laptop to a free server and run it for two days? One developer's answer lies in a contradiction: the process stays alive the whole time, yet the public route errors out; after a restart the service comes back up as usual, but the deduplication ledger has vanished. This isn't a platform failure—it's a real exposure of the design constraints of the free tier.

The author set three rules for himself: use free model access for structured extraction, use a free server to host the receiver, and commit all scripts and tests to the repo so anyone can reproduce it in ten minutes. This "harmless" experimental design is exactly what surfaces the most boring problems first.

Breakpoint One: The Model Returns a String, Not a dict

You ask the model for JSON, and what you get back is a fenced code block wrapped in explanatory text before and after. json.loads fails on the very first character—this is a formatting failure, not a reasoning failure.

The author's fix was pragmatic: first use a regex to find the fenced code block, fall back to the raw text, then slice out the outermost curly braces and parse. Twenty lines of code compressed two hours of debugging into a file. At the same time he maintained three fixture files—bare JSON, fenced text, and pure prose—giving "it works" an offline definition, where pure prose must raise ValueError rather than return half a record.

The insight here: a model is not a function that returns a dict, but a text producer that needs a contract enforced. The validator must sit between the model and the write path.

Fenced code block is Markdown syntax that wraps a code snippet in three backticks, and models habitually add it plus surrounding explanation when outputting JSON. When parsing, you should not assume the text starts with a curly brace; instead locate the fence boundary first, extract the inner content, then fall back to slicing out the substring between the outermost curly braces.

Contract validation refers to making explicit structural and type assertions on inputs and outputs at system boundaries, for example using JSON Schema or Pydantic models to verify field presence, types, and value ranges. It is separated from business logic and raises clear exceptions on failure, so integration tests can assert success and failure separately against bare JSON, fenced text, and pure prose—rather than eyeballing logs.

Fixture refers to fixed input samples constructed in advance for tests, usually committed alongside the test code. The three fixtures in this article represent normal output, output with formatting noise, and fully unstructured output, giving "the parser works" an objective, offline-repeatable definition.

Breakpoint Two: The Process Is Healthy, But the Proxy Can't Find It

From inside the instance everything looks fine: startup logs print, localhost requests respond, the process is alive. But the public route errors out. The problem came down to two lines of code—the port was hardcoded to 8000 instead of reading the $PORT environment variable, and it bound to 127.0.0.1 instead of 0.0.0.0.

The author calls these the two cheapest habits in the whole article: bind to 0.0.0.0 and read $PORT, and print the resolved port at startup. If you copy only one snippet, copy this one.

Reverse proxy and port binding are key to understanding this breakpoint. Free hosting platforms typically place a reverse proxy in front, which forwards requests received on the public domain to some port inside the instance and sets a PORT environment variable to tell the app which port to listen on. If the app hardcodes 8000 while the platform assigned 3000, the proxy can't find its target.

The difference between 127.0.0.1 and 0.0.0.0 lies in the scope of the bound address: the former only accepts connections from the local loopback interface, while the latter accepts connections from all network interfaces. Accessing localhost from inside the container or VM succeeds, but connections initiated by the proxy from outside get refused. So "curl works inside the instance but the public route fails" is almost always a problem with the bind address or the port environment variable.

Config echo means printing the actually resolved port, state directory, and model identifier to the logs at startup, so you can directly cross-check expected versus running values in the platform's log panel.

Breakpoint Three: The State File Is a Lie You Tell Yourself

The most alarming finding: a free server gives you a running process, not a persistent disk. The author wrote the deduplication ledger into the working directory, assuming by default that it would still be there after a restart—an assumption that would wait until Friday to bite.

He didn't argue; he just wrote a startup audit script: on first boot it records boot_id, appends a run record, and prints it. Compare the two lines of output before and after a restart and the conclusion is obvious—if boot_id is unchanged and entries grow, the disk survived; if boot_id changed and entries reset, the disk is instance-level ephemeral space and all records are lost.

This isn't a bug report; it's a design constraint. There are only two fix paths: external storage, or convert to a stateless service. The script uses os.replace to achieve atomic writes within the same filesystem, avoiding a state file corrupted by a half-completed write.

boot_id is a unique identifier generated by the OS kernel on each boot, readable via /proc/sys/kernel/random/boot_id. If it stays the same across a restart, it means the data on disk still exists; if it changes, it means the instance has been rebuilt from a fresh image or snapshot and all files written to the working directory are gone.

Persistent disk vs. instance-level ephemeral storage is the easiest thing to confuse in the free tier: a live process only proves compute resources are running, not that the filesystem survives a restart. Writing the deduplication ledger to the current working directory is equivalent to assuming the instance won't be reclaimed and rebuilt—an assumption that usually doesn't hold in the free tier.

Atomic write means writing to a temporary file first, then renaming it to the target path via os.replace. Within the same filesystem this operation is atomic, preventing a process crash mid-write from leaving half a JSON behind, so the state file is always a parseable, complete snapshot.

The Twenty-Minute Acceptance Checklist

The author regrets not doing this check in the first hour instead of the thirtieth, because every step has an unambiguous answer and doesn't depend on release notes:

1. Binding check—curl the local port from inside the instance, then hit the public URL and compare
2. Restart check—run boot_audit.py before and after
3. Contract check—run the three fixtures offline, assert pure prose raises
4. Timeout check—point at a deliberately slow stub, confirm it errors rather than hanging forever
5. Config echo—print port, state directory, and model identifier at startup
6. Cold start measurement—record the timestamp of the first request after a restart, write it down rather than guess

Decision Table: What Workloads Are Suitable for Freeloading

Workload Type	Free Model + Free Server?	Reason
Low-risk text-to-JSON triage with schema validation	Yes, keep a human review queue	A formatting mistake only costs a few seconds and loses no records
Any scenario where writes absolutely must not be lost	Not yet—move the state out first	Let the startup audit decide, not the marketing page
Strict interactive latency budget	Usually no, measure first	Cold start is part of p50, not a footnote
Regulated or personal data	Read the provider's data terms before discussing	Nobody else can answer this for you

The Real Boundaries of the Free Tier

The author closes with caveats: this workflow suits people who can add validation code and read logs. For scenarios that require guaranteed uptime, persistent disks, fixed egress IPs, or signed availability commitments, the free tier is the wrong tool—no amount of scripts changes that.

If the task requires long-chain multi-step reasoning rather than short structured extraction, test the free model with your own fixtures before deciding whether to build on it, and be prepared to give it up.

The sharpest line is this: if you can't put a validator between the model and the write path, don't let the model into the write path.

Free models and free servers are enough to run this two-day loop, and the startup audit is why "enough" can be quantified. Run it on your own deployment, record the numbers, and let the second boot_id tell you the truth before your users find out.