Deploy a Wasp App on SnapDeploy: Server, Client and PostgreSQL from One Repository

4.Add client.Dockerfile and nginx.conf

ARG WASP_VERSION=0.25.0
ARG NODE_IMAGE=node:24-bookworm-slim

FROM ${NODE_IMAGE} AS builder
ARG WASP_VERSION
ARG REACT_APP_API_URL
RUN apt-get update \
 && apt-get install -y --no-install-recommends openssl ca-certificates python3 build-essential \
 && rm -rf /var/lib/apt/lists/* \
 && npm install -g @wasp.sh/wasp-cli@${WASP_VERSION}
WORKDIR /app
COPY . .
RUN wasp install && wasp build
RUN test -n "$REACT_APP_API_URL" || (echo "REACT_APP_API_URL is not set" && exit 1)
RUN REACT_APP_API_URL=${REACT_APP_API_URL} npx vite build

FROM nginx:1.27-alpine
COPY nginx.conf /etc/nginx/conf.d/default.conf
RUN rm -rf /usr/share/nginx/html/*
COPY --from=builder /app/.wasp/out/web-app/build /usr/share/nginx/html
EXPOSE 80

Wasp's Vite build emits 200.html as the entry page, not index.html, and COPY merges into the nginx image's html directory, so the stock welcome page is removed first and nginx is told to serve 200.html:

server {
    listen       80;
    server_name  _;
    root         /usr/share/nginx/html;
    index        200.html;
    location /assets/ {
        add_header Cache-Control "public, max-age=31536000, immutable";
        try_files $uri =404;
    }
    location / {
        try_files $uri $uri/ /200.html;
    }
}

5.Deploy the client from the same repository

Deploy Your Application → GitHub → the same repository → Advanced Options → Dockerfile Path client.Dockerfile. Add one variable before the first build:

Vite bakes REACT_APP_API_URL into the compiled JavaScript. SnapDeploy passes REACT_APP_, VITE_ and NEXT_PUBLIC_ variables into the Docker build as build arguments, which is why the Dockerfile declares it as ARG and refuses to build without it. If you change it later, redeploy; a restart is not enough.

6.Point the server at the client and redeploy

On the server container set WASP_WEB_CLIENT_URL to the client's URL and redeploy. Open the client URL, sign up, create something. From now on every push to the branch rebuilds both containers; new Prisma migrations committed with your code are applied by the server on its next start.

Do I have to run wasp build before deploying to SnapDeploy?

No. The server Dockerfile on this page installs the Wasp CLI and runs wasp install and wasp build inside the build, so the repository holds your app's source and every push to the branch rebuilds the container. You never commit the .wasp/out output.

Why two containers?

A built Wasp app is a Node.js API server plus a static React client, and Wasp's own docs deploy them as two things with two URLs. On SnapDeploy they are two containers from the same repository: the server from Dockerfile and the client from client.Dockerfile, chosen with the Dockerfile Path field under Advanced Options. Both fit in the free tier's 4 containers.

Where does the PostgreSQL database come from?

From a managed PostgreSQL add-on next to the containers: the $1 DB Sprint Pack runs for 12 hours to try things, the Mini tier is $29 a month. Link it to the server container and DATABASE_URL is injected into the environment; the server runs prisma migrate deploy on every start, so committed migrations are applied automatically.

How does the client know the server's URL?

Through REACT_APP_API_URL, which Vite bakes into the JavaScript at build time. Add it as an environment variable on the client container before the first build: SnapDeploy passes REACT_APP_, VITE_ and NEXT_PUBLIC_ variables into the Docker build as build arguments. Changing it later needs a redeploy, not a restart.

Does the Wasp server need a health route?

No. The platform probes the common health paths and then the root path before routing traffic, and the Wasp 0.25 server answers GET / with 200, so the deploy passes without any change to the app.

Can a Wasp app run on the free tier?

Yes, as a demo: two of the four free containers, 100 container-hours a month shared, no credit card. Both containers sleep after 15 idle minutes. A browser visit wakes the client, but the client's API calls do not wake a sleeping server, so for anything people depend on run the server on Always-On at $12 a month; the client can stay free.

Which Wasp version does this cover?

Wasp 0.25, the current release on 6 October 2026, with Node.js 24 in the build. The Wasp version is an argument at the top of each Dockerfile; bump it when you upgrade the app.