Merge pull request #2871 from appwrite/changelog/build-runtime-specs

Changelog/build runtime specs

Author: eldadfux

.optimize-cache.json

@@ -1183,6 +1183,7 @@
   "images/changelog/2025-10-29.png": "88204210852acd50bc72a9d7de29f088ef81a4c90941378125fa4f662bb61264",
   "images/changelog/2025-11-19.png": "a152a7c9cd960c5123075aac94098070ce5ac98f10ee88d71e461dce136520f7",
   "images/changelog/2026-02-17.png": "70a2c577bd927bd3e9391840d7fd030f195e975dfcecad536f6d713e23b60624",
+  "images/changelog/2026-04-08.png": "ad7549efc81af619c7bb1429472d3e792d9e49fd6be8e831027ad64c8da8a260",
   "images/changelog/oss-progam.png": "e50d1c497ac1d07494fa1d40b1f219c8f14770f7b72e1258147f527e86f40eed",
   "images/changelog/threads-cover.png": "f5599b528f33797f125da1fecaffc70763118d4d420b04f6d67a70bc651cf40a",
   "images/community/avatars/1.png": "3448e87720fd3f55326ad04f18263f5094b61116c79d7e48e8b692b8012513bc",

src/lib/components/MobileNav.svelte

@@ -7,7 +7,6 @@
     import { Button } from '$lib/components/ui';
     import { GithubStats } from '$lib/components/shared';
     import { trackEvent } from '$lib/actions/analytics';
-    import { browser } from '$app/environment';
 
     export let open = false;
     export let links: NavLink[];
@@ -45,14 +44,15 @@
         <div class="web-side-nav-scroll max-w-screen! pr-0!">
             <section>
                 <ul>
