
Sixty containers on one server
One bare-metal box runs dozens to hundreds of Hoody containers. KSM and BTRFS dedup make the marginal cost near zero.
Boarding announcement. The daily report job is set for 7am UTC, but the recipient is in Tokyo and the time is wrong. You open the crontab URL on your phone, tap the row, change two fields, hit Save. PATCH goes through. The job fires tonight on the new schedule. No SSH session, no jump box, no laptop.
The cron service speaks JSON over HTTPS. The phone's browser sends a PATCH on the entry's UUID with the new schedule field. The system crontab gets re-injected by the service. The next fire is in the response body.
The PATCH only carries the field that changed. The service merges it into the existing entry, recomputes next_run, and re-injects the line into the system crontab. There is no SSH session, no jump host, no laptop.
The whole edit fits between the boarding call and the priority queue. Open the URL. Change the field. Walk to the plane.
The cron service has its own URL — cron.containers.hoody.com/users/me/crontab. The same page opens in any browser, including the one on your phone. Auth is the URL. No bastion, no AnyConnect prompt, no key-on-laptop ritual.
Each managed entry is a JSON object with schedule, command, comment, enabled. You tap the row, the schedule field becomes editable, you replace 0 7 * * * with 30 4 * * 1-5. The other fields are not touched.
Save fires a PATCH on /users/me/entries/[id]. The response says 200 OK and gives back the new next_run. The system crontab is updated within the second. You close the tab and walk.
Hoody Cron exposes a small CRUD over the crontab. Each managed entry has a UUID; each entry can be patched in isolation. Below are the four endpoints the phone uses to edit, mute, list, or delete a job.
Endpoints per the Hoody Cron service. Paths are relative to https://PROJECT-CONTAINER-cron-1.SERVER.containers.hoody.com.
The numbers that matter to a person standing at a gate with a 6-inch screen.
schedule, command, comment, enabled, expires_at. Each can be sent on its own. The other fields stay untouched, so the comment you wrote at 9am yesterday survives the airport edit.
One PATCH from the phone. One 200 response with the new next_run. The system crontab is re-injected by the service in the same call — no second request, no polling.
No SSH, no bastion, no AnyConnect. The crontab is a URL and the auth is the URL. The hardware key on your laptop stays in your bag.
Your crontab is a URL, so editing it is a URL.
When the schedule is reachable from a browser, the place you happen to be standing stops mattering. The boarding gate is a fine office. The phone is a fine terminal. The PATCH is the change.
Most of these only exist because the crontab wasn't reachable from a phone. When the schedule is a URL, the rituals around getting to the schedule go away with it.
You stood at the gate and changed when the job fires tonight.