Set-PSUCache -Integrated fails with "Request body too large" (30000000 bytes) - no documented way to raise the limit

Hello Laurie,

Thank you for the clear report.

Is there a supported way to raise the limit? Not in 2026.3.3. With -Integrated, Set-PSUCache does not go through the web server you configured: it uses PowerShell Universal's internal loopback connection, which keeps Kestrel's built-in limit of 30,000,000 bytes and does not take its Kestrel limits from appsettings.json. That is why Kestrel:Limits:MaxRequestBodySize made no difference. Our developers have since raised the limit on that internal connection, and the change is planned for an upcoming update. It is not in a public build yet.

Until then, each item has to fit under that limit after Set-PSUCache serializes it. The cmdlet stores the value as CLIXML (at -Depth 1 unless you pass -Depth), so you can check an item's size before caching it with the command below (replace 1 with your -Depth value if you pass one):

[Text.Encoding]::UTF8.GetByteCount([Management.Automation.PSSerializer]::Serialize($value, 1))

A result at or above about 30,000,000 will fail, so leave a margin.

For large data, objects are the expensive part. In our test, 60,000 small objects came to about 14.5 MB once serialized, while the same rows as one CSV string (for example $data | ConvertTo-Csv -NoTypeInformation | Out-String) came to about 3.1 MB. Caching the data as text and running ConvertFrom-Csv after reading it back can bring an item well under the limit. The trade-off is that every value comes back as a string, so numbers and dates need converting again. If one item is still too large as text, split it across several keys.

Kind regards,

Michel