Use a serverless container for HTTP traffic and a finite run for work that should start, finish and report an exit status. Add a schedule when that finite command must repeat. A cron expression chooses when to start work; it does not turn a web server into a reliable batch processor.
That distinction is especially useful when the same codebase serves an API and also contains migrations, reports or cleanup commands. Reusing one image is practical. Reusing one lifecycle for every task causes duplicated startup work, lost background promises and jobs that never terminate.
Choose by lifecycle, then check the limits
| Workload | Starting choice | Completion signal |
|---|---|---|
| API, webhook receiver or web app | HTTP serverless container | Response status and request metrics |
| Migration, backfill or bounded export | Finite Run | Terminal run state, exit code and business outcome |
| Daily report or hourly cleanup | Schedule invoking a finite Run | Each occurrence’s result plus expected output |
| Continuous queue consumer | A supervised worker environment appropriate to the queue | Consumer health, acknowledgements and backlog |
| Work exceeding the Run timeout | Resumable smaller tasks or another execution environment | Durable checkpoint and final completion record |
On DanubeData, Rapids provides the HTTP container model. Rapids Runs executes that container’s image as a separate finite job. As of 1 November 2026, the Runs documentation describes preview access for selected accounts; confirm availability and limits for your project before making it a production dependency.
HTTP containers: requests determine the useful work
A web container starts an HTTP server, listens on its configured port, and returns responses. Replicas may scale with incoming traffic and may scale to zero when configured to do so. Application state that must survive a process exit belongs in an appropriate durable system, rather than in process memory.
A webhook receiver belongs here because a remote sender needs an HTTPS endpoint. Authenticate each delivery, validate its payload, commit it to a database or durable queue, then acknowledge it. If processing takes longer than the sender’s deadline, a later worker handles the accepted event. Starting an untracked task after returning success does not establish durable responsibility.
Scale-to-zero introduces a possible idle-to-active startup delay. Image size, runtime startup, networking and dependencies affect that delay, so do not promise instant cold starts or treat a successful local request as a latency guarantee. If predictable response time requires warm replicas, evaluate the cost of a minimum scale and measure the real application.
Keep startup free of unguarded migrations or destructive cleanup. Multiple replicas and revisions can start, and a process can restart. Any action that must happen once for a release needs its own coordination. The Rapids automation guide also explains that old and new revisions can overlap and maximum scale applies per revision, so calculate dependency capacity for rollout overlap.
Finite Runs: the process exit is part of the contract
A Run starts the parent container’s image with a finite command. It does not create an HTTP endpoint for that job, and it does not replace the normal replicas serving traffic. The command should perform a bounded unit of work, commit its outcome and exit zero for success or non-zero for failure. The tracked state lets an operator distinguish acceptance from completion.
Typical commands include python report.py --date 2026-10-31, node scripts/backfill.mjs --batch 1000 or a framework’s migration command. The image must actually contain that executable and script. A command override cannot install missing code or change the run to an unrelated image repository.
Always provide an intentional command for a web image. Omitting it usually runs the HTTP server, which waits for traffic instead of completing the maintenance task. That consumes resources until cancellation or timeout and prevents another run on the same container. A process that started successfully but never reaches its intended operation is not a successful batch job.
Run commands are argument arrays in the API. They are not shell expressions. Pipes, redirects and variable expansion require an explicitly invoked shell, which also introduces quoting and injection risks. Prefer the direct executable and separate arguments, especially when any input originates outside your deployment system.
{
"command": ["python", "report.py", "--date", "2026-10-31"],
"timeout_seconds": 900
}Submit that body to POST /api/v1/serverless/{container_id}/runs using your authorised token. A 202 response means the request was accepted, not that Python succeeded. Poll the run resource until terminal is true, then examine its status and outcome. Retain the run ID in your deployment or reporting record.
Schedules: timing, overlap and replay are separate concerns
A schedule combines a five-field cron expression, an IANA timezone and a finite command. For example, 0 6 * * * in Europe/Bucharest asks for 06:00 local time each day. A named timezone tracks seasonal offsets; a fixed UTC offset does not express the same year-round local-time rule. Avoid ambiguous overnight transition hours if the task needs one predictable local-time occurrence.
Rapids schedules live in the parent container’s Runs tab. The documented API path is /api/v1/serverless/{container_id}/schedules, and the CLI exposes danube rapids schedules create. Consult the installed CLI help for its flags. Creating a schedule is not evidence that an occurrence ran: inspect the generated runs and the expected business output.
The current model permits one queued or running Run per container. A second manual start returns 409. If a scheduled occurrence becomes due while the previous run is still active, that occurrence is skipped, its skip information is recorded, and the schedule moves to the next occurrence. The skipped occurrence is not automatically replayed.
Scheduled runs inherit the container environment. Unlike a one-off run, a saved schedule takes no environment overrides. Store secrets in the container configuration through your approved workflow, rather than embedding them in a command. If you change a container setting, review its effect on future HTTP replicas and scheduled work that shares that image and environment.
The timezone chooses an execution time; it does not choose your report’s business period. Compute dates with the same named timezone, use explicit dates for backfills, and reconcile missing periods. For billing exports or accounting tasks, a durable completion ledger is more useful than assuming every cron tick produced a valid file.
Three practical patterns
Release migrations
Build and review the image, run a backward-compatible migration as a finite command, inspect its terminal result, and then proceed with the application rollout according to your deployment plan. Use a migration lock where appropriate and ensure older application code can tolerate the intermediate schema. Separating the command avoids invoking it independently on every HTTP replica; it does not make an incompatible schema change safe.
Daily reporting
Have a scheduled command select a reporting date, read a bounded source snapshot, write a stable object key and exit. A rerun for the same date should have a defined replacement or versioning policy. Check the object itself, not only the exit status. S3 versioning can retain previous outputs, while retention controls may intentionally prevent replacement.
Cleanup and backfills
Operate on explicit batches and persist progress. Delete only records that satisfy a carefully reviewed predicate and use a dry-run mode when the underlying operation needs one. If a run stops midway, a later invocation should continue from its durable checkpoint rather than repeat unknown side effects. A tested database recovery plan remains necessary for destructive maintenance.
Budget resources and cost across both lifecycles
A Run uses the parent container’s CPU and memory profile, so a database migration and a web request may have different optimal resource needs even when they share an image. Run execution is independent of HTTP scaling but still competes for project capacity. Account quotas and available cluster capacity can prevent work from starting. A run shown as active is not proof its script has already begun.
The documented timeout range is 60–3600 seconds, with a default of 900. Capacity waiting can consume that window. No automatic Run retry is provided by this model. Add bounded application retries only for operations that are safe to repeat, and distinguish an SDK retry from retrying the whole command.
Runs are documented as using the container’s compute rates and free-tier accounting, rather than a separate per-run fee. Avoid a fixed monthly promise: execution duration, resource profile, HTTP usage, storage, database capacity and traffic can all affect the bill. Consult current Rapids pricing documentation and the account’s actual usage. Failed or cancelled work can consume billable compute once resources are allocated.
Keep database connections bounded across HTTP processes and runs. A single scheduled job can exhaust the final available connection while a rollout temporarily doubles replicas. Connection pooling controls part of that demand, but the complete budget still includes jobs and administrative access.
Define a useful completion check
- HTTP: response errors, latency and an end-to-end synthetic request.
- Run: terminal state, exit code, diagnostic message and the durable output it should produce.
- Schedule: last occurrence, skipped occurrences, generated run results and missing business periods.
- Data: row counts, explicit date ranges, object keys and checksums appropriate to the task.
Keep sensitive values out of logs. Export the operational evidence you need under your own retention policy instead of assuming platform logs last forever. A zero exit code can coexist with an empty report or an accidentally broad cleanup predicate. Make success conditions explicit in the command and in monitoring.
Frequently asked questions
Can I call an HTTP endpoint from a Run?
A Run can make network requests, including to an appropriate service endpoint, but it does not expose its own job endpoint. Check authentication, timeouts and idempotency before turning a cron job into an HTTP client.
Why not run cron inside the web container?
Each replica could start its own scheduler, while scale-to-zero can remove all schedulers. A separate tracked schedule gives execution timing an owner independent of request-driven replica count.
Does one job mean exactly-once business processing?
No. Restarts, ambiguous external responses, manual retries and duplicate input still require idempotency and reconciliation. The application must define what can safely be repeated.
When is another worker environment a better fit?
Use one when work must remain continuously connected, exceeds the available timeout, needs many concurrent jobs per logical container, or depends on specialised resources. Choose the environment after measuring those requirements rather than forcing every workload into an HTTP or finite-run model.
Sources
- docs.danubedata.ro/serverless-overview
- docs.danubedata.ro/rapids-runs
- docs.danubedata.ro/rapids-automation
- docs.danubedata.ro/cli-serverless
- danubedata.ro/solutions/rapids
- docs.danubedata.ro/serverless-overview#pricing