-                    {#each links as { href, label, mobileSubmenu }}
+                    {#each links as { href, label, mobileSubmenu, showBadge }}
                         <li>
                             {#if mobileSubmenu}
                                 <svelte:component this={mobileSubmenu} {label} />
                             {:else}
                                 <a
                                     class="web-side-nav-button"
                                     {href}
+                                    data-badge={showBadge ? '' : undefined}
                                     onclick={() =>
                                         trackEvent(
                                             `mobile-nav-${label.toLowerCase().replace(' ', '_')}-click`
@@ -71,3 +71,21 @@
         </div>
     </div>
 </nav>
+
+<style>
+    [data-badge] {
+        position: relative;
+
+        &::after {
+            content: '';
+            position: absolute;
+            background-color: hsl(var(--color-accent));
+            border-radius: 100%;
+            width: 0.375rem;
+            height: 0.375rem;
+            inset-block-start: -2px;
+            inset-inline-end: -4px;
+            translate: 100%;
+        }
+    }
+</style>

src/lib/layouts/Main.svelte

@@ -22,6 +22,7 @@
     import { getAppwriteDashboardUrl } from '$lib/utils/dashboard';
     import { Button, Icon, InlineTag } from '$lib/components/ui';
     import MongoPartnershipBanner from '$lib/components/MongoPartnershipBanner.svelte';
+    import { changelogNavBadgeVisible } from '$routes/changelog/utils';
 
     export let omitMainId = false;
     export let hideNavigation = false;
@@ -121,7 +122,8 @@
         },
         {
             label: 'Changelog',
-            href: '/changelog'
+            href: '/changelog',
+            showBadge: changelogNavBadgeVisible(page)
         }
     ];
 

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

@@ -0,0 +1,26 @@
+---
+layout: changelog
+title: "Separate build and runtime compute specs for Sites and Functions"
+date: 2026-04-08
+cover: /images/changelog/2026-04-08.png
+---
+
+You can now choose **independent compute specifications** for the **build** and **runtime** phases of [Sites](/docs/products/sites) and [Functions](/docs/products/functions). Each spec sets CPU and memory for that phase, so you can tune both performance and spend: right-size compute for heavy builds or busy runtimes without paying for peak capacity in the phase that does not need it.
+
+# Sites
+
+- **Build specification:** CPU and memory used while installing dependencies and producing your deployment artifact.
+- **Runtime specification:** CPU and memory used when your site handles traffic, including server-side rendering (SSR).
+
+# Functions
+
+- **Build specification:** CPU and memory used while building and packaging your function deployment.
+- **Runtime specification:** CPU and memory available to each function execution.
+
+Build steps (dependency installs, compilers, bundlers) often need different resources than steady execution or request handling. For example, a large frontend build may benefit from more RAM during CI-style build, while a lightweight API or static output might need fewer resources at runtime, or the opposite if runtime work is heavy. Setting build and runtime specs separately lets you align capacity with each phase instead of over-provisioning for both, which helps control cost as well as latency and reliability.
+
+Configure these under each resource’s **Settings > Resource limits** in the [Appwrite Console](https://cloud.appwrite.io). On Appwrite Cloud, customizing specs beyond the default is **available on the Pro plan**; Starter organizations see an upgrade prompt when adjusting CPU and RAM.
+
+{% arrow_link href="/docs/advanced/platform/compute" %}
+Read the Compute docs to learn more
+{% /arrow_link %}

src/routes/changelog/utils.ts

@@ -1,19 +1,25 @@
 import { browser } from '$app/environment';
-import { page } from '$app/stores';
 import { isNumeric } from '$lib/utils/is';
-import { get } from 'svelte/store';
 
 export { changelogCount, changelogs } from '$lib/content/changelog';
 
 export const CHANGELOG_DEPENDENCY = 'dependency:changelog';
 
 export const CHANGELOG_KEY = 'changelog';
 
-export function hasNewChangelog() {
+/** Whether the main nav should show the “new changelog” dot (client-only; compares localStorage to current count). */
+export function changelogNavBadgeVisible(page: {
+    data: { changelogCount?: number };
+    url: { pathname: string };
+}) {
     if (!browser) return false;
+    if (page.url.pathname.includes('/changelog')) return false;
+
+    const count = page.data.changelogCount;
+    if (typeof count !== 'number') return false;
 
     const prev = localStorage.getItem(CHANGELOG_KEY);
     if (!prev) return true;
 
-    return isNumeric(prev) && JSON.parse(prev) < get(page).data.changelogCount;
+    return isNumeric(prev) && JSON.parse(prev) < count;
 }

src/routes/docs/advanced/platform/+page.markdoc

@@ -109,7 +109,7 @@ Learn about additional features and functionalities that Appwrite offers.
 
 {% cards %}
 {% cards_item href="/docs/advanced/platform/compute" title="Compute" %}
-Learn about Appwrite's different compute add-ons.
+CPU and memory for Functions and Sites, including build and runtime specs.
 {% /cards_item %}
 {% cards_item href="/docs/advanced/platform/phone-otp" title="Phone OTP" %}
 Learn how Appwrite handles SMS-based OTP authentication.

src/routes/docs/advanced/platform/compute/+page.markdoc

@@ -1,16 +1,16 @@
 ---
 layout: article
 title: Compute
-description: Learn about Appwrite Functions compute add-ons and the different CPU and memory options for function runtimes.
+description: Learn about CPU and memory options for Appwrite Functions and Sites on Cloud, including separate build and runtime specifications.
 ---
 
-Appwrite's paid plans give you the ability to change your function's allocated CPU Cores and Memory, enabling functions and builds to perform more computionally demanding actions quicker.
+On Appwrite Cloud, paid plans let you choose how much **CPU** and **memory** apply to **build** work and to **runtime** work. [Functions](/docs/products/functions) and [Sites](/docs/products/sites) each expose two settings: a **build specification** (install, compile, bundle, package) and a **runtime specification** (executions for functions; serving traffic and SSR for sites). You can pick different tiers for each phase so heavy builds do not force you to oversize steady execution, and vice versa.
 
-These options enable greater performance and flexibility, allowing developers to optimize their functions based on specific requirements. For instance, resource-intensive tasks such as real-time data processing or complex computational operations can now be executed more efficiently. Additionally, enhanced memory configurations support larger datasets and more demanding applications, broadening the scope of what can be achieved with Appwrite Functions.
+These options help you tune performance and cost: for example, a large install or compiler step can use a higher build spec while a smaller spec covers routine invocations or traffic.
 
 # Specifications {% #specifications %}
 
-Appwrite Cloud has the following specifications available:
+Appwrite Cloud offers the following specification tiers. The same tiers are available for **build** and **runtime** independently on each function or site:
 
 | Memory | CPU cores | Hourly usage |
 |--------|-----------|--------------|
@@ -22,30 +22,33 @@ Appwrite Cloud has the following specifications available:
 | 4GB    | 4         | 16           |
 
 {% info title="Note" %}
-Only customers on either Pro or Scale are able to change their specification from the default 512MB & 0.5 CPU option. For custom compute options please contact our [sales team](https://appwrite.io/contact-us/enterprise).
+On Appwrite Cloud, **Pro** plan organizations can change build and runtime specifications from the default 512MB and 0.5 CPU. The Free plan uses the default. For custom compute options, contact our [sales team](https://appwrite.io/contact-us/enterprise).
 {% /info %}
 
+Configure specifications in the Appwrite Console under each function or site **Settings** - **Resource limits**. See also the [Functions](/docs/products/functions/functions#resource-limits) and [Sites](/docs/products/sites/develop#resource-limits) configuration guides.
+
 # GB-Hours {% #gb-hours %}
 
-GB-hours is a metric used to quantify the consumption of compute resources by combining both memory usage and the duration of that usage. Specifically, it represents the number of gigabytes (GB) of memory utilized multiplied by the number of hours those resources are active. This metric provides a comprehensive view of resource usage over time, allowing for accurate tracking, optimization, and billing based on actual compute needs.
+GB-hours quantify compute use by combining memory (in GB) and duration (in hours). Both **build** activity and **execution** (function runs or site serving, depending on the product) draw from your plan's GB-hour pool according to the specifications in effect for that phase.
+
+How it works:
 
-How It Works:
-- Memory allocation: Determine the amount of memory (in GB) that your application or function requires while running.
-- Duration: Measure the total time (in hours) that the allocated memory is in use.
-- Calculation: Multiply the memory allocated by the duration to obtain the total GB-hours consumed.
+- Memory allocation: The GB value comes from the spec in use for that phase (build or runtime).
+- Duration: Time that phase is active (for example, build duration or execution time).
+- Calculation: Memory (GB) multiplied by hours gives GB-hours for that usage.
 
 **Example:**
 
-Assuming you have a function that requires 4 GB of memory to operate. If this function runs continuously for 2 hours, the compute resource usage would be:
+If a function runs with 4 GB of memory for 2 hours of execution time:
 
 **4GB * 2 hours = 8 GB-hours**
 
-This means the function has consumed 8 GB-hours of compute resources.
+That counts toward your execution GB-hours for the billing period.
 
 ## Pricing {% #pricing %}
 
-- Free plan includes up to 100 GB-hours of execution and build time per month.
+- The Free plan includes up to 100 GB-hours of execution and build time per month.
 
-- Pro and Scale plans include up to 1,000GB of execution and build time per month. Additional usage is available at a rate of $0.09 per GB-hour.
+- The Pro plan includes up to 1,000 GB-hours of execution and build time per month. Additional usage is billed at $0.09 per GB-hour.
 
-Once the monthly GB-hours limit is reached, additional usage will automatically apply add-ons to your Pro or Scale account. It is recommended to set budget alerts and a budget cap to prevent unexpected payments. 
+Once the monthly GB-hours limit is reached, additional usage is billed automatically. Set budget alerts and a budget cap to avoid unexpected charges.

src/routes/docs/products/functions/deployments/+page.markdoc

@@ -57,5 +57,5 @@ Redeployment behavior varies depending on how the initial deployment was created
 Users subscribed to the Appwrite Pro plan or above receive certain special benefits:
 
 - [Express builds](/changelog/entry/2024-08-10) for quicker deployments, resulting in reduced wait times and smoother workflows
-- Customizable [runtime specifications](/blog/post/introducing-new-compute-capabilities-appwrite-functions), allowing for tailored performance and resource allocation
+- Customizable [build and runtime specifications](/docs/advanced/platform/compute) for CPU and memory on each function
 {% /info %}

src/routes/docs/products/functions/functions/+page.markdoc

@@ -103,6 +103,12 @@ It's recommended you use one of the [starter function templates](/docs/products/
 Under **Build settings**, you can update your build commands. 
 These are terminal commands that will be executed in the runtime containers in the build step of the deployment process.
 
+## Resource limits {% #resource-limits %}
+
+Under **Settings** - **Resource limits**, you can set **build** and **runtime** specifications independently. The build spec applies while your deployment is being built and packaged; the runtime spec applies to each function execution. Both use the same CPU and memory tiers on Cloud. This lets you align compute with heavy dependency installs or compilation without over-provisioning every invocation.
+
+On Appwrite Cloud, customizing specifications requires the **Pro** plan. See [Compute](/docs/advanced/platform/compute) for tiers, GB-hours, and pricing.
+
 ## Git integration {% #git-integration %}
 You can update the entrypoint file and build settings of your function by navigating to your function > **Settings** > **Configuration**.
 

src/routes/docs/products/sites/deployments/+page.markdoc

@@ -81,5 +81,5 @@ Redeployment behavior varies depending on how the initial deployment was created
 Users subscribed to the Appwrite Pro plan or above receive certain special benefits:
 
 - [Express builds](/changelog/entry/2024-08-10) for quicker deployments, resulting in reduced wait times and smoother workflows
-- Customizable [runtime specifications](/blog/post/introducing-new-compute-capabilities-appwrite-functions), allowing for tailored performance and resource allocation
+- Customizable [build and runtime specifications](/docs/advanced/platform/compute) for CPU and memory on each site
 {% /info %}