How to Share a Confluence Knowledge Base With Customers

Your team already writes documentation in Confluence.

Internally, that works well. People can create pages together, organise them into spaces, review changes and keep everything up to date.

The problem often comes later:

How do you share that knowledge with your customers?

You could give customers access to Confluence. You could make pages public. You could maintain a separate help centre. Or you could publish your Confluence content somewhere else entirely.

The right option depends on what you're trying to achieve.

This guide explains the main approaches and where each one works best.

The first question: do your customers need to use Confluence?

This is the easiest way to narrow down your options.

There is a difference between:

collaborating with customers inside Confluence

and:

using Confluence to create information that customers consume somewhere else.

If a partner needs to comment on pages, edit content or work alongside your team, giving them some form of Confluence access might be exactly what you want.

But that's quite different from a customer who simply needs to:

• read your product documentation

• search your knowledge base

• follow setup instructions

• view policies or guides

• read release information

• find an answer to a support question

In those cases, your customers don't necessarily need Confluence at all.

They need the content that's stored in Confluence.

That distinction matters.

Option 1: Invite customers into Confluence as guests

Confluence supports guest users for external collaboration.

Guests are people outside your organisation who are given access to a Confluence space.

This works well when you genuinely want customers or partners working inside Confluence alongside your team.

For example, you might have a dedicated space for a major implementation project where your employees and a customer's project team need to collaborate.

Guest access works well when:

• you know exactly who needs access

• customers need to collaborate with your team

• customers need more than read-only documentation

• using the Confluence interface isn't a problem

• the content belongs in a dedicated space

It works less well when:

• you have hundreds or thousands of customers

• customers only need to read documentation

• you want your documentation to look like part of your own website

• you don't want customers thinking about Confluence accounts or Atlassian

For collaboration, guests make sense.

For a traditional customer-facing knowledge base, they can introduce unnecessary friction.

Option 2: Share individual Confluence pages with public links

Confluence also lets you create public links for individual pages.

Someone receiving the link can view the shared content without being given normal access to your Confluence site.

This is probably the simplest option if you occasionally need to send a customer one particular page.

For example:

"Here's our migration guide."

or:

"Here are the release notes for this version."

Public links are especially useful because the external visitor gets a simplified view of the page rather than your normal internal Confluence navigation.

There is an important limitation, though.

A public link shares the individual content item, not the branch of pages beneath it.

So if you have a knowledge base structured like this:

Getting Started
→ Installation
→ Configuration
→ User Management
→ Troubleshooting

sharing the Getting Started page doesn't automatically turn that entire structure into a browsable public documentation site.

You would need to share the relevant content individually.

Public links work well when:

• you need to share individual pages

• you want the fastest possible option

• the recipient doesn't need an account

• navigation between lots of documentation isn't important

They work less well when:

• you have an entire customer knowledge base

• customers need to browse between related pages

• navigation and hierarchy matter

• you want your own domain and branding

• you want the documentation to behave like a website

For occasional sharing, this may be all you need.

For a full documentation site, you'll probably want something more structured.

Option 3: Make a Confluence space publicly accessible

If you want to expose a larger collection of content, Confluence also supports anonymous access.

Instead of sharing individual public links, anonymous access can make content in a space available to people who aren't logged into Confluence.

This is much closer to a public knowledge base.

Atlassian itself suggests use cases such as support documentation, open knowledge bases and publicly available roadmaps.

It can therefore be a perfectly reasonable solution.

If you simply want:

"Everything in this Confluence space should be public."

then anonymous access may already solve the problem.

There are some trade-offs.

Anonymous access is genuinely public. Content made available this way can be accessed by people on the internet and can be indexed by search engines.

You're also still using Confluence as both:

the place where your team creates the documentation

and:

the experience through which customers consume it.

For some organisations that's fine.

For others, those are two separate requirements.

Option 4: Copy your Confluence content into a separate help centre

Another common approach is to keep Confluence internally and maintain a separate customer knowledge base.

That gives you much more control over the customer experience.

Your help centre can have:

• your branding

• your own navigation

• your website domain

• customer-oriented search

• support features

• analytics

• other customer-facing tools

There is one obvious downside.

You now have two places containing documentation.

Someone writes or updates something in Confluence, then somebody needs to make sure the customer-facing version is updated too.

For a small knowledge base this might not matter.

As the documentation grows, however, duplicated content creates another process your team has to maintain.

It also raises an awkward question:

Which version is the source of truth?

If your team already likes writing and managing documentation in Confluence, moving the publishing workflow elsewhere can create more work rather than less.

Option 5: Keep Confluence as the source and publish it as a separate website

There is another model:

Keep creating the content in Confluence, but separate Confluence from the website your customers see.

Your team continues working as normal:

Write in Confluence
→ Organise pages in Confluence
→ Review and update them in Confluence

The publishing layer then turns selected content into a separate customer-facing site:

Confluence
↓
Publishing layer
↓
Customer documentation website

This means Confluence remains your source of truth without requiring the customer experience to look or behave like Confluence.

This approach is useful when you want things like:

• a customer-facing knowledge base

• your own navigation

• a branded documentation site

• your own public URL

• selected Confluence content rather than an entire internal space

• different documentation for different customer audiences

It also removes the need to manually copy content into another system.

Which approach should you use?

There isn't one correct answer.

A useful rule of thumb is:

And these approaches aren't mutually exclusive.

You might use guests for implementation partners, public links for occasional sharing and a dedicated documentation site for your wider customer base.

The important thing is to start with what experience the customer needs, rather than simply asking how you can expose Confluence.

A simple way to make the decision

Ask these four questions.

1. Do customers need to edit or collaborate?

If yes, giving them controlled Confluence access is worth considering.

If they only need to read your documentation, they probably don't need to enter Confluence.

2. Are you sharing one page or a whole knowledge base?

A public link is extremely convenient for individual pages.

Once customers need to browse a structured collection of documentation, navigation becomes much more important.

3. Should the documentation feel like Confluence or like your product?

For some organisations, the Confluence experience is perfectly acceptable.

For others, documentation is part of the customer experience.

They want customers going to something like:

docs.yourcompany.com

rather than an Atlassian URL.

4. Do you want to maintain documentation in more than one place?

If your team already works comfortably in Confluence, duplicating everything into another help centre may create work you don't need.

In that case, keeping Confluence as your source of truth and publishing from it can be simpler.

How Satori Cloud approaches this

This is the problem I'm building Satori Cloud to solve.

The idea is deliberately simple:

Write and manage your documentation in Confluence. Publish the content your customers need as a separate website.

Your internal team continues using Confluence, while customers get a site designed for consuming documentation rather than editing it.

That means you don't have to choose between keeping Confluence and having customer-facing documentation.

Confluence can remain where you create the content.

Satori Cloud handles how you publish it.

Already managing customer documentation in Confluence?

See how Satori Cloud works