Build and deploy Railpack applications locally #801

Parent

Build runner spec (#798)

What to build

Add the Railpack recipe to the proven local capture/execute path. A real application without a Dockerfile should build, produce a usable image, and reach ordinary Deploy. Reuse the existing execution, secret, image-result, and cleanup behavior instead of introducing a second runner.

Acceptance criteria

• Select an explicitly configured recipe first. Automatic selection prefers an explicit/inline or existing default Dockerfile and otherwise uses Railpack for a buildable Service. Image-only Services remain image-only. Missing explicit Dockerfiles, failed Dockerfile builds, failed Railpack detection, and failed compilation never fall back to another recipe.
• Provision compatible pinned Railpack preparation and frontend tooling alongside the existing pinned BuildKit setup. Prepare against the captured inputs on the execution host and run a real single-native-platform solve through the same executor. Preparation participates in existing cancellation, timeout, and cleanup ownership; the frontend is not a Dockerfile generator.
• Apply Railpack's merged configured exclusions and Docker ignore patterns before source can be transferred, with upstream negation and control-file behavior. Keep the capture/execute caller interface opaque; callers must not run Railpack preparation or merge exclude lists themselves.
• Supply the effective Service/build variables using the pinned frontend's secret mechanism, preserving provider-once semantics and build-only precedence. Implement its variable-dependent cache invalidation so a changed build variable does not reuse stale output. Keep source, result metadata, and Ployz-generated diagnostics free of private values; arbitrary recipe output remains the recipe author's responsibility.
• Return the same exact image identity, tags, native Linux platform, and location used by Dockerfile results, and let normal standalone build, image delivery, and Deploy consume it. Keep validation-only outcomes honest; if an existing validation option has no recipe-equivalent, refuse it by name before execution instead of claiming image success.
• Use rung-1/2 selection/capture/variable tests and CLI checks for automatic versus explicit recipes and no fallback. Add a registered rung-4 real Railpack application build and Deploy that proves variable consumption, changed-variable cache invalidation, image usability, failure stopping Deploy, and builder teardown/cache reuse. Use the retained prototype findings as evidence for tool choices, not as product-path test results.

Blocked by

• #800 — Capture portable build source and private variables