Deploy an app with a Dockerfile
If your repository includes a Dockerfile, Zonda Cloud builds it as is and runs the container. Your app has to listen on the port from the PORT variable and respond over HTTP.
Port and health
The platform takes the port from the EXPOSE instruction in your Dockerfile (if there is none, it uses 8080) and passes it to your app in the PORT environment variable. It then waits up to ninety seconds for the app to respond over HTTP on that port; if it does not, the deployment fails and the log includes the container's last output.
A common mistake is for the app to listen only on 127.0.0.1: it has to listen on 0.0.0.0, or the published port rejects connections.
Minimal example (Node.js)
FROM node:22-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]In server.js, listen on process.env.PORT and on 0.0.0.0.
Variables, logs and rolling back
- You set environment variables in the console; they are stored encrypted and their values are masked in the logs. They apply on the next deployment.
- You see the build and the app logs live.
- You can go back to an earlier version without rebuilding.
- The result of each deployment shows up as the commit status in GitLab or GitHub.
What is not allowed
User apps run with a restricted profile: no system administration privileges, no access to the Docker socket, and caps on processes, open files and memory. Builds also have limits on time, memory, and the size of the code and the image. A public base image works; an image from the platform's internal registry does not.
If the repository has no Dockerfile and is not a static site, the deployment fails with a message asking you to add a Dockerfile.