Configuration

gigadrive.yaml declares what a deployment contains: which files become Functions, which paths reach them, which static files ship, and which storage buckets exist. Gigadrive Network deploys most projects without one, so you write the file when framework detection does not describe your project.

Where the file goes

The build looks for twelve names at the project root and stops at the first one it finds:

The first six are executed as modules and have to default-export the object the YAML would have described, which TypeScript configuration covers. Keep one file: a repository holding both gigadrive.ts and gigadrive.yaml deploys from the TypeScript file, and nothing reports the one that lost. The nebula.* names come from the product's earlier name and still work.

The project root is your repository root, or the root directory configured for the application when the project sits in a subdirectory, which Build commands covers. Every example on these pages is written as YAML, and the keys are the same whichever format you pick.

The version key

version: 4

version is the only required key, and 4 is the only version the platform accepts. Write it as a number: version: "4" is a string, and the read fails on it before schema validation runs.

A complete file

version: 4

assets: public

functions:
  public/index.php:
    runtime: php-84
    memory: 512
    max_duration: 30
  api/report.js:
    runtime: node-22
    memory: 1024
    max_duration: 120
    includeFiles:
      - templates/**

routes:
  - source: ^/api/report(/.*)?$
    destination: api/report.js
    methods: [GET, POST]
    headers:
      cache-control: no-store
  - source: /*
    destination: public/index.php

services:
  storage:
    buckets:
      user-uploads:
        visibility: private
      brand-assets:
        visibility: public

That file deploys a PHP application with one Node Function beside it, everything under public/ as static files, and two storage buckets. public/index.php is not published as a static file, because a functions pattern claims it. The order of the two routes does not matter here: the edge tries an exact path match first, then longer patterns before shorter ones.

When you write no file at all

Framework detection runs on every build, whether or not a config file exists. With no file and a recognised framework, the build generates the whole configuration and logs Detected framework: <name> to your deployment log.

With no file and no framework, a project that looks like a static site gets a generated one containing exactly version: 4 and assets: ".", which publishes the project root as edge assets. A project that is neither fails the build with No config file found and no framework detected.

What your file replaces

When a config file and a detected framework are both present, the two are combined section by section, and each section is all or nothing. Your functions, routes, and assets replace the framework's version of that section whenever yours is non-empty. Storage services always come from your file. The two env maps are the one deep merge, with your values winning per name, and that merged map is then never applied: Environment variables covers what does reach a build and a Function.

One custom route therefore drops every route the framework generated, so a Next.js project that needs one extra path has to restate the framework's routes as well. The same combination step has no field for the image policy, which is why an images block behaves differently on a framework project. Images explains that case.