Open kkankala opened 3 years ago
Any update on this issue please?
@anthonychu
We are running into the same issue, would be great if the file limit could be increased. When can we expect a resolution?
hello, i'm also bumping into this issue -- we have a site that hosts around 25k files, largely statically generated content. can someone please provide guidance on timelines, etc? tks.
Also receiving this error, any known workarounds for it?
This seems true even for the Standard Plan, regardless that all files combined are only ~320MB.
@MaximRouiller Any thoughts?
FYI. Worked out kind of a workaround https://github.com/Azure/static-web-apps/issues/782#issuecomment-1186322614
This is still a problem. We might have to look into other solutions if this can't be resolved very soon.
Please fix this issue as soon as possible. It is so easy to increase the limit to 1 000 000. Why are you limiting us to only 15 000?
@ytodorov We solved it by building the app in Github Actions and just uploading the built artifacts.
name: Build and Deploy Job
steps:
- uses: actions/checkout@v3
with:
submodules: true
- uses: pnpm/action-setup@v2.2.2
with:
version: 7
- name: Setup node
uses: actions/setup-node@v3
with:
node-version: 16
token: ${{ secrets.GITHUB_TOKEN }}
cache: pnpm
- name: Install
run: pnpm install
- name: Build
run: pnpm run build
- name: Remove 'node_modules'
run: rm -rf node_modules/
- name: Build And Deploy
id: builddeploy
uses: Azure/static-web-apps-deploy@v1
with:
azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN }}
repo_token: ${{ secrets.GITHUB_TOKEN }}
action: "upload"
skip_app_build: true
app_location: "/build"
No, this will not work for me. My build artefacts contain more than 15 000 files. I am using https://nextjs.org/docs/advanced-features/static-html-export and my website has more than 15 000 HTML pages (Not to mention that It has 10000+ images which are separate files). Any ideas?
We have the same issue. Any updates on this?
There are no updates in regards to this. I tried to deploy a very simple application which doesn't exceed the 500MB quota on the Standard plan. The file quota is something in addition that is not properly documented anywhere. Incredibly frustrating. Azure Static Web Apps is not a reliable solution for hosting, unless it is purely static content.
Hi all, thanks for the feedback on this limitation. We're working on improving our content distribution, and are looking into increases to this limit which could come out of this engineering effort.
To help us better understand how many files need to be supported, can any of you share any repos or file count ranges that you would hope to see supported by Azure Static Web Apps?
Is there a reason to have a hard file limit, as long as it doesn't exceed the said quota? My use case was less than 30.000 html files - only real limit for practicality was the duration of the build and deploy.
Hi all, thanks for the feedback on this limitation. We're working on improving our content distribution, and are looking into increases to this limit which could come out of this engineering effort.
To help us better understand how many files need to be supported, can any of you share any repos or file count ranges that you would hope to see supported by Azure Static Web Apps?
? No one wants caps or limitations when the deployment artifacts remain under the quota (500 MB). This is definitely what I would expect when you pay for this service and don't have it anywhere documented that a file limit applies in the TOS. Why do you implement it anyway? Besides to annoy customers and have them first pay for Azure Static Web Apps and create CI/CD (which is still a pain 1 year into GA), only to realize they need to migrate to App Service.
Hi all, thanks for the feedback on this limitation. We're working on improving our content distribution, and are looking into increases to this limit which could come out of this engineering effort.
To help us better understand how many files need to be supported, can any of you share any repos or file count ranges that you would hope to see supported by Azure Static Web Apps?
Firstly call out this restriction/limitation Quotas in Azure Static Web Apps. Running swa start
works perfectly fine, it is when you do a swa deploy
it fails silently without any issue.
To your feedback, our use case would potentially have a million or so static files which are quite small in size. To be specific, we are generating documentation from various internal system and that can create a large number of html files.
In summary after spending a week on trying to figure out why swa deploy
failed, we won't be using static web apps. It is shame because we felt it had lot of nice options out of the box.
For many here,
We are looking at using Azure Storage Static Website in conjuction with Azure CDN (+ Custom Domain, SSL..) and traditional FunctionApp deployments which handles all of our use case. Considering our file sizes are smal, this works could be cheaper than Static Web Apps.
Hi all, thanks for the feedback on this limitation. We're working on improving our content distribution, and are looking into increases to this limit which could come out of this engineering effort.
To help us better understand how many files need to be supported, can any of you share any repos or file count ranges that you would hope to see supported by Azure Static Web Apps?
I have a site where we use DocFx to build a static web site, it out puts roughly 35,000 files and with downloadable assets (zip files, etc) that equal approximately 1.2GB in size.
I would suspect a Standard application, for paying customers, should have a plan for at least 50,000 files with 5GB of space. Perhaps that just wishful thinking. 😄
Our site uses around 30000 files and is approximately 1.7 GB in size. So I would also like to see at least 3GB with a generous file limit
Hey all. Is there some sort of timeline for when we can expect the limit to be increased (both in terms of bundle size and file count)?
Hi all, thanks for the feedback on this limitation. We're working on improving our content distribution, and are looking into increases to this limit which could come out of this engineering effort.
To help us better understand how many files need to be supported, can any of you share any repos or file count ranges that you would hope to see supported by Azure Static Web Apps?
our use case is having large model exporting to HTML files with images separately (20,000+) and accessed as HTML online report, so it would be at least 30,000 files when adding other contents in the app, so please increase the limitation ASAP!
@chcomley Is there any update you could provide? Will the file count increase? And bundle size as well? Thank you
Hey folks! We definitely see the ask here, so thanks all for chiming in with feedback. We're going to be adding the file count limitation to the quota page, and we're actively working on improving our content distribution to support this use case
It's there any work around to this? Anything that we could do to reduce the amount of files, like a tool or something?
When will this be fixed please? This is a pretty non-sensical arbitrary limit which is obviously causing issues to multiple clients (for GIS apps 15000 files is way too low for our needs).
Hi @thomasgauvin, do you have an update on the work happening here? Thank you!
@thomasgauvin any updates on this please? thanks
We've heard the feedback and have been putting in the infrastructural improvements to have increased limits across the board for Static Web Apps, whether that be number of staging envs, file counts, app sizes, etc. We're still some months away from this at this time, I will continue to provide status updates in this thread.
@thomasgauvin would you have any update on this? Three months have passed by in the meantime. Thanks.
Thanks for the ping @BertVandenberghe, at this time, we're setting the investments to have a new SKU that would address this need.
I see a new "Dedicated plan" is now in preview, but the quotas page lists file count and storage limits are still 15k / 500 MB :(
So, several years later, no way for azure to catch up to 21st century?
Hi @thomasgauvin, any update on this? Is this new 'dedicated plan' supposed to have an increased number of files eventually? Or is there another plan coming up with more files? And when can this be expected?
I'm using Next JS app for front end and Azure devops to deploy to SWA.
I have azure devops task as below.
- task: AzureStaticWebApp@0 inputs: app_location: 'NextJS/sample-app' api_location: 'NextJS/api' output_location: 'out' env: azure_static_web_apps_api_token: $(deployment_token)
Pipeline Error `Determining projects to restore... Restored /working_dir/NextJS/api/SampleApi/SampleApi.csproj (in 2.83 sec).
Publishing to directory /ss-oryx/api...
Microsoft (R) Build Engine version 16.7.2+b60ddb6f4 for .NET Copyright (C) Microsoft Corporation. All rights reserved.
Determining projects to restore... All projects are up-to-date for restore. SampleApi -> /working_dir/NextJS/api/SampleApi/bin/Release/netcoreapp3.1/SampleApi.dll SampleApi -> /ss-oryx/api/ Preparing output...
Removing existing manifest file Creating a manifest file... Manifest file created.
Done in 16 sec(s).
---End of Oryx build logs--- Function Runtime Information. OS: Windows, Functions Runtime: v3, .NET Core version: 3.1 Finished building function app with Oryx Zipping Api Artifacts Done Zipping Api Artifacts The content server has rejected the request with: BadRequest Reason: The number of files in the app content folder exceeds the limit of 15000.`
I have tried to reduce the output of number of files then I received below error
---End of Oryx build logs--- Function Runtime Information. OS: Windows, Functions Runtime: v3, .NET Core version: 3.1 Finished building function app with Oryx Zipping Api Artifacts Done Zipping Api Artifacts The content server has rejected the request with: BadRequest Reason: The size of the app content was too large. The limit for this Static Web App is 262144000 bytes.
We are at a stage to productionalize our application but this is a deal breaker. We have around more than 25k files now and that is only going to grow (significantly) larger over time.
I can't share repository details.