Push. The rest is automatic.
Every push is built on our servers, passes the security checks and your tests, and is deployed. main is production and every other branch gets its own preview. No separate CI service needed.
From push to production
One path for apps and functions, in any language.
Push
To a connected GitHub or GitLab, or straight to our git address inside Iran.
git push origin mainBuild and check
The framework and language are detected. The secret scan, package checks and your tests run in the same build.
cloudhost apps builds my-shopPreview
Each branch gets its own address, and its link is written on the pull request.
new-menu--my-shop.app.trustpage.irProduction
All at once or as a gradual release. Rolling back is one command.
cloudhost release start 42 --steps 10,50,100
Build and deploy
Connect GitHub and GitLab
Connect a GitHub, GitLab or self-hosted GitLab account and import a repository. Every push is built, and its status is written on the commit and the pull request.
A git address inside Iran
Send straight to us with git push cloudhost main. Packages install from our servers inside Iran too, so you build and release even during an international internet cut.
Zero config, every field yours
The language, framework and commands are detected from the project. Change any of them in cloudhost.toml or the dashboard: the root folder for a monorepo, install and build commands, the Node.js version.
A preview per branch
Each branch and pull request gets its own address, with its own database branch, bucket and variables. Delete the branch and its preview goes too.
Build cache
Installed dependencies and the framework's cache are kept between builds, so the next build is faster. One click to invalidate the cache or redeploy without it.
Ignored build step
A command run before the build that skips it when nothing changed. In a monorepo only the project that changed is built.
Queue, cancel and redeploy
See each build's place in the queue and why it waits. Cancel a build, or build and deploy the same commit again.
Build errors you can read
When a build fails, what happened and how to fix it is written above the log, with the file and line. A coding agent reads the same through the API and MCP.
Any language
Next.js, Astro, static sites and JavaScript functions, plus Python, Go, PHP, Java and other languages from source.
Security inside the build
DevSecOps with no separate service and no setup, on every plan. Every check's result is on the deployment page, in the API, the CLI and MCP.
Secret scanning
Every build's code is scanned before it runs for keys and passwords committed by mistake. A finding shows only where it is; the value is never stored or shown.
Malicious packages blocked
A package version known to be malicious is not installed. The build stops naming the package and version, and cache entries holding it are removed.
A wait for brand-new versions
A version less than 3 days old is not installed by default, since most malicious packages are found within that time. A project can shorten the wait or allow one version early.
Install scripts off
Packages' install scripts do not run, except for packages on the project's allow list or ours.
Vulnerable dependencies
Every build matches the lock file against a security advisory database: package, version, severity and the fixed version. A critical vulnerability stops the build; a rescan catches new advisories.
Checks before production
A smoke request, your tests, a type check, and checks your own CI reports. A version does not reach production until all pass, and visitors keep the previous one.
Bill of materials (SBOM)
Every build has the list of all its packages and versions in the standard CycloneDX format, for licence reviews and security questionnaires.
Signed provenance
Every deployed version has a signed record: which commit, which lock file and what output. Anyone can verify it with our public key.
Isolated builds
Each build runs in its own environment, reaches only our package servers and your git host, and is destroyed when it ends. Only secrets marked for builds are present.
Release with confidence
Gradual release
Send a share of production traffic to the new version and raise it step by step, by hand or on a schedule. If errors pass the threshold, it stops by itself and traffic goes back.
Deploy without promoting
A production build gets ready and waits at its own address. Promote it, or release it gradually, when you choose.
Rollback
Every deploy is an immutable version. Go back to any earlier one with one command or one click, with no rebuild.
Deployment protection
Previews, and production if you like, open only for team members or with a password. Shareable links for people outside the team and a bypass token for automated tests.
Version skew protection
An open page keeps getting answers from the version it loaded with, even after a new one is released. On by default.
Notified at once
When a build is stopped or a gradual release rolls itself back, the team hears by email, SMS or webhook.
From the terminal, the dashboard or an agent
Everything in the dashboard also works through the CLI, the API and MCP, so a coding agent can follow a build and read why it failed.
cloudhost git connect github
cloudhost apps git import my-shop acme acme/shop
# every push to main deploys production; other branches get previewsPer build minute
A build is counted per second, from start to finish. The security checks are part of the build and cost nothing extra. Pro has more builds at once and a larger build cache.
Questions
Not to build and deploy. If you run tests elsewhere, your CI reports the result through the API and that check becomes required before production.
The live version is untouched. The explanation and the fix are above the build log, in the dashboard, the CLI and MCP.
Only the ones you mark for builds. The rest never reach the build environment and are read only at run time.
You can move the secret scan and the vulnerability check from block to warn, but the scan itself always runs. A malicious package is always blocked.
No, because their code would run with the project's variables. Pull requests from the repository's own branches get previews.
You still release with git push to our git address. Packages install from our servers inside Iran, so builds keep going.
Connect your repository
Your next push is built, checked and deployed.
Sign-up is by invite for now. If you have a code, create your account.
Sign up withEmail codeSMS code