{"slug":"serverless-overview","title":"Serverless Containers","description":"DanubeData Serverless Containers lets you deploy containerized applications with automatic scaling, scale-to-zero, and pay-per-use pricing — powered by Knative on Kubernetes with zero infrastructure m...","section":"Features","url":"https://docs.danubedata.ro/serverless-overview","markdown_url":"https://docs.danubedata.ro/serverless-overview.md","breadcrumbs":[{"title":"Features","slug":null},{"title":"Rapids","slug":"serverless-overview"}],"headings":[{"level":1,"title":"Serverless Containers","id":"serverless-containers"},{"level":2,"title":"Key features","id":"key-features"},{"level":2,"title":"Deployment methods","id":"deployment-methods"},{"level":3,"title":"Docker image","id":"docker-image"},{"level":3,"title":"Git repository","id":"git-repository"},{"level":3,"title":"ZIP upload","id":"zip-upload"},{"level":2,"title":"Changing the deployment source","id":"changing-the-deployment-source"},{"level":2,"title":"How it works","id":"how-it-works"},{"level":3,"title":"Deployment pipeline","id":"deployment-pipeline"},{"level":3,"title":"Container statuses","id":"container-statuses"},{"level":3,"title":"Build statuses","id":"build-statuses"},{"level":2,"title":"Container access","id":"container-access"},{"level":2,"title":"Resource profiles","id":"resource-profiles"},{"level":2,"title":"Pricing","id":"pricing"},{"level":3,"title":"Free tier","id":"free-tier"},{"level":2,"title":"Scaling","id":"scaling"},{"level":3,"title":"Auto-scaling","id":"auto-scaling"},{"level":3,"title":"Scale-to-zero","id":"scale-to-zero"},{"level":3,"title":"Scheduled scaling","id":"scheduled-scaling"},{"level":2,"title":"Custom domains","id":"custom-domains"},{"level":3,"title":"Adding a domain","id":"adding-a-domain"},{"level":3,"title":"Domain verification","id":"domain-verification"},{"level":3,"title":"Connecting your domain","id":"connecting-your-domain"},{"level":3,"title":"Domain statuses","id":"domain-statuses"},{"level":3,"title":"Setting a primary domain","id":"setting-a-primary-domain"},{"level":2,"title":"Environment variables","id":"environment-variables"},{"level":2,"title":"Git webhooks","id":"git-webhooks"},{"level":3,"title":"Setting up webhooks","id":"setting-up-webhooks"},{"level":3,"title":"Webhook verification","id":"webhook-verification"},{"level":3,"title":"Auto-build on push","id":"auto-build-on-push"},{"level":2,"title":"Deployments and rollbacks","id":"deployments-and-rollbacks"},{"level":3,"title":"Viewing deployments","id":"viewing-deployments"},{"level":3,"title":"Rolling back","id":"rolling-back"},{"level":3,"title":"Traffic splitting","id":"traffic-splitting"},{"level":3,"title":"Startup work and rollouts","id":"startup-work-and-rollouts"},{"level":2,"title":"Builds","id":"builds"},{"level":3,"title":"Build configuration","id":"build-configuration"},{"level":3,"title":"Build actions","id":"build-actions"},{"level":3,"title":"Build logs","id":"build-logs"},{"level":3,"title":"Deploy failure reasons","id":"deploy-failure-reasons"},{"level":2,"title":"Monitoring","id":"monitoring"},{"level":3,"title":"Real-time metrics","id":"real-time-metrics"},{"level":3,"title":"Historical charts","id":"historical-charts"},{"level":3,"title":"Usage summary","id":"usage-summary"},{"level":2,"title":"Deploy failure alerts","id":"deploy-failure-alerts"},{"level":2,"title":"Networking","id":"networking"},{"level":3,"title":"Internal services","id":"internal-services"},{"level":3,"title":"Allowed outbound connections","id":"allowed-outbound-connections"},{"level":3,"title":"Security","id":"security"},{"level":2,"title":"Container limits","id":"container-limits"},{"level":2,"title":"Recommended images","id":"recommended-images"},{"level":2,"title":"Reserved ports","id":"reserved-ports"},{"level":2,"title":"Container actions","id":"container-actions"},{"level":2,"title":"FAQ","id":"faq"},{"level":3,"title":"What types of applications can I deploy?","id":"what-types-of-applications-can-i-deploy"},{"level":3,"title":"Do I need a Dockerfile?","id":"do-i-need-a-dockerfile"},{"level":3,"title":"How fast is a cold start?","id":"how-fast-is-a-cold-start"},{"level":3,"title":"Can I use a private container registry?","id":"can-i-use-a-private-container-registry"},{"level":3,"title":"How does billing work?","id":"how-does-billing-work"},{"level":3,"title":"Can I connect to my database from a serverless container?","id":"can-i-connect-to-my-database-from-a-serverless-container"},{"level":3,"title":"Can I use a custom domain?","id":"can-i-use-a-custom-domain"},{"level":3,"title":"How do rollbacks work?","id":"how-do-rollbacks-work"},{"level":3,"title":"What happens if my build fails?","id":"what-happens-if-my-build-fails"},{"level":3,"title":"Is there a request size limit?","id":"is-there-a-request-size-limit"},{"level":2,"title":"Next steps","id":"next-steps"}],"format":"markdown","word_count":4057,"content":"# Serverless Containers\n\nDanubeData Serverless Containers lets you deploy containerized applications with automatic scaling, scale-to-zero, and pay-per-use pricing — powered by Knative on Kubernetes with zero infrastructure management.\n\n## Key features\n\n- **Three deployment methods** — Pull a Docker image, connect a Git repository, or upload a ZIP file\n- **Switch source anytime** — Move an existing container between Docker image, Git repository, and ZIP upload from its Edit page, without recreating it\n- **Scale to zero** — Containers automatically scale down to zero replicas when idle, so you only pay for actual usage\n- **Automatic scaling** — Scales up instantly based on incoming traffic (requests per second or concurrency)\n- **Custom domains** — Bring your own domain with DNS verification and automatic TLS via Let's Encrypt\n- **Git auto-build** — Push to GitHub, GitLab, or Bitbucket and your container builds and deploys automatically\n- **Buildpacks** — Auto-detect your runtime (Node.js, Python, Go, Java, Ruby, PHP, .NET, Rust) without writing a Dockerfile\n- **Real-time metrics** — Monitor requests, latency, error rate, and replica count in the dashboard\n- **Environment variables** — Configure secrets and settings without rebuilding your container\n- **Traffic splitting** — Route traffic between revisions for canary deployments and A/B testing\n- **Scheduled scaling** — Pre-scale containers on a schedule for predictable traffic patterns\n- **Internal networking** — Access your team's databases and caches via internal cluster DNS\n- **EU data residency** — All data stored in Falkenstein, Germany (GDPR-compliant)\n\n## Deployment methods\n\n### Docker image\n\nDeploy a pre-built container image from any supported registry. Best for teams with existing CI/CD pipelines or pre-built images.\n\n**Supported registries:**\n\n| Registry | Host |\n|----------|------|\n| Docker Hub | `docker.io` |\n| GitHub Container Registry | `ghcr.io` |\n| Google Container Registry | `gcr.io` |\n| GitLab Container Registry | `registry.gitlab.com` |\n| Red Hat Quay | `quay.io` |\n| AWS Public ECR | `public.ecr.aws` |\n| Microsoft Container Registry | `mcr.microsoft.com` |\n\n**How it works:**\n\n1. Enter your image URL and tag (e.g., `docker.io/myorg/myapp:v1.2`)\n2. DanubeData validates the image exists and is pullable\n3. The image is deployed as a Knative Service in your team's namespace\n4. Your container is accessible at its auto-generated URL\n\n### Git repository\n\nConnect a GitHub, GitLab, or Bitbucket repository for automatic builds and deployments. Each push to your configured branch triggers a new build.\n\n- **Supported providers** — GitHub, GitLab, Bitbucket\n- **Authentication** — Public repos need no credentials. Private repos support SSH keys or access tokens.\n- **Auto-deploy** — Builds trigger automatically on push via webhooks\n- **Branch selection** — Deploy from any branch (defaults to `main`)\n\n**Build methods:**\n\n| Method | Description |\n|--------|-------------|\n| **Buildpacks** | Auto-detect your runtime and build without a Dockerfile. Supports Node.js, Python, Go, Java, Ruby, PHP, .NET, and Rust. |\n| **Dockerfile** | Use your own Dockerfile for full control over the build process. Configurable Dockerfile path and build context. |\n\n**Available buildpack builders:**\n\n| Builder | Runtimes |\n|---------|----------|\n| Paketo Base | Java, Node.js, Python, Go, Ruby, .NET |\n| Paketo Full | Extended language support |\n| Paketo Tiny | Go (minimal images) |\n| Google Cloud Buildpacks | Node.js, Python, Go, Java |\n| Heroku Builder 22 | Node.js, Python, Ruby, PHP, Go, Java |\n\n**Runtime auto-detection:**\n\n| File present | Detected runtime |\n|-------------|-----------------|\n| `package.json` | Node.js |\n| `requirements.txt`, `setup.py`, `pyproject.toml`, `Pipfile` | Python |\n| `go.mod` | Go |\n| `pom.xml`, `build.gradle` | Java |\n| `Gemfile` | Ruby |\n| `composer.json` | PHP |\n| `*.csproj`, `*.sln` | .NET |\n| `Cargo.toml` | Rust |\n\n### ZIP upload\n\nUpload your source code as a ZIP file via the API. DanubeData builds and deploys it using Buildpacks or your Dockerfile.\n\n- Maximum upload size: 500 MB\n- Supports both Buildpacks and Dockerfile builds\n- Ideal for CI/CD integration without Git provider webhooks\n- **Single-folder ZIPs are auto-unwrapped** — if you ran `zip -r app.zip myproject/` and everything sits inside one wrapper folder, DanubeData looks inside it automatically, so your `Dockerfile` or manifest files are still found. If a manifest is genuinely missing, the build error points you to the wrapper-folder fix.\n- **Editable build configuration** — after the first upload you can change the build settings from the Edit page: switch between Buildpacks and Dockerfile, change the Dockerfile path, the source subdirectory, or the buildpack builder. Saving rebuilds from your last uploaded ZIP.\n- **Your upload is retained** — the ZIP is stored so manual rebuilds and **Retry** don't require re-uploading the archive.\n\n```bash\ncurl -X POST \\\n  -H \"Authorization: Bearer YOUR_API_TOKEN\" \\\n  -F \"file=@source.zip\" \\\n  https://api.danubedata.ro/api/v1/serverless/{container-id}/deploy\n```\n\nAfter an upload starts building, the form is replaced with **Follow build** and **Cancel build** controls so it's clear a build is in progress.\n\n## Changing the deployment source\n\nYou are not locked into the deployment method you picked at creation. From a container's **Edit** page you can switch its source between **Docker image**, **Git repository**, and **ZIP upload** at any time — for example, start from a pre-built image and later connect a Git repo for auto-builds, or the other way around.\n\n- Your **cost baseline and deployment history carry over** cleanly across the switch — you keep the same container, URL, environment variables, custom domains, and usage record.\n- Switching **away** from a Git-connected source automatically stops that repository's push-to-deploy webhook from triggering new builds, so old pushes won't deploy over your new source.\n- After saving the new source, deploy as usual — the change takes effect on the next deployment.\n\n## How it works\n\n### Deployment pipeline\n\n```\nDocker Image / Git Push / ZIP Upload\n         |\n         v\n   Build Queued (Git/ZIP only)\n         |\n         v\n   Image Built (Tekton Pipeline)\n         |\n         v\n   Pushed to Registry\n         |\n         v\n   GitOps Commit (Knative Service YAML)\n         |\n         v\n   ArgoCD Sync\n         |\n         v\n   Container Running\n```\n\n1. **Source** — You provide a Docker image, push to a Git repo, or upload a ZIP file\n2. **Build** (Git/ZIP only) — A Tekton pipeline clones your code, builds an image using Buildpacks or Dockerfile, and pushes it to the DanubeData container registry\n3. **Deploy** — The serverless deployment service generates a Knative Service manifest and commits it to the GitOps repository\n4. **Sync** — ArgoCD detects the change and reconciles the Knative Service in your team's namespace\n5. **Live** — Your container is accessible at its URL with automatic TLS and auto-scaling\n\n### Container statuses\n\n| Status | Description |\n|--------|-------------|\n| **Pending** | Container created, waiting for first deployment |\n| **Deploying** | Deployment in progress via ArgoCD |\n| **Running** | Container is live and serving traffic |\n| **Stopped** | Container manually stopped (scaled to zero) |\n| **Error** | Deployment or runtime failure — check the error details |\n| **Degraded** | Container is partially operational |\n\nStatus changes are pushed to your dashboard in real time via WebSocket.\n\n### Build statuses\n\n| Status | Description |\n|--------|-------------|\n| **Pending** | Build queued, waiting for resources |\n| **Cloning** | Fetching source code from the repository |\n| **Building** | Building the container image |\n| **Pushing** | Uploading the built image to the registry |\n| **Succeeded** | Build completed, deployment starting |\n| **Failed** | Build failed — check build logs for details |\n| **Cancelled** | Build was cancelled before completion |\n\n## Container access\n\nEach container is accessible at an auto-generated URL:\n\n```\nhttps://{container-slug}-{team-name}.danubedata.run\n```\n\nThe slug is derived from your container name. You can also add custom domains for branded URLs.\n\n## Resource profiles\n\n| Profile | vCPU (request - limit) | Memory (request - limit) | Best for |\n|---------|----------------------|-------------------------|----------|\n| **Free** | 0.01 - 0.1 | 64 - 128 MB | Trying the platform, webhooks (max 3 replicas) |\n| **Small** | 0.5 - 1 | 256 - 512 MB | Standard APIs, workers |\n| **Medium** | 1 - 2 | 512 MB - 1 GB | Data processing, batch jobs |\n| **Large** | 2 - 4 | 1 - 2 GB | Heavy compute workloads |\n\nProfiles have no fixed monthly fee — you pay only for what you use (see Pricing below).\n\n## Pricing\n\nServerless containers use pay-per-use pricing. You are billed for actual compute time, not idle time.\n\n| Metric | Price |\n|--------|-------|\n| **vCPU-second** | EUR 0.000015 (~EUR 0.054/vCPU-hour) |\n| **Memory (GiB)-second** | EUR 0.0000025 |\n| **Requests** | EUR 0.15 per million |\n| **Egress traffic** | EUR 0.09 per GB |\n| **Minimum billing increment** | 100 ms |\n\n### Free tier\n\nEvery account includes a generous free tier:\n\n| Metric | Free allowance |\n|--------|---------------|\n| **Requests** | 2,000,000 per month |\n| **vCPU-seconds** | 250,000 per month (~69 vCPU-hours) |\n| **Memory (GiB)-seconds** | 500,000 per month (~139 GiB-hours) |\n| **Egress** | 5 GB per month |\n\nBilling is recorded every 5 minutes based on actual resource consumption. Monthly invoices are generated on the 1st of each month, and your free allowances reset at the same time.\n\nGoing over a free allowance **never suspends or throttles your container** — usage simply becomes billable at the pay-per-use rates above. The usage meters in the dashboard are there for visibility, not enforcement. The **Usage & Billing** tab on each container shows your included allowances alongside a clear Used / Billable / Charge breakdown, so you can see at a glance whether anything is billable this month.\n\n## Scaling\n\n### Auto-scaling\n\nContainers scale automatically based on incoming traffic. Two scaling metrics are available:\n\n| Metric | Description | Default target |\n|--------|-------------|---------------|\n| **RPS** (requests per second) | Scales based on throughput per pod. Recommended for most workloads. | 100 RPS/pod |\n| **Concurrency** | Scales based on simultaneous in-flight requests per pod. | 100 concurrent/pod |\n\n**Scaling parameters:**\n\n| Parameter | Default | Range | Description |\n|-----------|---------|-------|-------------|\n| Min replicas | 0 | 0 - 100 | Minimum running instances. Set to 0 for scale-to-zero. |\n| Max replicas | 10 | 1 - 100 | Maximum instances during traffic spikes. |\n| Scaling target | 100 | 1+ | Target value for the selected scaling metric. |\n| Idle timeout | 5 min | Fixed | Time before scaling to zero after last request. |\n| Cooldown period (scale-down delay) | 5 min | 0s - 1h, per container | How long a revision keeps its instances after losing traffic. See [Startup work and rollouts](#startup-work-and-rollouts). |\n| Initial scale | Platform default (effectively 1) | 0 - max replicas, per container | Instances a new revision starts with before it counts as ready. See [Startup work and rollouts](#startup-work-and-rollouts). |\n\n### Scale-to-zero\n\nWhen min replicas is set to 0 (the default), your container scales to zero after 5 minutes of inactivity. This means:\n\n- No compute charges during idle periods\n- First request after idle triggers a cold start (typically 1-5 seconds)\n- Set min replicas to 1 or higher to avoid cold starts\n\n### Scheduled scaling\n\nConfigure time-based scaling rules for predictable traffic patterns. For example, scale up during business hours and back down at night.\n\nEach schedule defines:\n- **Days of week** — Which days the schedule applies\n- **Start and end time** — When the scaling rule is active (HH:MM format)\n- **Minimum replicas** — The minimum replica count during this window\n- **Timezone** — Any IANA timezone (e.g., `Europe/Berlin`)\n\nOvernight schedules (e.g., 22:00 to 06:00) are supported.\n\n## Custom domains\n\nAdd up to 10 custom domains per container with automatic TLS.\n\n### Adding a domain\n\n1. Navigate to the container detail page\n2. Click **Manage Domains** from the Actions dropdown\n3. Click **Add Domain**\n4. Enter your domain (e.g., `api.example.com`)\n\n### Domain verification\n\nAfter adding a domain, verify ownership by creating a DNS TXT record:\n\n- **Record name** — `_danubedata-verify.your-domain.com`\n- **Record value** — The verification token shown in the dashboard\n\nDNS propagation may take a few minutes. Click **Verify** to check.\n\n### Connecting your domain\n\nAfter verification, create a CNAME record pointing to your container URL:\n\n```\napi.example.com  CNAME  my-api-acme.danubedata.run\n```\n\nA TLS certificate is provisioned automatically via Let's Encrypt once the CNAME is in place.\n\n### Domain statuses\n\n**Verification:**\n\n| Status | Description |\n|--------|-------------|\n| **Pending** | Awaiting DNS TXT record |\n| **Verifying** | DNS check in progress |\n| **Verified** | Domain ownership confirmed |\n| **Failed** | Verification failed — check DNS records |\n\n**TLS:**\n\n| Status | Description |\n|--------|-------------|\n| **Pending** | Awaiting certificate provisioning |\n| **Provisioning** | Certificate being generated |\n| **Active** | HTTPS active with valid certificate |\n| **Failed** | Certificate provisioning failed |\n\n**Deployment:**\n\n| Status | Description |\n|--------|-------------|\n| **Pending** | Domain not yet deployed to the container |\n| **Deploying** | Domain being added to the Knative Service |\n| **Active** | Domain is live and routing traffic |\n| **Removing** | Domain being removed |\n| **Failed** | Domain deployment failed |\n\n### Setting a primary domain\n\nDesignate any verified domain as the primary domain. The primary domain is used as the canonical URL for your container.\n\n## Environment variables\n\nConfigure your container with environment variables for secrets, connection strings, and application settings.\n\n- Maximum 100 variables per container\n- Maximum key length: 256 characters\n- Maximum value length: 10,000 characters\n- Maximum total size: 100 KB\n- Variables are encrypted at rest and injected at container startup\n\n**Adding variables:**\n\n1. Navigate to the container **Edit** page\n2. Scroll to **Environment Variables**\n3. Add key-value pairs\n4. Save and redeploy\n\nValues are masked by default in the editor; authorized users can reveal and edit\nthem. Each container has its own runtime environment, so use separate containers\nfor development and production secrets. Build-time configuration is separate.\n\nRapids does not automatically scrub values that your application or build scripts\nprint. Avoid logging secrets, request bodies, patient details or sensitive query\nparameters, and keep credentials out of image layers and frontend bundles.\n\n## Git webhooks\n\nWhen using Git repository deployment, DanubeData generates a webhook URL and secret for automatic builds.\n\n### Setting up webhooks\n\n1. Navigate to the container detail page\n2. Go to the **Activity** tab\n3. Copy the **Webhook URL** and **Webhook Secret**\n4. In your Git provider settings, add a webhook:\n   - **URL** — The webhook URL from the dashboard\n   - **Secret** — The webhook secret from the dashboard\n   - **Events** — Push events only\n\n### Webhook verification\n\n| Provider | Signature header | Method |\n|----------|-----------------|--------|\n| **GitHub** | `X-Hub-Signature-256` | HMAC-SHA256 |\n| **GitLab** | `X-Gitlab-Token` | Token comparison |\n| **Bitbucket** | `X-Hub-Signature` | HMAC-SHA256 |\n\n### Auto-build on push\n\nWhen enabled, every push to the configured branch triggers a build and deployment automatically. Disable auto-build from the container edit page if you prefer manual deployments.\n\n## Deployments and rollbacks\n\nEvery deployment creates a new revision. Your deployment history shows all revisions with their status, image, and sync state. A rollout that gets stuck times out and resolves on its own instead of hanging indefinitely — the failed revision is marked, and your previously healthy version keeps serving.\n\n### Viewing deployments\n\nBuilds and deployments share a single **Activity** tab on the container detail page. Navigate to the container detail page and click the **Activity** tab.\n\nEach deployment shows:\n- Revision name (e.g., `my-api-00007`)\n- Container image\n- ArgoCD sync and health status\n- Creation and sync timestamps\n- Traffic percentage\n\n### Rolling back\n\nTo revert to a previous deployment:\n\n1. Open the **Activity** tab\n2. Find the revision you want to restore\n3. Click **Route traffic here** and confirm the request\n\nRapids checks that the retained revision is ready, then requests 100% of traffic\nfor that revision. The request remains pending until the platform observes the\nnew traffic destination; it does not mark the revision current merely because the\nrequest was submitted. No rebuild or new revision is needed. A missing or unready\nrevision cannot be selected.\n\nThis changes traffic routing. It does not restore database contents or previous\nsecret values. For a new rollout from an earlier image using current settings,\nuse **Redeploy** on a retained successful build instead. A subsequent normal\ndeployment resumes routing to its new ready revision.\n\n### Traffic splitting\n\nSplit traffic between multiple revisions for canary deployments or A/B testing. Navigate to the container detail page to view the current traffic distribution across revisions.\n\n### Startup work and rollouts\n\nBy default, a rollout briefly runs two revisions at once: your new revision starts an instance and has up to five minutes to become ready, while the previous revision keeps its own instances running for five minutes after it stops receiving traffic. For most containers this overlap is invisible. It matters if your container does work on startup — running database migrations, warming a cache — because that work then runs on **both** revisions, including right after a deployment that also changes **Minimum Replicas** from 1 back down to 0.\n\nTwo settings on the **Edit** page (and the API) give you control over that overlap:\n\n| Setting | What it controls | Default | Trade-off |\n|---------|-------------------|---------|-----------|\n| **Initial Scale** (`initial_scale`) | How many instances a new revision starts with before it counts as ready. The platform uses whichever is larger, Initial Scale or Minimum Replicas. | Platform default (effectively 1) | Set to **0** together with **Minimum Replicas 0** and a revision can become ready without ever starting an instance — cold start moves to the first request instead of the rollout. If your image is broken, you find out on that first request rather than immediately after deploying. |\n| **Scale-Down Delay** (`scale_down_delay_seconds`) | How long the previous revision keeps its instances after the new one takes over traffic. | 5 minutes | Set to **0** and the old revision's instances are released as soon as the new one takes traffic, instead of five minutes later. |\n\n**For a container that runs migrations or other startup work and scales to zero**, set Initial Scale to `0` and Scale-Down Delay to `0`. The old revision releases its instances as soon as the new one takes over, and the new revision does not start an instance — and does not run your startup work — until its first request arrives, so the two revisions' startup work never overlaps.\n\nLeave both unset to keep the platform defaults described above.\n\n## Builds\n\nFor Git and ZIP deployments, builds are executed via Tekton pipelines in a dedicated build namespace.\n\n### Build configuration\n\n| Setting | Default | Description |\n|---------|---------|-------------|\n| **Build timeout** | 30 minutes | Maximum build duration |\n| **Max concurrent builds** | 3 per team | Parallel builds allowed |\n| **Max builds per day** | 50 per team | Daily build limit |\n| **Build log access** | 10 days after completion | History metadata is separate from log output |\n\n### Build actions\n\n- **Trigger build** — Start a new build manually from the Actions dropdown\n- **Cancel build** — Stop an in-progress build\n- **Retry build** — Retry a failed build with the same configuration\n- **Redeploy build** — Deploy a previously successful build without rebuilding\n\n### Build logs\n\nBuild logs stream live from the **Activity** tab as your container builds and refresh on their own — no manual reload. You get the **full build output** (there is no 500-line cap). Logs include the clone, build, and push stages.\n\nCompleted build output expires after ten days. Stored build text is removed by\nhourly cleanup; build history metadata remains. See [Logs](https://docs.danubedata.ro/monitoring-logs)\nfor the scope of the retention policy.\n\n### Deploy failure reasons\n\nWhen a deploy fails, the container shows a plain-language reason instead of a raw error, each with a hint on how to fix it. Common reasons:\n\n| Reason | What it usually means |\n|--------|----------------------|\n| **Architecture mismatch** | The image was built for the wrong CPU architecture (e.g. `arm64` from an Apple Silicon Mac). Rebuild for `linux/amd64`. |\n| **Image or tag not found** | The referenced image or tag doesn't exist or isn't pullable — check the spelling and that the push finished. |\n| **Out of memory** | The container exceeded its memory limit at startup — move up a resource profile or reduce memory use. |\n| **Startup timed out** | The application didn't become ready in time — make sure it listens on the configured port and starts promptly. |\n\n## Monitoring\n\n### Real-time metrics\n\nThe container detail page shows live metrics:\n\n- **Total requests** — Cumulative request count with sparkline trend\n- **Current replicas** — Active pod count vs. max scale\n- **Average latency** — Response time in milliseconds\n- **Error rate** — Percentage of 5xx responses\n\n### Historical charts\n\nThe Overview tab includes time-series charts for:\n- Request rate\n- Average latency\n- Replica count\n- Error rate\n\n### Usage summary\n\nMonthly usage tracked per container:\n- Average CPU (millicores)\n- Average memory (MB)\n- Total requests\n- Total compute seconds\n- Total cost\n\n## Deploy failure alerts\n\nDanubeData continuously watches your running containers — not just the first rollout. If a new revision fails to deploy while your last healthy version keeps serving, the container is flagged **Degraded** and your team is notified so a bad deploy never goes unnoticed.\n\n- **Email alerts** — your team gets an email the moment a container runs into trouble, with the failure reason and a link to investigate.\n- **Auto-recovery** — a container that recovers on its own (for example, a later revision succeeds) clears automatically back to healthy; no action needed.\n- **`serverless.build_failed` webhook** — if you have webhooks enabled, build failures are also delivered to your own tooling so you can wire them into your existing alerting.\n\nBecause your previously healthy revision keeps serving throughout, a failed deploy does not take your container offline.\n\n## Networking\n\n### Internal services\n\nServerless containers can access your team's databases and caches using internal cluster DNS:\n\n```\n{service-name}.tenant-{team-name}.svc.cluster.local\n```\n\nFor example:\n```\nmy-database.tenant-acme.svc.cluster.local:3306   # MySQL\nmy-cache.tenant-acme.svc.cluster.local:6379       # Redis\n```\n\nPass connection strings as environment variables.\n\n### Allowed outbound connections\n\n| Port | Service |\n|------|---------|\n| 80 | HTTP |\n| 443 | HTTPS |\n| 3306 | MySQL |\n| 5432 | PostgreSQL |\n| 6379 | Redis |\n| 27017 | MongoDB |\n\n### Security\n\nContainers run with strict security policies:\n\n- Non-root execution (UID 1000)\n- Read-only root filesystem\n- No privilege escalation\n- All Linux capabilities dropped\n- Seccomp profile: RuntimeDefault\n- Blocked access to cloud metadata services\n- Blocked access to Kubernetes API\n\n## Container limits\n\n| Limit | Value |\n|-------|-------|\n| **Containers per team** | 50 |\n| **Containers per user** | 10 |\n| **Max request body** | No platform-imposed limit (tested up to 500 MB; in practice bounded by your request timeout and upstream upload speed) |\n| **Max response body** | No platform-imposed limit (streamed through the gateway; bounded by your request timeout) |\n| **Request timeout** | 300 seconds (default); configurable per container up to 3600 seconds (1 hour) from the edit page |\n| **Environment variables** | 100 per container, 100 KB total |\n| **Custom domains** | 10 per container |\n| **Revisions kept** | 50 per container |\n| **Revision retention** | 90 days |\n| **Ephemeral storage** | 1 GB per container |\n\n## Recommended images\n\nDanubeData provides pre-vetted images for common runtimes:\n\n| Runtime | Image | Default port |\n|---------|-------|-------------|\n| **Node.js** | `docker.io/library/node:20-alpine` | 3000 |\n| **Python** | `docker.io/library/python:3.12-slim` | 8000 |\n| **Go** | `docker.io/library/golang:1.22-alpine` | 8080 |\n| **Nginx** | `docker.io/library/nginx:alpine` | 80 |\n| **PHP** | `docker.io/library/php:8.3-fpm-alpine` | 9000 |\n| **Ruby** | `docker.io/library/ruby:3.3-slim` | 3000 |\n\n## Reserved ports\n\nThe following ports are reserved by the platform's Knative queue-proxy sidecar. Do not configure your container to listen on any of these — your application will fail to start with `bind: address already in use`:\n\n| Port | Used for |\n|------|----------|\n| 8012 | Knative queue-proxy readiness probe |\n| 8013 | Knative queue-proxy serving |\n| 8022 | Knative queue-proxy admin / profiling |\n| 8112 | Knative queue-proxy serving (TLS) |\n| 9090 | Knative queue-proxy Prometheus metrics |\n\nWe recommend `8080` (the default) for your application port.\n\n## Container actions\n\n| Action | Description | Available when |\n|--------|-------------|---------------|\n| **Start** | Start a stopped container | Status: stopped |\n| **Stop** | Scale to zero and stop serving traffic | Status: running |\n| **Restart** | Stop and start the container | Status: running |\n| **Redeploy** | Pull latest image and create a new revision (Docker image only) | Status: running, stopped, error |\n| **Build & Deploy** | Trigger a new build from source (Git only) | Any status |\n| **Delete** | Permanently delete the container and all revisions | Any status |\n\nBulk operations (start, stop, delete) are available from the container list page for up to 25 containers at once.\n\n## FAQ\n\n### What types of applications can I deploy?\n\nAny application that runs in a Docker container and listens on an HTTP port. This includes REST APIs, GraphQL servers, web applications, webhook receivers, background workers, and microservices.\n\n### Do I need a Dockerfile?\n\nNo. If you use Git repository deployment with Buildpacks, DanubeData auto-detects your runtime and builds the image without a Dockerfile. Buildpacks support Node.js, Python, Go, Java, Ruby, PHP, .NET, and Rust.\n\n### How fast is a cold start?\n\nCold start time depends on your image size and application startup time. Typical cold starts are 1-5 seconds. Use slim or Alpine base images and minimize initialization work to reduce cold start latency. Set min replicas to 1 to avoid cold starts entirely.\n\n### Can I use a private container registry?\n\nThe platform supports pulling from Docker Hub, GitHub Container Registry, GitLab Registry, Quay, AWS ECR, and Google Container Registry. For Git deployments, images are built and stored in the DanubeData container registry automatically.\n\n### How does billing work?\n\nYou are billed for actual compute time (vCPU-seconds and memory-GiB-seconds), requests, and egress traffic. When your container is scaled to zero, you incur no compute charges. The free tier covers 2M requests and ~69 vCPU-hours per month.\n\n### Can I connect to my database from a serverless container?\n\nYes. Serverless containers can access databases and caches in your team's namespace using internal cluster DNS. Pass the connection string as an environment variable.\n\n### Can I use a custom domain?\n\nYes. You can add up to 10 custom domains per container with automatic TLS via Let's Encrypt. Domain verification requires a DNS TXT record.\n\n### How do rollbacks work?\n\nEach deployment creates a revision. In the Activity tab, choose **Route traffic\nhere** on a retained ready revision. Rapids requests the traffic switch and\nconfirms it after observing the live destination. This requires no rebuild and\ndoes not reverse database changes or restore previous secrets. Redeploying a\nretained successful build is a separate action that creates a new rollout.\n\n### What happens if my build fails?\n\nYour current live deployment remains active. Failed builds do not affect the running container. Check the build logs for error details and retry.\n\n### Is there a request size limit?\n\nThere is no platform-imposed body size limit today; uploads and downloads stream through the gateway and are bounded only by your request timeout and network speed. We have validated transfers up to 500 MB. The default request timeout is 300 seconds, configurable per container up to 3600 seconds (1 hour) from the edit page.\n\n## Next steps\n\n- [Invoking containers](https://docs.danubedata.ro/serverless-invoking) — Code examples in cURL, JavaScript, Python, PHP, and Go\n- [Authentication](https://docs.danubedata.ro/serverless-authentication) — Secure your container endpoints\n- [Custom domains](https://docs.danubedata.ro/serverless-domains) — DNS verification and TLS setup\n- [Git deployments](https://docs.danubedata.ro/serverless-git) — Webhooks and auto-build\n\n---\n\n**Questions?** Contact support at support@danubedata.ro\n","prev":{"title":"Git Deployments","slug":"static-sites-git","url":"https://docs.danubedata.ro/static-sites-git","markdown_url":"https://docs.danubedata.ro/static-sites-git.md","json_url":"https://docs.danubedata.ro/static-sites-git.json"},"next":{"title":"Quick Start","slug":"serverless-quickstart","url":"https://docs.danubedata.ro/serverless-quickstart","markdown_url":"https://docs.danubedata.ro/serverless-quickstart.md","json_url":"https://docs.danubedata.ro/serverless-quickstart.json"},"index_url":"https://docs.danubedata.ro/index.json"}