Deployments

From GitHubCopy Anchor Link

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 a branch linked to a custom environment deploys there.
• 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.

Branch URLsCopy Anchor Link

Every preview branch also gets a stable URL that always serves its newest live deployment:

https://<project>-git-<branch>.clouzark.com

The branch name is lowercased, and anything other than letters and digits becomes - (feature/Login becomes feature-login). When that's too long for a hostname, or another branch or project already has it, a short hash of the branch name is added instead. A branch keeps its URL once it has one. clouzark deploy prints it when a preview goes live, and the dashboard's Copy URL uses it.

To serve a branch on your own domain, see branch domains.

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 -e test         # a custom environment's branch, to it

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 machineCopy Anchor Link

--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.

FrameworksCopy Anchor Link

Clouzark detects the framework from the repository:

The build command, output directory, install command, and root directory (for monorepos) can be changed in the project's settings.

NuxtCopy Anchor Link

Nuxt apps run their built server with npm run start, and the server reads PORT and HOST from the environment. New Nuxt projects don't have a start script, so add one to package.json:

{
  "scripts": {
    "build": "nuxt build",
    "start": "node .output/server/index.mjs"
  }
}

AngularCopy Anchor Link

Angular writes its build to dist/<app>/browser (Angular 17 and later) or dist/<app>, where <app> is the project name in angular.json. Clouzark finds the folder that holds index.html and serves it as a single-page app, so deep links work with the Angular router. If dist/ holds more than one app, set the Output Directory in the project's settings, for example dist/my-app/browser.

Angular apps with server-side rendering (@angular/ssr) run as a Node server instead. Angular's own start script runs the development server (ng serve), so point start at the built server:

{
  "scripts": {
    "build": "ng build",
    "start": "node dist/my-app/server/server.mjs"
  }
}

The server listens on the PORT environment variable, which Clouzark sets.

MonoreposCopy Anchor Link

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 cacheCopy Anchor Link

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 sizeCopy Anchor Link

The instance size sets how much memory and CPU your app gets while it runs:

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 logsCopy Anchor Link

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.

Runtime logsCopy Anchor Link

Runtime logs are what your running app prints to stdout and stderr: console.log output, request logs, and errors. Build output is in the build log instead.

In the dashboard, open the project's deployments, open the menu on a live deployment, and choose View Runtime Logs. You see recent lines, can filter to stdout or stderr, and new lines appear as the app prints them while the deployment is running.

• Runtime logs are kept for 3 days.
• A single line is cut at 16 KB.
• If an app prints faster than Clouzark can store, some lines are dropped and a [clouzark] … log line(s) dropped line marks the gap.
• Only deployments that run a server have runtime logs. Static sites don't, and a sleeping deployment shows its stored history without new lines.

To read them from scripts or coding agents, use GET /deployments/:id/runtime-logs or the get_runtime_logs tool in the MCP server.

Promote and roll backCopy Anchor Link

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.