Zum Inhalt springen
GigadriveDocs

Drag and drop

Upload a file, a folder, or a ZIP from the console and deploy it without a repository or the CLI.

Drop takes files straight from your machine, packages them in the browser, and deploys them. Use it for output you have already built, for a one-off preview, or for code that is not in a repository Gigadrive Network can read.

What you can drop

A single file, a folder, several of either, or a ZIP archive. Folder structure is preserved. When everything you dropped sits under one top-level folder, that folder is stripped, so mysite/index.html is deployed as index.html.

A ZIP is unpacked in the browser, filtered, and repacked before it is uploaded. Its paths are kept as they are, so an archive whose files all sit under one folder deploys with that folder still in the path. Everything else is zipped client side.

Deploy an upload

  1. Open Drop

    Drag files onto any console page, or select your organization, choose New app, then open the Drop tab.

  2. Add your files and name the application

    Drop the files, or use Choose files and Choose folder. The console counts what you selected and suggests an application name from it. Dropping onto an application page instead offers to redeploy into that application.

  3. Deploy

    Deploy packages the archive in your browser, creates the application, then uploads the archive in parts with a progress bar. The deployment is queued the moment the upload completes, and the console opens its log.

Static sites without a config file

The console uploads your files as they are and adds no configuration. When the upload has no gigadrive.yaml at its root (or one of the legacy nebula.* names), the build first looks for a framework such as Laravel, Symfony or Next.js and deploys it with that framework's defaults. Only an upload with neither a configuration file nor a detected framework, whose contents look like static web files, is published as a static site. That is what makes a bare folder of HTML deployable with no setup.

Put your own gigadrive.yaml in the upload when the project needs more than the defaults, for example a Function or a route table. Configuration describes the file.

Gigadrive Network picks a page for / when the upload has no index.html or index.htm at its root:

  • One HTML page at the root: that page also answers /. It keeps answering at its own path too.
  • One file in the whole upload, and it is not HTML: / redirects to the file, so an image or PDF renders in the browser and other types download.
  • Anything else: / returns 404 until you add an index.html. The console warns you about this once the archive is packaged.

This applies only to the generated configuration. If you include your own gigadrive.yaml, / answers only what your configuration routes to it.

How an upload differs from a Git deployment

An upload carries no branch, so it lands in the Preview environment and is served on that deployment's own permanent URL. The production alias <name>.gigadrive.app moves only for a deployment that runs in the Production environment, which needs a connected repository and a branch Production matches.

Nothing else about the deployment changes. The same build pipeline runs, and the same build cache applies. What you give up is the commit behind the deployment: to ship a change, drop the files again.