[EASY] Build and ship the solana service binaries in the release images

[squadgazzz]

Description

The release pipeline only builds and ships the EVM binaries, so the devnet deployment has no solana images to pull. This adds the four solana services that have binaries on main (solana-indexer, solana-orderbook, solana-driver, solana-solvers) to every image path: the release cargo build in the deploy workflow, the production image (Dockerfile.deploy-ci), and the local/playground image with its per-service stages. autopilot-svm follows once its binary wiring PR merges.

The migration image needs no change, it already copies the whole database/ directory including the solana flyway series.

Changes

• The deploy workflow's release build and both Dockerfiles cover the four solana service binaries

How to test

CI builds the images on this PR. The deployed combined image gains the four binaries under /usr/local/bin, entrypoints unchanged.

[linear-code]

BE-228

[squadgazzz]

@claude review

[claude]

Claude finished @squadgazzz's task in 1m 13s —— View job

---

PR Review

• Read the changed files and gather context
• Review deploy workflow, Dockerfile, Dockerfile.deploy-ci
• Verify crate/binary names and workspace membership

Verdict: LGTM — no issues found.

The change is correct and internally consistent:

• All four crate names (solana-indexer, solana-orderbook, solana-driver, solana-solvers) exist under crates/, are workspace members (members = ["crates/*"]), and each declares a [[bin]] whose name matches the path used in the -p flags and the cp/COPY lines — so both cargo build -p … and the binary copies resolve correctly.
• The three image paths line up: the release build in deploy.yaml produces the binaries, Dockerfile.deploy-ci (the production image actually used by the deploy job) copies them from the binaries build context, and Dockerfile (playground) adds both the per-service stages and the combined final-stage copies.
• Entrypoints for the new per-service stages match the pattern of the existing ones.
• Agree with the PR note that the migration image needs no change — it copies the whole database/ directory.

One thing to watch (not a blocker): if any of the solana crates pull in system build deps beyond what the cargo-build stage already installs (git libssl-dev pkg-config build-essential), the Docker build would surface it. CI on this PR builds all three images, so that will be caught here.
· solana-infra/be-228-ci-images

[claude]

Claude finished @squadgazzz's task in 1m 13s —— View job

---

PR Review complete

• Read the changed files and gather context
• Review deploy workflow, Dockerfile, Dockerfile.deploy-ci
• Post findings and summary

No blocking issues found. This is a clean, correct change.

Verified:

• All four package names (solana-indexer, solana-orderbook, solana-driver, solana-solvers) match existing workspace crates, and each declares a [[bin]] whose name equals the hyphenated crate name — so the cargo build -p … targets and the cp target/release/<name> / COPY --from=binaries <name> paths all resolve.
• The four binaries are added consistently across all three image paths: the release cargo build in deploy.yaml, the in-container build + copy in Dockerfile (including the per-service FROM intermediate AS solana-* stages used by the playground), and the final COPY --from=binaries block in Dockerfile.deploy-ci (the production image built with build-contexts: binaries=target/release).
• Ordering is consistent everywhere (indexer → orderbook → driver → solvers), and entrypoints for the combined image are unchanged (tini), matching the PR description.

The migration image is correctly left untouched (it already copies the whole database/ tree), and deferring autopilot-svm until its binary wiring lands is the right call.