Scroll Sites is a serious Confluence publishing product. The question is whether its pricing model fits the size of your publishing need.

If you are comparing Confluence publishing options, Scroll Sites will probably appear quickly. It is built by K15t, the team behind well-known Scroll products for Confluence. It is designed to help teams publish branded websites, documentation, help centres, blogs, and public content from Confluence.

For many documentation teams, that is exactly the kind of product they are looking for.

But pricing is where some teams need to slow down and think carefully.

How Scroll Sites pricing works

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

That means the price is connected to your Confluence user count, not simply the number of people who actively publish external documentation.

This also fits the broader Atlassian Marketplace pattern. Atlassian’s billing documentation says 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.

In plain English: your publishing app cost can grow as your Confluence site grows, even if your publishing team stays small.

When Scroll Sites pricing can make sense

There are plenty of cases where this model can be completely reasonable.

If Confluence is your main documentation platform, and many teams depend on external publishing, then a full Confluence publishing product may be worth it. If you need branded documentation sites, a complete publishing workflow, structured content, navigation, a polished help centre, and a mature Confluence publishing operation, Scroll Sites may be a strong fit.

In that case, the app is not just solving one narrow problem. It is part of how your organisation publishes and manages documentation.

When it may feel expensive

The pricing conversation changes when your Confluence instance is large but your external publishing use case is small.

Imagine a company with hundreds or thousands of Confluence users. The business may only need a few people to publish selected pages externally. Those pages might be release notes, setup guides, security FAQs, product documentation, onboarding content, or a trust centre.

The value is real. But the buying team may still ask a fair question:

If only a handful of people publish content, do we need a publishing tool priced around every licensed Confluence user?

That is not a criticism of Scroll Sites. It is a fit question.

Questions to ask before buying

Before choosing any Confluence publishing tool, ask these questions:

  • How many licensed Confluence users do we have?
  • How many people will actually publish external content?
  • How many external pages or hubs do we need?
  • Do we need a full documentation publishing platform?
  • Or do we mainly need a clean way to publish selected Confluence pages?
  • Is our main pain branding and documentation operations, or copy/paste drift and external sharing?

Those questions help you separate platform needs from lightweight publishing needs.

Where Satori Cloud fits

Satori Cloud is being built for teams that want a narrower workflow: publish selected Confluence pages externally, keep Confluence as the source of truth, and avoid stale PDFs or copied CMS pages.

It is not trying to be the heaviest Confluence publishing suite. It is trying to be the cleaner option for teams who know exactly what they want to publish and do not want the buying decision to feel bigger than the problem.

If you need a full publishing platform, Scroll Sites may be the right answer. If you need lightweight external publishing from selected Confluence pages, Satori Cloud may be closer to the job.

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