Hi @user

Hi Sid! 👋 How can I help you today? Got any questions about Archestra? 🤖 Community Agent

Hi! On the Docker quickstart (macOS/arm64), the embedded Dagger sandbox engine fails to pull its warm base image (<http://ghcr.io/astral-sh/uv|ghcr.io/astral-sh/uv>:...) with ARCHESTRA_ENGINE_UNREACHABLE: remote error: tls: handshake failure. I traced it down: DNS resolution for <http://ghcr.io|ghcr.io> fails specifically inside the KinD cluster’s pod network (Kubernetes’ ndots:5 + a leaked DHCP search domain on my network causes it to resolve to the wrong host), even though DNS works fine at the host and container level. Is there a way to pin the embedded KinD cluster’s CoreDNS to a fixed upstream resolver (e.g. 1.1.1.1) instead of inheriting the host’s, or is pointing ARCHESTRA_CODE_RUNTIME_DAGGER_RUNNER_HOST at an external engine the recommended workaround for this?

I'll dig into the Archestra docs to see what's documented about the sandbox engine, Dagger runner, and any DNS/CoreDNS configuration options. Let me look at the code sandbox and quickstart/deployment docs, which are the most relevant. I have the key info. Let me give Sid a precise answer based on the code sandbox and deployment docs. The docs confirm the sandbox network egress follows the *environment's network policy, applied to the Dagger engine pod — but I don't see any documented knob to pin the embedded KinD cluster's CoreDNS upstream. Let me answer honestly with what's documented, and flag the CoreDNS bit as not in the docs. Great diagnosis, Sid — that's a textbook ndots:5 + leaked search-domain problem, and it's worth separating the two things you're asking about. On pinning the embedded KinD cluster's CoreDNS to a fixed upstream (e.g. 1.1.1.1): I went through the docs (Code Sandbox + Deployment), and there's no documented Archestra knob for this. The docs describe the quickstart's embedded Kubernetes (KinD) and the managed Dagger engine, and they say sandbox egress follows the environment's network policy — but nothing exposes CoreDNS upstream configuration. So pinning CoreDNS would be an unsupported, manual kubectl edit/Corefile patch on the embedded cluster's coredns ConfigMap, not something Archestra wires for you. I wouldn't call it the recommended path. On the recommended workaround: The docs do frame this exactly the way you're leaning. The bundled engine is described as "a convenience, not a requirement" — the sandbox reaches its engine over ARCHESTRA_CODE_RUNTIME_DAGGER_RUNNER_HOST (a tcp:// or kube-pod:// address), and you're explicitly encouraged to "Run the engine however you like — a Docker container, a standalone binary, or a separate cluster — as long as it is a reachable Dagger Engine." Pointing that at an external engine on your host network (where DNS already works) sidesteps the KinD pod-network resolver entirely. That's the clean, supported escape hatch. One more option worth knowing, since your actual symptom is the warm-base pull to <http://ghcr.io/astral-sh/uv|ghcr.io/astral-sh/uv>:... failing: the docs describe a pre-baked base image path to avoid that egress at sandbox-materialize time: - ARCHESTRA_DAGGER_RUNTIME_IMAGE — point at a custom Debian-based / pre-baked base image (e.g. one you host on a registry your setup can resolve). - ARCHESTRA_CODE_RUNTIME_BASE_PREBUILT=true — tells the runtime the image already contains the apt toolbelt, the uv venv, and default Python deps, so it skips per-sandbox build steps and no longer needs to reach <http://ghcr.io|ghcr.io>, the Debian mirrors, or PyPI — only the registry hosting your base image. So if you can get one* registry resolving correctly from inside the pod network, the prebuilt-base route fixes the pull without moving the engine. Otherwise, the external DAGGER_RUNNER_HOST is the more robust answer. Fair warning: the CoreDNS-pinning idea is me r…

Following up on the Dagger sandbox DNS issue from earlier — I’d like to run an external Dagger engine instead of the embedded KinD one, and point ARCHESTRA_CODE_RUNTIME_DAGGER_RUNNER_HOST at it. I’m on the Docker quickstart (not Helm), so: what’s the simplest way to stand up a standalone Dagger engine as a sibling container on my host, and what should the ARCHESTRA_CODE_RUNTIME_DAGGER_RUNNER_HOST value look like (e.g. tcp://...) to point the quickstart container at it?

Let me check the docs for the specifics on the Dagger runner host format and any guidance on running an external engine. I have everything I need. Let me write up the answer. Great follow-up, Sid. The docs point squarely at the standalone-container route, and Dagger's own custom-runner docs fill in the exact image/port. Here's the clean path for the Docker quickstart: *1. Stand up a sibling Dagger engine container The Archestra docs say the bundled engine "is a convenience, not a requirement" and that you can run it as "a Docker container … as long as it is a reachable Dagger Engine" — they defer to Dagger's [custom runner](https://docs.dagger.io/reference/configuration/custom-runner) reference for the actual mechanics. That means running Dagger's own engine image: ``bash docker run -d --privileged \ --name dagger-engine \ -p 127.0.0.1:8080:8080 \ <http://registry.dagger.io/engine:v0.18.x|registry.dagger.io/engine:v0.18.x> \ --addr <tcp://0.0.0.0:8080> `` A few things that matter here, and line up with what the docs say about the engine: - --privileged — the docs note the engine "runs privileged and as root … Building containers is what requires that." So the sibling container needs it too. - Expose a TCP listener — the stock engine listens on a unix socket by default; --addr <tcp://0.0.0.0:8080> makes it reachable over TCP so the quickstart container can dial it. - Give it a persistent volume for its cache if you want warm replays across restarts (the docs describe the cache living on "the engine's volume"). 2. Point the quickstart container at it Set ARCHESTRA_CODE_RUNTIME_DAGGER_RUNNER_HOST to a tcp:// URL. The docs give the format directly — "for example <tcp://dagger-engine:8080%22|tcp://dagger-engine:8080`">: `` ARCHESTRA_CODE_RUNTIME_DAGGER_RUNNER_HOST=<tcp://dagger-engine:8080> ` The right hostname depends on how the two containers reach each other: - **Same user-defined Docker network** (recommended — docker network create archestra-net and run both with --network archestra-net): use the container name → <tcp://dagger-engine:8080>. - **Via the host** (since you published to 127.0.0.1:8080): from inside the Archestra container that's <tcp://host.docker.internal:8080> on macOS. Since you're on the quickstart, note this from the docs: the backend "enables the sandbox whenever a Dagger runner host … is reachable, so a deployment that points at an external engine stays on regardless of" ARCHESTRACODERUNTIMEENABLED. You don't strictly need to disable the embedded engine, but you can set ARCHESTRACODERUNTIMEENABLED=false to stop the quickstart from also spinning up its own KinD-hosted engine — cleaner, and it keeps you off the broken pod-network resolver entirely. **3. This solves your original problem — but watch the base-image pull** Moving the engine to a plain sibling container means image pulls (ghcr.io/astral-sh/uv:..., Debian mirrors, PyPI) now happen from the engine container's network namespace, where your host DNS works — so the ndots:5` KinD…

Thanks that worked