Cost makes you look. Ownership makes you consider moving. What usually stops you is the same thing: no one owns infrastructure. That is starting to change.
Most products don't start with infrastructure anymore. You don't rent a server, stand up a database, and build a deployment pipeline before you write a feature. You push to GitHub and it deploys. You create a table and you can start storing data. That's where Supabase and Vercel come in, and Firebase, Netlify, and Railway play similar roles. Tools like these let people without deep infrastructure expertise build and ship products quickly.
And yet products that start this way eventually begin looking at other options. Sometimes the bill gets uncomfortable. Sometimes the service grows complex enough that it needs a deployment setup the platform doesn't cover. And sometimes you simply keep paying without seriously considering that running things yourself is an option at all.
This piece follows that arc. Why you choose Supabase or Vercel in the first place, what changes as the product grows, and where you get stuck when you try to move. Along the way, we'll look at how you can put Alpacon to use in that process.
You picked Supabase and Vercel for two reasons
The first is that it's hard to justify a big investment before the product is proven. You don't know yet whether anyone will use it. Spending money and time on infrastructure before you know that is difficult to justify, whether it's a side project or a new product inside a company. Building it cheaply, putting it in front of people, and seeing whether they come back is usually the better move. What makes Supabase and Vercel strong at that stage is how they charge. A server costs the same in a month with no traffic, while a managed platform has a free tier and bills for what you use above it.
The second is that the amount you need to know before you can ship has collapsed. Getting a service onto the internet used to mean provisioning a server, configuring a web server, running a database, and building a deployment path. Add certificates and being on call when something breaks, and you needed someone who actually understood infrastructure. Now you can start without knowing most of that. Push code and it deploys, certificates are handled for you, and a database is a few clicks away in a dashboard.
Choosing a managed platform at the start is often the sensible call. Building infrastructure before you know whether you have a product can easily put things in the wrong order. Hold onto that second reason, though, because it comes back: the infrastructure knowledge you didn't need to get started is exactly what you begin to need when you try to run things yourself.
Cost is what you notice first
Run a product for a while and the bill starts to stand out. The convenience only grows as you get better with the tool. What changes is that usage and cost rise together. More traffic, more stored data, a bigger invoice, and several projects can mean several bills. At some point, you ask the question for the first time. Is this still the right way to run this?
Cost alone doesn't settle it. Depending on your scale, renting a server and running it yourself may not be dramatically cheaper. Add the hours it takes to migrate and the time you'll spend operating it afterwards, and staying where you are may still come out ahead.
The arithmetic does change as you grow, though. Much of the effort involved in running things yourself is front-loaded. You spend days or weeks getting the environment right, and then that cost is spread across the months or years you operate it. Over a year, what initially looked like a large setup cost may start to look smaller. It is the same reason companies running on a cloud or hosting provider start weighing a data centre of their own once usage grows.
The point is that cost is often what makes you look at alternatives. It's rarely the only thing that decides whether you move.
Then ownership starts to matter
Run the product long enough and something besides cost starts to come into view. Who actually controls the data and the infrastructure? On a managed platform, your data and runtime live on that platform's infrastructure. Usually, that's completely fine, and in many cases the platform operates that infrastructure better than you would yourself. You can export your data, while security patches, availability, and much of the operational burden stay with the provider.
But there are still things you don't get to decide. There may be limits on which regions can hold your data. If pricing or platform policies change, you adapt. If you need a particular version or feature the platform doesn't support, you have to find another way.
Start selling to companies and those constraints become more visible. A customer may require that data stay in a particular region or inside its own environment. A security review may ask where data is stored, who can access it, and whether that access is recorded. At that point, being able to run things yourself isn't really about owning a server. It's about whether you have the option when you need it.
Cost and ownership stall in the same place
Whether you're considering a move because of cost or because you want more control, you eventually hit the same wall. Everything the platform used to do quietly in the background becomes your responsibility. Supabase ran the database. Vercel handled builds, deployments, and certificates. When something failed inside the platform, the platform handled it.
Run things yourself and much of that lands on you. You have to build the deployment path and manage certificates. Back up the database, and make sure those backups actually restore. Watch whether the server is healthy and get alerted when it isn't. Apply security updates. Find the cause when something breaks. Add a second person and you also have to manage who can access which server, and with how much privilege.
Written out, it starts to look like a job description, which is why companies have traditionally hired DevOps or infrastructure engineers to handle it. For a small team, the calculation used to be simple. If you have someone who can own this, run it yourself. If you don't, stay on the platform. Even if the bill was painful, or you wanted more control over your data, taking on an entire operational discipline could be worse than simply paying the invoice. So the thing you didn't need in order to start turns out to be the thing you need in order to leave.
That bottleneck is starting to move
Two things are beginning to change that calculation.
The first is deployment tooling. Install something like Coolify or Dokploy on your own server and you get a management layer: connect a Git repository, deploy an application, attach certificates, and run databases through a dashboard. Roughly speaking, tools like these let you bring some of the convenience of Vercel onto infrastructure you control.
That doesn't mean infrastructure disappears. You still need the server itself, domains still involve DNS, and you need at least a working understanding of containers, environment variables, and how your applications fit together. When a disk fills up or a service refuses to start, somebody still has to figure out what happened. The repetitive deployment work gets smaller; setting up the environment and dealing with it when something breaks does not.
The second change is AI agents. Preparing a server, installing packages, configuring deployment tooling, standing up a database, and wiring up certificates are all tasks that can increasingly be delegated. When something breaks, an agent can inspect logs, narrow down possible causes, and tell you what to check next.
Deployment tooling reduced repetitive operations work. AI agents are now lowering the knowledge barrier to working with those tools and servers in the first place. Together, they make that long list of infrastructure responsibilities look less like a full-time job description than it used to.
So who decides?
That raises the obvious question. If the agent does the work, who decides whether the work is right?
For a small team without an infrastructure specialist, that question needs to be framed a little differently. Such a team was never in a position to make every infrastructure decision with certainty in the first place. When something broke, you asked someone who knew servers. You searched, read documentation, and worked through the problem one step at a time. Sometimes nobody knew the answer and you spent a while figuring it out. So simply saying "a human should make the final call" doesn't really solve the problem, because the missing specialist is the reason we're having this conversation in the first place.
What agents can change is the quality of the information available when a decision has to be made. They can tell you what to check, summarize what they found, and explain what a command is about to do. Information that once took experience to piece together can now arrive in a much more organized form. That means someone who isn't an infrastructure expert can still make certain decisions. Take a question like "Running this will delete existing data. Continue?" You don't need to be an infrastructure engineer to answer that.
The real problem is whether you ever get asked. If the agent executes the command without stopping, there is no opportunity for a person to intervene. If it stops before the actions that matter, a non-expert can still block something dangerous. What you need isn't someone standing by to judge every action. You need a place where execution stops and a person gets asked.
Three moments where that pause matters most
So when should the system stop? Approving every command one by one defeats much of the point of using an agent. The useful distinction is between routine work and work that carries real impact.
- Work that can't easily be undone. Code has history, so if something goes wrong you can usually roll back to an earlier version. A server changes the moment a command runs, and deleting data or sending it somewhere else can be much harder to reverse. A bad configuration can usually be corrected; data deleted without a usable backup may be gone for good. Those are the kinds of actions that should stop before they run.
- Calling the work finished. Say you've just migrated a database. You created a dump and restored it, row counts match, and the data looks right in the dashboard. That still doesn't necessarily mean the migration is finished. Did the user accounts come across intact? Are any files missing? Were the extensions you depend on configured properly? Does the actual application behave the way it did before? The checklist is different for every service, and an agent deciding that the task is complete and the service actually being migrated successfully are two different things.
- When looking turns into changing. Incidents follow a similar pattern. You start by reading logs and metrics and looking for the cause, and most of that is read-only. Once you find a likely cause, however, you may restart a service, change a configuration, delete a file, or roll back a version. Reading logs is one thing; restarting a service is another.
If a human can intervene at a few points like these, much of the remaining work can be delegated to the agent.
Five things you need before you can hand it over
Putting all of this together, handing infrastructure work to an AI agent requires five things.
- It needs to be able to reach the real environment when necessary. Properly diagnosing an incident sometimes means looking inside the actual server.
- It should get only the access required for the task, and that access should end when the task is over. Reading logs and migrating a database do not require the same level of privilege.
- Dangerous work needs to be stoppable before it runs. Not every command. Just the ones that actually carry meaningful risk.
- Servers in different environments should be manageable in a consistent way. A small team's infrastructure rarely sits neatly in one place. There may be a cloud instance, a cheaper server from another provider, and a machine sitting in the office.
- The purpose of the work and what was actually executed should be recorded together. Months later, you should still be able to see why someone connected and what they ran.
The usual way of granting server access doesn't fit those requirements especially well. Create a server and you often get an SSH key. If the account behind that key has broad privileges, then whoever holds it, person or agent, may be able to read and change large parts of the machine. And once you've handed out the key, it keeps working until you deliberately revoke or replace it. That leaves you with an awkward choice: withhold the key and the agent can't do the work, hand it over and you may be giving it far more access than the task requires. You need something in between.
Where Alpacon fits
Alpacon is built around that middle ground. It is designed to let teams work directly on their servers without requiring a dedicated infrastructure engineer for every task, while keeping what people and AI agents execute under control. The five requirements above are a useful way to look at it.
| What you need | In Alpacon |
|---|---|
| Reach the real environment | Rather than handing over a server key, you open access for the work that needs doing |
| Only what the task needs, ending when it does | Access can be scoped to a particular server and task, and can expire when the window closes |
| Dangerous work stops before it runs | Work your policy says needs a look can pause before execution and wait for a person to approve it |
| Different environments, handled the same way | Install the necessary components on each server and a cloud instance, a rented box and an office machine are reached the same way |
| Purpose and execution recorded together | What ran inside a session can be recorded and read alongside the stated purpose of the work |
Checking logs and migrating data don't have to happen under the same set of privileges. Approvals can be handled from the console, Slack, or a mobile device, and the workflow can be configured so that the side making the request cannot approve its own request. This is the place to stop and decide we talked about earlier. And if an agent's chat history disappears, or the work crosses several tools, the actions that actually happened on the server can still exist as their own record.
One thing is worth stating clearly. If there is still a separate path into the server, such as an existing account or SSH key, work performed through that path is not automatically covered by Alpacon. If there are actions you need to control, the access paths themselves need to be managed as well.
Real small-team infrastructure is messier than this
Small teams rarely have all of their servers arranged neatly in one place. Leftover cloud credits put one workload on one provider. The next thing ends up on a cheaper host. A spare machine in the office runs something else. Nobody necessarily designed it that way; it accumulates, one reasonable decision at a time.
Then an incident happens, and the cause isn't always contained within one server. The app may be slow because the database server is out of disk space, and the disk may be full because of a nightly job running somewhere else. If every server has a different access path and its records are scattered, finding that chain becomes difficult. Work across those environments from one place and an agent can see more of the picture too, pulling together logs and system state while narrowing down the cause.
There's one more thing worth doing: write down how your infrastructure is put together. Which server does what, where each service is installed, which application talks to which database. Even a basic map like this can noticeably improve how accurately an agent works, because it doesn't have to rediscover the environment from scratch every time. That document matters for people too. Infrastructure built by an agent that nobody on the team understands is not a good place to end up, and if the structure is documented, the next person who joins has something concrete to follow.
None of this is only for AI agents, either. The same structure still works when you add teammates or bring in an outside developer: open the access that person needs, close it when the work is done. On a small team, sharing a single SSH key can look like the simplest option in the world, but it stops being simple once more people are involved. Who has which key? Which servers can each key reach? Is the key belonging to someone who left the company still active? Cleaning up one controlled access path is one thing; cleaning up after several people already hold copies of credentials is a much larger job.
So when should you start running your own?
If you still don't know whether the product will work, there's usually no reason to move. Use the free tier, and spend the hours you would have put into infrastructure on the product instead. Once people are genuinely using the product and you can see revenue or steady traffic, the calculation begins to change. At that point, you can compare costs and decide how much control you want over the data and infrastructure.
There used to be one condition waiting at the end of that decision: can we actually operate this ourselves? That condition is starting to change. Deployment tooling is absorbing more of the repetitive setup, while AI agents are lowering the knowledge barrier.
And when any of the following starts to happen, it's time to think seriously about access and execution, regardless of where the servers themselves live.
- Someone besides you starts connecting to the servers
- An AI agent starts working without someone watching it the entire time
- You begin handling data that is difficult to recreate or belongs to real customers
- A customer's security review or audit asks you to explain who can access the servers and the data
What is actually left to decide
Why teams start on managed platforms is straightforward. You don't want to invest heavily in infrastructure before you know the product is real, and managed platforms let you ship without deep infrastructure expertise. Later, cost gets your attention. Later still, the question becomes how much control you want over your data and infrastructure.
And when you consider moving, you run into the same problem: the infrastructure capability you didn't need in order to start is the capability you suddenly need in order to leave. That bottleneck is starting to move. Deployment tooling is taking away repetitive setup work, and AI agents are lowering the knowledge barrier.
What's left isn't doing every infrastructure task by hand. It's deciding what to hand over, and where a person should be asked to step in. Maybe what a small team needs isn't someone watching the servers full time, but a place where execution stops at the moments that matter and a person gets to decide. Build that, and a small team can run its own servers with far less operational overhead than before.
