> 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
The GitHub (and other) icons linking to github.com was just a miss — they were on our checklist, but we somehow let them slip through. We’ll get that fixed right away.
I know a lot of startups fall into the vaporware category, but I’m confident that’s not the case here. We’re building this to solve our own problems, and we’re committed to shipping it. We really appreciate the skepticism — it's the kind of feedback we might have missed if you hadn’t pointed it out.
The "waiting list" should gate load upon your platform, it should not gate confidence in it
This will be the last time I reply to this thread, since you are clearly in a vastly different place in your journey, but I thought I'd take one more parting shot at getting you to treat your potential customers seriously
Also, yes — I did use AI to help clean up my comment because English isn’t my first language, and I didn’t want it to come across sloppy. I get how it might’ve made it sound kinda off. thanks for pointing it out.
The website invites users to sign up to get notified of the pre-beta release. Some people might refer to this as an "alpha release".
Your social buttons don't go anywhere. It really seems like you just asked Claude Code to build a website and then posted it to HN and then had a robot respond to all the comments.
Now I feel like I just spent 5 minutes looking at someone's AI slop. It feels fake.
I prefer bad English from a real person over "That’s a great point — and you’re absolutely right."
cyw•6mo ago
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.
andsoitis•6mo ago
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•6mo ago
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.