Deploy without Git: from ZIP to a live site in minutes

Stacks supported without a Dockerfile

If there is a Dockerfile at the root of the ZIP, it is used instead of the automatic recipe. When there is none, the build log shows the generated Dockerfile — handy for understanding and fixing an error.

Step by step

• Create your account at devoracloud.com/register (7-day free trial, no card).
• In the dashboard, create a new project and choose ZIP upload.
• Upload the file (up to 512 MB).
• Follow the build: analysis, build, publishing and health check.
• When the status is ready, the site answers at https://your-project.apps.devoracloud.com with an automatic certificate.

Rather not do any of this? Generate the AI token in the dashboard and ask your AI to deploy: it prepares the ZIP, creates the project and follows the build for you.

How to build the ZIP

Put the file that identifies the project at the root of the ZIP: package.json, requirements.txt, go.mod or index.html. A single top-level folder also works. Use ZIP; tar archives are not accepted.

Leave out:

• node_modules — dependencies are installed during the build.
• .next, dist and build — the build runs again on the platform.
• .git — history is not needed.
• .env and any file with passwords or keys — use the project’s environment variables.
• User uploads and local databases such as .sqlite files — files go to S3 and data to PostgreSQL.

A lean ZIP uploads faster and keeps things that only made sense on your machine out of the cloud.

PORT and 0.0.0.0: the most common mistake

The application must listen on 0.0.0.0 and on the port given by the PORT environment variable. If it listens only on localhost (127.0.0.1) or on a different fixed port, the build succeeds but the health check cannot reach the app, and the deploy fails.

• Node.js: app.listen(process.env.PORT || 3000, "0.0.0.0").
• Next.js: the default start script (next start) already honors PORT.
• Python: run the server (uvicorn, gunicorn) with host 0.0.0.0 and the port from PORT.
• Go: read os.Getenv("PORT") and listen on ":" + port.

Check your scripts too: in Node projects, package.json needs build (if there is a build step) and start.

Other common first-deploy errors

If the deploy fails, open the log before changing anything. The most frequent cases are easy to fix:

• Missing dependency: the package works on your machine because you installed it by hand, but it is not in package.json or requirements.txt.
• Wrong runtime version: the project needs a different Node.js or Python version from the one the build detected.
• File name case mismatch: it works on Windows or macOS but not on the Linux build machine.
• Environment variable missing at build time: the code reads a key that only existed in your local .env.

Fix it, create a new ZIP and deploy again. Meanwhile, the previous version stays live.

Variables, database and S3

Passwords and keys go in as project environment variables, available at build and run time. If the app uses a database, create PostgreSQL or Redis before the first deploy: the connection reaches the app as DATABASE_URL (or REDIS_URL). For images and documents, create the project’s private S3; the app receives ready-made S3_* variables.

Never put secrets in variables read by the browser, such as those starting with NEXT_PUBLIC_.

New versions, and GitHub later

To update, upload a new ZIP and deploy again. A failed deploy never replaces the version that is live: the site keeps running while you fix things.

When the project matures, connect GitHub once in the dashboard under Connections and link the repository to the project. From then on, every push to the chosen branch triggers a deploy. ZIP upload remains available if you prefer it.

Frequently asked questions