agentsclimarketplace

Litestar deployment

Skill litestar-org/litestar-skills/plugins/litestar/skills/litestar-deployment

Opinionated first-party agent skills, plugins, subagents, slash commands, and MCP servers for the Litestar framework ecosystem — publishable to Claude Code, Gemini CLI, Codex CLI, Cursor, OpenCode, and VS Code/Copilot from a single repo.

Install
npx -y skills add litestar-org/litestar-skills --skill litestar-deployment

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 13 stars13 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Auto-activate for Dockerfile, compose, Railway, Cloud Run, GKE, systemd, Kubernetes, Terraform, deploy scripts, or granian/litestar run at runtime. Not for packaging artifacts.

SKILL.md

9.9 KB, ~2.4k tokens by cl100k_base, as published. Nobody here has run it

Litestar Deployment

Production deployment patterns for Litestar ASGI applications across Docker, Railway, Kubernetes/GKE, Cloud Run, and systemd. Covers multi-stage Dockerfiles, distroless images, asset pipelines, worker containers, and health-check integration.

All deployment paths use Granian (via litestar-granian) as the ASGI server, uv for Python package management, and Bun for frontend asset builds.

Build vs. deploy split: this skill is about running Litestar artifacts in production. For producing those artifacts — wheel bundling with embedded Vite assets, PyApp onefile binaries, GitHub Actions CI/release pipelines — see litestar-build.

Code Style Rules

  • from __future__ import annotations is allowed in consumer-app modules (Dockerfiles, deploy scripts, settings).
  • All Python samples use PEP 604 unions (T | None).
  • Granian over uvicorn in every CMD/entrypoint. Use litestar run (which delegates to Granian when litestar-granian is installed).
  • Environment-driven configuration via @dataclass settings — never hardcode secrets or connection strings.
  • Shell scripts follow Google Shell Style Guide (set -euo pipefail, quoted variables).

Quick Reference

TargetReferenceKey File
Docker (standard multi-stage)references/docker-standard.mdDockerfile
Docker (distroless production)references/docker-distroless.mdDockerfile.distroless
SAQ worker containerreferences/docker-workers.mdDockerfile.worker
Docker Compose (app + infra)references/docker-compose.mddocker-compose.yml
Railwayreferences/railway.mdrailway.app.json
Kubernetes / GKEreferences/kubernetes.mddeploy.py, templates/
Cloud Runreferences/cloud-run.mdservice.yaml
systemd nativereferences/systemd.mdlitestar.service

Dockerfile CMD (all variants)

# Web server
ENTRYPOINT ["tini", "--"]
CMD ["litestar", "run", "--host", "0.0.0.0", "--port", "8000"]

# SAQ worker (separate container)
ENTRYPOINT ["tini", "--"]
CMD ["app", "workers", "run"]

Environment variables (required in every target)

LITESTAR_APP="app.server.asgi:create_app"   # app discovery
DATABASE_URL="postgresql+asyncpg://..."       # async driver
SAQ_REDIS_URL="redis://cache:6379/0"         # worker queue
SECRET_KEY="..."                              # session signing
<workflow>

Workflow

Step 1: Choose deployment target

Docker Compose for local/staging. Railway for rapid PaaS. GKE/K8s for production at scale. Cloud Run for serverless containers. systemd for bare-metal.

Step 2: Write the Dockerfile

Start from Dockerfile.distroless for production (preferred). Use standard multi-stage for environments that need a shell. Use Dockerfile.dev for local Docker development. Always pin ARG PYTHON_VERSION=3.13.

Step 3: Build frontend assets inside Docker

Copy Bun lockfiles first (layer caching), install JS deps, then bun run build and uv run app assets build. Assets must be in the wheel before uv build.

Step 4: Create separate worker image

SAQ workers use the same build stages but a different CMD (app workers run). No port exposed, no health-check HTTP endpoint. Set SAQ_USE_SERVER_LIFESPAN=false.

Step 5: Set up CI/CD

Build images in CI, push to registry, deploy via railway up, gcloud run deploy, or kubectl apply. Tag images with git SHA for production — never deploy latest to prod.

Step 6: Configure health checks and monitoring

Expose /health on the API container. K8s uses startupProbe + livenessProbe + readinessProbe on /health:8000. Cloud Run and Railway use the same endpoint for readiness.

</workflow> <guardrails>

