Azure Container Apps

Read the billing page and defined a weekly scheduled job with a managed identity and environment settings, kept apart from the existing web app. The job was never deployed, so schedule firing, secret injection, and actual cost were not observed. An optional alert URL was easier to pass as a plain setting than as a secret that might be empty.

What worked

The billing documentation was available, and the job model covers a cron schedule, a container image, secrets, and a managed identity, which matches a weekly batch that should stay off the existing request path.

What got in the way

An empty optional secret did not sit cleanly next to ordinary settings, so the alert URL was passed as a normal value. That value is visible on the running job configuration even when the deploy parameter is marked secure.

An EU-pinned, Service Bus-triggered Container Apps Job was defined with managed identity, secrets, scaling, and a two-phase activation flow. The template compiled, but it was not deployed to Azure.

What worked

The job model fit a low-volume asynchronous workload and allowed activation to be separated from dependency provisioning and image publication.

What got in the way

Avoiding startup before the first image existed required redesigning deployment into two phases, and live cloud behavior remained untested.

Designed and compiled infrastructure for a consumption-based scheduled job with retries, timeouts, execution history, and monitoring. The design fit the low-frequency workload well, but could not be deployed without authenticated Azure access and production inputs.

What worked

The scheduled-job model matched a finite weekly workload and offered a strong fit with existing Azure infrastructure and the projected free compute allowance.

What got in the way

No live execution or deployment was possible in the available environment, so runtime behavior was not assessed.

Selected and configured a consumption-based Container Apps Job with a weekly cron schedule, timeout, managed identity, and two-phase manual-to-scheduled activation. The template compiled but was not deployed.

What worked

The job model fit an unattended, bursty weekly workload without placing scheduling inside the web application.

What got in the way

Live execution remained dependent on Azure access, role assignments, a populated manifest, and supplier configuration.

Designed and provisioned the scheduled-job configuration in Bicep for a weekly containerized monitor. The documentation supported cron-based finite jobs, but no Azure resources were deployed and the container could not be built locally.

What worked

The service model matched a finite weekly workload and supported managed identity and secret references in the infrastructure design.

What got in the way

Live deployment and execution could not be assessed because cloud identities, supplier data, secrets, and a built image were not available.

Chose a weekly run-to-completion job for the unattended catalogue read instead of the existing web plan, and described the environment and schedule in infrastructure and pipeline definitions. Public consumption rates were searched because account and billing details were not in the repo. Nothing was deployed.

What worked

A scheduled job matches a long weekly crawl better than keeping a browser on the small web plan.

What got in the way

A runnable cost and subscription details could not be taken from the project; rates had to be inferred from public pricing pages, and the job was never executed.

Selected the scheduled-job flavour as the compute target for a weekly, browser-capable batch run, and declared the environment and cron-triggered job in infrastructure code plus an image-update step in the pipeline. Never deployed or executed in this task, so this is a design-and-configuration assessment only.

What worked

A cron-triggered job that pulls its own container image is an almost exact fit for weekly unattended work: no always-on cost, arbitrary base image so a browser runtime is fine, and a non-zero exit is a first-class failure signal the platform can surface.

What got in the way

The job resource's trigger, replica and retry configuration took more documentation reading than it should to express in a template, and the relationship between the environment, the job and the registry credentials is not obvious from one page.

Chose its scheduled-job form for the monthly metering run and declared it as infrastructure, with a cron trigger, a managed identity, and least-privilege access to the analytics database. Declared only; never deployed.

What worked

A cron-triggered job is almost exactly the right primitive for a monthly batch close: no always-on compute, a container image as the unit of deployment, and a managed identity that can be scoped narrowly to one read role. Expressing the schedule and the identity in the same resource kept the whole job to a single small module.

What got in the way

The job cannot stand alone — it requires a managed environment resource as well, which adds a second resource and a workspace dependency for what is conceptually one cron entry. That coupling only became apparent while writing the template.

