Features¶
An overview of what's available on the CheesyServe SaaS today, with more detail on each capability below.
Overview¶
-
Deploy any container image from a public or private registry.
-
Organize workloads into projects, with isolated environments underneath each one.
-
Every deploy is a release — roll back to a previous one if something goes wrong.
-
Expose a workload publicly over HTTPS, or keep it internal-only. HTTP, gRPC, and WebSockets are all supported.
-
Provision a Postgres database for your workload directly on the platform.
-
Config & environment variables
Attach configuration to a workload without rebuilding the image.
-
Store sensitive values and private registry credentials, kept separate from plain configuration.
-
Attach your own domain to a publicly exposed workload, with HTTPS handled for you.
-
Choose how much compute a workload gets, and let it scale automatically under load.
-
Built-in dashboards and a log viewer — no separate observability stack to run.
-
Track changes made across a project.
-
Isolated environments with per-environment quotas and access control.
Deployment¶
Bring your own image¶
Deploy any container image from a public or private registry — Docker Hub, GHCR, a private registry, anywhere your image already lives. There's no buildpack step and no required base image: whatever runs in your container runs on CheesyServe.
Projects & environments¶
Workloads live inside projects, and each project can have multiple environments — for example staging and production. Environments are fully isolated from one another: separate namespace, separate quotas, separate configuration. Promoting a change from staging to production means deploying the same image to a different environment, not rebuilding anything.
Releases¶
Every deploy creates a new release. CheesyServe keeps the history of releases for a workload, so if a deploy introduces a problem you can roll back to the last known-good release rather than scrambling to redeploy an older build by hand.
Flexible networking¶
A workload can be exposed publicly over HTTPS, or kept strictly internal so it's only reachable by other workloads in the same environment. Beyond plain HTTP, workloads can also serve gRPC and WebSocket traffic — useful for streaming APIs, real-time features, or internal service-to-service calls.
Data¶
Managed PostgreSQL¶
Provision a PostgreSQL database for your workload directly on the platform, without standing up and operating your own database server. Connection details are made available to your workload as configuration, so there's nothing extra to wire up.
Configuration & secrets¶
Config & environment variables¶
Attach environment variables and configuration values to a workload independently of its image, so you can change configuration — a feature flag, an external API URL — without rebuilding or re-pushing the image.
Secrets¶
Sensitive values (API keys, tokens, database credentials) are stored as secrets, kept separate from plain configuration so they're never shown in logs or exports the way regular config might be. Private registry credentials are also managed as secrets, so a workload can pull from an authenticated registry without the credentials living anywhere in your image or repo.
Networking¶
Custom domains¶
A publicly exposed workload gets a default CheesyServe domain automatically, but you can attach your own custom domain instead. HTTPS/TLS for the domain is handled for you — there's no certificate to generate or renew by hand.
Scaling¶
Sizing & autoscaling¶
Choose how much CPU and memory a workload gets, independent of other workloads in the same environment. On top of a fixed size, autoscaling can add or remove replicas automatically as load changes, so a workload scales up during a traffic spike and back down once it passes.
Observability¶
Metrics & logs¶
Every workload comes with built-in metrics (CPU, memory, request activity) and a log viewer, both accessible directly from the platform — there's no separate monitoring stack to deploy and maintain just to see how your workload is doing.
Audit log¶
Changes made across a project — who deployed what, when a configuration changed, who added or removed access — are recorded in an audit log, so you have a record to refer back to beyond what's in your own deploy history.
Multi-tenancy¶
Each environment is isolated with its own resource quotas, so one team's or project's workloads can't starve another's of CPU, memory, or other resources. Access to a project — who can view it, who can deploy to it, who can manage it — is controlled per project, so teams can share a CheesyServe account without stepping on each other.