Skip to main content

Deployment

Page summary:

Deployment options cover hardware/software prerequisites, environment variable setup, and building the admin panel before launch, plus the principles a continuous deployment pipeline should respect. In the documentation: links to provider‑specific and advanced guides to help pick the right hosting strategy.

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 Cloud

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

Tip

If you already created a content structure with the Content-Type Builder and added some data through the Content Manager to your local (development) Strapi instance, you can leverage the data management system to transfer data from a Strapi instance to another one.

Another possible workflow is to first create the content structure locally, push your project to a git-based repository, deploy the changes to production, and only then add content to the production instance.

Caution

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.

Before installing Strapi, the following requirements must be installed on your computer:

  • Node.js: Only Active LTS or Maintenance LTS versions are supported (currently v22, v24, and v26). Odd-number releases of Node, known as "current" versions of Node.js, are not supported (e.g. v23, v25).
  • Your preferred Node.js package manager:
    • npm (v6 and above)
    • pnpm (on Strapi Cloud, Corepack matches the pnpm version pinned in your project's package.json packageManager field, or uses Corepack's bundled default if none is pinned)
  • Python (if using a SQLite database)
  • A supported web browser: The Admin panel targets browsers matching the default Browserslist query: last 3 major versions, Firefox ESR, last 2 Opera versions, and not dead. See browsersl.ist for the current coverage matrix. Projects can override these defaults with a Browserslist configuration at the project root.

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

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

    HardwareRecommendedMinimum
    CPU2+ cores1 core
    Memory4GB+2GB
    Disk32GB+8GB

  • A supported database version:

DatabaseRecommendedMinimum
MySQL8.48.0
MariaDB11.410.3
PostgreSQL17.014.0
SQLite33

Strapi does not support MongoDB (or any NoSQL databases), nor does it support any "Cloud Native" databases (e.g., Amazon Aurora, Google Cloud SQL, etc.).

Database deployment

Deploying databases along with Strapi is covered in the databases guide.

  • A supported operating system:

    Operating SystemRecommendedMinimum
    Ubuntu (LTS)24.0420.04
    Debian11.x10.x
    RHEL10.x8.x
    macOS26.011.x
    Windows Desktop1110
    Windows ServerNot SupportedNot Supported

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:

/config/server.js

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
Tip

To learn more about configuration details, see the configurations documentation.

2. Launch the server​

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

terminal
NODE_ENV=production yarn build

Run the server with the production settings:

terminal
NODE_ENV=production yarn start
Caution

We highly recommend using 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:

./server.js

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

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.

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:

.github/workflows/deploy.yml
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).
Caution

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.

Tip

Strapi Cloud handles this pipeline for you: it builds and deploys on every push to the tracked branch, so no workflow file is needed.

Additional resources​

Prerequisites

Before following any of the provider guides listed below:

The integrations page 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:


In addition, community-maintained guides for additional providers are available in the Strapi Forum. This includes the following guides:


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

Multi-tenancy

If you're looking for multi-tenancy options, the Strapi Blog has a comprehensive guide.

Was this page helpful?
On this page
Contribute to this page