Your whole company may use Confluence. But your whole company does not publish external documentation.

That is the tension behind a lot of Confluence publishing decisions. A business rolls Confluence out broadly across product, engineering, support, sales, operations, leadership, implementation, and customer success. Then a small group needs to turn a few useful pages into something external: release notes, product docs, onboarding guidance, a trust centre, or a customer knowledge base.

The need is narrow. The Confluence footprint is not.

The real pricing question is not “how many people use Confluence?”

It is “how many people actually need to publish Confluence content externally?”

Why Confluence publishing costs can feel strange

Many Confluence publishing tools are sold through the Atlassian Marketplace. Atlassian explains that Marketplace apps are generally priced based on the number of users in the Atlassian app. For example, if your Confluence Cloud site has 25 users, you pay the 25-user price for each installed Marketplace app.

K15t’s own Scroll Sites pricing documentation says the cost of a Scroll Sites for Confluence subscription is determined by the number of licensed Confluence users you have.

That can be perfectly reasonable for some teams. If your documentation operation is large, mature, and central to how many Confluence users work, a full publishing platform may be exactly what you need.

But for smaller publishing use cases, the economics can feel disconnected from the job. You may have 1,000 Confluence users, but only four people publishing public release notes. You may have 5,000 Confluence users, but only one team needs to maintain a customer-facing setup hub.

When user-based pricing makes sense

User-based pricing is not automatically wrong.

It can make sense when the publishing workflow is used widely across the organisation. It can make sense when many teams manage external documentation. It can make sense when the tool is a core part of a larger documentation platform with branded sites, navigation, versioning, permissions, workflows, templates, and operational controls.

In that scenario, you are not just buying a way to publish a few pages. You are buying a serious publishing system.

The problem is when a team does not need the whole system.

When it starts to feel like overkill

The pain usually appears in companies where Confluence is everywhere, but external publishing is owned by a tiny group.

Product marketing wants to publish a small set of product pages. Customer success wants a clean onboarding hub. Sales wants a polished link to send to prospects. Security wants a few pages that answer recurring buyer questions. Product wants public release notes without copying everything into a CMS.

These are valuable jobs. But they are not always big enough to justify treating every Confluence user as part of the publishing operation.

The buying question becomes simple: are you buying a full Confluence publishing platform, or do you need a lightweight way to publish selected Confluence pages?

The lightweight publishing alternative

A lightweight Confluence publishing tool should start from a different assumption.

It should not assume every Confluence user is a publisher. It should assume most people keep writing and maintaining content inside Confluence, while a small group chooses which pages are safe, useful, and polished enough to share externally.

That means the product should optimise for the publishing job itself:

  • Select the Confluence pages that should be external.
  • Turn them into a clean public-facing experience.
  • Keep Confluence as the source of truth.
  • Avoid copy/paste drift into documents, PDFs, or CMS pages.
  • Give buyers, customers, or partners one polished link.
  • Keep the workflow simple enough for a small team to own.

The Satori Cloud view

Satori Cloud is being built around a narrower idea: publish selected Confluence content externally without turning external publishing into a heavy platform decision.

That does not mean every team should avoid enterprise publishing suites. Some teams need them. But if your need is simpler — publish product docs, release notes, setup guides, a trust centre, or a prospect-facing hub from Confluence — then the tool should match that job.

Your whole company uses Confluence. Your whole company does not publish docs.

Your publishing setup should reflect that.

Sources: K15t Scroll Sites pricing documentation and Atlassian Marketplace app billing documentation.