迷思 FAQ：免費開發環境在工作階段之間會遺失甚麼？

Yesterday my agent ran the test suite and everything passed. Today the same free dev box failed on a missing binary. No code changed. No lockfile changed. So what actually changed?

The box did not remember yesterday. That sounds obvious, and I still got it wrong for weeks. Here are five myths I kept repeating, the commands that killed each one, and the mental model I use now.

Myth 1: "It's still the same machine"

Short answer: probably not. Session identity is not machine identity.

Print a receipt at the start of every session:

# receipt.sh — a stable summary of this box
set -euo pipefail
echo "host:   $(hostname)"
echo "kernel: $(uname -srm)"
echo "uptime: $(cut -d' ' -f1 /proc/uptime)s"
echo "user:   $(id -un):$(id -u)"
echo "cwd:    $(pwd)"
echo "utc:    $(date -u +%Y-%m-%dT%H:%M:%SZ)"

Run it in two sessions and diff the output. diff session-a.txt session-b.txt. If uptime resets to a small number, you got a cold start. That is not a bug. That is the environment behaving exactly as designed.

Corrected model: a session is an event, not a place. Record facts about the run, not hopes about the box.

Myth 2: "Package installs stick to the project"

Where did apt-get install, npm i -g, or pip install write? Not into your git repo. So why expect them back tomorrow?

Check what actually exists:

node --version; python3 --version; command -v pnpm || echo "no pnpm"
git status --porcelain
du -sh ~/.cache/* 2>/dev/null | head

Different Node versions between sessions means your tests ran on different engines. Same green check, different runtime. That is how flaky reports are born.

Fix it with one idempotent bootstrap script, versioned next to the code:

# bootstrap.sh — safe to run on every cold start
set -euo pipefail
corepack enable            # reads "packageManager" from package.json
pnpm install --frozen-lockfile
test -x ./node_modules/.bin/vitest

Idempotent means running it twice must not change state twice. If it cannot be re-run safely, it is not a bootstrap. It is a ritual.

Myth 3: "My background process is still alive"

Is it? Have you looked?

pgrep -af 'node|vite|uvicorn' || echo "nothing running"
ss -ltn 2>/dev/null | head || true

Cold starts kill watchers, tunnels, and dev servers. The port is free because nothing is listening, not because everything is fine.

Stop relying on a manual &. Own the process, its log, and its exit code in one command:

mkdir -p .logs
( npm run dev > .logs/dev.log 2>&1 & echo $! > .logs/dev.pid )
sleep 3
curl -fsS http://127.0.0.1:3000/health \
  || { tail -n 50 .logs/dev.log; exit 1; }

Now a dead server is a failed command. Not a mystery you debug twenty minutes later.

Myth 4: "A cache hit is just a performance thing"

No. A cache hit is a correctness input.

If node_modules, ~/.cache, or a build folder survived from an earlier run, your "fresh" test was not fresh. It reused bytes you never chose.

Define freshness explicitly:

1. Cold — empty caches, locked dependencies, clean checkout.
2. Warm — identical caches, identical lockfile, identical runtime.
3. Mixed — you have no idea, and neither does your test result.

Only two of those are useful. Write down which one you ran, right next to the result.

Myth 5: "Exit code 0 means the evidence survived"

The box exits. The evidence exits with it.

Push results out before the session ends:

mkdir -p out
{ ./receipt.sh; echo; pnpm test 2>&1; } | tee out/session.log
sha256sum out/session.log

Then copy out/ somewhere durable, or upload it as a CI artifact. Logs living inside a disposable box are drafts, not records.

A cold-start drill you can finish in one sitting

Here is the whole loop in four steps.

1. Session A: run receipt.sh, then bootstrap.sh, then the tests. Save out/.
2. Close the session. Do not keep it warm on purpose.
3. Session B: run the exact same three commands.
4. Diff the two receipts and the two test summaries.

If session B fails, you found a hidden dependency. That is a gift, not a setback.

Where MonkeyCode fits

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

Two MonkeyCode capabilities matter for this drill: free model access for the agent step, and a free server option for the run itself. That combination makes cold starts cheap enough to repeat. A throwaway box you rebuild several times a day is only practical when the rebuild costs nothing.

That is the honest fit. It is not a reason to skip bootstrap.sh. It is a reason to write it carefully.

Check the current limits and quotas before you plan a workflow around them. The availability claims above are operator-supplied, and limits change over time.

If you want to run this drill without maintaining your own machine, MonkeyCode's free server option is a reasonable place to start.

Who should skip this approach

Be honest about the boundaries.

• Do not use an ephemeral box as a system of record. Git and object storage are records.
• Do not leave long-lived secrets in a filesystem you cannot audit. Prefer short-lived tokens injected at run time.
• Do not run training jobs, stateful databases, or regulated data on a box that resets.
• Do not treat this as a CI replacement. CI is shared, versioned, and auditable. A dev box is where you discover what CI must do.
• Do not assume fixed hardware specs or permanent uptime unless your provider states them.

If your workload genuinely needs persistence, this workflow will annoy you. Use a long-lived environment instead, and keep the receipt habit anyway.

The part that actually changes

So which of my five myths survives a reboot? None of them.

The next time a green run turns red with no commit in between, do not debug the code first. Print the receipt. Diff it. The box already told you what it forgot.

What would you put in yours?