Clouzark

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, main by 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 production

clouzark 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 skips node_modules, build output, and similar folders, and --upload is the default.
  • .env files are never sent. Set variables with clouzark env add.
  • The upload limit is 100 MB.

Frameworks

Clouzark detects the framework from the repository:

FrameworkHow it runs
Next.jsnext build, then next start
React (Vite and similar)Built, then served as a single-page app from the output directory (dist by default)
Nodenpm run start; the app should listen on the PORT and HOST environment variables
Static HTMLServed 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 docs

A 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/cache is 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 cache

In 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:

SizeMemoryCPU
512mb512 MB0.5 vCPU
1gb1 GB1 vCPU
2gb2 GB2 vCPU
4gb4 GB2 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 finishes

A 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 queued

Promotion and rollback switch traffic without rebuilding, so they only work with deployments that are still live.

On this page