Deployments
How Clouzark builds and serves your app.
From GitHub
Every push to a connected repository creates a deployment:
- A push to the production branch (set per project,
mainby default) deploys to production. - A push to any other branch, or a pull request, deploys a preview with its own URL.
Each deployment also keeps its own immutable URL, so you can always open exactly what a given build served.
To deploy without pushing, run:
clouzark deploy # the current branch's latest pushed commit
clouzark deploy --branch staging
clouzark deploy --prod # the production branch, to productionclouzark deploy builds what's on GitHub, not your local files. It warns when you have uncommitted changes or unpushed commits that won't be included.
From your machine
--upload builds the directory as it is now, uncommitted changes included:
clouzark deploy --upload # preview, named after the current branch
clouzark deploy --upload --prod # production- In a git repo, the CLI sends the files git sees (tracked and untracked, minus
.gitignore). Outside a git repo it skipsnode_modules, build output, and similar folders, and--uploadis the default. .envfiles are never sent. Set variables withclouzark env add.- The upload limit is 100 MB.
Frameworks
Clouzark detects the framework from the repository:
| Framework | How it runs |
|---|---|
| Next.js | next build, then next start |
| React (Vite and similar) | Built, then served as a single-page app from the output directory (dist by default) |
| Node | npm run start; the app should listen on the PORT and HOST environment variables |
| Static HTML | Served as-is |
The build command, output directory, install command, and root directory (for monorepos) can be changed in the project's settings.
Monorepos
One repository can hold several projects. Import the repo once per app and give each project its own root directory, such as apps/web and docs:
clouzark projects create acme/monorepo --name acme-web --root apps/web
clouzark projects create acme/monorepo --name acme-docs --root docsA push then builds every project that uses the repo, except projects whose root directory had no changes. To always build on every push, turn off Skip deployments when nothing in the root directory changed in the project's settings. Deploys started from the dashboard or with clouzark deploy always build.
Build cache
Builds reuse a cache from the project's earlier builds, so they don't download every package and recompile every page each time:
- npm downloads are kept per project and reused by every build. npm still checks each package against your lockfile.
- Next.js's
.next/cacheis restored into every build, but only production builds save it. A preview from another branch never changes what production builds with.
node_modules itself isn't cached, so a dependency change always installs cleanly.
If a build behaves oddly and you suspect the cache, rebuild without it:
clouzark redeploy --force # rebuild the latest deployment without the cache
clouzark deploy --force # deploy without the cacheIn the dashboard, untick Use existing build cache when you redeploy. A production build without the cache saves a fresh one for the builds after it.
Instance size
The instance size sets how much memory and CPU your app gets while it runs:
| Size | Memory | CPU |
|---|---|---|
512mb | 512 MB | 0.5 vCPU |
1gb | 1 GB | 1 vCPU |
2gb | 2 GB | 2 vCPU |
4gb | 4 GB | 2 vCPU |
Set it in the project's settings (General → Instance size), or with the CLI:
clouzark projects memory # show the current size
clouzark projects memory 2gb # set it
clouzark projects memory default # back to the platform default- A new size applies to running deployments straight away.
- A running deployment that's already using close to or more than a smaller size keeps its current limit until it's next deployed.
- An app that goes over its memory is restarted.
Build logs
clouzark deployments ls # recent deployments
clouzark logs # the latest deployment's log
clouzark logs <id> -f # follow a build until it finishesA deployment moves through queued, building, deploying, and then live, failed, or canceled.
Promote and roll back
clouzark promote <id> # make a deployment the live production deployment
clouzark rollback # go back to the previous production deployment
clouzark redeploy # rebuild the latest deployment with current env vars
clouzark redeploy --force # the same, without the build cache
clouzark cancel <id> # cancel a deployment that's still queuedPromotion and rollback switch traffic without rebuilding, so they only work with deployments that are still live.