Apps
An app represents a single deployable service — a Git repo or Docker image that canette builds and runs in your cluster.
An app represents a single deployable service backed by a Git repository or a Docker image. It lives inside a project and is the unit that gets built, deployed, and monitored.
What defines an app
- Source — a Git repository (built on every deploy) or a pre-built Docker image
- Branch — which branch to track (default:
main) - App path — subdirectory within the repo (for monorepos)
- Port — the port your process listens on
- Git credential — optional credential for private repos
- Environment variables — plaintext key-value pairs injected at runtime
- Secrets — encrypted environment variables, never returned by the API after being set
Deployment type
Every app has a deployment type that controls what Kubernetes resources are created and whether a public URL exists:
| Setting | Kubernetes resources | Access |
|---|---|---|
Public (web, default) | Deployment + Service + HTTPRoute | Reachable at https://<app>-<project>.<cluster-domain> |
Private (private) | Deployment + Service only | Reachable inside the cluster at <slug>.<namespace>.svc.cluster.local |
Scheduled (cronjob) | CronJob | Not reachable — runs on a schedule, then exits |
Set the deployment type in the Visibility toggle on the app creation or settings page. It can also be set via deployment_type in a template, or web/private overridden per-deployment by setting ingress.enabled: false in canette.yaml.
Use Private for databases, internal APIs, message brokers, or any service that should not be exposed through the gateway. Use Scheduled for batch jobs, cleanup tasks, or anything that should run on a cron schedule instead of serving traffic — it requires a schedule (a standard 5-field cron expression, e.g. 0 2 * * *, or a predefined schedule like @daily) and does not accept a port — canette does not inject PORT into scheduled apps since there's no server to listen on.
Changing the deployment type takes effect on the next deployment — existing live resources are not updated until you redeploy.
Lifecycle
An app goes through the following states when you trigger a deploy:
pending → building → deploying → live
↘ failedSee Deployments for details.