Frameworks

Gigadrive Network reads your project's dependencies once the build has finished and picks a framework preset, which decides what becomes a Function and how the edge routes to it. Detection is a convenience rather than a requirement: a project carrying a gigadrive.yaml deploys whether or not a framework matches.

How detection works

Detection runs against the resolved project root, after your build, so it sees build output as well as source. Node presets read dependencies and devDependencies from package.json. PHP presets read require and require-dev from composer.json. Ruby presets read every gem in Gemfile.lock, including the ones your gems depend on, or the gem lines in Gemfile when there is no lockfile.

Each preset lists detectors: a package name, a file that must exist, or a regular expression that file has to match. Every detector belonging to a preset must match. Presets are then tried in priority order and the first complete match wins, which is why a SvelteKit project is never treated as a Vite project even though it depends on Vite.

Exactly one preset is chosen, and no configuration key picks a different one or turns detection off. When a preset matches, the build log records Detected framework: <name>.

What a preset supplies

A preset names the file that becomes a Function, its runtime, its memory and its maximum duration, a /* route pointing at the Function, and default environment variables. Node presets set NODE_ENV=production.

A preset also walks the assets directory it names, once the build has produced it, and publishes every file inside to the edge. A zero-config deployment therefore already serves the client bundle, stylesheet or image the framework built, with no assets key of your own required. Next.js is the exception: its own build manifest resolves asset paths, rather than a plain directory walk.

Some presets look further at your project before settling. NestJS reads outputPath from nest-cli.json, the single-file server presets resolve your entrypoint from main, then a start script, then common filenames on disk, and Next.js reads the manifest its adapter wrote during the build.

A preset never decides how your project is built. The build installs dependencies with the package manager it detected and runs the build script from your package.json, framework or no framework. A Ruby project's gems are installed with Bundler, and the build then runs the build step its framework needs, such as bin/rails assets:precompile or jekyll build, chosen from the gems in its lockfile. Builds covers that half.

Detected frameworks

Rows are in the order they are tried. Maximum duration is 30 seconds everywhere except Next.js, which takes the longest maxDuration your route segments declare. The Next.js row describes Next 16.2 and newer; an older release keeps the plain 256 MB Node default.

The PHP rows show the default. A PHP preset reads require.php from your composer.json and runs on php-83 when the constraint excludes PHP 8.4. See Runtimes.

The two generic PHP rows look for the front controller in public/, web/, webroot/, public_html/, htdocs/ and then the project root, and take the first index.php they find. Every PHP preset publishes its document root as static assets, never the PHP files in it, dotfiles such as .env, or vendor/, and sends every other path to the front controller. The directories a framework writes its cache, sessions and logs to are created writable, so none of them needs a configuration file or a change to move those paths to /tmp.

The Ruby rows run on the Ruby version the project names in .ruby-version, .tool-versions, the ruby line in its Gemfile or the RUBY VERSION in Gemfile.lock, and on ruby-34 when it names none. Their assets directory is only published when it exists, and Ruby source, Gemfile, config.ru and vendor/ never are.

A project matching nothing on this list and carrying no config file deploys as static assets when it looks like a static site, and fails otherwise. See Static sites.

Taking the defaults over

A gigadrive.yaml at the project root is merged over the preset section by section, and each section is all or nothing.

One custom route therefore removes the /* route the preset created for your server, and one functions entry removes the preset's entrypoints. Re-declare whatever you still need. Raising the memory on a Nuxt server, for example, means restating the entrypoint but leaves routes and assets alone:

version: 4

functions:
  .output/server/index.mjs:
    runtime: node-22
    memory: 1024
    max_duration: 60

Settings you leave out fall back to the file format's defaults rather than the preset's, so name the runtime even when it matches. An entrypoint with no runtime is node-20.

The env row is the one that changes nothing. Nothing in the deployment pipeline reads the merged map, so a preset's values and yours alike are discarded, and a name a preset lists is not present in your Function. Set what your application needs under Environment variables.

Next.js is the exception to all of this, because the merge does not carry the manifest its adapter produces. Read Next.js before adding a config file to one. Configuration documents every key in the file.