The Auto-Detection Engine: How Deployxa Identifies 30+ Frameworks in Under 5 Seconds

The Auto-Detection Engine

When you push a project to Deployxa, the platform identifies your framework in under 5 seconds, configures the build and start commands automatically, and deploys your app without requiring a Dockerfile. This is the auto-detection engine, and it is the foundation of Deployxa's zero-config experience. The engine supports 30+ frameworks across 10 runtimes (Node.js, Python, Go, PHP, Rust, .NET, Ruby, Java, Elixir, and Crystal), and it identifies the correct framework by inspecting manifest files and source code patterns. Here is how it works, why it is so fast, and what it can detect.

The direct answer is that the auto-detection engine is a multi-stage pipeline that inspects your repository's manifest files (package.json, requirements.txt, go.mod, etc.), parses them to identify dependencies, and matches the dependencies against a database of known framework signatures. Each signature is a rule that says "if these dependencies are present, the framework is X." For example, if package.json includes next as a dependency, the framework is Next.js. If it includes vite and react, the framework is Vite + React. The engine runs all signatures in parallel and returns the first match, which takes under 5 seconds for most repositories.

Why Auto-Detection Matters

Auto-detection matters for three reasons. First, it eliminates the Dockerfile: the most common reason vibe coders struggle with deployment is that they do not know how to write a Dockerfile. Auto-detection eliminates the need for a Dockerfile by generating the build and start commands automatically. Second, it eliminates configuration: even platforms that do not require a Dockerfile (e.g., Heroku, Railway) often require a configuration file (e.g., Procfile, railway.toml). Auto-detection eliminates the configuration file by inferring the correct settings from the repository. Third, it eliminates errors: hand-written Dockerfiles and configuration files are error-prone, because they depend on the target environment in ways the developer might not understand. Auto-detection produces correct configuration by using battle-tested rules maintained by the platform.

The trade-off is flexibility: auto-detection handles the 95 percent of standard frameworks, but it does not handle the 5 percent of edge cases (custom runtimes, unusual configurations). For edge cases, Deployxa supports a custom Dockerfile, which overrides the auto-detection. For more on this, see our article on why AI-generated Dockerfiles won't build.

The Detection Pipeline

The auto-detection engine has four stages:

Stage 1: Manifest file identification

The engine looks for known manifest files in the repository root. The files it looks for include:

package.json (Node.js)
requirements.txt or pyproject.toml (Python)
go.mod (Go)
Cargo.toml (Rust)
composer.json (PHP)
*.csproj or *.sln (.NET)
Gemfile (Ruby)
pom.xml or build.gradle (Java)
mix.exs (Elixir)
shard.yml (Crystal)

If multiple manifest files are present (e.g., a monorepo with backend/requirements.txt and frontend/package.json), the engine identifies multiple services.

Stage 2: Manifest parsing

For each manifest file, the engine parses the contents to extract the dependencies. For package.json, it reads the dependencies and devDependencies fields. For requirements.txt, it reads the package list. For go.mod, it reads the require block. The parsing is done with a fast, streaming parser that handles large manifest files efficiently.

Stage 3: Framework signature matching

The engine matches the dependencies against a database of framework signatures. Each signature is a rule that specifies:

A set of required dependencies (e.g., next for Next.js)
A set of optional dependencies (e.g., react, react-dom for Next.js)
A set of conflicting dependencies (e.g., if vite is present, the framework is not Next.js)
The framework name (e.g., nextjs)
The build command (e.g., npm run build)
The start command (e.g., npm start)
The output directory (e.g., .next for Next.js, dist for Vite)

The engine runs all signatures in parallel and returns the first match. If multiple signatures match (e.g., a Next.js app that also uses Vite for a sub-project), the engine uses a priority order to determine the primary framework.

Stage 4: Configuration generation

Based on the matched framework, the engine generates the build configuration, which includes:

