How Deploy 360 works

1. We read your repository

When you pick a repository and branch, we scan it to find your apps and work out how each one builds.

Language	What we recognise
Node.js	Next.js, Nuxt, Remix, SvelteKit (server-rendered); NestJS, Fastify, Express (backends); Astro, Angular, Vue, Create React App, Vite (static frontends)
PHP	Laravel, Symfony and plain PHP
Python	Django, FastAPI, Flask
Go, Ruby, Java	Go modules, Ruby on Rails, Spring Boot (Maven or Gradle)
Static site	A folder with an index.html
Docker	Any language, if the repository has a Dockerfile

We also read each folder's .env.example file. This lets the wizard list the environment variables your app expects.

Node.js version: we use the version set in a NODE_VERSION variable, then .node-version, .nvmrc or engines.node in package.json. Versions 18, 20, 22 and 24 are supported. If none is set, we use 22.

2. Your server is prepared

After payment, we create a cloud server for the site, sized by your plan. On the first deploy we prepare it: we install Docker and the web server, turn on the firewall, and set up HTTPS. You can watch each step in the build log as Preparing the server…. Preparing takes a few minutes on the first deploy only.

3. Your code is built

Each deploy builds the exact commit at the head of your environment's branch, on your own server.

• "The commands below": we write the build instructions for you from your install, build and start commands.
• "Your repository's Dockerfile": your Dockerfile decides how the app is built and started.

Your environment variables are available during the build, so frontend frameworks can bake public values in. A build is stopped if it runs longer than 15 minutes.

4. The new version goes live with no downtime

1. The new version starts beside the one already running.
2. We check that it answers. If you set a health check path, it must return a success response.
3. Only when every service answers do we switch traffic to the new version.

No downtime on failure

If the build fails, or the new version doesn't start, the new version is thrown away and the previous version keeps serving. The deployment is marked Failed, and its build log shows why.

5. Your address and HTTPS

Every environment gets a free HTTPS address. The certificate is issued and renewed automatically.

Service	Address
Frontend	https://<your-name>.<apps domain>
Backend	https://<your-name>--api.<apps domain>

You choose <your-name> in the wizard's Address step. The full address is shown there and on the project page.

Common failure messages

Message	What to do
The build failed. See the log for what went wrong.	Open the build log. Usually a dependency or build-command error.
The new version did not start.	Your app crashed or didn't answer on its port. Check the Port and Start command, then the app's own output at the end of the log.
The commit could not be fetched…	The Git account lost access. Reconnect it in Git accounts.
The database could not be started. The previous version is still live.	Check your database settings, then deploy again.
These variables contain line breaks…	Put multi-line values, such as keys, on one line, for example base64-encoded.