How DeployHQ detects your project's tech stack

When you connect a repository to a DeployHQ project, we look at a small set of well-known manifest files in the working copy to identify which framework the project uses. We use that information today to send more relevant onboarding emails. This article documents what we look at, when, and how to correct a result if it is wrong.

What we detect

DeployHQ recognises the following frameworks and runtimes:

• PHP: Laravel, Symfony, WordPress, Drupal, Craft CMS, Statamic, October CMS, Lunar, Twill, Winter CMS
• Ruby: Ruby on Rails, Jekyll
• Python: Django
• Node: Next.js, Nuxt, Astro, Remix, SvelteKit, Hexo, Eleventy
• Static-site generators: Hugo

If your project does not match any of these specifically, it may still be classified as a generic Node or PHP application based on the presence of a package.json or composer.json. Projects we cannot classify at all are simply skipped — there is no error, no impact on your deployments.

What files we read

Detection is read-only and limited to manifest files. Specifically we may read:

• composer.json and composer.lock
• package.json, package-lock.json, yarn.lock, pnpm-lock.yaml, bun.lockb
• Gemfile and Gemfile.lock
• requirements.txt, pyproject.toml, Pipfile
• manage.py
• _config.yml
• hugo.toml, hugo.yaml, hugo.json, config.toml, config.yaml, config.json
• .eleventy.js, eleventy.config.js, eleventy.config.cjs, eleventy.config.mjs
• wp-includes/version.php, wp-includes/vars.php
• .ruby-version, .nvmrc, .node-version

We do not read application source code, environment files, secrets, or anything outside this list.

When detection runs

Detection runs automatically:

• After the first time we clone your repository
• After subsequent pulls when new commits have arrived

The check is local to the cached working copy on our build infrastructure. It does not make outbound network calls and does not affect deployment performance.

What we use the result for

Today, the detected framework is used to pick a more relevant onboarding email template — for example, sending Laravel-specific deployment tips when we know your project is Laravel, rather than generic guidance. The result is stored against the project, and is not shared with anyone outside DeployHQ.

Limitations

• Monorepos: we currently only scan the root of the repository. If you have multiple frameworks under a directory like apps/web or packages/*, only the framework at the root (if any) is detected.
• Custom or proprietary frameworks: we only recognise the frameworks listed above. Anything else falls back to a generic classification or none at all.
• Private dependency mirrors: if your manifest files reference a renamed or vendored copy of a known framework, detection may not recognise it.

Correcting a wrong classification

If you believe the detected framework is wrong and it is affecting the relevance of the emails you receive from us, please contact our support team. We can adjust the classification on your project directly.

Privacy

Detection runs per project, scoped to the account that owns it. Detected stack data is never shared across accounts and is never sent to any third party. We rely only on the manifest files listed above and never read your application code or environment configuration.