Local Import

Use local import when the project already exists on your machine but is not ready to come from GitHub yet.

Typical cases:

• You have a prototype folder and want it online quickly.
• You received a ZIP from a client or teammate.
• You want to test the import path before connecting GitHub.

The import path is intentionally simple:

1. Upload a ZIP file.
2. d1v.ai extracts the archive and normalizes the root folder.
3. Common project signals such as package.json, framework files, and .env are inspected.
4. A new cloud project is created from that snapshot.
5. You can then continue through Chat, preview, deployment, and GitHub-related flows.

   Important: importing a local archive is treated like creating a new project from a snapshot, not like binding to an existing cloud workspace.

A reliable archive usually has one clear project root and only the files you actually need.

Prefer this shape:

my-project.zip
  package.json
  src/
  public/
  README.md

Also acceptable:

my-project.zip
  my-project/
    package.json
    src/

The importer can usually collapse a single redundant top-level folder automatically.

Most failed imports come from bad archive hygiene rather than product bugs.

Avoid zipping these into the upload when possible:

• node_modules/
• build output such as .next/, dist/, build/
• OS metadata like __MACOSX/ or .DS_Store
• giant caches, logs, screenshots, and exported videos
• multiple unrelated apps in one ZIP unless that is truly the intended root

Environment files may be parsed during import so project configuration can be reconstructed later in the workspace.

Practical guidance:

• Keep only the keys the app actually needs.
• Remove secrets you do not want uploaded.
• If a key is environment-specific, verify it again in preview before any production release.

Treat local import as a controlled handoff, not as a blind filesystem dump.

After the project is created:

1. Open the project and inspect the file tree.
2. Verify framework detection and preview behavior.
3. Ask Chat for one safe, observable change first.
4. Connect GitHub later if you need PRs, collaboration, or long-term release discipline.

Fastest checks:

• Recreate the ZIP from the true project root.
• Remove node_modules/ and build output, then upload again.
• Make sure the archive is a normal ZIP, not rar/7z/tar disguised as .zip.
• Check whether the project root actually contains the app entry files you expect.

If support is needed, provide the archive shape, approximate size, and the exact step where failure occurs.