InstaPods vs Birta: Do You Need a Server, or Just a Site?

The short answer

Start with the thing most comparisons in this category get wrong. InstaPods is not a neighbouring product to Birta. Its own quickstart lists the runtime presets, and the first one is Static, "HTML/CSS/JS served by nginx", sitting next to PHP, Node.js and Python, with Go documented on its own page. It serves the same files Birta serves, and then it keeps going: a real Linux pod, SSH, environment variables, logs, and MySQL, PostgreSQL or Redis from the $7 plan up.

So the comparison is short, and one question settles most of it. Does the thing you are publishing need a server?

If it does, use InstaPods. Nothing further down this page changes that. Birta publishes static files and only static files, which is a deliberate boundary rather than a gap we're closing.

If it doesn't, the fork gets narrower and more interesting, and that's what the rest of this is about.

One thing to settle first, because search results blur it badly. This page is about instapods.com, the app host. Search the name on its own and half the results are about something else: an unrelated Instagram engagement app that shares it, and the older slang sense of "Instagram pods", groups who trade likes and comments with each other. Different subject, no connection to the company here.

What each side costs

Both price lists below were read from the vendors' own pages on 5 September 2026. This category moves fast, so check them before you decide anything.

InstaPods sells five plans: Launch at $3 a month (1 CPU, 512 MB, 10 GB), Build at $7 (2 CPU, 2 GB, 25 GB), Grow at $15, Scale at $25 and Turbo at $49. Every one of them includes SSH and custom domains, and the domain documentation puts the ceiling at five per pod with Let's Encrypt certificates that are issued and renewed automatically. Databases start at Build.

There is no free tier. New accounts get $10 in credit when a card is added, which is about three months of Launch.

That last sentence needs a qualifier, and it's a real one rather than a technicality. InstaPods documents a free trial pod: if an AI assistant tries to deploy for somebody with no payment method on file, the system quietly grants a real pod on a real HTTPS URL instead of refusing. It runs on the Launch plan, lasts 90 minutes, is one per person, and is deleted if nobody claims it with a card. So you can get a site live through your assistant without paying. You just can't leave it there.

Birta's free tier is a different shape. It's free indefinitely and it isn't a trial: 50 projects at 25 MB each, no card involved. What it holds back is specific. There's no custom domain at all, a "made in Birta" badge sits fixed in the corner of every published page and can't be switched off, and 10 form submissions per project per month are readable. Solo is $12 a month for one custom domain, 100 MB per project, 100 leads and no badge. Pro is $39 for five domains, 200 MB and no lead cap.

Put the two domain numbers side by side and the row goes to InstaPods, by four times. $3 a month there includes the domain and the certificate; $12 a month here is the price of the first one. If the domain bill is what you are optimising, that row settles it.

One row goes the other way, and it's the one nobody's marketing puts together. InstaPods bills per pod: the billing page shows a monthly rate and a prorated amount for each one, and stopping a pod doesn't stop the charge, only deleting it does. A second pod is a second $3. On Birta a second project is still inside the same free 50.

What each agent connection can reach

An agent can drive both of these, and InstaPods' side of it is properly built.

InstaPods runs an MCP server at app.instapods.com/api/mcp, ships it as a published Claude connector, and documents it as working with Claude.ai custom connectors, Claude Desktop, or any client that speaks remote MCP. The tool reference lists 21 tools. Through them an assistant creates a pod, deploys code, reads and writes files, runs shell commands, sets environment variables, pulls logs, changes plan and deletes the pod when it's done. Add the trial pod above and an agent can take somebody from nothing to a live HTTPS address without a payment step anywhere in the conversation.

Twenty-one is a long list, and it traces the InstaPods dashboard. All 21 tools point at one running pod: its files, its shell, its environment variables, its logs, the feedback left on the pages it is serving right now.

Your agent already reads a folder off your disk. It already fetches a document or a page by its link, and it already turns whatever it finds into HTML. What a host adds is everything that starts once the files exist: an address, a record of what was published, a way back to it. That's the surface worth comparing.

On that surface, as of 6 September 2026, InstaPods' documented tool reference lists nothing for deploy history, rollback, versions or backups.

Those features do exist, and this is where the row stops being a win. InstaPods says its dashboard shows the deploy history and that clicking any previous deploy rolls back instantly, because the previous build is kept. Every pod also gets a daily backup, with retention by plan: one on Launch, five on Build, up to thirty on Turbo. A restore is destructive and can't be undone.

What decides this is where the history lives. On InstaPods it lives in the panel a person opens, and the connector reaches around that panel rather than into it: it hands the agent the ability to write files onto a running server, so undoing a bad write means writing over it again or opening the dashboard yourself.

Birta is arranged the other way. The agent connection is the primary way the product is used, not an extra route onto the panel, so publishing is a version rather than a file copy and the version tools sit in the same connection as the file tools. The same conversation that broke the site can list what was published before and put an earlier version back, files intact. The last 10 stay available, and each one downloads as a single archive.

Both are defensible. If you are the one deploying and you like a panel, InstaPods' arrangement is fine. If the thing doing the work is an assistant, the version it can reach is the version it can undo.

Send a version out for review

The same axis has a second half, and it's the one people notice on client work. Before a page is public, somebody usually has to look at it and say what's wrong.

On Birta a version has its own address. create_version returns it when the draft opens, publish_version returns it again, and it keeps working after the site is live. You send that link to whoever signs the work off.

