Confirm the platform supports changing the active path, symlink or equivalent deployment reference. Identify persistent uploads, secrets, caches and database changes that must be managed separately.

1. Create a new release directory identified by a commit or build. Upload and verify the complete artifact without replacing the active directory in place.

2. Attach the approved runtime configuration and persistent data paths. Build release-specific caches and run safe readiness checks.

3. Apply database changes in a compatible, reviewed sequence. A file switch alone does not make an incompatible schema change reversible.

4. Switch the active path using the supported operation, then restart or reload processes so they execute the intended release.

5. Verify customer workflows and retain the previous release for the recovery window. Clean up only releases and generated data confirmed no longer needed.

A release layout can use the following roles. These illustrative paths describe a design to adapt to your platform, not a shell script to run.

Runtime secrets stay in protected configuration. After switching, confirm both web requests and background workers report the intended release and can read a recent upload. Database compatibility remains a separate deployment requirement.

Check the release identifier through a safe endpoint or private diagnostic. Confirm both web processes and workers use the new path and that recent uploads remain present.

If the platform cannot switch paths atomically, plan an appropriate maintenance or staged deployment procedure. Do not assume a sequence of FTP overwrites has the same behavior.

• Building a deployment artifact in CI
• Rolling back application files without losing new user data
• Planning a backward-compatible database deployment
• Maintaining a deployment log and release identifier

• Symfony deployment practices
• Express graceful shutdown