DocumentationProduction artifacts

Production artifacts

Create separate production output from your prepared workspace. Dwell writes files to artifact/; production configuration and getting them onto your server remain your responsibility.

What is an artifact?

Use artifact when preparing production output for a supported stack. dwell build prepares the local workspace first; it is not itself a production build.

  • Output is created separately in artifact/ at the project root.
  • Dwell installs production backend dependencies and builds supported Vite frontends.
  • Source, manifests and lockfiles in the original workspace remain unchanged.

Supported combinations

The following combinations are currently supported. Local development support for a stack does not automatically imply artifact support.

Symfony without a frontend
Symfony application with production Composer dependencies; webroot public/.
Symfony with React + Vite or Vue + Vite
One Symfony application whose public/ also contains the built frontend files.
Laravel, TYPO3 or Shopware 6 without a separate frontend
The respective backend application with production dependencies; webroot public/.
WordPress without a separate frontend
Composer-managed WordPress application; webroot wordpress/.

Laravel or CMS with a separate React/Vue frontend, frontend-only projects and custom roles are unsupported. Dwell reports those combinations before the artifact build; prepare their production output using your own process.

Standard workflow

Work from the project directory. Prepare the workspace and retain dependency lockfiles. Then create the artifact:

Prepare the local workspacebash
dwell build

Create production outputbash
dwell artifact

  • The backend needs composer.json, composer.lock, Docker and its configured PHP build image. Installation can contact package registries.
  • React/Vue requires a supported Node version, npm, package.json, package-lock.json and a working Vite build command.
  • If artifact/ already exists, deliberately move the previous output elsewhere before building again. Dwell does not overwrite it.

Dwell works in a temporary copy and publishes artifact/ only after successful checks. On failure the copy is removed; your workspace is preserved. Read the diagnostic and address its cause instead of treating old output as a newly successful build.

Use the output

The CLI reports the output directory and webroot. For example, Symfony + React puts backend files at the artifact root and integrates the built frontend into artifact/public/. The development backend/ and frontend/ directories stay separate.

Configure the target server’s production environment, database connection, domains, mail and other required services. Local .env files and credentials are not adopted as production configuration. Dwell does not run Composer application scripts; plan required setup, migration or cache steps for your application yourself.

Frontend builds receive no local .env files or inherited application secrets. Define intentional public production settings in the build configuration and review the bundle. Production API addresses and server-side SPA routing remain your responsibility.

What Dwell does not handle here

  • No upload or deployment.
  • No production server setup, hosting or starting a production runtime.
  • No generation of production secrets.
  • No database export as part of the artifact.

Notes & limits

Review the application and output before distributing them: Dwell cannot infer arbitrary secrets hardcoded into source. The standard Vite pipeline must accept the supported build arguments. External Composer path packages outside the copied backend are rejected. The technical reference covers exact exclusions, file collisions, symlinks and failure contracts.

Next steps

Back up application data separately using the database guide. When a build fails, the troubleshooting guide helps identify prerequisite issues.

Technical reference