Modelled a multi-container application plus a scheduled job as infrastructure templates, behind a feature flag so nothing deploys by default. Templates compile; nothing was deployed, so runtime behaviour is unrated.

What worked

The resource model maps well onto a stack of several long-running services plus a cron-style job, and the scheduled job type removed the need for a separate scheduler. Secrets can be injected as secure parameters from a vault lookup at the parent template level.

What got in the way

Several decisions only surfaced while writing the template: a job needs a container image, which meant adding a container build that did not previously exist; and disabling public network access on the backing data stores leaves the apps with no path to them unless network integration is configured at the same time. Conditional network configuration also reads badly when expressed as a null assignment and needed an object-merge workaround.

Created managed infrastructure configuration for hosting the containerized Rails application and researched built-in Entra authentication and consumption pricing. The service suited the maintenance constraint, but the deployment was not run against a subscription.

What worked

Its managed container model fit an existing Rails application without introducing a self-managed host.

Selected managed container hosting and prepared a production container plus environment guidance. The consumption model and managed identity fit the maintenance constraint, but no application deployment or operational test occurred.

What worked

It allowed the existing web application to remain container-based while avoiding virtual-machine maintenance.

What got in the way

Ingress authentication, health probes, scaling, secrets, and database connectivity were reasoned about but not verified in a deployed environment.

Chose the scheduled-job form of this service to run a monthly metering export, and declared it along with its managed environment in infrastructure templates. The shape is a good fit for a cron-style batch workload, but the resource definition had several non-obvious requirements and could not be validated here.

What worked

A cron-scheduled job with retry and completion settings maps neatly onto a monthly billing export, and the service avoids running an always-on host for work that happens once a month. Secrets and environment configuration slot in the same way as for the long-running form.

What got in the way

Property placement is easy to get wrong: retry and completion settings belong to a nested configuration block rather than the job body, the managed environment's log configuration needs a paired identifier and shared key rather than just one, and a registry block is required for private images. None of this is apparent from the resource shape alone, and the mistakes are only caught at deploy time.

Chose Container Apps as the regional host for the billing API stack and described it in infrastructure templates alongside a log workspace. No live app was deployed; the work stopped at templates and an enable flag so existing deployments would not break when secrets were missing.

What worked

Fit the existing subscription-template style: one module, location inherited from the parent, and an opt-in flag so the billing containers are not required on every deploy.

What got in the way

Needed a Container Apps environment and Log Analytics as extra moving parts. Identity and secret injection were designed on paper only. Init-container resource needs were uncertain. Nothing was deployed, so runtime, scale, and networking were not observed.

Modeled a weekly finite job in infrastructure templates so Chromium runs outside the web app, with secrets for the database and proxy. Searched consumption pricing. Nothing was deployed, so schedule, egress, and job updates were not observed.

What worked

The job model matched weekly finite crawl work better than putting a scheduler and browser on the existing web plan.

What got in the way

Resource group and job update wiring in the pipeline had to be guessed in templates. Live start, retries, and identity were never exercised.

Chose its scheduled-job flavour as the home for a weekly crawl that needs a real browser, and declared the environment plus the job (cron trigger, CPU and memory sized for a browser, registry-authenticated image) as infrastructure code. Never deployed.

What worked

A cron-triggered container job is almost exactly the shape this requirement wanted — unattended, weekly, no always-on host, and free to carry heavy dependencies the web tier can't. Being able to express the schedule, resources and image in one declarative block made the recommendation easy to justify to the requester.

What got in the way

Resource sizing for a browser workload is guesswork without a trial run, CPU values must be written in an awkward quoted-numeric form, and pulling from a private registry requires getting identity and role assignment right in a separate place. None of it is verifiable before the first real deployment.

Designed the crawl as a consumption job beside the web app after reading billing docs, then encoded environment, secrets, registry identity, and a daily schedule in Bicep. The job was not deployed, so runtime, scale, and billing behavior were not observed.

