FastAPI apps tend to hold things across requests, a database pool, an in-memory cache, a background task started with BackgroundTasks or a lifespan hook. A serverless function that recreates the process per request fights that model. On DenkOps the app runs in one always-on slot, so the pool stays warm and a background task actually finishes instead of getting cut off when the response is sent.
Point a local database, an upload directory or a local cache at /persist and it survives redeploys. Add outbound domains to the egress allowlist for the third-party APIs the service actually calls.
Run it however you'd run it locally, uvicorn main:app or gunicorn with uvicorn workers both work. The slot gives the process a fixed CPU and RAM allocation and keeps it running continuously, so however many workers you start is however many you get, with no platform-imposed process recycling.
Push the project the same way you deploy anything else on DenkOps: from Claude Code say "deploy on DenkOps" and it packs the app, builds it and returns a live HTTPS URL. requirements.txt is read automatically; no Dockerfile required unless you want one.
← API hosting · FastAPI webhook guide · FastAPI scraper guide