fix: update Railpack version to 0.17.2

[kadma]

What is this PR about?

Please describe in a short paragraph what this PR is about.

Railpack version updated

Checklist

Before submitting this PR, please make sure that:

• [✅] You created a dedicated branch based on the canary branch.
• [✅] You have read the suggestions in the CONTRIBUTING.md file https://github.com/Dokploy/dokploy/blob/canary/CONTRIBUTING.md#pull-request

Greptile Summary

This PR bumps the default Railpack version from 0.15.4 to 0.17.2 across four files: the Dockerfile, the database schema default, the server setup install script, and the frontend build configuration form. New intermediate versions 0.16.0, 0.17.0, and 0.17.1 are also added to the selectable versions list in the UI.

The version update in the Dockerfile, application.ts schema default, and the RAILPACK_VERSIONS array in show.tsx are all correct. However, there are several places in show.tsx where the old version string "0.15.4" was not updated, which will cause inconsistent behavior. Additionally, the installRailpack function in server-setup.ts skips re-installation if Railpack is already present, meaning existing servers will not be upgraded to the new version.

Key issues:

• onSubmit fallback in show.tsx still uses "0.15.4" as the default when railpackVersion is null/empty (line 239).
• Switching from manual to predefined version mode resets the field to "0.15.4" instead of "0.17.2" (line 477).
• The <Select> component's null-value fallback still resolves to "0.15.4" (line 493).
• The "Latest" badge in the version list still marks "0.15.4" as latest instead of "0.17.2" (line 507).
• installRailpack in server-setup.ts only installs on fresh setups — existing Railpack installs are silently skipped without a version check or upgrade path.

Confidence Score: 2/5

• Not safe to merge — multiple stale version references in the UI and no upgrade path for existing Railpack installations.
• The core intent (updating the default Railpack version) is partially implemented, but 4 out of 5 changed locations in show.tsx still reference the old version "0.15.4". This would result in inconsistent behavior: the schema default and RAILPACK_VERSIONS list are updated, yet the form's submit fallback, select fallback, manual-mode reset, and the "Latest" badge all still point to the old version. Additionally, the server-setup install script will silently skip upgrading existing Railpack installations.
• Pay close attention to apps/dokploy/components/dashboard/application/build/show.tsx (multiple stale version references) and packages/server/src/setup/server-setup.ts (upgrade path for existing installs).

_{Last reviewed commit: ea8937b}

_{(4/5) You can add custom instructions or style guidelines for the agent here!}

[greptile-apps]

_{4 files reviewed, 5 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Additional Comments (5)

apps/dokploy/components/dashboard/application/build/show.tsx
Stale fallback version in onSubmit

The fallback version used when railpackVersion is empty or null in onSubmit still references the old version "0.15.4" instead of the updated "0.17.2". This means applications that somehow end up with a null/empty railpackVersion will be saved with the old version rather than the new default.

				? data.railpackVersion || "0.17.2"

---

apps/dokploy/components/dashboard/application/build/show.tsx
Stale default version when switching back from manual entry

When a user clicks "Use predefined versions" to revert from manual mode, field.onChange("0.15.4") resets the field to the old default version instead of the new default "0.17.2". The value fallback on the <Select> (line 493) also still uses "0.15.4". These should both be updated to "0.17.2" to stay consistent with the rest of the PR.

									field.onChange("0.17.2");

---

apps/dokploy/components/dashboard/application/build/show.tsx
Stale fallback value for Select component

The value prop falls back to "0.15.4" when field.value is null. This should be "0.17.2" to match the updated default version.

							value={field.value ?? "0.17.2"}

---

apps/dokploy/components/dashboard/application/build/show.tsx
"Latest" badge still points to old version

The "Latest" badge is rendered conditionally for version "0.15.4", which is no longer the latest — "0.17.2" was just added as the new default. This will confuse users seeing 0.15.4 labelled as "Latest" while 0.17.2 sits above it in the list without that badge.

												{version === "0.17.2" && (

---

packages/server/src/setup/server-setup.ts
Existing Railpack installations are not upgraded

The installRailpack function skips installation entirely when command_exists railpack is true. This means servers already running Dokploy with Railpack 0.15.4 installed will never be upgraded to 0.17.2 through this setup script. The version bump in RAILPACK_VERSION only takes effect on fresh installations.

If the intent is to enforce a specific version, the check should compare the installed version against the expected one (similar to how other tools are version-pinned), or the else block should be replaced with an unconditional reinstall when the version doesn't match. Without this, the server-setup version update is effectively a no-op for existing installs.

[Siumauricio]

Hey, you need generate the migration

[kadma]

I have already applied the migration. I will stay tuned in case anything else is needed, and I apologize for being clumsy, but I am learning. 😅