New Postproxy pricing, and why

Scale moves to $99/mo and Enterprise to $699/mo for new subscriptions starting May 7. Existing customers keep their current price. Here's what changed and the stories behind the decision.

New Postproxy pricing, and why

Today we’re updating Postproxy pricing.

If you’re already a customer, nothing changes. Your current price stays exactly the same, including any future stacking on the Scale plan — every new item keeps the old price. We’re not raising pricing on existing accounts.

The change applies only to new Scale and Enterprise subscriptions and future upgrades.

What’s changing

  • Scale — $99/month
  • Enterprise — $699/month
  • Starter is now Build — still $17/month
  • Free — unchanged

Limits on posts and profile groups stay the same across all plans.

Pricing hadn’t moved since we launched. The product has. Back then Postproxy was a basic posting tool. Today it runs across multiple server locations, is more fault-tolerant, and has grown into a much broader publishing platform — comment management, post analytics, queues, webhooks, team management, more supported platforms, idempotent publishing, partial-success handling. We want the price to reflect what the product is actually worth now.

If you were already planning to upgrade, the old pricing is still good through today.

Why we still don’t charge per social account

This comes up regularly — “why don’t you charge per connected account, like Buffer and others do?” We’ve thought about it and decided not to, for one specific reason: it doesn’t fit how our customers actually use Postproxy.

For a Buffer-style user, per-account pricing is fine. You connect your own brands, you know how many accounts you have, you control the number. It maps cleanly to your workflow.

For a developer building a product on top of Postproxy, it doesn’t. Imagine a SaaS in early stages, running a free trial. They get a spike of signups from somewhere — a launch, a Hacker News post, whatever. New users connect their social accounts, poke around, decide it’s not for them, and leave. The accounts stay connected for a moment, but the value never materialized.

If that SaaS is on per-account pricing, every one of those abandoned trials costs them money they can’t predict or control. Five dollars per profile, four profiles per signup, a hundred signups in a day — that’s $2,000 of bill for users who never converted. The SaaS has no real lever to push back on it.

Profile groups give you a fixed quota you control. You can swap accounts in and out as trials come and go. Successful trials stay, unsuccessful ones get removed, and you stay inside the same plan. Your cost is bounded by the plan you chose, not by what your users do this week.

That’s the model that makes sense for the people building on us.

Why we feel comfortable with this price

Two things happened with Meta last week that explain it better than a feature list does.

Saturday: a Meta bug, two responses

On Saturday someone at Meta deployed a bug to their video processing. Reels posting via API started failing intermittently. Both us and Buffer reported it.

We took roughly an hour to ship a fix. Buffer waited a day for Meta to fix it on their side.

Our fix wasn’t magic. We pulled a sample of failed and successful videos and found one codec parameter (out of approximately 5 billion ffmpeg has) that influenced the outcome. We added transcoding to the pipeline, deployed it, and pushed the reels queue through. Our servers got a bit of a sweat, but we had the capacity. On Monday, after Meta fixed everything on their end, we switched the workaround off.

Why ship that hard, that fast? Because the promise is that we do everything we can to keep publishing working. If we can route around a platform bug, we will.

The other Meta issue: who eats the complexity

The second one is a recurring Meta problem — looks like a long-standing bug or maybe a feature, hard to tell. It comes and goes. We hit it back in April and spent about four hours figuring out a workaround. After that, no issues.

Some other publishing services in the space still have long-running incidents around this same problem, and at least one is now advising customers to fix it on their own CDN.

That last part is what stuck with me. We would never push that on a user. Yes, you still need to follow the basics — don’t send an image to a video post, that kind of thing. But asking customers to tune their CDN so Meta is happy? Most users don’t even control the CDN their content sits on. That’s our problem, not yours. You send us a request, we deal with the rest.

What you’re paying for

We’re not perfect. We have bugs. We make mistakes. What we commit to is that you don’t have to care about the technicalities underneath.

  • We monitor everything daily, weekends included.
  • We reach out proactively when something is blocking publishing.
  • When platforms break, we route around it where we can rather than waiting it out.
  • Support is always a human. No AI bot in the chat.

There are complexities that come with the territory — X has its ever-changing pricing model, Meta ships occasional regressions, OAuth tokens expire on weird schedules. But when it comes to “hey Postproxy, here’s the file, here’s the text, publish it there and there” — we make it our job to make that happen.

It’s all about attitude.

Thanks for using Postproxy.

Cheers, Denis

Ready to get started?

Start with our free plan and scale as your needs grow. No credit card required.