I built this because I wanted to make Python agents easier to deploy as microservices, so they’re cheaper to host, easier to scale horizontally, and have good visibility once they’re running.
dank-py takes an existing agent project, inspects it, generates config, locks dependencies, validates everything in an isolated environment, and turns the agent into a Dockerized HTTP microservice.
The output is meant to be production-ready by default: standardized runtime contract, input/output validation, health/status/metrics/logs/traces, and support for either separate containers or bundled multi-agent containers.
It’s framework-agnostic. You describe how the agent is invoked in `dank.config.json`, so it can work with LangChain, LangGraph, CrewAI, PydanticAI, LlamaIndex, or custom agents with direct LLM calls. The CLI can usually bootstrap the config automatically.
If you try it, I’d be especially interested in whether it fits naturally into your existing project structure, and whether the runtime contract covers the functionality you’d want from agent microservices.
A problem I keep running into, and hear from others, is teams embedding agents directly into their backend because it’s easy. But in production, debugging becomes painful and scaling gets expensive. Running agents as separate services fixes this, but the infra work is heavy, so most teams delay it until they are forced to rebuild.
I built Dank Cloud to handle that deployment layer so agents run as separate services you can call from your backend, with per-agent logs, GitHub-based deploys, and optional hosted vector memory.
The cloud is in beta and currently supports agents built with our open-source JS framework, with LangChain and CrewAI support coming next.
Would really appreciate feedback from anyone who has deployed agents in production or hit similar issues.
I’ve been building a platform called Dank AI (www.ai-dank.xyz), basically a “Vercel for AI agents.” You define an agent in JavaScript with our framework, connect a GitHub repo, and it deploys to a production URL in one click (containerized, with secrets, logs, CPU/RAM selection, etc.).
I recently added a big update so that now you can also deploy and host weaviate vector databases alongside your agent. I put together this AI chatbot example to show how easy it is to define an agent with Dank, integrate weaviate memory for RAG, and connect to an application frontend. The project is designed to run the whole demo locally from a single command, and you can immediately deploy the agent + weaviate on Dank cloud, and deploy the front end on Vercel (just set env variables accordingly to switch the project from local to prod).
It’s set up so you can fork it and immediately build your own Dank agent application without worrying about infra. I hope this makes it easier to build and deploy AI agents. Any feedback you have would be greatly appreciated.
We think that using event based agents will eventually become the standard. Currently most AI agent frameworks are essentially a single runtime and use "agents" as nodes in a "workflow". This design pattern is fine for most non-developers to automate tasks locally. However we believe that this pattern doesn't scale well especially for developers. Which is why our agents operate their own runtimes as microservices, and "workflows" are the abstraction layer above agents that allow you to connect and attach agents together to do real work (Workflows to-be-announced soon). We separate "workflows" & agents as different layers in the stack, we think this design pattern is the future of agentic.
dank-py takes an existing agent project, inspects it, generates config, locks dependencies, validates everything in an isolated environment, and turns the agent into a Dockerized HTTP microservice.
The output is meant to be production-ready by default: standardized runtime contract, input/output validation, health/status/metrics/logs/traces, and support for either separate containers or bundled multi-agent containers.
It’s framework-agnostic. You describe how the agent is invoked in `dank.config.json`, so it can work with LangChain, LangGraph, CrewAI, PydanticAI, LlamaIndex, or custom agents with direct LLM calls. The CLI can usually bootstrap the config automatically.
If you try it, I’d be especially interested in whether it fits naturally into your existing project structure, and whether the runtime contract covers the functionality you’d want from agent microservices.