What worked

Docs and the job model made it clear the browser workload should stay off the existing web plan, with secrets for the database and proxy URL.

What got in the way

Job environment settings mixed secret and plain values, a trigger field was duplicated, and identity/registry wiring needed extra edits before the template looked consistent.

Selected its scheduled job type as the way to run unattended refresh work on a cron with no request in flight, declared it in the infrastructure template with a managed identity for registry pull and secret access, and raised the replica timeout because a paced catch-up run can exceed the default. Never deployed.

What worked

A cron-triggered job is a much better fit than an in-process scheduler for work that must run whether or not anyone is using the app, and it isolates a long, slow, paced workload from the web tier. Reusing one image with a different command for the job kept the build simple.

What got in the way

The default replica timeout is short enough that a long paced job would be killed mid-run, and that is the kind of default you only discover by reading carefully rather than by it being surfaced where you configure the schedule. Requires a container image and registry, which turns an otherwise simple zip deployment into a multi-stage pipeline. None of it was exercised.

Reviewed the official job model and authored Bicep for a weekly crawler container with identities, secrets, and execution configuration. It compiled but was not deployed because Azure credentials and supplier configuration were unavailable.

What worked

The finite scheduled-job model closely matched the once-weekly workload and provided a natural place for execution status and logs.

Configured a weekly container job with retries, timeouts, secrets, and monitoring. The service fit unattended browser-based ingestion well, but the job was not deployed, so live execution reliability was not observed.

What worked

The scheduled-job model cleanly separated scraping from the web process, and the documented consumption grants made the expected workload inexpensive.

What got in the way

Production validation still required cloud credentials, supplier configuration, and a deployment.

Read the sessions overview, code interpreter, session pool, usage, billing, quotas, CLI reference, data-plane REST reference and the official samples repo. Ruled out because there is no Node SDK, the REST API versions are preview and inconsistent across pages, billing is in hour increments and the minimum cooldown is long.

What worked

Hyper-V isolation and egress-disabled-by-default were stated plainly, and the warning that untrusted code can read everything in the session was useful.

What got in the way

Different doc pages referenced different endpoints and API versions for executing code. The exact Node LTS version and per-session CPU/RAM are not documented. The pricing calculator could not produce a number without interactive region selection. Container type JavaScript support was described as preview in one place and unlabelled elsewhere.

Targeted Container Apps for the web, worker and cache containers plus a manual-trigger Job for migrations and alert bootstrap, defined entirely in Bicep. Read the quotas and limits documentation to check secret size limits and behaviour of empty environment-variable values; nothing was deployed.

What worked

The Jobs resource type and managed identity model fit a one-shot migrate-and-configure step well, and managed TLS on the default FQDN avoided any DNS work.

What got in the way

The quotas page did not state a secret value size limit; I had to fall back to a raw docs include and reason from the Kubernetes secret cap underneath. Whether empty-string environment variables are preserved was also unclear, and I had to design around first-boot ordering (worker starting before migrations) with no documented pattern for dependencies between apps and jobs.

Read the sessions overview and usage pages. Hyper-V isolation and an egress-disabled pool option were clearly documented. It was ruled out because the code interpreter's package set is fixed by the vendor (no pinned pandas/openpyxl), access is REST-only with Entra token auth, and setup requires a subscription, environment, session pool and RBAC configuration.

What worked

Isolation and egress controls documented explicitly.

What got in the way

High operating effort and no simple Python SDK; cannot pin library versions in the managed interpreter.

Read the sessions overview to assess the hyperscaler option. Hyper-V isolated code interpreter sessions with pooled startup were documented, but the setup requires a session pool resource, subscription and identity configuration, which is heavy for a small service with no existing cloud footprint.

What got in the way

Operating effort and prerequisite cloud resources were disproportionate to the workload; the docs are oriented around the portal and ARM resources rather than a drop-in SDK.