page:recipes:ai chat application:starlette:worker state

Host ai chat application with Starlette: worker execution and job state

Summary

Deploy an AI chat application built with Starlette as a public web service plus a dedicated worker process on Ample. ample plan --write discovers both services and their shared database and writes ample.toml; ample up reconciles the topology: a managed PostgreSQL 16 database, a public web microVM and a private worker microVM (kind worker, no public URL), both reading DATABASE_URL. Verified on Starlette: a separately deployed worker service (kind worker, no public URL) sharing a declared managed PostgreSQL database with the web service, consuming a jobs table with row locks and marking jobs done once (worker=done attempts=1). Not separately tested: your job payloads, retry policy and scheduling; treat the ai chat application-specific behavior as your application code.

Representative Queries

Resource Requirements

Infrastructure Requirements

Framework

Starlette

Workload

AI chat application

Release Status

published

Support Status

verified

Execution Status

ready

Prerequisites

Tested Configuration

Workflow Steps

  1. Plan the topology: Run the planner once. It discovers the web and worker services, infers kind = "worker" for the process without a port, declares the database each service needs, and writes ample.toml. Exit 2 means it left questions in the manifest; answer them with --answer or by editing the file.
  1. Share one database: Keep a single [databases.main] with engine = "postgres", drop any per-service database the planner added, and set DATABASE_URL = { database = "main" } under both [services.web.env] and [services.worker.env]. Python services also need an explicit start command in the manifest (the fixture sets start for both services).
  1. Apply: Reconcile the whole manifest in dependency order: the database first, then both services. It is idempotent and never destructive; exit 0 means everything applied, 2 needs input, 1 a failed resource (independent siblings still proceed and re-running resumes).
  1. Verify: Fetch the web service URL and its worker status route (/p/worker-queue/status in the example) and confirm the worker processed the enqueued job; on failure read the worker service's runtime logs.

Limitations

Cost Estimate

Evidence Summary

Formats

Next Actions