Caravan

POC IN DEVELOPMENT

An application-definition compiler.

Caravan sits between application code and infrastructure-as-code. A caravan is your application as a graph of units that travels together and splits where deployment demands.

Follow on GitHub

PoC implementation in progress.

The thesis.

Concept

An application is a graph of components connected through the caravan-rpc-<lang> SDK at each inter-component seam. Caravan lets one YAML project that graph onto any point in three orthogonal dimensions, with the source code unchanged.

Three orthogonal axes.

How it works

Packaging

How source seams become deploy units.

Modular monolith · multi-container · multi-service. Per target, each seam dispatches as inproc, container, or lambda.

Placement

Where processes run.

Local docker-compose · cloud long-running · cloud function · cloud batch. Move the same module without source changes.

Composition

What each resource is bound to.

Local OSS engine · cloud managed service · existing cloud resource by ID. Mixing is first-class.

One target: names a point in (packaging × placement × composition). A repo declares many: dev, staging, prod, pr-preview, and caravan up --target=<name> flips between them. Same source code everywhere.

What one YAML looks like.

Sketch

Illustrative shape. The final schema lands with the PoC.

application:
  entries:
    - name: smart-query
      runtime: python
  seams:
    - from: smart-query
      to: vector-store
      sdk: caravan-rpc-python

targets:
  dev-local:
    packaging: monolith
    placement: docker-compose
    composition: oss-local
  prod-cloud:
    packaging: services
    placement: serverless
    composition: managed

Why it's useful

One declaration. Many deployments.

Today, the same application lives in several hand-written deployment configurations: one for local dev, one for staging, one for prod, more for preview environments. Each is target-specific, drifts from the others, and rots between releases.

Caravan replaces them with one declaration. Splitting a monolith into services becomes a target change, not a source rewrite. Moving a component into a serverless function becomes a yaml edit, not a refactor. Mixing local engines with real cloud resources during development is first-class.

Follow on GitHub