Skip to main content

File Sync & Hot Reload

kindling sync is the inner loop for agentic development. When a coding agent generates or modifies a service — a FastAPI endpoint, an Express route, a Go handler, a Rails controller — the changes land in the running container in seconds. No image rebuild. No rollout. No waiting.

This is purpose-built for the languages AI agents actually write: Python, Node.js/TypeScript, Go, and Ruby. These four cover the vast majority of code that Copilot, Claude Code, Cursor, and similar agents generate in practice.

The agentic dev loop​

Agent writes code ──► file saved ──► kindling sync ──► app restarts
       │                                                     │
       └──── agent tests endpoint ◄── result in <2 seconds ─┘

With kindling intel feeding your agent the project context and kindling sync hot-reloading every change, the agent can iterate autonomously: write code → see it running → fix issues → repeat. No human in the loop for the build-deploy cycle.

Dashboard

You can also trigger a sync from the dashboard: Develop → Environments, then click the Sync button on any environment. See Dashboard for details.

Core language support​

These are the languages kindling is optimized for — the languages AI agents generate real projects in:

Python Hot reload​

The #1 language for AI-generated backends. FastAPI, Django, Flask, Celery workers — all detected automatically.

RuntimeStrategyHow it works
python / python3Wrapper + killRestart loop, kill child on sync
uvicornSignal (SIGHUP)Zero-downtime graceful reload
gunicornSignal (SIGHUP)Zero-downtime graceful reload
flaskWrapper + killRestart loop
celeryWrapper + killRestart loop
# FastAPI with uvicorn — zero-downtime reload
kindling sync -d my-api --restart

# Django
kindling sync -d backend --src ./backend --restart

Node.js / TypeScript Hot reload​

The #2 language for agent-generated code. Express, Next.js API routes, Deno, Bun — all covered.

RuntimeStrategyHow it works
nodeWrapper + killRestart loop
denoWrapper + killRestart loop
bunWrapper + killRestart loop
ts-node / tsxWrapper + killRestart loop
nodemonAuto-reloadFiles only — nodemon watches itself
# Express / Next.js API
kindling sync -d my-api --restart

# Deno service
kindling sync -d deno-svc --restart

Go Build + sync​

Agents write Go frequently. Compiled, but kindling handles it: cross-compiles locally for the container's OS/arch, syncs just the binary, restarts the process. The pod stays running — no image rebuild, no rollout.

# Auto-detected cross-compile + binary swap
kindling sync -d gateway --restart

# Custom build command
kindling sync -d gateway --restart \
  --build-cmd 'CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -o ./bin/svc .' \
  --build-output ./bin/svc

The cross-compile command is auto-generated based on the Kind node's architecture. For example:

CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -o <tmpfile> .

Ruby Hot reload​

Rails scaffolding is still a common agent pattern. Puma and Unicorn get graceful signal-based reload; plain Ruby and Bundler use the restart loop.

RuntimeStrategyHow it works
rubyWrapper + killRestart loop
railsWrapper + killRestart loop
pumaSignal (USR2)Graceful phased restart
unicornSignal (USR2)Graceful rolling restart
bundleWrapper + killRestart loop (delegates to inner cmd)
# Rails with Puma — zero-downtime reload
kindling sync -d web --restart

# bundle exec rails server
kindling sync -d web --src ./app --restart

Also supported​

These runtimes work but are outside the core agentic AI use case:

LanguageRuntimesStrategy
PHPphp, php-fpm, apache2Auto-reload / signal
Elixirmix, elixir, iexWrapper + kill
PerlperlWrapper + kill
Lualua, luajitWrapper + kill
RR, RscriptWrapper + kill
JuliajuliaWrapper + kill
Rustcargo, rustcLocal build + sync
Java/Kotlinjava, kotlinRebuild
C#/.NETdotnetLocal build + sync
C/C++gccRebuild
ZigzigLocal build + sync
Nginx / Caddynginx, caddySignal (HUP)

Quick start​

# Watch current directory, restart the app on each change
kindling sync -d my-api --restart

# One-shot sync (no file watching)
kindling sync -d my-api --restart --once

Every time you save a file, it lands in the container and the process restarts (or reloads, or does nothing — depending on the runtime).

How it works​

  1. Finds the running pod for the target deployment
  2. Reads /proc/1/cmdline to detect the runtime
  3. Syncs local files into the container via kubectl cp
  4. Restarts the process using the detected strategy
  5. If --once is not set, watches for changes and repeats

More examples​

# Python/uvicorn — signal reload (SIGHUP)
kindling sync -d orders --src ./services/orders --restart

# Nginx — zero-downtime SIGHUP reload
kindling sync -d frontend --src ./dist --dest /usr/share/nginx/html --restart

# Extra excludes
kindling sync -d my-api --src ./src --exclude '*.test.js' --exclude 'fixtures/'

# Multi-container pod — target a specific container
kindling sync -d my-api --container app --restart

Default excludes​

These patterns are excluded automatically: .git, node_modules, __pycache__, .venv, vendor, target, .next, dist, build, *.pyc, *.o, *.exe, *.log, .DS_Store.

Add more with --exclude.

Flags​

FlagShortDefaultDescription
--deployment-d— (required)Target deployment name
--src—.Local source directory to watch
--dest—/appDestination path inside the container
--namespace-ndefaultKubernetes namespace
--restart—falseRestart the app process after each sync
--once—falseSync once and exit (no file watching)
--container——Container name (for multi-container pods)
--exclude——Additional exclude patterns (repeatable)
--debounce—500msDebounce interval for batching rapid changes
--language—auto-detectOverride runtime detection
--build-cmd—auto-detectLocal build command for compiled languages
--build-output—auto-detectPath to built artifact to sync

When to use sync vs. push​

ScenarioUse
Agent iterating on Python/Node/Ruby codekindling sync --restart
Agent modifying a Go servicekindling sync --restart (auto cross-compiles)
Dockerfile or dependency manifest changedgit push (triggers full CI rebuild)