Add sqfs blog

src/routes/blog/post/appwrite-sites-squashfs-migration/+page.markdoc

@@ -0,0 +1,136 @@
+---
+layout: post
+title: "Faster Appwrite Sites deployments powered by SquashFS"
+description: Appwrite Sites now packages new deployments with SquashFS to reduce extraction work, improve cold starts, and make larger sites more reliable on Appwrite Cloud.
+date: 2026-08-05
+cover: /images/blog/appwrite-sites-squashfs-migration/cover.png
+timeToRead: 8
+author: luke-silver
+category: announcement
+featured: false
+callToAction: true
+faqs:
+  - question: "What is SquashFS?"
+    answer: "[SquashFS](https://docs.kernel.org/filesystems/squashfs.html) is a compressed, read-only filesystem for Linux. Appwrite can mount a SquashFS deployment artifact directly instead of extracting every file from a tar.gz archive before serving a Site."
+  - question: "Why is Appwrite Sites moving to SquashFS?"
+    answer: "SquashFS removes the full archive extraction step from deployment cold starts. Mounting stays nearly constant as a deployment grows, while extracting tar.gz archives takes progressively longer and can contribute to cold-start timeouts."
+  - question: "Do I need to change my Site's code or configuration?"
+    answer: "No. The migration changes how Appwrite packages and prepares deployment artifacts on Appwrite Cloud. Your framework, build commands, output directory, domains, and environment variables do not need to change."
+  - question: "How do I migrate an existing Appwrite Site to SquashFS?"
+    answer: "Create a new deployment. In the Appwrite Console, open your Site's **Deployments** tab and redeploy the active deployment. A new push to a connected production branch also creates a new deployment."
+  - question: "Will Appwrite rewrite my existing Site deployments?"
+    answer: "No. Existing deployments remain unchanged. The new format is applied when Appwrite creates a new deployment, so you must redeploy each existing Site that you want to move to SquashFS."
+  - question: "Are SquashFS deployment artifacts larger than tar.gz archives?"
+    answer: "They can be. In Appwrite's production sample, SquashFS artifacts were about 2.2 times larger on the wire for the same source tree, but they avoided the growing cost of full archive extraction. Configure [deployment retention](/docs/products/sites/deployments#deployment-retention) if you want Appwrite to remove older non-active deployments automatically."
+  - question: "Does the SquashFS migration also apply to Appwrite Functions?"
+    answer: "Yes. New Appwrite Functions deployments also use SquashFS. Functions typically have smaller artifacts, so their improvement is usually less substantial than the improvement for Sites, but larger Functions still benefit from removing full archive extraction."
+---
+
+The first request to a Site deployment should not spend seconds unpacking files before Appwrite can serve them. That work becomes increasingly expensive as a deployment grows, and at the far end it can turn a cold start into a timeout.
+
+Today, we are moving **new Appwrite Sites and Functions deployments on Appwrite Cloud to SquashFS**.
+
+SquashFS changes how Appwrite packages and prepares a deployment after the build finishes. Instead of downloading a compressed tar archive and extracting the complete output before it can be used, Appwrite downloads a compressed, read-only filesystem and mounts it directly. Existing Sites and Functions keep running as they do today. To move an existing deployment to the new format, you only need to trigger a new deployment.
+
+# What SquashFS gives Appwrite Sites
+
+- **Less work during cold starts:** Appwrite mounts the deployment instead of extracting every file before serving it.
+- **More predictable startup time:** Mount duration stays nearly flat as the Site grows, while archive extraction time scales with the amount of content.
+- **Better results for larger deployments:** Sites with larger framework bundles, generated assets, or dependency-heavy server output avoid the longest extraction paths.
+- **Fewer extraction-related failures:** Removing a size-dependent step reduces the chance that deployment preparation exceeds a cold-start timeout.
+- **No application migration:** The change is internal to Appwrite's deployment pipeline. Your code, framework, build settings, domains, and environment variables stay the same.
+
+Functions receive the same packaging change. Their artifacts are typically smaller than Site artifacts, so they usually spend less time extracting today and will see a less substantial improvement. Larger Functions can still benefit, but Sites are where we expect the clearest cold-start gains.
+
+# Why Appwrite Sites is replacing tar.gz artifacts
+
+A Site deployment is immutable after it has been built. That makes a compressed, read-only filesystem a natural fit for the workload.
+
+With the previous tar.gz format, an edge worker had to complete two format-dependent steps before using a cold deployment:
+
+1. Download the archive.
+2. Extract the entire archive to disk.
+
+The download is efficient because gzip compresses source trees well. The extraction is the problem. It touches every file, consumes CPU and disk I/O, and grows with the uncompressed size of the deployment. A small static page barely notices this work. A large build output can spend several seconds extracting before the platform reaches the rest of its startup path.
+
+[SquashFS](https://docs.kernel.org/filesystems/squashfs.html) takes a different approach. It stores the deployment as a compressed filesystem image. Appwrite downloads the image and mounts it as read-only, so the Site can use its files without expanding the complete archive first.
+
+Mount time stayed between roughly **0.02 and 0.06 seconds** across the artifact-size buckets in our production analysis. By comparison, tar.gz extraction rose from **0.23 seconds** for 1 to 5 MB archives to **12.72 seconds** for 250 to 500 MB archives. The filesystem mount replaces a step whose cost grows with deployment size with one that is close to constant.
+
+## SquashFS improves serving, not the build itself
+
+The optimization begins after Appwrite has successfully built your Site. It does not make package installation, framework compilation, or static generation faster. Those steps still depend on your build specification, dependencies, cache state, and framework.
+
+SquashFS improves the path that prepares an already-built deployment for traffic at the edge. A warm deployment can already be available locally, so a visitor may not encounter this preparation at all. On a cold path, Appwrite must fetch the artifact and make its files available before it can serve the request. That is the path where removing full extraction matters.
+
+This distinction also explains why the improvement is not a fixed number on every request. SquashFS reduces one specific source of cold-start latency and variance. It does not remove network transfer, scheduling, image preparation for server-rendered Sites, or the time your application needs to start and respond. The goal is a shorter, more predictable platform path, especially when a deployment contains many files or a large amount of generated output.
+
+# Production cold-start results
+
+We compared seven-day production means across Sites and Functions using gzip and SquashFS deployments, then normalized the artifact buckets against their estimated uncompressed source size. This matters because the two formats make a different tradeoff: SquashFS artifacts are larger to download, while gzip archives require more work to extract.
+
+The selected scenarios below show the time spent in the format-dependent cold-start phases. These include download, extract or mount, symlink, preparation, and startup.
+
+| Estimated source size | tar.gz phases | SquashFS phases | Relative result |
+| --- | ---: | ---: | ---: |
+| 0.5 MB | 0.69s | 0.91s | SquashFS is 32% slower |
+| 5 MB | 1.03s | 0.85s | SquashFS is 17% faster |
+| 10 MB | 1.06s | 0.85s | SquashFS is 20% faster |
+| 50 MB | 1.79s | 1.04s | SquashFS is 42% faster |
+| 100 MB | 2.65s | 1.61s | SquashFS is 39% faster |
+| 200 MB | 3.70s | 1.81s | SquashFS is 51% faster |
+| 800 MB | 13.35s | 8.24s | SquashFS is 38% faster |
+
+Tiny deployments can still favor gzip because there is almost nothing to extract and the downloaded archive is smaller. The crossover happens quickly. Once the uncompressed source is a few megabytes, avoiding extraction offsets the additional download size. At 50 MB, SquashFS cut the format-dependent portion from 1.79 seconds to 1.04 seconds. At 200 MB, it reduced the same path from 3.70 seconds to 1.81 seconds.
+
+Across the full cold-start path, including format-independent work such as scheduling and image preparation, SquashFS deployments averaged **9.82 seconds** compared with **11.01 seconds** for gzip. At p95, the result improved from **24.81 seconds** to **23.23 seconds**.
+
+These figures describe production workloads, not a promise that every Site will improve by the same amount. Network conditions, edge cache state, build output, and framework behavior still contribute to startup time. However, the largest and most consistent improvement comes from eliminating extraction as deployment size increases.
+
+# The archive-size tradeoff
+
+SquashFS is not simply a smaller tar archive. It optimizes for a different job.
+
+In a sample of live deployments, the median uncompressed-to-artifact ratio was **5.69x for gzip** and **2.62x for SquashFS**. For the same source tree, the SquashFS artifact was therefore about **2.2 times larger on the wire**. Appwrite accepts that additional download work because mounting the artifact avoids fully expanding it on every cold start.
+
+This tradeoff is most useful for medium and large deployments. Download time can grow with the SquashFS image, but mount time remains almost flat. Gzip downloads fewer bytes, then pays an extraction cost that keeps climbing. Removing that variable step makes the cold-start path more predictable and reduces pressure near the platform timeout.
+
+Deployment artifacts count toward your project's storage allowance on Appwrite Cloud. If your project keeps many inactive deployments, configure [deployment retention](/docs/products/sites/deployments#deployment-retention) to delete them after the rollback window your team needs. Appwrite always keeps the active deployment.
+
+# Migrate an existing Site with one redeployment
+
+Existing Site deployments are not rewritten in place. Appwrite applies SquashFS when it creates a new deployment, so every existing Site needs one new deployment to receive the change.
+
+To redeploy from the Appwrite Console:
+
+1. Open **Sites** and select your Site.
+2. Open the three-dots menu on the active deployment.
+3. Select **Redeploy**.
+
+Redeploying creates a new deployment from the same source and configuration. The active deployment continues to represent the version currently serving traffic until the new deployment is ready and activated. You do not need to make an empty commit or change an environment variable just to migrate the artifact format.
+
+If your Site is connected to Git, pushing the next change to its production branch also creates and activates a new deployment. Teams that already ship frequently can pick up SquashFS through their normal workflow. If you want the cold-start improvement immediately, use **Redeploy** instead of waiting for the next code change.
+
+The same principle applies to deployments created through the CLI or a manual upload: the migration happens when Appwrite builds a new deployment. Your local source package and build output workflow do not need a SquashFS-specific step.
+
+# What stays the same after migration
+
+SquashFS changes deployment packaging, not the contract between your application and Appwrite Sites.
+
+- Your Site URL and custom domains stay unchanged.
+- Your framework, install command, build command, start command, and output directory stay unchanged.
+- Your environment variables are still applied when the new deployment is built.
+- Git deployments, preview deployments, CLI deployments, and manual deployments keep their existing workflows.
+- Existing ready deployments remain separate versions you can inspect or activate while they are retained.
+
+Because the format belongs to the deployment artifact, rolling back to an older deployment also rolls back to the artifact that was created for that version. Create a fresh deployment when you want that version of the code packaged with SquashFS.
+
+# Redeploy your Appwrite Sites and Functions
+
+New Appwrite Sites and Functions deployments on Appwrite Cloud now use SquashFS. Existing deployments continue serving normally, but they only receive the new artifact format after a new deployment is created. Open each production Site and trigger one redeployment when it fits your release process.
+
+- [Redeploy an Appwrite Site](/docs/products/sites/deployments#redeploy)
+- [Redeploy an Appwrite Function](/docs/products/functions/deployments#redeploy)
+- [Deploy Appwrite Sites from Git](/docs/products/sites/deploy-from-git)
+- [Configure Site deployment retention](/docs/products/sites/deployments#deployment-retention)
+- [Open Appwrite Cloud](https://cloud.appwrite.io)

src/routes/changelog/(entries)/2026-08-05.markdoc

@@ -0,0 +1,14 @@
+---
+layout: changelog
+title: "Redeploy Sites and Functions for faster SquashFS cold starts"
+date: 2026-08-05
+cover: /images/blog/appwrite-sites-squashfs-migration/cover.png
+---
+
+New [Appwrite Sites](/docs/products/sites) and [Functions](/docs/products/functions) deployments on Appwrite Cloud now use **SquashFS**. Mounting the compressed, read-only deployment artifact removes the full extraction step from cold starts, making startup more predictable. Sites typically have larger artifacts than Functions, so they will see the more substantial improvements.
+
+Existing Sites and Functions keep running normally and are not rewritten in place. To migrate one, open its **Deployments** tab and redeploy the active deployment, or create a new deployment through your existing Git, CLI, or manual workflow. No source-code or configuration change is required.
+
+{% arrow_link href="/blog/post/appwrite-sites-squashfs-migration" %}
+Read the SquashFS migration analysis
+{% /arrow_link %}