The runtime version (e.g., Node.js 20, Python 3.11)
The build command (e.g., npm run build)
The start command (e.g., npm start)
The output directory (e.g., .next)
The port (e.g., $PORT)
Any framework-specific configuration (e.g., Next.js's output: 'standalone')

The configuration is logged in the build output, so you can see exactly what was detected and how it was configured.

Supported Frameworks

Deployxa's auto-detection engine supports 30+ frameworks across 10 runtimes:

Node.js

Next.js (SSR and static)
Vite (React, Vue, Svelte, Solid)
Create React App
Nuxt.js
SvelteKit
Express
Fastify
NestJS
Remix
Gatsby
Astro

Python

FastAPI
Django
Flask
Streamlit
Gradio
Poetry-based apps

Go

Fiber
Gin
Echo
Chi
Standard library (net/http)

Rust

Axum
Actix Web
Rocket

PHP

Laravel
Symfony
Lumen

.NET

ASP.NET Core (Web API, MVC, Razor Pages)

Ruby

Rails
Sinatra

Java

Spring Boot
Quarkus

Elixir

Phoenix

Crystal

Lucky

For each framework, the engine knows the correct build command, start command, output directory, and port configuration, which means you can deploy any of these frameworks without writing a Dockerfile.

Step-by-Step: How the Engine Processes a Repository

Here is how the engine processes a typical Next.js repository.

Step 1: Manifest identification

The engine finds package.json in the repository root. This identifies the runtime as Node.js.

Step 2: Manifest parsing

The engine parses package.json and extracts the dependencies: next, react, react-dom, clsx, lucide-react.

Step 3: Signature matching

The engine matches the dependencies against the framework signatures. The next dependency matches the Next.js signature, which requires next and optionally react, react-dom. The match is confirmed.

Step 4: Configuration generation

The engine generates the build configuration:

[ingest] Detected Node.js project
[ingest] Framework: nextjs
[ingest] Runtime: node 20.x
[ingest] Build command: npm run build
[ingest] Start command: npm start
[ingest] Output directory: .next
[ingest] Port: $PORT

Step 5: Deployment proceeds

The build runs npm run build, the container starts with npm start, and the app is live within 60 to 90 seconds.

Common Pitfalls and Troubleshooting

The first pitfall is monorepo detection. If your repository has multiple manifest files in different directories, the engine needs to identify them as separate services. The fix is to structure your monorepo clearly (e.g., backend/ and frontend/ directories with their own manifest files), which the engine can detect. For more on this, see our article on deploying a FastAPI + Next.js monorepo. The second pitfall is non-standard framework configurations. If your app uses a non-standard build or start command (e.g., a custom build script), the engine might not detect it correctly. The fix is to specify the build and start commands in your manifest file (e.g., scripts.build and scripts.start in package.json). The third pitfall is conflicting dependencies. If your app has dependencies that match multiple frameworks (e.g., both next and vite), the engine uses a priority order to determine the primary framework. The fix is to remove the conflicting dependency or to specify the framework explicitly in a configuration file. The fourth pitfall is unsupported frameworks. If your app uses a framework that the engine does not support, it falls back to a generic configuration (e.g., npm install && npm start for Node.js). The fix is to provide a custom Dockerfile or to request support for the framework via Deployxa's support channels. The fifth pitfall is slow detection. For very large repositories (e.g., monorepos with many packages), the detection might take longer than 5 seconds. The fix is to use a shallow clone (which the engine does by default) and to exclude unnecessary files via .gitignore.

How the Engine Integrates with the Zero-Config Experience

The auto-detection engine is the foundation of Deployxa's zero-config experience. Without it, you would need to write a Dockerfile or configuration file for every app, which is a tax on vibe coders. With it, you push your code, the platform identifies your framework, configures the build and start commands, and deploys your app, all without any configuration. For more on the zero-config experience, see our articles on static analysis without execution and why AI-generated Dockerfiles won't build. For more on specific frameworks, see our articles on deploying Django + React, deploying Go Fiber APIs, and deploying Rust Axum APIs.

Advanced Detection Patterns

Beyond the basics, framework detection benefits from several advanced patterns. The first is custom framework support. The engine supports 30+ frameworks, but some teams use custom frameworks (e.g., an internal framework built on top of Express). The fix is to allow teams to define custom framework signatures via a configuration file (e.g., .deployxa/framework.json), which the engine loads and uses alongside the built-in signatures. The second is version-specific detection. Some frameworks have different configurations for different versions (e.g., Next.js 14 vs. Next.js 15 have different default behaviors). The fix is to detect the framework version (from the manifest file) and to apply version-specific configuration. The third is monorepo workspace detection. Monorepos often have multiple workspaces (e.g., apps/web, apps/api, packages/shared), each of which might be a separate service. The fix is to detect workspaces (via package.json's workspaces field, or via Turborepo's turbo.json) and to treat each as a separate service. The fourth is build tool detection. Some apps use non-standard build tools (e.g., esbuild directly, instead of via Vite or Webpack). The fix is to detect the build tool from the manifest file and to configure the build command accordingly. The fifth is runtime version detection. Some apps require a specific runtime version (e.g., Node.js 18, not 20). The fix is to detect the required version from the manifest file (e.g., engines.node in package.json) and to use the correct runtime. For more on detection, see our articles on static analysis without execution and the heuristic advisor.

Conclusion: Detect Once, Deploy Anywhere

The auto-detection engine is the foundation of Deployxa's zero-config experience. By inspecting your repository's manifest files and matching them against a database of framework signatures, the engine identifies your framework in under 5 seconds and generates the correct build and start commands automatically. This eliminates the Dockerfile, eliminates the configuration file, and eliminates the errors that come with hand-written configuration. For vibe coders, this means you can deploy any of 30+ frameworks without learning Docker or writing configuration files.

Ready to deploy with zero configuration? Drag your project to Deployxa Drop for an instant live preview, or install the CLI with npm i -g @deployxa/cli and deploy from your terminal. For more on Deployxa's engineering, see our articles on the heuristic advisor and database connection pooling across blue/green deployments. Learn about static analysis without execution and building the Deployxa CLI in our companion articles. Explore our free developer tools to speed up your workflow.