Apps
An app is a deployable unit that runs as a containerised workload. Apps can be connected to databases, object storage, and custom domains.
Service types
Section titled “Service types”When creating an app, you choose a service type:
| Service type | Description |
|---|---|
| Generic app | A standard container workload. You bring the image and configuration. |
| WordPress | Manual or Automated WordPress with managed MySQL and Varnish. |
Source types
Section titled “Source types”Apps can be created from several sources. The source type determines how the container image is built and updated:
| Source type | Description |
|---|---|
| Container image | A pre-built image from any public or private registry (e.g. nginx:latest, myrepo/app:v2). |
| GitHub | A Git repository linked via the GitHub integration. The platform builds and deploys on every push when auto-deploy is enabled. |
| GitLab | A Git repository linked via the GitLab integration. Works the same as GitHub - webhook-triggered builds. |
| Upload | Upload a .tar.gz, .tgz, or .zip archive (max 50 MB). The platform builds a container and deploys it. |
The source type is set at creation and determines how redeployments work. Git-based apps rebuild the source; image-based apps simply restart with the new image tag.
Resource tiers
Section titled “Resource tiers”Every app runs with a configurable resource tier that sets CPU and memory limits:
| Tier | CPU | Memory | Best for |
|---|---|---|---|
| Micro | 0.5 vCPU | 512 Mi | Small apps and testing. |
| Small | 1 vCPU | 1 Gi | Low-traffic applications. |
| Medium | 2 vCPU | 2 Gi | Most production workloads. |
| Large | 4 vCPU | 4 Gi | High-traffic applications. |
| X-Large | 8 vCPU | 8 Gi | Demanding workloads. |
You can change the resource tier at any time from the app settings. The platform performs a rolling update to apply the new limits.
Scaling
Section titled “Scaling”Apps can be scaled horizontally by changing the replica count from the app overview. A higher replica count spreads traffic across multiple containers.
To adjust the replica count, you need the app.scale permission.
Deployment
Section titled “Deployment”Deployment is the process of getting your app’s container running on the platform.
Initial deployment
Section titled “Initial deployment”When you create an app, the platform:
- Provisions the required Kubernetes resources (ConfigMap, secrets, pull secrets).
- For GitHub, GitLab, or upload sources: starts a build job that produces a container image.
- Installs or upgrades the Helm chart with your configured resources, env vars, and domains.
- Waits for the rollout to complete.
Deployment progress is shown in real time via server-sent events (SSE) in the dashboard.
Redeploying
Section titled “Redeploying”Redeploy an app to pick up image changes, new env vars, or configuration updates:
- Git-based apps: triggers a new build from the linked repository, then deploys the resulting image.
- Image-based apps: performs a Helm upgrade with the current configuration and image reference.
- Upload apps: upload a new archive to rebuild.
Redeployments create a deployment record in the database so you can track build and deploy status over time.
Auto-deploy
Section titled “Auto-deploy”Git-based apps can enable auto-deploy. When enabled, a push to the linked branch triggers a build and deployment automatically via webhook.
Health checks
Section titled “Health checks”The platform performs liveness and readiness probes on every app container. If a health check fails:
- The container is restarted automatically (liveness).
- Traffic is paused until the container reports healthy (readiness).
You do not need to configure health checks manually for standard HTTP workloads. The platform uses sensible defaults.
Persistence
Section titled “Persistence”Apps can be configured with persistent storage that survives restarts and redeployments:
- Enable persistence from the app settings.
- Set a storage size (e.g.
1Gi,10Gi). - Set a mount path where the volume appears inside the container.
- The access mode defaults to
ReadWriteOnce.
Persistent volumes are useful for stateful apps that need filesystem storage.
WordPress specifics
Section titled “WordPress specifics”See WordPress for shared settings, Manual for WP Admin and SFTP, or Automated for Git and container deployments.
End-user optics and analytics
Section titled “End-user optics and analytics”WordPress apps support built-in analytics and end-user optics tracking via the rab-analytics plugin. Toggle these features on or off from the app’s Analytics and Optics tabs without redeploying.
Starting and stopping
Section titled “Starting and stopping”You can start and stop apps from the dashboard. A stopped app scales to zero and consumes no compute resources, but its configuration and persistent storage are preserved. You need the app.start_stop permission.
Deleting an app
Section titled “Deleting an app”Deleting an app removes its Helm release, ConfigMaps, secrets, object storage archives, and - for WordPress - the associated MySQL database and ProxySQL registration. This action is permanent.
You need the app.delete permission.