---
title: "Payload CMS Alternative: Flat-Rate Managed Hosting"
description: "Figma acquired Payload on June 17, 2025. As of July 2026, Payload's
own cloud-pricing page states that new-project deployment on Payload
Cloud is \"currently paused,\" so a team starting a new project..."
url: "https://adaptocms.com/articles/payload-cms-alternative/"
category: "Comparisons"
date: "2026-07-07"
source: adaptocms.com
---

# Payload CMS Alternative: Flat-Rate Managed Hosting

## TL;DR

Figma acquired Payload on June 17, 2025. As of July 2026, Payload's own cloud-pricing page states that new-project deployment on Payload Cloud is "currently paused," so a team starting a new project today has to self-host. Self-hosting Payload's core stays free under the MIT license, and the maintainers have publicly reaffirmed that commitment. Free covers the software license only: you still run the database, object storage, backups, upgrades, and a CDN for media yourself. Adapto CMS is a managed alternative built around one flat published price. A media CDN and unlimited contributors come with every tier, for a team that wants Payload's data-modeling approach without owning the infrastructure underneath it.

## The short answer: who Payload suits, and who needs a managed alternative

Payload suits a team with an engineer who wants a TypeScript-native CMS that lives in the same repo as a Next.js app, defines content as code, and is willing to run the infrastructure underneath it in exchange for full control. If your Next.js app already needs a server anyway, Payload's self-hosted model costs you engineering time instead of a subscription fee.

A managed alternative fits better if a database and object storage shouldn't be your team's responsibility, or if you found out Payload Cloud isn't taking new projects and want a published price and a bundled CDN instead of standing up infrastructure to get started.

## The timeline since Figma bought Payload (June 17, 2025)

Figma announced its acquisition of Payload on June 17, 2025 (figma.com/blog, payloadcms.com/posts/blog/payload-is-joining-figma).

Payload's core stays open source under the MIT license, and a Payload maintainer publicly reaffirmed that commitment after the deal closed (github.com/payloadcms/payload/discussions/12843). Self-hosting Payload today costs the same as it did before the acquisition: nothing, beyond your own infrastructure.

As of July 2026, Payload's cloud-pricing page states that new-project deployment on Payload Cloud is "currently paused" (payloadcms.com/cloud-pricing). A team starting a new Payload project today has one deployment path: self-host it. There's no published date for when, or whether, new signups reopen. Check the live page before you plan around it.

Figma has also said it's steering Payload toward Figma Sites and Figma's own CMS tooling, aimed more at designers and marketers building sites in Figma than at developers running a standalone content API (figma.com/blog). Figma hasn't published a developer roadmap for Payload beyond that statement.

## Payload's model today: free, MIT, and yours to run

Strip away the acquisition news and Payload's underlying deal hasn't changed: the framework is free, MIT-licensed, and self-hosted (payloadcms.com/get-started). You install it into a Node project, point it at a database (Postgres, MongoDB, or SQLite), and it runs as part of your own application.

Free, in this context, describes the software license. The database, object storage, backups, and the CDN in front of your media all still need someone to run them, and that someone is your team. Self-hosting Payload puts you on the hook for:

-   A database to provision, back up, and scale as content grows.
-   Object storage for uploaded media, plus whatever CDN you wire up in front of it.
-   Server capacity and deploys, since there's no managed hosting layer taking new signups right now.
-   Version upgrades, which land on your team's schedule instead of a vendor's release calendar.

## The mechanics gap: what self-hosting doesn't include

Compare that model against what a managed CMS bundles in.

**No bundled media CDN.** Payload doesn't ship image optimization and global delivery for uploaded media. You wire up your own storage adapter and, if you want fast image delivery, a CDN in front of it. Strapi has the same gap: its Media Library writes to local disk by default, and teams commonly add Cloudinary, Imgix, or S3 plus a CDN on top (docs.strapi.io). It's a familiar pattern for anyone who's run Strapi, and it applies to self-hosted Payload too.

**No managed uptime, and the ops work never stops.** With Payload Cloud paused for new projects, there's no managed hosting tier standing behind your uptime. A server going down at 2 a.m. lands on your team's on-call rotation. Backups and version upgrades don't happen once either; they're recurring work that scales with how many Payload projects your team runs and how long you keep each one alive.

