Build

Deploying changes

Hatchik gives you two ways to redeploy your sandbox. Either works; pick whichever your AI tool finds easier. Most of the time it'll be git push.

The Git way (default)

Every sandbox repo has a GitHub webhook pre-installed at provision time. Push to main and Hatchik picks the change up within a few seconds, rebuilds the affected Docker services, and restarts your sandbox.

git add .
git commit -m "Add meal-plan form"
git push

You don't need to set anything up. The webhook is already there, signed with your per-tenant deploy token. The first push after signup is almost always the AI tool's idea — when you say "ship it" or "deploy" in chat, your AI runs Git for you.

The direct way (for AI tools)

Some AI tools (especially browser-based ones like ChatGPT, Gemini, Grok, or Perplexity Comet) prefer not to commit half-finished work just to test a change. For those cases, your AI_CONTEXT.md file includes a per-tenant deploy URL and a deploy token. POST to the URL with the token in a header and we'll redeploy without needing a Git commit.

curl -X POST https://hatchik.com/api/tenants/<your-slug>/redeploy \
  -H "X-Deploy-Token: <your-deploy-token>"

Both <your-slug> and <your-deploy-token> are written into your AI_CONTEXT.md. Treat the token like a password — it grants redeploy rights to your sandbox. If you suspect it's leaked, email us and we'll rotate it.

How fast is "fast"?

Typical redeploys land in twenty to forty seconds. Two-thirds of that is Docker compose pulling and restarting the affected service; the remainder is your push reaching GitHub and the webhook firing.

It takes longer if:

• You've changed Python or Node dependencies — Docker has to install them. Add about thirty seconds.
• You've added a new Supabase migration — migrations run before the app comes back. Add a few seconds.
• You've changed something in the Dockerfile — full rebuild from scratch. Could be two minutes.

Rate limit

Each sandbox is capped at six redeploys per five-minute window. That's enough headroom for normal "tweak, push, refresh" loops but stops a runaway AI tool from queuing fifty deploys in a minute. If you hit the cap you'll see an HTTP 429 response; wait until the window rolls over and push again.

Hitting the rate limit is almost always a sign the AI tool got stuck in a loop (typically: "the test fails", push, "still fails", push, etc.). When you see a 429, stop the AI tool, read its last few messages, and unblock it manually before the next push.

Worked example

Say your sandbox is prepsheet.hatchik.com and your deploy token is 8f3c…2a1b (we won't actually print real tokens here — yours is in AI_CONTEXT.md).

Via Git

cd prepsheet-hatchik
# ... edit a file in apps/web/src/product/ ...
git add apps/web/src/product/MealPlanForm.tsx
git commit -m "Add meal-plan form"
git push origin main
# 25 seconds later, https://prepsheet.hatchik.com reflects the change

Via curl

curl -X POST https://hatchik.com/api/tenants/prepsheet/redeploy \
  -H "X-Deploy-Token: 8f3c...2a1b"

# response on success:
# { "ok": true, "via": "token", "duration_seconds": 23 }

What the response means

Where the logs live

Each redeploy attempt streams to /var/log/hatchik/redeploy-<slug>.log on the sandbox host. On a failed redeploy, the API response includes the last 50 lines of this log so you don't need to shell in to diagnose.

For a successful redeploy, only the start and finish lines land in the log (the underlying Docker output goes to Docker's own logs). If you need the full Docker output of your tenant container, email us — we can docker logs from the host.

Dual auth: token vs webhook signature

Under the hood there's one endpoint and one token. The GitHub webhook signs each delivery with X-Hub-Signature-256 using the same token as HMAC-SHA256. The direct curl flow sends the token in the clear in X-Deploy-Token. Either authenticates. There's no second secret to manage.

Next

• Troubleshooting — what to do when a push doesn't update the sandbox.
• Account management — pause, archive, restore, delete.