ELASTIC COMPUTE FOR DLT

Your dlt pipeline is written. Just run it.

Add one decorator and your flow gets isolated compute that starts on schedule, sizes itself to the job, and shuts off the second it finishes. Full run history, retries and alerts included.

SCALES TO THE JOB
A 40M-row backfill gets the memory it needs. A 200-row sync never reserves it.
ZERO WHEN IDLE
Compute runs only while a flow executes, and drops to zero between runs.
ISOLATED PER FLOW
One heavy run can't starve the others, and a crash takes nothing else down.

$ uv add repster · open core, self-host or cloud

flows/stripe.py
import dlt
import repster as rp

@rp.flow(schedule="0 * * * *")
def stripe_to_warehouse():
    pipeline = dlt.pipeline(
        pipeline_name="stripe",
        destination="bigquery",
    )
    return pipeline.run(stripe_source())
That's the whole integration. ↑ 10 lines
01 / WORKFLOW

Three commands, start to production

@rp.flow Decorate the function you already wrote. The cron string is the schedule.
rp dev Run flows locally with the same semantics as production. Iterate in seconds.
rp deploy Serverless workers that scale to the size of the run and back to zero. Or the identical flows on your own infra.
$ rp dev
  →  discovered 3 flows in ./flows
  →  stripe_to_warehouse    next run in 04:12
  →  hubspot_contacts       next run in 26:41

$ rp run stripe_to_warehouse
  ✓  extract   1,284 rows        2.4s
  ✓  normalize 1,284 rows        0.8s
  ✓  load      bigquery.stripe   3.1s
  ✓  run 4f2a9c succeeded in 6.3s
02 / AI-NATIVE

Anything the UI can do, the CLI can do.

Agents don't click. The CLI is the full surface: scaffold, run, inspect, schedule, deploy. Your coding agent can do the whole job and verify it locally, not just write code and hope.

agent session
 add a daily sync from hubspot to snowflake

  writing flows/hubspot.py
  $ rp run hubspot_contacts --dry
  ✗ missing credential HUBSPOT_TOKEN
  adding to .env.example, retrying
  ✓ run 9a1f04 succeeded in 4.1s

 flow scheduled: 0 6 * * *
03 / TRADEOFFS

Where Repster sits

Repster cron + scripts Airflow / Dagster
Time to first scheduled run Minutes Minutes Days
Run history & alerting Built in You build it Built in
Infrastructure to operate None A box, somewhere Scheduler + workers + DB
Scaling a heavy backfill Automatic, per run Resize the box Provision more workers
Complex DAG dependencies Trigger it from yours No Yes, keep them

Already run an orchestrator? Keep it. Repster exposes a Python API, so an Airflow or Dagster task can kick off a flow and wait on it. Replication stays in one dependency graph with your transformations and ML jobs, without you hand-rolling the extract step.

Managed ELT solves a different problem. Fivetran and Airbyte sell connectors you don't want to maintain, priced per row or per MTU. Repster assumes you're happy writing dlt sources and just want them to run reliably.

04 / PRICING

Compute seconds. Nothing else.

Repster Cloud is free during the design-partner phase. When metered billing launches, you'll pay for compute seconds — no seats, no rows, no monthly active users. The engine is Apache 2.0, so self-host and the bill is zero.

BILLED Compute
FREE Seats
FREE Rows
FREE Connectors
05 / HONESTY

Don't use Repster if…

Your pipelines aren't dlt Repster is built around dlt's run model. Arbitrary shell jobs and bespoke ETL scripts want a general-purpose scheduler instead.
You'd rather not write Python If maintaining sources isn't your job, buy a managed connector catalog. Repster starts after the pipeline exists.
You need sub-minute latency Repster schedules batch runs. Streaming and second-by-second CDC are a different category of tool.
DESIGN PARTNER PROGRAM

We're picking a few teams to build this with.

If you're running dlt in production today, you get a direct line to the engineers, real roadmap influence, and free cloud usage while the program runs.

LIMITED COHORT Apply as a design partner Read the quickstart or: uv add repster