> ## Knowledge Base Index
> Fetch the complete knowledge base index at: https://help.hodi.host/sitemap.xml
> Use this file to discover available pages before exploring further.
> Pure-Markdown content can be obtained by appending a '.md' suffix to the content URLs listed in the sitemap (without the trailing slash).

# Can I use a vercel.json file?

Hodifly reads the `vercel.json` at the root of your repository and applies it at deploy time. For most static projects, migrating from Vercel means changing nothing at all: push the same repository and your redirects, headers, clean URLs and cron jobs carry over. Serverless functions in `api/` run too: see the dedicated article "[How to create serverless functions?](https://help.hodi.host/en/article/how-to-create-serverless-functions-hnbl67/)".

## What is converted

| vercel.json key | What happens on Hodifly |
| ---- |
| `redirects` | Converted to Apache rules. `permanent: true` (or omitted) gives a 308, `permanent: false` a 307, `statusCode` is honored (301, 302, ...). Path patterns like `/blog/:slug`, `/files/:path*` and regex sources like `/(.*)` work, and named parameters can be reused in the destination. External URLs are allowed. |
| `rewrites` | Converted to internal rules: the URL stays as typed while another page is served (the classic SPA fallback `{ "source": "/(.*)", "destination": "/index.html" }` works as-is). Real files always win over a rewrite, exactly like on Vercel. |
| `headers` | Each `source` pattern becomes a header rule (security headers, `Cache-Control`, ...). |
| `cleanUrls` | `/about` serves `about.html`, and `/about.html` answers a 308 redirect to `/about`. |
| `trailingSlash` | `true` adds the slash with a 308, `false` removes it. |
| `images` | Translated into image optimization with [PageSpeed](https://help.hodi.host/en/article/what-is-modpagespeed-19op1ti/): recompression at configured quality and WebP conversion. `sizes`, `domains`, and `remotePatterns` have no equivalent (no on-demand resizing API). If you are already using PageSpeed ​​for this site, yours wins; nothing is overwritten. |
| `crons` | Each entry becomes a real cron job on your account, visible and editable in cPanel, Cron Jobs. If your project has a `CRON_SECRET` environment variable, invocations carry `Authorization: Bearer <secret>`, same convention as Vercel. |
| `buildCommand`, `outputDirectory`, `installCommand` | Read from the file at every deploy: they pin the install and the build. For a **static site** they also pin the published folder: the project is detected as framework "Vercel" and those fields become read-only in the cPanel form. For an **application** (Next.js, Nuxt, TanStack Start, Astro or SvelteKit in server mode, Remix, and also PHP and Ruby apps), the framework decides the shape of the deployment: `buildCommand` and `installCommand` are applied, but `outputDirectory` is **ignored**, with a note in the deploy log. It has to be: for an application the published folder is the app root Passenger serves (`.output`, `build`, `.next/standalone`), not a folder of static files. Editing `vercel.json` and pushing is how you change them. |
| `api/` functions | Run for real, with or without a vercel.json. See the functions article. |

The deploy log lists exactly what was converted (rule counts) and warns about anything that was not, so you never have to guess.

## Precedence

If your repository also contains Netlify-style `_redirects` or `_headers` files, they are ignored as soon as a `vercel.json` exists: one configuration source, no silent merging. The deploy log says so explicitly.

## What is not converted, and why

* `rewrites` pointing at an **external URL** (proxying): serving another site through yours needs a proxy layer that shared hosting does not expose. The rule is skipped, with a warning in the deploy log. Redirects to external URLs work fine.
* `has` / `missing` conditions on redirects, rewrites or headers: condition matching on cookies, query or headers is not translatable to per-directory Apache rules. Rules carrying them are skipped, with a warning naming each one.
* `routes` (the legacy syntax): migrate those entries to `redirects` / `rewrites` / `headers`; Vercel itself deprecated the key.
* `regions`, `fluid`: platform-specific to Vercel, no equivalent here. Images are served as-is (no optimization pipeline).

## Good to know

* The `vercel.json` file itself is never served: it is removed from the published output.
* `cleanUrls` and `trailingSlash` redirects are safe with SPA rewrites and custom 404 pages: internal rewrites never re-trigger them.
* Everything is re-applied on every deploy. Editing `vercel.json` and pushing is all it takes.