DEV Community: Bobby Chugani

We run our whole growth engine on one VPS. Here's the cron table.

Bobby Chugani — Sat, 22 Aug 2026 08:28:19 +0000

We sell AI systems that run an independent business's growth: content, search, social,
outreach, follow-up. The obvious question a buyer asks is whether we run the thing we
sell on ourselves. We do, and it is all cron. Here is the whole machine.

70 active cron jobs on one VPS. Not 70 tasks in a project management tool. 70 lines in
crontab -l.

What actually runs

*/5  * * * *   cal-reminder.py            calendar bookings -> Telegram
15   * * * *   signup-monitor.py          new signups -> Telegram
30   * * * *   ig-inbox-monitor.py        Instagram DMs
0    */4 * * * cli-canary.sh              is the LLM path still alive
30   */2 * * * cron-heartbeat.sh          is anything silently dead
0    6 * * *   platform-pulse.sh          daily health report
0    9 * * 1-5 email-outreach.py          cold email, weekdays only
0    10 * * 1-5 email-followup.py         the follow-up sequence
0    4,16 * * * segment-lead-finder.py    lead discovery, twice daily
0    9 * * *   ig-engagement.py           Instagram engagement
30   3 * * *   backup.sh                  nightly DB dump, offsite
0    9 * * 1   seo-audit.sh               weekly SEO audit
0    7 * * 2   competitor-monitor.sh      competitor pages
0    8 * * 3   ai-discoverability.sh      are we cited by AI assistants
0    5 * * 1   seonaut-crawl.py           full site crawl
0    17 * * 0  gen_posts.sh 7             a week of social, generated
0    6 * * 2   gen_audit_reel.sh          video, weekly
30   3 * * 3   gen_podcast.sh             podcast episode, weekly

Plus blog publishing three times a day, location page generation, revenue attribution,
review monitoring, and a second brand's worth of the same running alongside.

Note how many of those are flock + timeout. Those are load-bearing, see below.

Three things that cost us real money to learn

A flock -n and a hung script is weeks of silent death. A job hangs holding the lock.
Every subsequent run exits immediately because the lock is held, cleanly, with status 0.
Nothing alerts. The signature is an empty log file next to a fat rotated one from before
the wedge. Every lock line now has a timeout on it, and a heartbeat job checks that each
log is younger than its expected interval.

A dead search API does not throw, it returns an empty list. Our egress IP got flagged.
Every search engine started returning zero results instead of an error. Nine scripts kept
running: the cold email personaliser wrote from an empty context string, the lead finder
reported "no leads in this segment" for segments it had never actually searched, and the
blog generator was told to look up statistics, got nothing back, and wrote the post from
the model's own memory anyway. Nothing errored for weeks.

The fix was one line of philosophy applied everywhere: an empty result and a broken tool
must be different return values. Our search wrapper now returns an error, not [], when
no provider answered, and callers branch on the error rather than on the length.

The auth token expires and everything just stops. Our scripts shell out to a CLI. When
its OAuth token lapses, every script fails fast and quietly, and cron jobs complete in
seconds with no output. Now there is a canary job whose only purpose is to make one call
every four hours and shout if it fails.

The pattern in all three: the failure mode was silence, not an error. Everything I would
now build differently is about making silence impossible.

Does it work

We do not publish traffic or revenue figures, so I am not going to make some up for a
post. What I can point at is checkable:

One inbound enquiry this week found us with no outbound touch at all: a guesthouse in
South Africa that booked a call through the site. We ran our own free tool against their
domain and found two things. Their web host had suspended the site, which they did not
know. And five booking platforms outranked their own domain for their own business name,
so every returning guest searching for them by name was landing on a channel that takes a
commission. That report went out the same day.

One enquiry is not a trend and I am not going to dress it up as one. It is the first
thing the machine has produced that I did not have to go and fetch.

The systems that found that, wrote it and sent it are the same 70 lines above.

The tools

One VPS. Postgres in Docker. Python and Node scripts. cron. flock. systemd for the
few things that need to be services. No queue, no Kubernetes, no orchestrator. The most
complicated piece of infrastructure is a connection pooler.

The scoring engine behind our free site checker is open source if you want to read how one
of these actually works: github.com/guestarAI/findable. MIT, no dependencies.

Happy to answer anything about the setup.

Running the Claude CLI as a production backend when the API won't take your token

Bobby Chugani — Sat, 22 Aug 2026 07:29:16 +0000

If you pay for a Claude Max subscription and try to reuse that OAuth token against
api.anthropic.com, you get a 404. Not a 401, which would at least tell you what
happened. The subscription and the API are separate products with separate billing,
and the token from one is not currency in the other.

That leaves you with a real cost decision. Either you pay twice, once for the
subscription your team already uses and again per-token for anything you build, or
you find a way to use the subscription you have. This post is about the second
option: running claude --print as a subprocess behind a small HTTP service, and
the four things that broke when I put it in production.

I have three of these running on one VPS now. They have been up for months. None of
this is subtle, but every one of these took a while to work out from a symptom that
did not obviously point at the cause.

The shape

