Deployment methods

Wasp apps are full-stack apps that consist of:

• A Node.js server.
• A static client.
• A PostgreSQL database.

To make deploying as smooth as possible, Wasp also offers a single-command deployment called Wasp Deploy.

Documentation

Wasp Deploy »

One-command deployment & redeployment

But even when not using Wasp Deploy, you can deploy each part anywhere where you can usually deploy Node.js apps or static apps. For example, you can deploy your client on Netlify, the server on Fly.io, and the database on Neon.

You can read our guides on how to deploy your Wasp app to different platforms, both from cloud providers and on your own infrastructure:

Documentation

Cloud Providers »

Deploy your Wasp app to various cloud platforms

Documentation

Self-hosted »

Use your own servers to host your app

Regardless of how you choose to deploy your app (i.e., manually or using the Wasp CLI), you'll need to know about some common patterns covered below.

Deployed? Get some swag! 👕🐝

Do you have a Wasp app running in production? If yes, we'd love to send some swag your way! All you need to do is fill this form out and we'll make it happen.

Missing files in the Docker image

The Docker image contains only the files the server needs at runtime, not the whole node_modules folder. Wasp finds those files by following the server's imports.

A package that loads files in a non-standard way can end up without them in the image. A common case is a package that serves static assets from its own folder (e.g. swagger-ui-express), which would fail in production.

Use server.traceDeps to copy such files:

main.wasp.ts

export default app({
  // ...
  server: {
    traceDeps: ["swagger-ui-dist*"],
  },
})

Each entry is a package name with an optional prefix or suffix, the same syntax as Nitro's traceDeps:

• "pkg" adds the package even when the server doesn't import it.
• "pkg*" copies all of the package's files.
• "!pkg" stops copying all files of a package Wasp copies fully by default.

We use nf3, which finds most of the files your dependencies need by default. Only use this setting if you've confirmed a necessary file is missing.

Customizing the Dockerfile

By default, Wasp generates a multi-stage Dockerfile. This file is used to build and run a Docker image with the Wasp-generated server code. It also runs any pending migrations.

You can add extra steps to this multi-stage Dockerfile by creating your own Dockerfile in the project's root directory. If Wasp finds a Dockerfile in the project's root, it appends its contents at the bottom of the default multi-stage Dockerfile.

Since the last definition in a Dockerfile wins, you can override or continue from any existing build stages. You can also choose not to use any of our build stages and have your own custom Dockerfile used as-is.

A few things to keep in mind:

• If you override an intermediate build stage, no later build stages will be used unless you reproduce them below.
• The generated Dockerfile's content is dynamic and depends on which features your app uses. The content can also change in future releases, so please verify it from time to time.
• Make sure to supply ENTRYPOINT in your final build stage. Your changes won't have any effect if you don't.

Read more in the official Docker docs on multi-stage builds.

To see what your project's (potentially combined) Dockerfile will look like, run:

wasp dockerfile

Join our Discord if you have any questions, or if you need more customization than this hook provides.