dltHub platform

The dltHub platform is a managed cloud platform for running your dlt pipelines, transformations, and notebooks. It mirrors your local dltHub Workspace into the cloud (called a workspace deployment), so your familiar dlt pipelines, datasets, notebooks, and dashboards run remotely with the same code that runs on your machine.

For a high-level summary of platform capabilities, see Pipeline operations in the introduction.

Where to start

If you want to...	Go to
Convert a Python project into a dltHub workspace and set up credentials	Workspace setup
Push code to the cloud — ad-hoc runs or full manifest deploys	Deployments
Schedule with cron/intervals, chain follow-ups, backfill with scheduler-driven intervals, gate on freshness, cascade refreshes, tag jobs for bulk operations	Triggers and scheduling
Configure timeouts, dependencies, timezone, and per-job TOML sections	Job configuration
Stream logs in real time, inspect run states, view metric dashboards, diagnose failures, cancel runs	Monitoring and debugging
Pick a deployment region	Regions

If you prefer a guided walkthrough, follow the dltHub platform tutorial.

Key concepts

Jobs vs runs

• A Job is a script registered in your workspace. It defines what code to run and optionally a schedule.
• A Run is a single execution of a job. Each run has its own logs, status, and metadata. See run states.

Batch vs interactive

• Batch jobs run with the prod profile and are meant for scheduled data loading.
• Interactive jobs run with the access profile and are meant for notebooks, dashboards, and Streamlit apps.

Interactive application types

Type	Description
Notebooks	Marimo notebooks for the pipeline dashboard, exploration, and analysis
Streamlit apps	Interactive Streamlit dashboards
MCP servers	Model Context Protocol servers that provide tool and data access for AI assistants and agents

Each interactive application is exposed via a unique public URL tied to its run.

Profiles

Profiles let you keep different configurations for different environments:

• Local development can use DuckDB with no credentials needed
• Production runs use MotherDuck (or any cloud destination) with full read/write access
• Interactive sessions use read-only credentials for safety

See profiles in dltHub for details, and Workspace setup for the relevant profile table.

Deployments and configurations

• Deployment — your code files (.py scripts, notebooks)
• Configuration — your .dlt/*.toml files (settings and secrets)

Both are versioned separately, so you can update code without changing secrets and vice versa.

Command line fundamentals

The dlthub CLI is split into two scopes:

• local — dlthub local ... operates on the local workspace (files in .dlt/, your machine's pipeline working dirs, local profiles).
• remote — dlthub ... (unqualified) operates on the connected dltHub workspace (the cloud deployment, configurations, jobs, runs).

Most actions and entities exist in both scopes: running a job, serving an interactive app, inspecting workspace state, listing pipelines. Use the local scope to validate jobs before pushing them to the cloud.

Verbs have consistent meaning regardless of the scope or the entity they operate on:

Verb	Meaning
info	Print structured information about the entity (workspace, job, run, deployment, configuration)
list	Enumerate entities
run	Execute a batch job or pipeline
serve	Start an interactive job (notebook, dashboard, MCP server, REST app)
show	Open the GUI / human-readable interface (web dashboard remotely, marimo view locally) for the entity
clean	Remove local artefacts (e.g. wipe pipeline working dirs and locally loaded data)
sync	Push local changes to the cloud counterpart
cancel	Cancel an in-flight job or run
connect	Bind a local entity to a remote one
deploy	Push the deployment manifest to the cloud

The local/remote split makes most pages of this guide read in pairs:

Local	Remote
dlthub local run [<selector_or_job>]	dlthub run [<selector_or_job>]
dlthub local serve [<selector_or_job>]	dlthub serve [<selector_or_job>]
dlthub local pipeline run <pipeline_name>	dlthub pipeline run <pipeline_name>
dlthub local info	dlthub workspace info
dlthub local show	dlthub show

Run the local form first to catch missing dependencies, misconfigured destinations, or broken decorators without burning a remote slot.

Web UI

Visit app.dlthub.com to access the web dashboard. It provides workspace overview, jobs and runs management, run details with execution logs, deployment & config inspection, pipeline dashboards, and workspace settings.

For monitoring runs, streaming logs, and diagnosing failures, see Monitoring and debugging.

Public links for interactive jobs

Notebooks and dashboards can be shared via public links. Manage them either from the dashboard — open the job's context menu (or its detail page) and click Manage Public Link to toggle the link — or from the CLI:

# Generate a public link
dlthub job publish fruitshop_notebook.py

# Revoke an active link
dlthub job unpublish fruitshop_notebook.py

Anyone with an active link can view the running notebook or dashboard — useful for sharing dashboards with stakeholders without dltHub platform access.

CLI reference

For detailed CLI documentation, see CLI.

Common commands

Command	Description
dlthub login	Authenticate with GitHub OAuth (interactive workspace selection)
dlthub logout	Clear local credentials
dlthub workspace list	List all accessible workspaces
dlthub workspace connect [name_or_id]	Connect project to a workspace (interactive picker if no arg)
dlthub local info	Show local workspace info
dlthub show	Open the dltHub dashboard
dlthub local run <script_or_job>	Run a batch job on the local machine (recommended before deploying)
dlthub local serve <script_or_job>	Serve an interactive app on the local machine
dlthub run [<script_or_selector>] [-f] [--refresh]	Deploy and run a batch script or named job
dlthub serve [<script_or_selector>] [-f]	Deploy and serve an interactive application
dlthub deploy [--dry-run] [--show-manifest]	Deploy jobs from __deployment__.py
dlthub job trigger <selectors...> [--refresh] [--dry-run] [--profile NAME]	Trigger runs for matching jobs (for example tag:backfill, schedule:*)
dlthub pipeline run <pipeline_name> [-f] [--refresh]	Run a job by pipeline name
dlthub job cancel <selector_or_name>...	Cancel active runs for matching jobs
dlthub job runs cancel <selector_or_name> [run_number]	Cancel a specific run (defaults to latest)
dlthub job logs <selector_or_name> [run_number] [-f]	View or stream logs for a run
dlthub job publish <script_path>	Generate a public link for an interactive notebook/app
dlthub job unpublish <script_path>	Revoke a public link

Platform limits

• Platform limits: non-interactive jobs default to 2 hours maximum execution time (override with execute={"timeout": "6h"} in the decorator — see Job configuration)
• Interactive timeout: interactive jobs (notebooks, dashboards, MCP servers) are capped at 15 minutes of execution time and are not extended
• UI operations: new jobs must currently be created via the CLI; once a job exists, subsequent runs can be triggered from the Web UI (and schedules can be changed there too)
• Pagination: list views are paginated; the page size can be adjusted in the Web UI
• Log latency: logs typically lag a few seconds during execution and are guaranteed complete after the run finishes (completed or failed state)
• One workspace per repo: a single GitHub repository can only be connected to one remote workspace at a time; reconnecting deactivates jobs deployed under the previous binding — see Workspace setup
• No drift detection: the CLI does not yet detect whether local code differs from remote. Run dlthub workspace deployment sync (or any run / serve / deploy) to ensure your latest code is deployed