A systemd unit runs a small Node server. It spawns the Claude CLI per request with
--print, captures stdout, and returns it. The public app calls that service over a
shared secret.

const args = [
  '--print',
  '--model', 'claude-sonnet-4-6',
  '--output-format', 'json',
  '--no-session-persistence',
  '--system-prompt', system,
];
const child = spawn(CLAUDE_BIN, args, { cwd: SANDBOX, env, stdio: ['pipe','pipe','pipe'] });

--output-format json is worth taking. You get a wrapper object with the result plus
total_cost_usd, so you can log what each request would have cost and keep an honest
picture of what the subscription is actually saving you.

1. The CLI's own auto-updater deletes the binary you are executing

This one produced the best bug of the year. Intermittent EACCES on spawn, maybe
one request in a few hundred, never reproducible on demand.

The Claude CLI updates itself. It replaces /usr/local/bin/claude in place. If a
request happens to spawn during that swap, the file you are executing is gone
mid-execution. Under normal interactive use you would never notice. Under a
per-request service, you notice.

The fix is to stop executing the file that updates itself:

src="$(readlink -f /usr/local/bin/claude)"
dst="/opt/myservice/bin/claude"
install -m 0755 "$src" "$dst.new"
mv "$dst.new" "$dst"          # atomic replace, no window where dst is missing

Point the service at the private copy and refresh it deliberately when you want a
newer CLI. DISABLE_AUTOUPDATER=1 in the unit environment is worth setting too, but
the private copy is the part that actually closes the race, because the updater you
are disabling is not always the one that runs.

2. `CLAUDECODE` leaks into child processes

If anything in your chain was itself launched from a Claude Code session, the
environment carries CLAUDECODE=1. A CLI spawned underneath sees it, believes it is
nested inside another session, and misbehaves.

const env = { ...process.env };
delete env.CLAUDECODE;
env.IS_SANDBOX = '1';     // required if the service runs as root

This one is nasty because it works perfectly when you test it by hand from your own
shell and fails only when triggered through the path that matters.

3. Bulk loops hit a burst limit that looks exactly like a code bug

Fire claude --print back to back and the first ten to twenty-five calls succeed,
then everything fails until it cools off. I found this the expensive way: a
ninety-page batch job produced eleven pages and seventy-nine consecutive failures,
and a single call by hand minutes later worked fine. So not auth, not quota. Pure
throttling.

If you are doing bulk work: pace it, back off and retry two or three times, and make
failures re-queueable so a transient throttle does not consume the work item. And log
e.stderr, not e.message. execFileSync puts the entire command line in the
message, and with a long prompt that turns your log into unreadable noise. That
detail hid the real cause from me for an embarrassingly long time.

4. Turn the tools off if the input is untrusted

One of my services takes a URL from the public internet, fetches the page, and asks
the model to analyse it. The page content is a stranger's text arriving inside my
prompt.

'--tools', '',      // empty allowlist, every built-in tool disabled

The model gets pre-fetched evidence and nothing else. It cannot fetch, cannot read
files, cannot be talked into either by a page that includes instructions addressed to
it. Everything the model needs is gathered by the Node process first and passed in as
data. If you take one thing from this post, take this one: prompt-level instructions
to ignore injected text are a request, not a control. An empty tool allowlist is a
control.

The one that surprised me: the CLI as a search provider

My server's IP is flagged. Every search engine I could reach from it either serves a
CAPTCHA or, worse, serves a page that looks like results and is not. I needed to know
whether a business ranks for its own name, and had no working way to ask.

The CLI has WebSearch built in, and it runs on Anthropic's infrastructure, so my IP
never enters the picture:

[bin, '--print', '--model', 'claude-haiku-4-5-20251001',
 '--no-session-persistence',
 '--allowedTools', 'WebSearch',
 '--permission-mode', 'acceptEdits',
 prompt]

Both flags are needed. Without --allowedTools WebSearch a non-interactive session
refuses the tool and tells you to grant permission in settings, which is not
actionable from a daemon.

It takes thirty to ninety seconds, so it is a fallback rather than a primary. But it
costs nothing on a subscription I already pay for, and it works where four scraping
approaches did not.

A warning attached to that, since it nearly shipped. Before I found this, I tried
scraping Bing with a headless browser. It returned HTTP 200, the correct page title,
my query echoed back in the HTML, and ten well-formed result rows whose hrefs
base64-decoded cleanly. Every structural check passed. The decoded URLs pointed at a
children's clothing retailer on one run and French anime sites on the next: a
convincing SERP shell full of unrelated ads, served because the site did not trust
me. Assert that results contain your query's own terms. A row count proves
nothing at all.

Is this a good idea

For internal tooling, batch work and anything where a slow path is acceptable: yes.
It is the difference between a line item and no line item.

For latency-critical user-facing requests: no. Process spawn plus model time is
seconds, not milliseconds.

And read your plan terms rather than taking my word for what yours permits. I am
describing what worked, not making a claim about what you are allowed to do.

The site checker I built on top of this is open source and MIT, if you want to see
the shape in full: github.com/guestarAI/findable.
The scoring engine there has no LLM in it at all, which is rather the point. The
model writes the explanation; the deterministic part does the looking.