Build Type Schema and UI Validation#

Dokploy's application build form uses a Zod discriminated union keyed on buildType to expose and validate only the fields relevant to the selected builder. The UI schema and the backend schema are structurally different — the UI uses strict per-variant objects while the backend uses a flat schema — and this mismatch creates gaps where backend builders respond to fields the UI never surfaces.

Entry point: ShowBuildChooseForm in apps/dokploy/components/dashboard/application/build/show.tsx.

Discriminated Union Schema#

The six-variant schema mySchema is defined locally in show.tsx and passed to react-hook-form via zodResolver. Each variant is a z.object with a z.literal discriminant:

The BuildType enum enumerates all six values. The default form value is nixpacks 7.

The backend input schema apiSaveBuildType is a flat Zod schema that picks the same set of fields but applies no per-type branching — all build-type-specific fields arrive as optional nullables regardless of which buildType was submitted.

Form State Management#

Three mechanisms keep form state consistent with the active build type:

1. resetData() — When the application data loads (or reloads after save), resetData() maps the ApplicationData record into the correct discriminated-union shape so the form is primed with exactly the fields the active variant expects.

2. Conditional JSX — Each build-type-specific field group is wrapped in a buildType === guard 8, so only the relevant inputs render. Switching build type unmounts the previous inputs and resets their underlying form state.

3. onSubmit() — Before calling the tRPC mutation, onSubmit() explicitly nulls out every field not belonging to the active build type. For example, dockerfile, dockerContextPath, and dockerBuildStage are sent as null for any non-Dockerfile build type.

Railpack has additional UX: the version input toggles between a predefined Select dropdown (pinned versions from RAILPACK_VERSIONS) and a free-text Input for custom versions, controlled by isManualRailpackVersion state 9.

The publishDirectory and isStaticSpa Gaps#

The UI schema restricts field visibility tighter than the backend actually requires, creating two notable gaps:

publishDirectory — nixpacks only in the UI, three builders at runtime#

The UI exposes publishDirectory exclusively when buildType === nixpacks 10. At runtime, however, three separate builders consume the field:

• nixpacks.ts: When publishDirectory is set, appends --no-error-without-start to the build, then extracts artifacts from the built image via docker cp and hands off to getStaticCommand() to generate a final nginx image.
• static.ts: getStaticCommand() uses publishDirectory directly in the generated Dockerfile's COPY instruction (line 56). A blank publishDirectory defaults to ".".
• docker-file.ts: When publishDirectory is present, the Dockerfile builder suppresses .env file generation to avoid accidentally embedding secrets in a public static image.

For static and dockerfile build types, there is no UI field for publishDirectory, so the backend behavior can only be triggered by direct API calls.

isStaticSpa — static only in the UI, also invoked via nixpacks#

The UI exposes the Single Page Application checkbox only when buildType === static 11. However, when buildType === nixpacks with publishDirectory set, the nixpacks builder calls getStaticCommand(application) 12, which reads isStaticSpa from the application record to decide whether to write an nginx SPA config (try_files $uri $uri/ /index.html). Because the UI never sets isStaticSpa through the nixpacks path, nixpacks+publishDirectory builds always produce standard nginx routing even if SPA routing is desired.

Key Source Files#

Related PR: feat: added SPA option for static sites (#1931) — introduced isStaticSpa, the static build type's discriminated union branch, and the nginx SPA config in static.ts.