Self-hosted frameworks make this tradeoff by design: full control over the stack, in exchange for the operational work a managed platform would otherwise absorb. The infrastructure work moves from vendor to your team; the code Payload ships doesn't change.

## Adapto's contrast: managed, flat-rate, no ops

Adapto CMS takes the other side of that tradeoff. It's a managed SaaS: content lives in Adapto, your frontend reads it over a REST API, and there's no server, database, or storage bucket for your team to run.

Pricing runs flat and published, from Hobby at $29/month up to Professional at $449/month, priced by usage: records, API calls, and bandwidth. A media CDN with image optimization is built into every tier (`media.adaptocms.com`), so there's no second Cloudinary bill to negotiate. Contributors are unlimited too: adding a teammate or a client stakeholder doesn't change your bill, unlike the per-seat pricing most CMS vendors charge. Full tiers and current pricing are published at [Adapto's pricing](/#pricing).

If your stack already leans on AI-assisted or CI-driven workflows, Adapto ships a CLI built for that: [agent and CI workflows](/docs/cli-ai-agents/) covers creating, updating, and translating content non-interactively, without a human clicking through an admin panel. If you're moving content out of an existing CMS, whether that's Payload, Strapi, or something else, [migrating content into Adapto](/docs/migrating-content/) walks through the import path.

The tradeoff runs the opposite direction from Payload's: you give up the "content lives in your own repo, deployed with your own app" model. In exchange, you stop running the database and the media CDN yourself, backups included.

## Strapi vs. Payload, if you're set on self-hosting

If self-hosting is the plan regardless of which framework you pick, Strapi and Payload land in a similar place operationally: both are open source and run on infrastructure you provision, and neither bundles a media CDN by default. [Our Strapi comparison](/strapi-alternative/) covers Strapi's self-hosting mechanics in detail, including the two-track pricing (a CMS license plus separate Cloud hosting) that trips up teams comparing the two.

The two frameworks differ mostly on developer experience. Payload is TypeScript-native and defines content as code that lives alongside a Next.js app, which suits a team that wants schema changes reviewed in a pull request. Strapi's admin panel and plugin ecosystem suit a team that wants a more conventional CMS UI layered on top of the same self-hosting tradeoffs. Either way, the database and backups stay on you.

## Honest note: when self-hosting Payload is still the right call

Self-hosting Payload makes sense when your team already runs infrastructure for other reasons: a Next.js app on a server you control, and an engineer who owns deploys and prefers content-as-code over an admin UI. In that setup, Payload's self-host model doesn't add much marginal ops work, because the operational muscle already exists.

It's a harder call when you're standing up infrastructure for the CMS alone: provisioning a database and wiring a CDN to get an editor live for a small team. That's the ops burden a managed platform is built to remove. Price the engineering hours against a flat monthly rate before you commit either way.

## FAQ

### Is Payload CMS still free after Figma acquired it?

Yes, for self-hosting. Payload's core remains open source under the MIT license, and a Payload maintainer publicly reaffirmed that commitment after Figma's acquisition closed on June 17, 2025 (github.com/payloadcms/payload/discussions/12843). Free applies to the software; the database, storage, and server you run it on are still your cost.

### Can I still sign up for Payload Cloud?

Not for a new project, as of July 2026. Payload's own cloud-pricing page states that new-project deployment on Payload Cloud is "currently paused" (payloadcms.com/cloud-pricing). New projects need to self-host until that changes, if it does.

### What happened to Payload now that Figma owns it?

Figma acquired Payload on June 17, 2025 (figma.com/blog). Since then, Payload's open-source core has stayed free and MIT-licensed, and Payload Cloud has paused new-project signups. Figma has also said it's steering Payload toward Figma Sites and Figma's own CMS tooling. The self-hosted path hasn't changed; the managed path is currently closed to new customers.

### Strapi vs. Payload: which is easier to self-host?

Ops-wise, they're close. Payload's content-as-code, TypeScript-native model fits a team that wants schema changes reviewed in a pull request. Strapi's admin panel and plugin ecosystem fit a team that wants a conventional CMS interface. Whichever you pick, you're still running the server and database yourself, with no bundled CDN either way.