Questions people ask before they have a problem. If something is already broken, start with troubleshooting.md.
No. The dev kit and the container images it runs are licensed for local development only. See TERMS.md. For a production license, contact sales@duplocloud.net.
Two different things are in this repo:
- The dev-kit source is Apache-2.0. Everything DuploCloud authored here —
run.sh,scripts/,samples/,docker-compose.yml,nginx/,.claude/— you can clone, modify, and redistribute. See LICENSE. - The container images and the vendored UI library are not. The
quay.io/duplocloud/*images and the@duplocloud-internal/ng-common-libtarball are proprietary, licensed under TERMS.md, and may not be modified. You may build extensions against the library and ship what your build bundles into a compiled extension; you may not republish, repackage, or modify it.
NOTICE is the full boundary, and Apache-2.0 §4(d) requires you to keep it in any redistribution.
You do. DuploCloud claims no rights in anything you write under extensions/. See NOTICE.
Improvements to the framework are welcome. Your own extensions belong in your repo, not upstream. See CONTRIBUTING.md.
No account, but three things: the ability to pull quay.io/duplocloud/* (run docker login quay.io if the
pull is denied), an LLM key for the agent — Anthropic, Azure AI Foundry, or AWS Bedrock — and a work email
address, because the stack is licensed. On an EC2 instance whose IAM role can already invoke Bedrock,
run.sh offers a keyless option and you need no LLM key at all.
Yes, and ./run.sh gets it for you. On first run it requests a trial license for the admin email you enter
and writes the JWT into .env as Licensing__Token; the studio reads it from there. You have to click a
verification link emailed to that address, so use a work address — personal domains are rejected — and expect
one interactive moment on a first install.
The server issues one license per address and never a second, so run.sh is built never to need one: it
reuses what it has, resumes an interrupted verification, and recovers a license an address already holds by
emailing you a confirmation link. Full behavior in
configuration.md § Licensing; symptoms and fixes in
troubleshooting.md § Licensing.
Yes. Set DUPLO_TARGET=remote with DUPLO_HOST and DUPLO_TOKEN (an Administrator bearer token) in
.env. The same scripts then build and deploy against that platform instead of the local stack. See
configuration.md.
- ARM Macs (Apple Silicon) — yes. The studio image is amd64-only and runs under emulation;
STUDIO_PLATFORM=linux/amd64in.env.examplehandles this. Expect it to be slower than native. - Windows and WSL — not verified. Docker Compose v2 and
python3are the only hard requirements and the scripts are POSIX shell, so WSL2 is the likely path, but nobody has confirmed it end to end. If you try it, please say how it went.
Docker with Compose v2, python3, an LLM key, and a work email address you can receive mail at (the license
verification link goes there). That is the whole list — building an extension needs nothing extra on your
machine, because the build runs in a container. See Prerequisites.
No. ./scripts/build-extension.sh runs the build inside a toolchain container that ships .NET SDK 8 and
Node 22, and starts it for you; the first build pulls that image, or builds it locally from
build/Dockerfile.builder if the pull fails. If you already have a toolchain and would rather use it, pass
--native or set DUPLO_BUILD_NATIVE=1.
No. Every port is deliberately offset — 4210 instead of 4200, 60031 instead of 60021, and so on — so both stacks can run at the same time. See configuration.md.
./scripts/upgrade_dev_kit.sh --version <branch|tag>. It refreshes framework-owned paths and never touches
extensions/ or .env. See upgrading.md.
No. extensions/ is not in the framework allowlist, and neither is .env. Docs you add under docs/ also
survive — that directory is merged, not mirrored.
The stack runs entirely on your machine. Three things leave it:
- Your LLM provider. The agent sends prompts to Anthropic, Azure, or Bedrock using the key you supply, under that provider's terms.
- Usage metrics, if you opt in inside the UI — see the next question and PRIVACY.md.
- Image pulls from
quay.io.
Your tickets, extensions, and platform data stay in your local Mongo and file store.
The portal sends product usage metrics to DuploCloud via Mixpanel only if you opt in inside the UI. It is not anonymous — the metrics are tied to the email you sign in with, along with your username, roles, and email domain. What is sent is which features you used and the names of objects you created, not their contents. PRIVACY.md enumerates every event and property.
The dev kit itself has no metrics prompt or setting; the consent lives in the product UI.
./run.sh starts warning seven days out and tells you the exact expiry date; after that it prints
⚠ License expired on <date> on every run. It never blocks or refuses to start on your behalf — enforcement
is the studio's, from the license's own claims.
Renewal is a conversation with DuploCloud, not a re-run: the license server issues exactly one license per
email address and will not issue a second one for yours. Contact sales@duplocloud.net (or see
SUPPORT.md), and if you are handed a new JWT, install it with ./run.sh --license <jwt>.
troubleshooting.md, then SUPPORT.md for what to include when you
ask. Redact your .env values before pasting anything.
Do not open a public issue. Email ai-reporting@duplocloud.net — see SECURITY.md.