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.

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)