Skip to content

Deployment process

Jump to bottom
Candice edited this page Jul 29, 2025 · 18 revisions

The Strapi instance is deployed automatically to AWS using GitHub Actions.

🌱 Branch Overview

  • dev Used for internal development and testing. Changes here are reflected in the development environment. The development instance is intended primarily for testing major updates (such as version upgrades), it has a separate/isolated server and database.

  • main Represents the production-ready version. The staging and production environments share a Strapi application and database. Pushing to this branch triggers a deployment to the staging and production environments.

Deploying content updated within the Strapi CMS

  • Adding or editing content entries (e.g., updating a description, adding a new item) does not trigger a rebuild.
  • These changes can be made at any time via the Strapi admin and will appear immediately with no downtime. (See Deploying Content to the Portal)

Deployment Process

  • Modifying content types (e.g., adding a field, renaming a model property) does trigger a rebuild of the backend.
  • This causes temporary downtime (typically a few minutes) of the admin interface as the server rebuilds and redeploys. Note that the API will continue to work without interruption.

Development Environment

  • Push your changes to the dev branch.
  • This automatically triggers a GitHub Action that updates the dev Strapi instance.

Staging & Production Environments

  • Push your changes to the main branch.
  • This triggers the GitHub Action to rebuild and deploy to both staging and production.

⚠️ Important Considerations

  • Downtime Risk: Since schema changes require a rebuild, expect temporary downtime of the admin interface during deployment. There will be no downtime for the API.
  • Coordinate with Server Team: If there is any confusion about production updates, please check in with the server team to ensure safe rollout and visibility.
  • API routes and permissions : When adding new API routes or users, you will need to apply the necessary permissions in the admin panel for them to be publicly available. See information about API Routes.

Deploying content to the portal

For most content managed in Strapi, updates made through the CMS are reflected automatically in the portal without requiring code changes or manual deployment.

🔄 When a Portal Rebuild is Required

If your content update involves the creation of a new route in the NIAID Data Ecosystem Portal - such as adding a new dynamic page (ex: documentation page docs/new-route) - you will need to trigger a portal rebuild to generate the new route.

Example

If you add a documentation page titled "Help" with the slug /docs/help, you must initiate a rebuild of the portal. This ensures that the route is statically generated and becomes accessible on the live site.

✅ No code changes are needed - just the rebuild.

Additional information about dynamic routing in Next.js can be found here.

Steps to re-build:

  1. Navigate to the NIAID Data Ecosystem Portal Github Actions tab. Find the last deployment on the desired branch. image

  2. Click on re-run all jobs. image

Clone this wiki locally