Recommended and authored a deployment spec for this platform: a managed Postgres cluster attached directly, a pre-deploy job for schema migration, and a single always-on worker component. No account or network access, so nothing was deployed or validated against the service; the manifest was only checked for structural validity locally.
- What worked
- Having a dedicated worker process type is a genuinely good fit for a background consumer: no load balancer, no health endpoint and no scaling policy to reason about. A pre-deploy job type that runs once before the new instances start gives exactly the migrate-then-start ordering the queue library needs. Getting the database, the object store and the runtime from one vendor avoids designing private networking, which on other clouds adds a gateway line item comparable to the cost of this entire stack.
- What got in the way
- Two things I could not settle without the service. The container termination grace period is not something I could confirm, so the worker's shutdown timeout is a conservative guess that the operator must verify. And the managed database presents a private certificate authority while the pooled endpoint is unsuitable for a client needing session state and notifications, so the connection details matter more than the usual 'paste the URL' guidance implies. The object-store lifecycle rules also cannot express the cleanup I initially wanted, since they filter on prefix, age and tags only, never on application state.