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

The short answer

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", next to PHP, Node.js and Python. It serves the same files Birta serves, then keeps going: a real Linux pod, SSH, environment variables, logs, and MySQL, PostgreSQL or Redis from the $7 plan up.

So one question settles most of it. Does the thing you are publishing need a server? If it does, use InstaPods, and nothing below changes that. Birta publishes static files and only static files, by design. If it does not, the fork gets narrower, and that is the rest of this page.

One thing to settle first, because search results blur it. This is about instapods.com, the app host, not the unrelated Instagram engagement app of the same name or the older "Instagram pods" slang.

What each side costs

Both price lists come from the vendors' own pages, and the category moves fast.

InstaPods sells five plans: Launch $3 (1 CPU, 512 MB, 10 GB), Build $7 (2 CPU, 2 GB, 25 GB), Grow $15, Scale $25, Turbo $49. All include SSH and custom domains, up to five per pod with Let's Encrypt certificates issued and renewed automatically. Databases start at Build. No free tier: a new account gets $10 in credit when a card is added, about three months of Launch.

One qualifier. InstaPods documents a free trial pod: if an assistant tries to deploy for somebody with no payment method, the system grants a real pod on a real HTTPS URL instead of refusing. Launch plan, 90 minutes, one per person, deleted unless somebody claims it with a card. So you can get a site live through your assistant without paying. You just cannot leave it there.

Birta's Free plan is free indefinitely and is not a trial, no card. It connects your own domain, carries the lead form, remarks and versions, and puts a Birta mark in the corner. Team, at $12 a month, removes the mark and adds shared context, more people and more room for a team on one project.

The domain row goes to Birta: a domain you own connects for free, where InstaPods' cheapest is $3 a month. The billing row too, because InstaPods bills per pod and stopping a pod does not stop the charge, only deleting it does. A second pod is a second $3; a second Birta project is still on the Free plan.

What each agent connection can reach

An agent can drive both, and InstaPods' side is properly built. It runs an MCP server at app.instapods.com/api/mcp, ships it as a published Claude connector, and documents it for Claude.ai custom connectors, Claude Desktop, or any remote-MCP client. The tool reference lists 21 tools: create a pod, deploy code, read and write files, run shell commands, set environment variables, pull logs, change plan, delete the pod. With the trial pod, an agent takes somebody from nothing to a live HTTPS address with no payment step. All 21 point at one running pod: its files, its shell, its variables, its logs, the feedback on the pages it serves right now.

What a host adds starts once the files exist: an address, a record of what was published, a way back to it. That is the surface worth comparing. On it, the documented tool reference lists nothing for deploy history, rollback, versions or backups.

Those features do exist, which is where the row stops being a win. InstaPods says its dashboard shows deploy history and that clicking a previous deploy rolls back instantly, because the previous build is kept. Every pod also gets a daily backup, retained one on Launch, five on Build, thirty on Turbo, and a restore is destructive.

So the question is where the history lives. On InstaPods it lives in the panel, and the connector reaches around that panel rather than into it: the agent writes files onto a running server, so undoing a bad write means writing over it again. On Birta publishing is a version, and the version tools sit beside the file tools for Birta's own agent and a connected one alike, so the conversation that broke the site can put an earlier version back with its files intact. The last 10 stay, each downloadable as one archive.

If you deploy and you like a panel, InstaPods' arrangement is fine. If an assistant does the work, the version it can reach is the version it can undo.

Send a version out for review

The same axis has a second half, the one people notice on client work. Before a page is public, somebody has to say what is wrong with it.

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 need no account: version access defaults to link, so a guest gets a nickname and marks the page up in the browser. Click the heading, button or paragraph that is wrong, type the remark, and it lands as a numbered pin on that element, the thread carrying its number, whether it is open, and every message with author and time. Numbering is not recycled, so "fix number 3" points at the same pin a week later.

The agent reads the threads with list_version_comments, changes the same draft and publishes, then replies in the thread and closes it with a note on what changed. Everyone with access gets one email digest roughly 15 minutes after the first remark, and no plan gates any of it. The remarks guide is the loop in four steps.

InstaPods has something adjacent, and a fair page says so. 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. An agent reads notes with list_feedback and triages them with manage_feedback.

What differs is what the note attaches to. On InstaPods it is collected on the running pod, one-way, with 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 honestly and InstaPods takes more rows. It is the broader product, and its pages carry no vendor mark. The rows Birta takes are fewer and sit in one place: what happens to a static site after it is published, all of it reachable by the same agent.

Use InstaPods when...

Use it whenever the site has a back end, or is about to: a contact form you handle yourself, a login, an admin page, a cron job, anything reading from a database.

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

Use it when you want a shell. SSH is on every plan, with a browser terminal, an IDE and logs through the connector.

Use it for a single-page app whose addresses have to stay regular paths. 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. Birta has no equivalent line. A single-page app can be published. Its in-app navigation has to run through #: with regular paths, opening or refreshing any path other than the root returns “page not found”.

Birta fits better when...

Birta fits when the output really is static files with nothing behind them: a landing page, a portfolio, a client site, a set of docs. If that is 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 90 minutes, not three months of credit, but indefinitely without a card, on your own domain.

Choose it when the agent needs to undo its own work. Every publish becomes a version, the last 10 stay available, and any goes live again with the original files, from the same conversation.

Choose it when somebody else signs the work off. You send the version address, they mark up the page where it is wrong, the agent reads the remarks and publishes the correction.

Choose it when a real lead form belongs on the site and you would rather not build one. The agent declares the fields and submissions land in the panel.

The tradeoff: the free page carries a Birta mark that only Team removes, there is no server of any kind, and payments are not there yet at any tier.

If you're moving

Either direction is easier than most migrations, because a static site is your own files. No export step, no proprietary format 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, or attach the files in Birta's chat, and have it publish to the other service.
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 will not travel: anything server-side you built on InstaPods, which was the point of being there, and any Birta form, which belongs 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 and adds everything Birta deliberately does not have.

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

Frequently asked questions