> ## Documentation Index
> Fetch the complete documentation index at: https://pipedream.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Build from Source

> Build the Conduit images yourself — the product image and the two load-test images — including behind a private package registry or artifact proxy.

If your environment can't pull from `ghcr.io` — registry policy, a
source-audit requirement, or a build network that only reaches your own
Artifactory or Nexus — build the same image CI builds. The entire build runs
inside Docker: code generation, the frontend, the docs, the Go binary, and
the full test suite, so a build that succeeds is a tested build. Git and
Docker (with BuildKit) are the only host requirements.

```sh theme={null}
git clone --branch vX.Y.Z https://github.com/PipedreamHQ/conduit.git
cd conduit
docker build -t registry.example.com/conduit/conduit:vX.Y.Z \
  --build-arg VERSION=vX.Y.Z .
docker push registry.example.com/conduit/conduit:vX.Y.Z
```

Build from a release tag, and pass that tag as `VERSION` — it becomes the
version the instance reports (in the app footer, logs, and telemetry), which
upgrade tooling and support will ask for.

## Every image the repository builds

The command above builds the product image, the Dockerfile's default target
and the only image published to `ghcr.io`. The same checkout builds two more
for the load-testing harness described in
[Load Tests](/docs/conduit/load-tests#run-it-on-your-own-infrastructure). Those are
not published: building them here and pushing them to your own registry is
how you get them.

| Image | What it is | Build |
| - | - | - |
| `conduit` | The product image. | `docker build --build-arg VERSION=vX.Y.Z .` |
| `loadtest-conduit` | The product image plus the load-test CLI as its entrypoint, which seeds the instance at boot — same server binary, same layers. Deploy it in place of `conduit` for a load test ([step 2](/docs/conduit/load-tests#2-deploy-conduit-from-the-load-test-image)). | `docker build --target loadtest-conduit --build-arg VERSION=vX.Y.Z .` |
| `loadtest-mcp-server` | The mock MCP upstream the seeded connectors call ([step 1](/docs/conduit/load-tests#1-deploy-the-mock-upstream)). A small Go module of its own under `loadtest/mock-upstream/`. | `docker build loadtest/mock-upstream` |

To build and push the load-test images next to the product image:

```sh theme={null}
docker build -t registry.example.com/conduit/loadtest-conduit:vX.Y.Z \
  --target loadtest-conduit --build-arg VERSION=vX.Y.Z .
docker build -t registry.example.com/conduit/loadtest-mcp-server:vX.Y.Z \
  loadtest/mock-upstream
docker push registry.example.com/conduit/loadtest-conduit:vX.Y.Z
docker push registry.example.com/conduit/loadtest-mcp-server:vX.Y.Z
```

Build them from the same tag as the product image you are measuring.

## What the build downloads

Every host the build contacts, and the build arg that repoints it:

| Download | Default host | Build arg |
| - | - | - |
| Base images (`golang`, `node`, `alpine`) | Docker Hub | `GOLANG_IMAGE`, `NODE_IMAGE`, `ALPINE_IMAGE` — full image references |
| Go modules | `proxy.golang.org` | `GOPROXY` |
| npm packages | `registry.npmjs.org` | `NPM_CONFIG_REGISTRY` |
| Alpine packages (`apk`) | `dl-cdn.alpinelinux.org` | `ALPINE_MIRROR` — must serve the standard path layout (`/alpine/v3.21/main`), which a pull-through remote of dl-cdn does |

The mock upstream's Dockerfile honors the same `GOLANG_IMAGE`,
`ALPINE_IMAGE` and `GOPROXY` args; it installs no npm or apk packages, so the
other two don't apply to it.

Building the docs embedded in the image contacts five more hosts. No build
arg repoints them:

| Download | Host |
| - | - |
| The Mintlify client that renders the docs, about 330 MB, downloaded on the first build and kept in the BuildKit cache after that | `releases.mintlify.com` |
| Icons, KaTeX CSS and KaTeX fonts the docs pages use, copied into the image | `d3gk2c5xim1je2.cloudfront.net`, `d4tuoctqmanu0.cloudfront.net` |
| Web fonts the docs CSS references, copied into the image | `cdn.jsdelivr.net`, `fonts.cdnfonts.com` |

The docs are a required part of the image. If the build can't reach one of
these hosts, the build fails. Because the assets are copied into the image,
the docs a running instance serves load nothing from these hosts or any
other external host.

Nothing else is contacted. Code generation runs locally inside the build,
and dependency integrity comes from the hashes committed in `go.sum` and the
npm lockfiles — no external checksum service is consulted, and a mirror
can't substitute a package unnoticed. npm re-points lockfile URLs from the
default registry to the one you configure.

A fully repointed build looks like:

```sh theme={null}
docker build -t registry.example.com/conduit/conduit:vX.Y.Z \
  --build-arg VERSION=vX.Y.Z \
  --build-arg GOLANG_IMAGE=registry.example.com/docker-remote/golang:1.27-alpine \
  --build-arg NODE_IMAGE=registry.example.com/docker-remote/node:22-alpine \
  --build-arg ALPINE_IMAGE=registry.example.com/docker-remote/alpine:3.21 \
  --build-arg GOPROXY=https://artifactory.example.com/api/go/go-remote \
  --build-arg NPM_CONFIG_REGISTRY=https://artifactory.example.com/api/npm/npm-remote/ \
  --build-arg ALPINE_MIRROR=https://artifactory.example.com/artifactory/alpine-remote \
  .
```

Match the base image versions to the ones in the repository's `Dockerfile`
for the tag you're building — they're part of the tested build.

If your network uses a forward proxy rather than registry mirrors, Docker's
predefined `http_proxy` / `https_proxy` / `no_proxy` build args cover the Go,
npm and Alpine package downloads with no per-ecosystem configuration.
The build downloads the docs icons, CSS and fonts directly, not through the
proxy, so allow their four hosts through your firewall.

## Running your build

Point your deployment at the pushed image: `image.repository` / `image.tag`
with the Helm chart (see
[Private registries](/docs/conduit/deploy/kubernetes#private-registries-and-air-gapped-installs)),
the `image:` line in raw manifests, or the image in your `docker run`
command. Upgrades are the same loop — check out the new tag, build, push,
roll — reading the [changelog](/docs/conduit/changelog#unreleased)'s **Upgrade
notes** first, as with any upgrade.

The load-test images go wherever [Load Tests](/docs/conduit/load-tests#run-it-on-your-own-infrastructure)
says to deploy them, by the names you pushed them under.

What the running instance downloads is a separate, deliberately short list —
see [Network Access](/docs/conduit/deploy/network).