Products

Checks and vulnerabilities

A new version does not reach production until it passes the checks you asked for, and every build measures its dependencies against a security advisory database.

How it works#

A production build of a project that has checks is staged: the version is built and uploaded, but it does not go live until every required check passes, and visitors keep seeing the previous version. Previews (any branch other than main) show their checks and are never blocked. A direct cloudhost deploy from your machine has no checks; they belong to builds on our builder.

Check	What it does
`smoke`	Before going live, one GET is sent to the new version (with production variables and bindings) and it must answer 2xx. Every plan.
`test`	The project's test command (for example `npm test`), in the same isolated build environment after dependencies install. Pro.
`typecheck`	The type check, default `npx tsc --noEmit`. Pro.
نام‌های بیرونی، مثلاً `ci/unit`	Anything your CI reports through the API. Pro.

A check that has not finished by its limit (check_timeout_minutes, default 15) counts as failed. If a required check fails or times out the version is blocked and the previous one stays live. If a newer build goes live meanwhile, this one is marked superseded and is not published.

The test and the type check are the result of your own build: code you wrote runs them. For independent assurance, require an external check from your own CI.

Settings#

In the dashboard: project, Settings, Build and deployment. With the API: GET and PUT on /v1/functions/<name>/build-settings or /v1/apps/<name>/build-settings (owner or admin).

Field	Value
`smoke`, `smoke_path`	on or off, and the path (default `/`)
`test_command`	one line, 300 characters at most, or `null`
`typecheck`, `typecheck_command`	on or off, and the command
`required_checks`	up to 10 external names: lowercase letters, digits, `. _ / -`
`check_timeout_minutes`	1 to 60
`scan_fail_on`	`none`, `high` (critical and high) or `critical`

cloudhost functions checks set my-api --smoke /health --test "npm test" --typecheck on --require ci/unit,lint --timeout 20
cloudhost functions checks settings my-api

Reporting from a CI#

Every build has an id (cloudhost builds my-api). Your CI sends a check's state with a PUT: running, passed or failed, with a summary, a details address and a log (up to 64 KB). A name listed in required_checks becomes required; until it is reported it shows as waiting for a report.

curl -X PUT -H "Authorization: Bearer $KEY" \
  https://api.ibel.ai/v1/functions/my-api/deployments/$BUILD/checks/ci%2Funit \
  -d '{"status":"passed","summary":"412 tests","url":"https://ci.example.com/run/88"}'

The names test, typecheck and smoke are reserved for the builder. A deployment has up to 30 checks.

Re-run and publish#

Re-run: the smoke check runs again; an external check goes back to waiting for a report; the test and the type check queue a new build of the same source. A passing report from the CI for a blocked build also puts it back to waiting.
Publish now (owner or admin): puts a waiting or blocked version live right away; it is written to the audit log.

CLI

cloudhost functions checks my-api            # the latest build
cloudhost functions checks rerun my-api $BUILD smoke
cloudhost functions checks promote my-api $BUILD

Dependency vulnerabilities#

Every build reads the project's root lockfile (package-lock.json, pnpm-lock.yaml or yarn.lock) and matches its packages against our advisory database. The result stays with each deployment: package, version, severity, advisory id and fixed version. The lockfile is only read, no code runs, and the scan needs no internet access. A project without a lockfile is not scanned, and its build says so.

The advisory database is our own copy of the public npm security advisories, refreshed every 6 hours from inside the platform. Each result says how old the data is; after 7 days without an update it is shown as out of date.

scan_fail_on fails a build whose dependencies have critical (critical) or critical and high (high) vulnerabilities, before it takes a build environment. Owners, admins and developers get a notification when a build is stopped, and another when serious findings are reported and the build goes on.

cloudhost functions vulns my-api            # the project's summary
cloudhost functions vulns my-api $BUILD     # one build's findings
cloudhost functions vulns rescan my-api $BUILD

Advisories are published after a build was made: a rescan matches that build's lockfile with today's data.