bom dia, sr.

já passei por isso q vc comentou, porém tomei decisões prévias e tive conhecimento mais embasado para decidir tecnicamente o que assumir, quais as contrapartidas (down sides, up sides). tem que colocar na balança.

quais processamentos acontecerão no server side do next.js?

é teu primeiro post, então não consegui entender teu nível de conhecimento em redes.

é necessário lembrar do modelo TCP/IP de redes. há camadas. estarei falando delas aqui.

na camada de aplicação, surgem diferentes regras entre aplicações, pois buscam diminuir as chances de spam e ataques de negação de serviço, ainda que acidentais.

antes de querer aumentar o valor de 2mb para 5mb ou 10mb, tem de entender, antes, se vale a pena para sua aplicação realizar tanto processamento no lado do servidor (back end).

considerando que acima fizemos o check out correto, podemos pensar em um processamento do lado do cliente.
como vc está trabalhando com imagens, vamos utilizar a biblioteca Brotli ou a Gzip, com a API nativa Web Workers do browser, a fim de processarmos imagens em paralelo, comprimimo-las e e enviarmo-las ao backend. caso n queira comprimi-las com brotli, vc vai ter de transformá-las em webp, utilizando conversão pela API nativa Canvas do browser.

cloudflare é um caso de sucesso para a lib Brotli, com imagens. vc n terá de se preocupar em salvar imagens como blob, mas tb pode.

fluxo:

2 ou mais imagens faz alocar web workers (processamento sm paralelo no lado do cliente) -> cada web worker vai chamar uma individual função de converter a imagem de PNG/JPG para WEBP, o que reduz tamanho KB/MB por imagem -> vai ter de transformá-la em base64, pois vamos manipular compressão por texto (preferencialmente, não obrigatoriamente, pois vc pode enviar por formData) -> comprima a string base64 utilizando Brotli ou GZip ou LZMK -> saindo de cada web worker, junte as compressões um array de objetos chave-valor -> envie em stream e com Promise.all para o back end do next.js, a fim de processá-los como um fluxo contínuo && E vc pode processá-los sob demanda migrando para um servidor node.js utilizando rabbitmq (filas) || OU você envie em stream com Promise.all para o back end do next.js simplesmente -> sugestão: descomprima de Brotli de volta para base64 WEBP -> sugestão: crie um bucket na firebase storage e armazene as imagens diretamente como webp -> sugestão: salve em um banco relacional ou em um nosql chave-valor como firebase firestore cada um daqueles links dos buckets, com uma boa descrição. -> talvez seja melhor: salve as strings brotli(base64(webp(png))) no firebase storage / firestore diretamente. talvez assim vc até agilize o processamento e não gaste serverless function em uma vercel-like company da vida.

pelo que estou notando, vc deveria comprar uma VPS de pelo menos 2 núcleos lógicos caso queira fazer altos processamentos de imagem, pois precisaríamos de realizá-los em paralelo CASO queira fazê-lo no lado do servidor por algum motivo.
para melhor controle do payload, que tal utilizar backend em nest.js (node.js, com express ou fastify), ou que tal utilizar Go para isso?

desta forma, vc vai conseguir processar imagens em paralelo no lado do cliente antes de enviar o conteúdo para o backend do next.js.

peço licença para poder perguntar:
por que vc está utilizando next.js?
qual problema o next.js está querendo resolver?
qual o tamanho dessas imagens? se forem avatares de usuário, poderíamos comprimir ainda mais na API Canvas para webp, já que o olho humano não enxergaria tanta diferença, com perda de qualidade imperceptível.
já possui um backend reservado?
já assina o plano Pro de uma vercel-like company? vai realmente preferir utilizar serverless functions?

podemos ver como teu projeto está ficando, apenas como um preview?

aguardo retorno.