Bring Your Own Code

Your code, your language, your cloud. Your site on us.

Some work needs real code: a data pipeline, a scientific model, a nightly job in Python, Go or R. Run it at the cloud provider you choose, and let your WebsitePublisher site show the results. You keep full control of the code. We keep your site fast, secure and online.

See how it works → Talk to us about your setup

Why this route

Integrations cover most of a site. Not all of it.

Forms, shops, bookings, payments, email: the platform has building blocks for all of that. But when your work is decoding gigabytes of model data every hour, or running a library that only exists in your language, the right place for it is a machine you control.

So we do not run your programs on our servers. We give you a clear, secure way to connect them instead. Any language, any runtime, any provider.

How it works

Your worker does the heavy lifting. Your site shows the result.

Each run produces files plus one small manifest. The manifest is written last, so visitors never see a half-finished run.

Your data

Source

An open data feed, an API, your own database.

Your cloud

Worker

Your container on a schedule, in any language, with your own dependencies.

Your bucket or our assets

Output + manifest

Files in a new run folder, then latest.json pointing to it.

WebsitePublisher

Your site

The page reads the manifest and shows the newest run. Nothing is computed per visitor.

Pick a route

Two ways to deliver results

Rule of thumb: more than a few dozen files per run, or files above a few MB, go to your own bucket.

Recommended for data-heavy work

Route B: your own storage bucket

Your worker writes to a bucket you own, for example DigitalOcean Spaces, Amazon S3, Cloudflare R2 or Backblaze B2. Your page loads the files straight from there.

No WebsitePublisher key on your worker
No limits from us on file count or size
Make the output folder public read-only and allow your site's domain in CORS
Remove old runs with a lifecycle rule

For small outputs

Route A: push to your project's assets

Your worker uploads a JSON summary or a few images straight into your project, overwriting a fixed path each run.

Create a key in the dashboard: project → API keys, with an expiry date
Store it as a secret at your provider, never in code
Counts towards your plan's asset and storage limits

# Route A: overwrite one JSON file in your project each run curl -sS -X POST "https://api.websitepublisher.ai/papi/project/$PROJECT_ID/assets" \ -H "Authorization: Bearer $WP_ACCESS_KEY" \ -H "Content-Type: application/json" \ -d "{\"slug\":\"data/latest.json\",\"content_text\":$(jq -Rs . < latest.json),\"overwrite\":true}"

Good to know about route A

A project API key can change everything in that project, not only assets. Keep it on the worker only, give it an expiry date, and revoke it when you stop the worker. If you would rather keep keys away from your site entirely, use route B.

Route A limits	Free	Solo	Starter	Pro	Agency
Assets per project	25	100	300	1,500	3,000
Storage per project	25 MB	100 MB	250 MB	1 GB	2.5 GB

Max file size: images and PDF 5 MB; JSON, JS, CSS, TXT and HTML 1 MB; CSV and TSV 50 MB; MP4, MP3 and OGG 20 MB. Binary science formats such as NetCDF, GRIB or ZIP are not accepted as assets: convert them in your worker first. API rate limit: 60 requests per minute.

The contract

One small file ties it together

Whatever your worker does, it ends every run the same way: upload the files to a new run folder, then overwrite latest.json. Your page only ever reads that one file.

{ "run": "2026-10-21T10Z", "generated_at": "2026-10-21T10:47:12Z", "source": "your data source and run id", "base_url": "https://your-bucket.example-cdn.com/runs/2026-10-21T10Z/", "files": ["t2m/000.webp", "t2m/001.webp", "precip/000.webp"] }

Fetch

Your worker downloads its input from the source.

Process

Your code, your libraries, pinned in your own container image.

Upload

All output files go into a new run folder.

Commit

Last of all, overwrite latest.json. The site picks up the new run on the next load; keep the cache time of this one file short.

Let your AI build the page

Tell your connected assistant where your manifest lives. It builds the page that reads it and shows the newest run, including the run time, so visitors can see how fresh the data is. See supported AIs →

Where to run it

Any provider that runs a container on a schedule

A few setups that work well. Pick the one you already know.

Before you go live

Checklist

The worker runs on a schedule, with its secrets in your provider's secret store.
Each run writes to a new folder, and the manifest is written last.
Old runs are removed automatically.
Route B: the output folder is public read-only and CORS allows your site's domain.
Route A: the API key has an expiry date and is only used by the worker.
Your page shows the run time from the manifest.
You respect the license and fair-use terms of your data source.

Who supports what

We support the site side: the page that reads your manifest, assets, forms and integrations. The worker, its code and your cloud account stay yours.