Distributing a worker

A worker is useful the moment it runs on your machine. It becomes infrastructure when somebody else can attach it without asking you how. That step is a packaging and hosting decision, and it's the same decision whichever language you built it in.

The decision

Three ways to share a worker

They aren't exclusive — plenty of workers start internal, go open source, and end up listed. Each one asks more of you and gives the user more in return.

Packaging

Ship a process, or run a service

Underneath all three routes there are only two shapes, and they differ in who runs the worker.

As a process, you publish an artifact and the user's DuckDB spawns it locally over pipes. You host nothing, there is no uptime to keep, and their data never leaves their machine — but they need the runtime installed, and every user runs their own copy.

As a service, you deploy the worker once and hand out a URL. Users attach it with no install at all, you can update it without anyone upgrading, and you can authenticate, meter, and rate-limit callers — in exchange for owning the hosting bill and the pager.

-- Distributed as a process: users run it themselves.
--   A published package, launched on demand …
ATTACH 'my_worker' AS mw (TYPE vgi, LOCATION 'uvx [email protected]');

--   … or a container image, over the same pipe transport.
ATTACH 'my_worker' AS mw (TYPE vgi, LOCATION 'docker run --rm -i ghcr.io/you/my-worker:1.2.0');

-- Distributed as a service: you run it, they attach a URL. Needs HTTP.
ATTACH 'my_worker' AS mw (TYPE vgi, LOCATION 'https://my-worker.example.com/');

The worker source is the same in both cases; only the transport it's started with changes. See Architecture for the hosting options — load balancers, Cloudflare Workers, Cloud Run, Lambda — and Connect to a worker for every LOCATION form a user can type.

Open source

Publishing on GitHub

The simplest way to share a worker with the world is a public repository and tagged releases. There is no registry to apply to and no review to pass — a VGI worker is just a program, so whatever your language already uses for distribution works here.

Published something? Tell us — we're happy to point people at it, and to help if you'd rather it were listed and billed for you.

Monetize

Listing it on the Orchard

The Orchard is Query.Farm's connector marketplace: workers a DuckDB user can subscribe to and attach with one line of SQL. If what you've built is worth paying for — a proprietary dataset, an expensive-to-run model, a service you already sell — listing it turns the worker into a product without you building a billing system, a credential store, or a distribution channel.

You keep running the worker. Query.Farm handles the commercial side and pays out a revenue share on subscriptions.

Before you publish

What changes when other people attach it

A worker you use yourself can be forgiving. One other people attach is an interface with users who can't read your code and won't file a good bug report. Four things are worth doing before you hand out the URL, whichever route you take.

If the worker exposes data with per-customer rules, do that work in the worker rather than in documentation — see row & column security and authentication.

Where to from here