They don't need an account. Version access defaults to link (DEFAULT_VERSION_ACCESS in packages/publish/src/projects-access.ts), so a guest who opens the address passes a signed handoff and gets a nickname to sign remarks with.

Then they mark up the page in the browser. Click the heading, the button or the paragraph that's wrong, type the remark, and it lands as a numbered pin on that element. Each thread carries its number, the page and the element it sits on, whether it's open or closed, and every message in it with an author and a time. The numbering isn't recycled, so "fix number 3" still points at the same pin a week later.

Your agent reads the threads with list_version_comments, changes the same draft, and publishes a new version. It can't reply in a thread or close one: that write returns a 403, and resolving stays with the person who wrote the remark. Birta's own tool text says it to the agent directly, on the way out of create_version: the owner "may mark remarks on the page — read them with list_version_comments, make the changes in this same draft, and tell them to refresh the same page."

Everyone with access also gets one email digest of the remarks, roughly 15 minutes after the first one lands. None of this is gated by plan, so it works on the free tier. The remarks guide is the whole loop in four steps.

InstaPods has something adjacent here, and a fair page says so before claiming anything. Its feedback documentation describes a pinned-comment widget injected into the pages a pod serves: a visitor clicks a spot, leaves a note with an optional name and email, and needs no account. Visibility can be set to everyone or to people holding a share link, and an agent reads the notes with list_feedback and triages them with manage_feedback, which is more than Birta's agent may do with a remark.

What differs is what a note is attached to. On InstaPods it's collected on the running pod, described as visitor feedback, one-way, with no thread to answer in and nothing tying it to a deploy. On Birta the remark belongs to version 7, marked up before version 7 is the site anyone can find, and the conversation that reads it can publish version 8 or put version 6 back.

Compare the work after the first publish

Count that honestly and InstaPods takes more rows than Birta does. It's the broader product and it's cheaper for a domain. The rows Birta takes are fewer, and they sit in one place: what happens to a static site after it's published, all of it reachable from the connection the agent already has.

Use InstaPods when...

Use it whenever the site has a back end, or is about to. A contact form you want to handle yourself, a login, an admin page, a cron job, anything reading from a database. Birta has no answer to any of that and isn't going to.

Use it when you need a database. MySQL, PostgreSQL and Redis are documented services from the $7 plan, running on the same pod as the app.

Use it when you want a shell. SSH is on every plan, the browser terminal and IDE are there, and logs come back through the connector. For anyone who debugs by looking at the box, that's the whole argument.

Use it for a single-page app. This one is worth spelling out, because it's the place where a static host quietly fails. InstaPods' static preset docs default nginx to try_files $uri $uri/ =404 and tell you to change it so unknown paths fall back to index.html and your JavaScript router takes over. Birta has no equivalent. An ordinary multi-page static site works here, because a directory URL resolves to that directory's index.html, but a browser-routed app with one file at the root will load at / and 404 everywhere else.

And use it when the domain decides it. If you need your own name on the site and $9 a month is the difference, InstaPods costs a quarter of what Birta does for that.

Birta fits better when...

Birta fits when the output really is static files and there's nothing behind them. A landing page, a portfolio, a client site, a set of docs. If that's the whole job, a Linux pod is a machine you now have to think about.

Choose it when the site should stay up for free. Not for 90 minutes, not for three months of credit, but indefinitely, without a card. Fifty of them, if it comes to that. Agencies and freelancers with a shelf of small client sites feel this row more than anyone.

Choose it when the agent needs to be able to undo its own work. Every publish becomes a version, the last 10 stay available, and any of them can go live again with the original files. Crucially the agent can reach that from the same conversation, so "put yesterday's version back" is something you say rather than something you go and do.

Choose it when the work has to be signed off by somebody else. A client, a partner, an editor. You send them the version's address, they mark up the page where it's wrong, and your agent reads the remarks and publishes the correction. Nobody installs anything and nobody signs up.

Choose it when a real lead form belongs on the site and you'd rather not build one. The agent declares the fields, submissions land in the project's panel, and everyone with access gets an email digest roughly 15 minutes after the first one arrives. On a server you'd write that yourself, which is more control and more work.

The tradeoff is not subtle and it's stated above: the free tier carries a badge you can't remove and can't take a custom domain, the first domain costs $12 a month, and there's no server of any kind. Taking a payment on your own site isn't there yet either, at any tier. What none of that touches is the loop the rows above describe. The publish, the previous version and the client's sign-off all stay inside the conversation you are already having.

If you're moving

Whichever direction you're going, this is easier than most migrations, because a static site is just your own files. There's no export step and no proprietary format to unpick on either side.

1. Step 1Take the filesCopy the site's HTML, CSS, JS and images out. On Birta every visible version downloads as one archive; on InstaPods pull them over SSH or through the connector.
2. Step 2Publish through the agentHand the folder to your assistant and have it publish to the other service. Both accept a folder of files directly.
3. Step 3Check, then move the domainWalk every page and any form before touching DNS. Repoint the domain last, once the new copy passes.

Two things won't travel. Anything server-side you built on InstaPods, which is the point of having been there, and any form on Birta, which is tied to the project rather than the page.

The decision

If the site needs a server, InstaPods is the answer and the rest of this page is detail. It runs static files as well as Birta does, adds everything Birta deliberately doesn't have, and includes a custom domain at a quarter of the price.

If the site is static and stays that way, the fork comes down to three things: whether you want it published free and permanently rather than at $3 a pod, whether the agent doing the work should be able to put the previous version back on its own, and whether somebody has to review the page before it's public.

Frequently asked questions