I guess you get a pass because it's not formally a Show HN but I detest launches that are "join our mailing list" because (a) seems like fishing for interest in vaporware (b) a spam risk when you sell my details if the product doesn't materialize
> Made with for developers
If that were true, you wouldn't have a template website that used the GitHub icon to point to just github.com instead of your repo or org. The whole site just seems autogenerated. I'm aware that's the popular accusation of late, but I don't mean it in the AI wrote it way, I mean the $(npx create-generic-business-site) way
gardnr · 15m ago
This is a cool idea that is not ready to share yet. Please consider writing your own comments on HN in the future.
cyw · 58m ago
We are working on Agentainer, a platform to make deploying and managing LLM-based agents as microservices feel effortless — especially for developers who don’t want to wrestle with infrastructure. This isn’t a pitch. we're sharing a pain we’ve run into hard, and we want to know if others are feeling it too. We’ve built agents using AutoGen, LangChain, and custom setups to monitor APIs, automate tasks, or manage systems autonomously. But running these in production? It’s a mess.
Most cloud platforms are designed for stateless apps or short-lived functions — not long-running agents that need to:
- Stay alive for hours or days
- Recover from crashes without losing context
- Expose secure APIs for integrations
- Scale up when demand spikes
- Persist state across redeploys
Dealing with Dockerfiles, Kubernetes, and manually wiring Redis/PostgreSQL eats up too much time — time we'd rather spend improving the agent’s logic.
Agentainer is our attempt to fix this. It’s a platform that gives agents the runtime treatment they deserve. Highlights:
- One-click deployment: Upload your code or Docker image, no YAML or infra scripts. (oh, and we designed it in a way where other AI agent can do it as well!)
- Lifecycle management: Start, stop, pause, resume, and auto-recover — via UI or API.
- Persistent state: Redis (runtime), Postgres (config), with automatic rehydration.
- Per-agent secure APIs: Each agent gets its own REST/gRPC endpoint with token auth and usage logging.
- Scaling and cloning: Horizontal scaling with optional memory cloning.
What makes Agentainer uniquely flexible is that we expose the entire platform through APIs. This means not just you, the developer, but also your own developer agent can programmatically deploy, monitor, or retire other agents. Want a planning agent that spins up task-specific agents on demand? That’s a first-class use case. We’re building toward a world where autonomous agents can coordinate and manage infrastructure without human input — and Agentainer is designed with that architecture in mind.
We are applying to YC and would love unfiltered feedback from anyone who’s run agents in production:
1. What’s the hardest part of deploying or scaling agents for you?
2. What infrastructure or tooling would actually make your life easier?
3. What debugging/monitoring features would save your sanity?
Honest takes are super welcome. If this idea feels useful — or totally off-base — we’d love to hear why.
Note: Agentainer doesn’t provide any LLM models or reasoning frameworks. We’re infra-only — you bring your own agent code, and we handle the deployment, state, scaling, and API exposure.
andsoitis · 42m ago
> We’re building toward a world where autonomous agents can coordinate and manage infrastructure without human input — and Agentainer is designed with that architecture in mind.
While it can manage infrastructure, how would it know what to manage toward? And would it know how to adapt when the business or other context changes?
cyw · 38m ago
That’s a great point — and you’re absolutely right.
Agentainer isn’t responsible for determining what to manage or why — it's not an orchestration brain or planner itself. It’s designed to enable that level of automation by giving agents the tools to act. Think of it more like the runtime and control plane that an intelligent planning agent (built by the developer) can use to execute its decisions.
So for example, if you’ve built a supervisor agent that analyzes workloads and spins up child agents to handle different tasks — Agentainer provides the infrastructure APIs to make that possible (create, monitor, terminate, etc.), but it’s up to you (or your planner agent) to define the logic based on business rules, goals, and evolving context.
We’re not building AGI — we’re just trying to remove the DevOps wall for people building toward that vision.
> Made with for developers
If that were true, you wouldn't have a template website that used the GitHub icon to point to just github.com instead of your repo or org. The whole site just seems autogenerated. I'm aware that's the popular accusation of late, but I don't mean it in the AI wrote it way, I mean the $(npx create-generic-business-site) way
Most cloud platforms are designed for stateless apps or short-lived functions — not long-running agents that need to:
- Stay alive for hours or days
- Recover from crashes without losing context
- Expose secure APIs for integrations
- Scale up when demand spikes
- Persist state across redeploys
Dealing with Dockerfiles, Kubernetes, and manually wiring Redis/PostgreSQL eats up too much time — time we'd rather spend improving the agent’s logic.
Agentainer is our attempt to fix this. It’s a platform that gives agents the runtime treatment they deserve. Highlights:
- One-click deployment: Upload your code or Docker image, no YAML or infra scripts. (oh, and we designed it in a way where other AI agent can do it as well!)
- Lifecycle management: Start, stop, pause, resume, and auto-recover — via UI or API.
- Persistent state: Redis (runtime), Postgres (config), with automatic rehydration.
- Per-agent secure APIs: Each agent gets its own REST/gRPC endpoint with token auth and usage logging.
- Scaling and cloning: Horizontal scaling with optional memory cloning.
- Logs and metrics: Real-time logs, crash history, uptime, Prometheus-backed metrics.
What makes Agentainer uniquely flexible is that we expose the entire platform through APIs. This means not just you, the developer, but also your own developer agent can programmatically deploy, monitor, or retire other agents. Want a planning agent that spins up task-specific agents on demand? That’s a first-class use case. We’re building toward a world where autonomous agents can coordinate and manage infrastructure without human input — and Agentainer is designed with that architecture in mind.
We are applying to YC and would love unfiltered feedback from anyone who’s run agents in production:
1. What’s the hardest part of deploying or scaling agents for you?
2. What infrastructure or tooling would actually make your life easier?
3. What debugging/monitoring features would save your sanity?
Honest takes are super welcome. If this idea feels useful — or totally off-base — we’d love to hear why.
Note: Agentainer doesn’t provide any LLM models or reasoning frameworks. We’re infra-only — you bring your own agent code, and we handle the deployment, state, scaling, and API exposure.
While it can manage infrastructure, how would it know what to manage toward? And would it know how to adapt when the business or other context changes?
Agentainer isn’t responsible for determining what to manage or why — it's not an orchestration brain or planner itself. It’s designed to enable that level of automation by giving agents the tools to act. Think of it more like the runtime and control plane that an intelligent planning agent (built by the developer) can use to execute its decisions.
So for example, if you’ve built a supervisor agent that analyzes workloads and spins up child agents to handle different tasks — Agentainer provides the infrastructure APIs to make that possible (create, monitor, terminate, etc.), but it’s up to you (or your planner agent) to define the logic based on business rules, goals, and evolving context.
We’re not building AGI — we’re just trying to remove the DevOps wall for people building toward that vision.