import HardwareRequire from '/docs/snippets/hardware-require.md'
import OperatingSystemRequire from '/docs/snippets/operating-system-require.md'
import InstallPrereq from '/docs/snippets/installation-prerequisites.md'
import SupportedDatabases from '/docs/snippets/supported-databases.md'

Deployment#

Strapi provides many deployment options for your project or application. Your Strapi applications can be deployed on traditional hosting servers or your preferred hosting provider.

The following documentation covers the basics of how to prepare Strapi for deployment on with several common hosting options.

:::strapi Strapi Cloud
You can use Strapi Cloud to quickly deploy and host your project.
:::

For self-hosted Kubernetes deployments, we recommend using npm rather than pnpm. pnpm aggressive hoisting of dependencies can break native modules, such as mysql2, that your application may rely on. npm flatter, more predictable node_modules layout helps ensure native packages load correctly.

General guidelines#

This section covers the hardware, software, and configuration requirements for deploying Strapi.

Hardware and software requirements#

To provide the best possible environment for Strapi the following requirements apply to development (local) and staging and production workflows.

• Standard build tools for your OS (the build-essentials package on most Debian-based systems)

• Hardware specifications for your server (CPU, RAM, storage):

• A supported database version:

:::strapi Database deployment
Deploying databases along with Strapi is covered in the databases guide.
:::

• A supported operating system:

Application Configuration#

Configuring a Strapi application for production takes 2 steps: setting the configuration through environment variables, then building the admin panel and launching the server.

1. Configure#

We recommend using environment variables to configure your application based on the environment, for example:

module.exports = ({ env }) => ({
  host: env('HOST', '0.0.0.0'),
  port: env.int('PORT', 1337),
});

Strapi generates a .env file with default values when you create a new project. You can edit this file or set variables in your chosen deployment platform (see example .env file):

HOST=10.0.0.1
PORT=1338

2. Launch the server#

Before running your server in production you need to build your admin panel for production:

NODE_ENV=production yarn build

NODE_ENV=production npm run build

npm install --save-dev cross-env

Then in your package.json scripts section:

"build:win": "cross-env NODE_ENV=production npm run build",

And run:

npm run build:win

Run the server with the production settings:

NODE_ENV=production yarn start

NODE_ENV=production npm run start

npm install --save-dev cross-env

Then in your package.json scripts section:

"start:win": "cross-env NODE_ENV=production npm run start",

And run:

npm run start:win

We highly recommend using a process manager such as PM2 to manage your process.

If you need a server.js file to be able to run node server.js instead of npm run start then create a ./server.js file as follows:

const strapi = require('@strapi/strapi');
strapi.createStrapi(/* {...} */).start();

If you are developing a TypeScript-based project you must provide the distDir option to start the server.
For more information, consult the TypeScript documentation.

:::tip Health check endpoint
Strapi exposes a lightweight health check route at /_health for uptime monitors and load balancers. When the server is ready, it responds with an HTTP 204 No Content status and a strapi: You are so French! header value, which you can use to confirm the application is reachable.
:::

Advanced configurations#

If you want to host the administration on another server than the API, please take a look at this dedicated section.

Continuous deployment#

The build and start commands described above are the steps a deployment pipeline automates. Strapi does not require a specific continuous integration tool. Any pipeline that can install dependencies, build the admin panel, and run the server works. This includes GitHub Actions, GitLab CI, Jenkins, and your hosting provider's own build system.

The following example builds a Strapi project on every push to the main branch. It stops at the build step, as the deployment step depends on your hosting provider:

name: Deploy

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: yarn

      - run: yarn install --frozen-lockfile

      # NODE_ENV is set on the build step only: setting it at the job level
      # would skip devDependencies during yarn install
      - run: yarn build
        env:
          NODE_ENV: production
          APP_KEYS: ${{ secrets.APP_KEYS }}
          API_TOKEN_SALT: ${{ secrets.API_TOKEN_SALT }}
          ADMIN_JWT_SECRET: ${{ secrets.ADMIN_JWT_SECRET }}
          JWT_SECRET: ${{ secrets.JWT_SECRET }}
          TRANSFER_TOKEN_SALT: ${{ secrets.TRANSFER_TOKEN_SALT }}
          ENCRYPTION_KEY: ${{ secrets.ENCRYPTION_KEY }}

      # Add your provider's deployment step here, for instance uploading the
      # build output, pushing a Docker image, or triggering a remote deploy.

The example above follows the principles any Strapi pipeline should respect, whichever tool you use:

• Build the admin panel in the pipeline, with NODE_ENV set to production. The admin panel is a static bundle that must be rebuilt whenever the code or the admin configuration changes.
• Inject secrets from the CI tool, never from a committed .env file. At minimum, APP_KEYS, API_TOKEN_SALT, ADMIN_JWT_SECRET, JWT_SECRET, TRANSFER_TOKEN_SALT, ENCRYPTION_KEY, and the database credentials must be available to the build and to the running server (see environment configuration).
• Use the same secrets across deployments of a given environment. Regenerating APP_KEYS, ADMIN_JWT_SECRET, or JWT_SECRET between 2 deployments invalidates existing sessions and API tokens.
• Keep environments isolated: a staging pipeline should never point at the production database.
• Account for the schema sync: starting Strapi with a modified content-types schema alters the database, and removing a content-type drops its table. Review the changes a deployment introduces before it reaches production (see database migrations).

Content-types created in one environment travel with your code, not with your data. Content-types cannot be created or updated in production (see FAQ), so schema changes must come from the deployed code. To move content between environments, use the Data Management feature.

Deployment guides#

Before following any of the guides listed below:

• Your Strapi project is created.
• You have read the general deployment guidelines.

The following guides cover serving Strapi behind a reverse proxy and running it under a process manager:

In addition, the of the Strapi website include information on how to integrate Strapi with many resources, including how to deploy Strapi on the following 3rd-party platforms. These guides expect your code to be hosted on GitHub:

The following external guide(s), not officially maintained by Strapi, might also help deploy Strapi on various environments:

:::strapi Multi-tenancy
If you're looking for multi-tenancy options, the Strapi Blog has a .
:::