Is there some way to limit the size that is allowed for Confluence page creation?

[david cockrell]

Dear Confluence Experts,

First, to give some background to my concerns and my question... 

I am a Confluence System Admin of a very large Confluence instance. 

We see growing number of users manipulating the content via API using personal tokens and even via non-authorized MCP servers.

Should I be concerned? 

What risks should I be aware of, what potential impact and are there any suggestions to mitigate? 

Recently we realized that occasionally the Content queue got stuck for quite some time
when analyzing, we found that it was due to very large pages that were auto-created via via personal token

To protect the system from such incidents and guaranty stability and performance, I wonder is there some way to limit the size that is allowed for Confluence page creation 

[Arkadiusz Wroblewski · Accepted solution]

Hello @david cockrell 

David, I’d definitely share your concern. In a large Data Center environment, uncontrolled scripts or MCP-style tools can really hammer your indexing queue and bloat the database before you even realize what’s happening. It’s not just the API usage itself that's the problem; it’s the potential for indexing backlogs and hard-to-govern data exposure.

To answer your specific question, there actually isn't a direct Confluence setting to limit the size of a page body. You have the attachment size limit, but that won't touch the actual text content of a page. There is a technical "sledgehammer" you could use—the -Datlassian.rest.request.maxsize system property—but I’d be extremely cautious with it. Since it’s a global REST limit, lowering it to stop a rogue script could easily break legitimate integrations, marketplace apps, or even standard site imports.

A much safer and more effective route is to lean on native Rate Limiting. It’s designed specifically to protect DC instances from REST-heavy automations that go off the rails. Beyond that, I’d look at tightening your Personal Access Token (PAT) governance. Forcing expiry dates, limiting the number of tokens per user, and requiring reviewed service accounts for any "official" automation will give you way more control than a single page-size setting ever could.

If users are connecting external tools via PATs, you're also looking at a significant security and governance topic, as those tools are acting with that user's full permissions. Monitoring your access logs to identify high-volume REST users is usually the best way to catch these issues before they impact the rest of the team. Use rate limiting to protect the instance and PAT governance to protect the data.

[Aron Gombas _Midori_ · Accepted solution]

@david cockrell 

Confluence does not have a built-in setting to enforce a maximum page body size.

You could use reverse proxy request size limits, instead. If you're running Data Center behind a reverse proxy like nginx or Apache, you can set a maximum request body size on the API endpoints (e.g., nginx's client_max_body_size or Apache's LimitRequestBody). This is probably the most direct way to reject oversized page creation requests before they even reach Confluence. It could be a solution to limit the size of a single request.

But, there is the additional problem with the frequency of requests. IMO rate limits alone are not sufficient to handle this. You can easily fit the rate limits, yet make Confluence useless if you create a new page in every 10 seconds...