Guardrails

  • Distroless for production, slim for dev. Distroless (gcr.io/distroless/cc-debian12:nonroot) has no shell, no apt, minimal CVE surface. Use slim only when you need a shell for debugging.
  • Non-root user (UID 65532). Match the distroless nonroot user. Create with useradd --system --uid 65532 in standard images.
  • uv for all package installs. No pip, no pip-tools. uv sync --frozen --no-dev in builder, uv pip install wheel in runner.
  • UV_COMPILE_BYTECODE=1. Pre-compile .pyc in the builder — saves 200-500ms cold-start in containers.
  • UV_LINK_MODE=copy. Hardlinks break on overlay filesystems. Always copy.
  • Tini as PID 1. Containers need an init process for signal forwarding and zombie reaping. ENTRYPOINT ["tini", "--"].
  • STOPSIGNAL SIGINT. Granian handles SIGINT for graceful shutdown. Docker sends SIGTERM by default; set STOPSIGNAL SIGINT or Granian ignores the signal and gets SIGKILL after timeout.
  • Multi-architecture support. Use docker buildx with --platform linux/amd64,linux/arm64. Distroless Dockerfile handles arch-specific lib paths via TARGETARCH.
  • Asset build inside Docker. Vite/Bun builds run in the builder stage. Never mount host node_modules into production images.
  • Health check endpoints. Every API container must expose /health. K8s probes hit this path. Cloud Run and Railway use it for readiness.
  • LITESTAR_APP env var. Both Litestar CLI and Granian read this for app discovery. Set it in Dockerfile and override per-environment.
  • Never run as root. USER nonroot in Dockerfile. runAsNonRoot: true in K8s pod security context.
  • Pin Python version. ARG PYTHON_VERSION=3.13 at the top. Never use python:latest.
  • Separate worker containers from web containers. SAQ workers poll Redis, not HTTP. They need different CMD, different scaling, and no port.
  • Build-time env vars to prevent connection attempts. Set DATABASE_POOL_DISABLED=true, SAQ_USE_SERVER_LIFESPAN=false, SAQ_WEB_ENABLED=false during build to prevent the app from trying to connect to databases during asset compilation.
</guardrails> <validation>

Validation Checkpoint

Before shipping a Litestar deployment, verify:

  • Dockerfile uses multi-stage build (python-base -> builder -> runner)
  • ARG PYTHON_VERSION is pinned (not latest)
  • COPY --from=ghcr.io/astral-sh/uv:latest /uv /uvx /bin/ present
  • UV_COMPILE_BYTECODE=1 and UV_LINK_MODE=copy set in builder
  • Frontend assets built inside Docker (not copied from host)
  • uv build creates wheel; runner installs wheel (not editable)
  • Runner uses non-root user (UID 65532)
  • ENTRYPOINT ["tini", "--"] set
  • STOPSIGNAL SIGINT set (for Granian graceful shutdown)
  • LITESTAR_APP env var set
  • /health endpoint exists and is used by probes/readiness checks
  • SAQ worker is a separate container with different CMD, no EXPOSE
  • No secrets in Dockerfile (use env vars or mounted secrets)
  • Production image is distroless or has documented justification for slim
  • Docker Compose depends_on uses condition: service_healthy
</validation> <example>

Example

See references/docker-distroless.md for a complete 4-stage distroless Dockerfile with multi-arch support, Vite asset build, and non-root execution.

For a full local stack (app + worker + migrator + PostgreSQL + Valkey), see references/docker-compose.md.

For Kubernetes production deployment with HPA, Ingress, and GKE Workload Identity, see references/kubernetes.md.

</example>

References Index

Official References

Cross-References

  • litestar-build — how the wheel and PyApp onefile artifacts this skill deploys are produced (Hatchling config, Vite-in-package bundling, GitHub release pipelines)
  • litestar-granian — ASGI server tuning (workers, threads, HTTP/2, backpressure)
  • litestar-saq — SAQ worker configuration and task definitions
  • litestar-vite — Vite asset build pipeline and TypeGen
  • litestar settings — env-driven @dataclass settings pattern

Shared Styleguide Baseline

What ships with it: 9 files

46.4 KB alongside SKILL.md

Gives 0 of the 12 instructions most containers cloud skills give in ~2.4k tokens

Counted across 607 of the 657 authors here whose files we hold, read 2026-08-07

  • Run containers as a non-root userin 66 of 607, across 46 files
  • Use multi-stage buildsin 53 of 607, across 44 files
  • Use Promise.all for independent operationsin 47 of 607, across 13 files
  • Import directly instead of barrel filesin 46 of 607, across 12 files
  • Use ternary instead of AND for conditionalsin 45 of 607, across 12 files
  • Use Set or Map for O(1) lookupsin 42 of 607, across 10 files
  • Create a .dockerignore filein 41 of 607, across 31 files
  • Read individual rule files for detailsin 39 of 607, across 9 files
  • Copy dependency files before source codein 36 of 607, across 23 files
  • Authenticate server actions like API routesin 35 of 607, across 7 files
  • Use next/dynamic for heavy componentsin 34 of 607, across 9 files
  • Use React.cache for per-request deduplicationin 34 of 607, across 10 files

Said here and by no other author read

  • use granian as the asgi server
  • configure environment via dataclass settings
  • start production images from distroless
  • create separate worker containers
  • set tini as pid 1
  • set stopsignal to sigint

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 327,069. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.