September 2026 Summaries

Strapi 5.47+ includes an MCP server that can expose content-management actions to AI clients such as Claude and Cursor when enabled and authenticated with admin tokens, whose permissions determine which tools and content are visible. The tutorial demonstrates creating a Strapi project with seeded content, connecting an MCP client, and developing a reusable healthcheck service that verifies application and database status through three interfaces: a REST endpoint, a custom MCP tool, and an in-admin AI chat tool. It distinguishes services, controllers, routes, MCP tools, API tokens, admin tokens, public/authenticated roles, and administrator RBAC, emphasizing that each interface requires separate permissions. It also explains how to install the TanStack AI plugin and Ollama to run a local tool-capable model without sending content or API keys off the machine, then register app services as chat tools through configuration and metadata. For reusable tools, the tutorial recommends packaging them as plugins, which centralizes tool definitions, permissions, MCP registration, and automatic chat discovery, while troubleshooting guidance focuses on permission misconfiguration, authentication-token misuse, tool registration, and stale client tool lists.

Vendor lock-in in content management occurs when proprietary schemas, APIs, templates, plugins, hosting, and workflow runtimes make moving to another platform costly despite nominal data-export options. The risk accumulates through custom integrations, vendor-specific rich-text formats and query languages, tightly coupled hosting, closed extensions, and undocumented business logic, limiting a team’s ability to change frontends, infrastructure, or services over time. The discussion recommends evaluating CMS products before purchase by testing complete content exports, checking standards compliance and extension portability, reviewing licensing and self-hosting options, and identifying exclusions or rate limits in migration tools. It presents open-source, headless, API-first architectures as ways to reduce dependence by separating content from presentation, enabling deployment flexibility, and allowing code to be audited or forked. To preserve an affordable exit path, teams are advised to use structured and portable content models, document relationships and localization, maintain migration runbooks in source control, conduct staging dry runs, and define rollback and cutover procedures.

SQL and GraphQL address different architectural layers rather than competing directly: SQL is a standardized relational database language for storage, transactions, integrity, joins, and optimizer-driven querying, while GraphQL is a typed API query language that lets clients request precisely shaped responses through resolvers connected to databases or other services. SQL remains strong for relational aggregation and portability, although vendor dialects reduce portability and recursive graph traversal, real-time subscriptions, and semi-structured data can be awkward; GraphQL improves API flexibility, nested data retrieval, introspection, polymorphism, and subscriptions but does not enforce data integrity or automatically prevent performance issues such as N+1 queries. Techniques including DataLoader batching, query compilation, and query-cost limits help GraphQL operate efficiently over SQL-backed systems. Other specialized languages, including Cypher for graph traversal, MongoDB’s query language for documents, PromQL for time-series metrics, and ES|QL for search relevance, can better suit domain-specific workloads but increase operational complexity. The recommended pattern is often SQL as the source of truth with GraphQL as an external API layer, as illustrated by Strapi 5, which exposes REST and GraphQL over SQL databases through its Document Service, Query Engine, Knex, and database-driver layers.

Content governance in a headless Strapi 5 architecture is presented as a developer-owned, code-driven system for controlling who can create, review, publish, localize, and audit content distributed across multiple channels. The guide recommends least-privilege role-based access control with Content-Type, field, locale, and token scopes; enterprise Review Workflows for formal approval stages; and Document Service middlewares, rather than lifecycle hooks, to enforce publication requirements such as completed metadata, approved workflow stages, translation coverage, and channel-specific rules. It highlights risks including accidental auto-publication, draft exposure caused by differing API defaults, incomplete locale publishing, and overly broad API tokens. Because built-in Enterprise Audit Logs primarily cover Admin Panel activity and exclude REST and GraphQL Content API mutations, the guide advises implementing custom append-only audit logging for API-driven actions, capturing actors, timestamps, before-and-after states, and checksums. Webhooks, signed payloads, retries, cache invalidation, scheduled checks, and integration tests extend governance beyond the CMS, while explicit locale rules and narrowly scoped public or partner API access help prevent incomplete translations and unauthorized content exposure.

Self-hosting a headless CMS such as Strapi eliminates license fees but transfers responsibility for infrastructure, databases, security, backups, monitoring, upgrades, incident response, and compliance to the organization, making engineering labor and operational maintenance major components of total cost of ownership. The guide estimates that modest hosting infrastructure may cost tens to hundreds of dollars per month, while recurring DevOps work, observability, security tooling, audits, scaling components, and downtime risks can substantially exceed the cloud bill. It highlights technical requirements such as supported Node.js and database versions, secret management, multi-instance scaling with object storage and Redis, and the manual work involved in major Strapi migrations. Self-hosting is presented as most appropriate for strict data-residency needs, unusual workload economics, deep architectural customization, or teams with existing platform engineering capacity, while managed hosting can reduce operational burdens without requiring changes to the core codebase. The recommended decision process is to compare deployment options using actual costs for infrastructure, fully loaded staff time, security and compliance, upgrades, scaling, incident coverage, knowledge concentration, and product-development opportunity cost.

A CMS migration checklist should begin with an exit audit that measures vendor lock-in before development starts, since moving content involves extracting, transforming, validating, and loading data rather than simply copying it between incompatible systems. The audit examines nine areas: content models and export fidelity, API queries and SDK dependencies, authentication and role configuration, plugins and integrations, media ownership and transformation pipelines, infrastructure and hosting control, and contractual and licensing risks. It recommends testing real, production-like exports because documentation may not reveal missing relations, excluded assets, rate limits, unavailable bulk exports, or import failures, while also cataloging every vendor-specific query, response format, SDK call, and configuration that requires rewriting. Teams should distinguish portable business logic from platform-specific wiring, document UI-only permissions and identity settings, assess ownership of databases and asset buckets, and review termination windows, API availability, deletion obligations, switching charges, and open-source governance risks. A three-level scoring model rates each area as portable, partially locked, or fully locked, producing a migration sequence that addresses the most restrictive dependencies first and favors target platforms with version-controlled schemas, standard interfaces, accessible databases, bulk export options, and storage controlled by the organization.

Content agents are autonomous AI systems that use CMS APIs to observe content state, plan and execute multi-step operations, and verify outcomes in a recurring observe-plan-act-evaluate loop. Unlike chatbots that only respond, copilots that require approval for each suggestion, and deterministic automation rules that follow fixed triggers, agents can adapt to contextual conditions such as missing locales, failed validation, review delays, or publishing schedules. They are best suited to API-first headless CMS platforms with granular permissions, scoped machine tokens, programmatic publishing and localization controls, event hooks, validation feedback, and audit trails. The article uses Strapi 5 as an example, highlighting its Document Service API, webhooks, Draft and Publish features, locale-aware operations, RBAC, tokens, and optional MCP server as components for agent workflows such as draft-review-publish cycles, multilingual orchestration, and continuous content governance. It emphasizes that agents should operate with least-privilege access and human approval for consequential actions such as publishing or deletion, and recommends starting with read-only monitoring before expanding autonomy. Rather than treating agents as an automatic upgrade, organizations should use them only when workflows require flexible, multi-step decisions that brittle rules or simple model calls cannot reliably handle.

CMS migrations can significantly reduce organic search visibility even when launches succeed technically, because search engines must recrawl and reassess URLs, redirects, canonical signals, rendering, internal links, and content metadata. Effective migration planning begins with a detailed pre-launch baseline of crawl data, Search Console performance, Core Web Vitals, internal link structure, and structured data, followed by a complete one-to-one URL map using single-hop server-side 301 or 308 redirects. Teams should preserve titles, headings, canonicals, hreflang, schema, social metadata, robots.txt rules, sitemaps, and rendered HTML while testing production-like redirect behavior and avoiding staging configuration leaks. After launch, they should submit old and new sitemaps, monitor crawling, index coverage, errors, rankings, traffic, and performance for several weeks, while retaining redirects for at least a year. Headless CMS architectures can reduce risks in future migrations by keeping slugs and SEO metadata in reusable content models rather than presentation-layer templates, but they still require reliable server rendering, sitemap generation, and automated SEO validation in deployment pipelines.

Strapi’s latest updates, including the generally available Media Library in v5.54, introduce a persistent folder tree, drag-and-drop organization, infinite scrolling, side-panel file details, and MCP tools for managing media. Plugin developers can now add custom MCP tools, while AI agent actions are logged in audit trails alongside administrator actions, with expanded exports and event tracking. Additional improvements include the ability to terminate active admin sessions and warnings when publishing documents linked to drafts, while planned work includes support for bring-your-own AI providers, content-type folders, and TypeScript enhancements. Demonstrations showed how custom MCP-enabled plugins can support internal AI chat interfaces and selectively expose tools to external clients, how a Claude Code skill can assist staged WordPress-to-Strapi migrations through planning and dry runs, and how VirtusLab’s paid XECP plugin promotes selected content, media, relations, dynamic zones, and locales safely between environments. Strapi also expanded its LaunchPad starter projects to Astro, Nuxt, and TanStack Start, alongside Next.js, and encouraged users to upgrade, contribute TypeScript feedback, and share community projects.

A Claude Code skill for migrating WordPress sites to Strapi v5 uses the WordPress REST API to export content, infer Strapi content types and components, generate a configurable migration plan, and move entries, media, and relations after human review. The migration separates reusable content such as titles, dates, images, authors, and structured page sections from WordPress theme presentation settings, while encouraging improvements such as typed fields, relations, repeatable components, and dynamic zones for page-builder layouts. Its main caution is that WordPress custom post types and fields may be absent from the REST API unless explicitly enabled, allowing incomplete migrations to appear successful; a temporary helper plugin and authenticated API requests can expose these hidden items. The workflow consists of export, analysis, review, schema generation, migration, and verification, supports repeat runs without duplicates through stored WordPress IDs, and provides reports for unsupported widgets, missing media, URL changes, and old-domain references. Tests on a practice site and a commercial-theme demo migrated content successfully but identified issues including hidden ACF and Meta Box fields, Elementor layouts, unsupported SVG uploads, page-builder widgets requiring reconstruction, tables flattened in rich text, orphaned media, comments, WooCommerce data, and multilingual content that need separate handling. The guidance recommends practicing on a copy, deciding URL and content-model rules before migration, using dry runs and incremental batches, and using database-level tools or custom scripts for very large sites.

Strapi’s Docs MCP server is a Kapa-hosted remote MCP endpoint that enables AI coding tools such as Cursor, VS Code with GitHub Copilot, Claude Code, and Windsurf to query current Strapi documentation at answer time, helping avoid outdated Strapi 4 patterns when developing with Strapi 5. Available through a single public URL without authentication or a Strapi version requirement, it provides documentation retrieval rather than access to project content, and can be configured with client-specific settings or the Claude Code CLI. The service is particularly useful for addressing migration-related differences including the replacement of Entity Service with Document Service, use of persistent documentId values instead of numeric IDs, flattened REST response structures, and changed publication APIs. Effective use involves explicitly asking the assistant to use the Docs MCP server, specifying Strapi 5, and linking relevant documentation pages, while persistent IDE rules or project instructions can reinforce these requirements. Strapi also offers llms.txt resources, Markdown documentation exports, repository guidance files, and the Inki plugin for broader AI-assisted workflows. In contrast, Strapi’s separate content MCP server runs on a user’s own Strapi instance, requires version 5.47.0 or later and an Admin token, and allows authorized agents to create, update, publish, and delete content; teams can use both servers together to combine accurate documentation-based coding guidance with controlled content management.

Strapi 5’s AI Media Library can generate editable alternative text and captions for supported image files during upload and, from version 5.34 onward, can retroactively process existing images missing metadata. Available only to Growth-plan users running version 5.30 or later, the feature uses shared monthly AI credits, continues through paid overages after the allowance is exhausted, and offers usage notifications but no published per-image cost or hard spending cap. Automated metadata can help reduce accessibility and SEO gaps associated with missing, generic, or filename-based alt text, but generated output requires editorial review because models may miss page context, make inaccurate assumptions, or describe decorative images that should have empty alt attributes. The upload workflow opens a review modal where editors can revise generated fields before saving, while the beta backlog tool processes images missing metadata in bulk, making credit planning and prioritizing high-value assets important. Strapi states that AI requests are processed through its infrastructure and sent to third-party AI providers, so organizations with sensitive-content or data-residency requirements may need additional clarification before enabling the feature.

An n8n and Strapi MCP pipeline can automate recurring content production by coordinating scheduled triggers, focused research and writing agents, deterministic validation steps, human approval, and restricted CMS publishing actions. n8n manages sequencing, retries, deduplication, approval waits, and error workflows, while Strapi’s built-in MCP server exposes typed content-management tools through the `/mcp` endpoint according to scoped Admin token permissions. A recommended research-to-publish design normalizes each topic, derives a stable slug, removes previously processed items, researches and drafts content through separate agents, searches Strapi before creating or updating a draft, and publishes only after human approval using a separate publish-only token. Reliable reruns depend on deterministic slugs, list-before-create checks, and retry policies that account for ambiguous network failures, while request and workflow timeouts provide operational limits. Security relies on dedicated, least-privilege Admin tokens, limited tool visibility, field- and locale-level permissions where needed, HTTPS, credential storage, token rotation, and optional audit logs for MCP writes.

Strapi AI adds a natural-language chat assistant to the Content-Type Builder that can generate and modify Collection Types, Single Types, Components, fields, and relations, explain existing schemas, and help plan data models using current content types as context. Available in development mode for Strapi 5.30 or later on Growth plans, including Cloud and self-hosted deployments, it uses a shared monthly AI-credit pool and produces unsaved changes that users must inspect, adjust, and save before Strapi writes standard schema.json files and restarts. Users can provide prompts, code, Figma projects, or images, with detailed descriptions of fields and relation cardinality generally producing more reliable results. The tool differs from external coding assistants and Strapi’s MCP integrations, which respectively edit code or manage content entries rather than live schemas through the Admin Panel. Careful review remains important for field settings, relation direction, dynamic-zone constraints, and naming, while production deployment, lifecycle hooks, plugin model extensions, custom implementation needs, and unsupported plans or environments still require manually maintained files, version control, and deployment workflows.

Strapi 5’s MCP server enables AI clients such as Claude Code or Cursor to manage multilingual content through locale-specific tool calls when the Internationalization feature is enabled, replacing repetitive manual Content Manager workflows with conversational automation. Each localized variant is selected through a shared documentId and a locale parameter, while omitted locales default silently to the configured default language, making explicit language instructions important. Effective setup requires enabling i18n for relevant content types and fields, activating the MCP endpoint, using an Admin token with least-privilege locale and action permissions, and optionally enabling Draft and Publish for reviewable per-locale releases. A typical workflow creates a source entry, creates or updates translations, verifies each locale individually because Strapi 5 no longer supports locale=all, confirms that localized variants share the source documentId, and publishes each language separately through MCP. MCP only targets and writes content; it does not translate automatically, unlike Strapi’s AI-powered internationalization feature, which translates default-locale edits into other locales but can overwrite manual edits. Important limitations include uncertain documented support for attaching generic locale-targeted creates to an existing document, no media uploads or bulk multi-locale MCP operations, untyped Dynamic Zones, shallow relation retrieval, scalar-only filtering, and runtime permission failures for unauthorized locale actions.

Strapi 5’s built-in Model Context Protocol server enables Claude Desktop to create, review, revise, and publish CMS content through conversational prompts, using the same permissions and Draft and Publish controls as the Content Manager. After a developer enables MCP and provides a suitably scoped Admin token, authors can generate draft articles from notes, retrieve them with list and get tools, update fields such as titles, body text, slugs, excerpts, and categories, and publish approved entries with a final command. New content is normally saved as a draft when Draft and Publish is enabled, although prompts should explicitly prohibit publishing during creation to prevent unintended state changes. The workflow requires deliberate handling of details that are not automatically generated, especially UID slugs, relation fields, locales, and excerpts, while Markdown body fields may be easier for AI to produce than structured rich-text blocks. Media uploads, dynamic zones, certain custom fields, and deeply nested relations still require manual work in the Admin Panel, though Claude can reference media assets already in Strapi’s library. The guidance emphasizes least-privilege token permissions and retaining human control over publication, since AI-generated copy still needs factual, editorial, and presentation review before it goes live.

Knex’s “Timeout acquiring a connection” error in Strapi generally indicates that the application could not establish a database connection within the configured timeout, rather than that its connection pool is full. Troubleshooting should begin by testing database reachability from Strapi’s actual runtime environment, then checking database logs and connection limits; common causes include missing IP allowlists, incorrect firewall or security-group rules, inaccessible private networks, and Docker host misconfiguration. Strapi passes pool settings to Tarn.js through its database configuration, with recommended adjustments including setting the minimum pool size to zero in Docker or serverless deployments and sizing the maximum pool across all application replicas to fit database limits. Increasing timeout values or reducing the pool to one connection is discouraged because it can only delay failures or serialize application queries. Other relevant factors include SSL requirements, transaction-mode connection poolers such as Supabase or PgBouncer, and custom long-running code that genuinely retains connections; configuration tuning should follow confirmation that network access and actual connection exhaustion are not the underlying problem.

A Strapi 500 Internal Server Error is a generic production response that intentionally hides exception details from API clients, making the server log the primary source for diagnosis. Effective troubleshooting involves watching Strapi logs while reproducing the failed request, increasing log verbosity or temporary SQL debugging when needed, distinguishing Strapi JSON errors from proxy-generated failures, and using curl to isolate frontend-related issues. Common causes include unhandled errors in custom controllers, services, middleware, or lifecycle hooks; dropped or exhausted database connections; invalid email or upload provider configuration; broken content-type relationships or components; malformed requests lacking expected JSON headers or bodies; and missing security-related environment variables. Investigation should determine whether the failure affects specific data, roles, parameters, or deployments, while long-term reliability can be improved through centralized searchable logs, error-tracking tools, and health monitoring.

Strapi’s “Cannot destructure property ‘client’ of ‘db.config.connection’ as it is undefined” startup error indicates that no usable database configuration was loaded, rather than a database credential or network failure. The recommended first check is adding a log to the database config file to determine whether it is being loaded; if not, common causes include TypeScript builds configured with `noEmit`, missing configuration files in Docker images, environment-specific database overrides that replace the base configuration with an empty or malformed result, and processes launched from an incorrect working directory or without the required TypeScript distribution directory. If the file does load, its exported function must return Strapi’s expected nested `connection` structure and use the correct module syntax. A diagnostic process should verify the source file, generated `dist/config/database.js`, container contents, active `NODE_ENV` overrides, and process working directory, while distinguishing this build or packaging issue from separate authentication, connection refusal, and timeout errors.

Strapi plugin developers can select icons from the maintained Strapi Design System icon catalog, community viewers, or a locally generated gallery that enumerates the exact exports installed in their project. Icons are imported from the separate @strapi/icons package and used differently depending on context: plugin navigation links and custom-field registrations require a component reference, while buttons and other JSX components require rendered icon elements. SVG icons can be resized and styled with theme-aware design-system color tokens, whereas branded and field-type symbols from @strapi/icons/symbols have built-in colors and should generally only receive dimensions. The guidance also notes major naming and package-location changes in Design System v2, recommends consulting migration resources when porting older plugins, and advises declaring the icon and design-system packages as peer dependencies to avoid duplicate React trees. Developers are encouraged to check imports first when an icon silently fails, use consistent domain-relevant iconography across plugin interfaces, and avoid duplicating icons already associated with Strapi’s core navigation.

A blank Strapi admin screen after deployment, accompanied by a CSP error involving `localhost:1337`, usually results from an admin React bundle built without the correct public URL rather than from an actual CSP configuration problem. Because Strapi embeds its API URL during `strapi build`, deployments must provide `PUBLIC_URL` at build time, set `config/server` to use the public HTTPS address, and rebuild the admin panel before starting production. The server should bind to `0.0.0.0` inside containers, read its internal listening port from `PORT`, and distinguish that port from the externally visible URL, which commonly uses HTTPS without an explicit port. Deployments should also ensure a fresh production build is included in the release artifact, configure a separate admin URL when applicable, and enable `proxy.koa` when operating behind a reverse proxy. CSP rules should only be expanded when the admin legitimately connects to external services such as S3 or Cloudinary, since allowing localhost merely hides the symptom while leaving the incorrectly compiled API endpoint unresolved.

Deploying Strapi 5 behind Nginx improves security by terminating TLS at the proxy, keeping the Node.js process off the public edge, and forwarding requests with headers that preserve the original hostname, protocol, client IP, and WebSocket support. Correct deployment requires both Nginx configuration and Strapi proxy settings, particularly `proxy.koa`, a public HTTPS URL, and bounded forwarded-IP trust, as omissions can cause insecure-cookie login failures, incorrect password-reset or OAuth links, broken admin API calls, and inaccurate client-IP logging. The configuration addresses HTTPS redirection, certificate handling, upload size limits, timeouts, health checks, and connection reuse, while noting that Strapi 5 proxy settings differ from Strapi 4 and that the admin interface must be rebuilt after public URL changes. It also covers subpath hosting, IP-restricted admin access, safe public API caching, and load-balanced deployments that require shared secrets, a common database, and shared media storage. Suggested verification includes checking health endpoints, redirects, login behavior, and large uploads, while common errors such as 502, 413, 504, localhost links, and missing WebSocket functionality are tied to specific proxy or application configuration issues.

Strapi’s “SASL: SCRAM-SERVER-FIRST-MESSAGE: client password must be a string” startup error from the PostgreSQL Node driver usually indicates that the database password is missing or not a string, most often because `DATABASE_PASSWORD` resolves to `undefined`, rather than a SASL, PostgreSQL authentication, or network problem. The issue can be quickly verified by logging only the password variable’s type and whether it is set, then tracing configuration sources such as a misplaced or incorrectly named `.env` file, absent deployment environment variables, a PostgreSQL role without a password, an overriding or malformed `DATABASE_URL`, use of a typed helper such as `env.int()` for the password, or an environment-specific database configuration that replaces the base settings. The recommended prevention measures are to validate required variables early with a clear application-level error and maintain a committed `.env.example` file containing all expected keys. It also distinguishes this error from related failures, noting that incorrect passwords, nonexistent roles or databases, refused connections, connection-pool timeouts, and unloaded configuration files each produce different messages and point to separate causes.

Strapi’s admin panel does not natively provide TOTP-based MFA for local accounts, but deployments can enforce stronger authentication through enterprise SSO connected to an identity provider, a maintained third-party 2FA plugin, or network-level protections such as Cloudflare Access, VPNs, identity-aware proxies, and restricted reverse-proxy routes. SSO is presented as the preferred approach because it centralizes MFA, offboarding, role mapping, and auditing, though teams should disable ordinary local logins for most users while retaining a break-glass Super Admin account to avoid lockout. Plugins may suit teams without an identity provider but require careful assessment of Strapi version compatibility, secret encryption, recovery procedures, maintenance, licensing, and upgrade resilience. Regardless of the chosen method, administrators should apply least-privilege RBAC, protect and rotate application secrets, review admin accounts, enable audit logs where available, restrict session lifetimes, revoke suspicious sessions, and scope API tokens, since compromised secrets or full-access tokens can bypass login protections.

Strapi administrator passwords can be reset without relying on the “Forgot password” email flow by using the supported `strapi admin:reset-user-password` CLI command from the project root, with Yarn, npm, or npx; npm requires an extra `--` before command options. Passwords must meet minimum complexity requirements, and administrators can be listed first with `admin:list-users` if the account email is unknown. Running the reset command without options provides interactive prompts through Yarn or npx, while a database with no administrator requires `admin:create-user` instead. On deployed environments, the command must use the same application configuration, environment variables, and database as the running Strapi instance, whether executed through SSH, Docker, a hosted shell, or locally with production credentials. To make future password-reset emails work, a real email provider such as Nodemailer, SendGrid, SES, Mailgun, or Resend should be configured along with the correct public admin URL. Older console-based methods that directly alter password data are discouraged for Strapi 5 because internal APIs and password hashing mechanisms have changed, making the official CLI commands the safer approach.

Strapi provides an unauthenticated `GET /_health` endpoint that returns HTTP 204 with no body, offering a lightweight liveness signal that confirms the Node process and HTTP server are running but does not verify ongoing database availability, migrations, upload providers, or admin-panel readiness. It can be used for Docker health checks, Kubernetes startup, liveness, and readiness probes, AWS ALB or NLB target-group checks, Nginx upstream monitoring, and external uptime services, though configurations must explicitly accept status 204 rather than the commonly expected 200. Slow Strapi startup due to schema loading, migrations, or database synchronization requires sufficiently long grace periods or Kubernetes startup probes to avoid restart loops. For dependency-aware monitoring, a separate public deep-health route can query the database and return 200 or 503, but it should not replace liveness checks because transient dependency failures could remove all instances from service. A small public content API endpoint is another option for monitors requiring 200 responses and for testing more of the application stack, although it creates database load with each poll.

Strapi’s “Cannot send secure cookie over unencrypted connection” error commonly occurs when HTTPS is terminated at a reverse proxy while Strapi receives the proxied request over HTTP and therefore does not recognize the original connection as secure. In Strapi 5, configuring `proxy.koa: true` enables Koa to trust headers such as `X-Forwarded-Proto`, but the proxy must also send those headers; this differs from Strapi 4, where proxy support used a top-level boolean, making outdated configurations a frequent migration issue. Administrators should rebuild after changing server configuration and verify behavior through request headers, login testing, or temporary protocol logging. Disabling secure cookies is discouraged because it exposes session tokens over HTTP; instead, TLS and forwarded-protocol handling should be configured correctly. The guidance also recommends bounding trusted forwarded IP addresses with `maxIpsCount` to prevent spoofing and ensure reliable rate limits, allowlists, and logs. Proper proxy configuration additionally corrects public URLs, authentication callbacks, client IP detection, and secure admin login behavior, while blank admin panels referencing localhost may indicate a separate build-time public URL issue.

TypeScript can continue emitting JavaScript despite type errors when `noEmitOnError` is false, but it cannot emit usable output for syntax errors such as TS1005 because the source cannot be parsed; the Strapi example involving `import parse = require('pg-connection-string').parse` must therefore be corrected to a valid named import. For temporary, controlled exceptions, the text recommends using `skipLibCheck` for faulty dependency declarations, `@ts-expect-error` for known single-line issues, `@ts-nocheck` only for generated or legacy files, `allowJs` for incremental JavaScript-to-TypeScript migration, and selectively relaxed strictness settings when necessary. To keep local development unblocked while enforcing quality before deployment, it advises separating builds from type checking: allow emission during development, run `tsc --noEmit --watch` in a separate terminal, and require type checking in CI. Strapi projects should avoid placing `noEmit: true` in the root configuration because it prevents production build output, and developers should regenerate Strapi types after schema changes with `strapi ts:generate-types` before suppressing apparent type mismatches.

Strapi 403 Forbidden errors on content API requests usually indicate that the route exists but the requesting identity lacks authorization, most often because the Public role has not been granted separate `find` or `findOne` permissions for a collection type. Other common causes include API tokens missing permissions, authenticated user JWTs governed by the Authenticated role rather than Public permissions, attempts to access admin-only routes instead of `/api` content routes, and route-level policies or middleware that explicitly reject requests. A 200 response with an empty data array is distinct from a 403 and commonly results from Draft & Publish behavior, since only published entries are returned by default and Strapi v5 uses `status=draft` to query drafts. Browser-only failures that work through curl are likely CORS configuration issues rather than permissions problems. The recommended diagnostic process is to verify the route, test it with a full-access token, check publication status, inspect registered routes, and grant only the narrowly required access because Public permissions expose content to the internet.

Strapi 5 admin panels can show a “host not allowed” blank page when accessed through custom domains, tunnels, or proxies during `strapi develop`, because Vite’s development server validates Host headers to protect against DNS-rebinding attacks and normally permits only localhost addresses. Current Strapi 5 releases may already resolve the issue by setting permissive Vite host handling, so upgrading is recommended before changing configuration. For older versions or stricter security, a Vite configuration file should be created under `src/admin/` and use `mergeConfig` to add an explicit `server.allowedHosts` list, with exact domains or dot-prefixed domain patterns preferred over disabling checks with `true` or `all`. The issue applies only to development mode; publicly deployed Strapi instances should instead use a production build and start process, which avoids the Vite dev server and its performance, security, and deployment drawbacks. Tunnel setups that rewrite ports may also affect hot module reloading, though adding Vite’s `hmr.clientPort` should be tested carefully because recent Strapi versions may already handle websocket connections through the application server.

In Strapi, default content for newly created content types should generally be seeded in the `bootstrap()` lifecycle function rather than migrations because migrations run before schema synchronization creates new tables. Bootstrap executes after schemas are synced, supports Strapi 5’s Document Service API, and should use idempotent logic such as unique-key checks, count checks, or plugin-store markers to avoid duplicate records on repeated application starts. Essential reference data, including categories, settings, and statuses, can be seeded in every environment, while demo content should be limited to development or an explicit environment flag, and larger datasets can be maintained as committed JSON files. Migrations remain appropriate for safely transforming existing database data before schema changes remove or alter old structures, such as copying values during a field rename, but they should guard against missing columns and are not intended for one-off production fixes. For moving editor-created content between environments, Strapi Data Transfer is more suitable than seeding, while isolated production cleanup should be performed through deliberate manual scripts.

Strapi’s Content-Type Builder is enabled by the command used to start the server, specifically `strapi develop`, rather than by the `NODE_ENV` variable, which only affects configuration loading, environment displays, and related Node behavior. Running `strapi start` with `NODE_ENV=development` can therefore show a development banner while keeping schema editing disabled because Strapi’s `autoReload` setting remains false. Users should confirm that their package scripts invoke `strapi develop`, inspect environment variables, npm wrappers, Docker configurations, and Windows-specific command syntax if development mode still appears locked, and clear stale build files if necessary. The restriction exists because content-type changes write schema files and require server restarts; enabling such changes on deployed or shared environments could cause untracked schemas, overwritten work on deployment, database schema deletions, data loss, and service interruptions. The recommended workflow is to define content types locally, commit schema files to source control, deploy them through standard releases, and use Data Transfer for moving content between environments.

Strapi’s “Cannot read properties of undefined (reading 'attributes')” startup error generally indicates that a content type schema references a missing component, relation target, dynamic-zone component, or custom field plugin, rather than requiring the project to be recreated. The recommended diagnosis is to compare component references in API and component schemas against files in `src/components`, inspect dynamic zones and relation targets separately, and verify that plugins supplying custom fields remain installed; nested component references can obscure the true missing file. The issue commonly follows major migrations because component locations, names, and schema structures change, so migrated component files and generated schemas should be reviewed carefully. Once identified, a missing component can be restored from version control to preserve its associated database data, or its schema attribute can be removed, though removal may cause Strapi’s schema synchronization to delete related tables and data unless a backup or migration safeguards are used. Temporary startup logging can identify the specific broken reference when the stack trace is unclear, while boot-loop recovery includes reviewing recent changes, stashing work, clearing build artifacts, and moving suspicious files rather than deleting them. Preventive measures include managing components through the Content-Type Builder, version-controlling schema directories, starting Strapi against a temporary database in CI, and running reference checks after migrations.

PM2 can keep self-hosted Strapi applications running after SSH disconnects, crashes, and server reboots, with startup available through a custom server.js file, npm or npx commands, or preferably a version-controlled ecosystem configuration using fork mode and a single instance. Cluster mode is cautioned against because concurrent Strapi processes can conflict during schema synchronization and migrations, duplicate cron jobs, and create problems with local uploads and in-memory caches; larger deployments should instead use shared services, controlled migration steps, and separate instances behind a reverse proxy. Sensitive credentials should remain in a protected server-side .env file rather than a committed ecosystem file, while pm2 startup and pm2 save are both required to restore processes after reboot. Updates should install dependencies and build the admin interface before restarting with refreshed environment variables, and deployments needing no downtime require multiple instances and load balancing. PM2 logging, log rotation, status commands, memory limits, and external health checks support maintenance, although recurring memory-triggered restarts should prompt investigation of leaks or resource-heavy operations. For containerized Strapi deployments, Docker or the orchestration platform should manage process restarts directly instead of running PM2 inside the container.

Strapi upload failures with HTTP 413 errors can result from four separate limits in the request path: a reverse proxy such as Nginx, Strapi’s body middleware using Formidable, the Upload plugin’s sizeLimit setting, and the selected storage provider’s own restrictions. Each layer must permit the intended file size, with Nginx often rejecting requests before Strapi receives them, while distinct HTML, JSON, timeout, provider, and out-of-memory errors help identify the responsible component. Configuration changes should preserve Strapi’s complete default middleware list, place Upload plugin settings in config/plugins, account for stale provider options that can override newer values, and be followed by a rebuild or restart and boundary testing through the API. Provider and platform limits, including Cloudflare plan caps, S3 single-upload constraints, Cloudinary limits, and Strapi Cloud’s fixed non-image cap, cannot be changed through Strapi configuration. For uploads of several hundred megabytes or more, memory consumption, long-running connections, proxy timeouts, and bandwidth costs may make direct-to-storage uploads using presigned URLs a more reliable architecture than routing files through Strapi.

A Strapi startup failure showing a Node.js `path` argument error while loading components usually indicates that Strapi cannot interpret something in `src/components`, causing the admin panel to remain in a restart loop. Possible causes include a Windows-specific regression in Strapi 4.25.x, an invalid component directory structure such as JSON files placed directly under `src/components`, stray non-JSON files, malformed component schemas missing required fields like `collectionName`, references to deleted components in content-type schemas, or stale compiled builds and caches. Recovery involves identifying recent schema or component changes through version control, temporarily moving suspect files out of the components directory, restoring valid schemas and references, and clearing generated build artifacts before rebuilding. The recommended long-term measures are upgrading Strapi rather than downgrading, treating component and content-type schema files as version-controlled code, creating components through the Content-Type Builder when possible, validating schemas in review, and running builds and server startup checks in continuous integration.

Strapi releases v5.49 through v5.52 introduce major extensibility, security, content-management, upload, and developer-experience improvements, including typed MCP builders for plugins, audit logs for MCP agent actions, and active-device session management with revocation support for password and SSO logins. Security updates add expiring admin password-reset tokens, safer SVG defaults for new projects, required environment-variable validation, improved cookie configuration, and resilience for permission roles containing missing or conditional permission rules. Content Manager changes improve publishing warnings for unpublished relations, relation ordering and unsaved-form preservation, accessible list links, dynamic-zone component previews, and revised keyboard shortcuts, while a redesigned Media Library beta adds folder navigation, search and filtering, asset editing, persistent upload queues, and mobile support. Upload handling now supports cache-aware file replacement, replacement size-limit enforcement, low-memory file-type detection, and rotating S3 credentials. Notable behavior changes include empty media galleries returning empty arrays rather than null, literal handling of percent and underscore filter characters, 400 responses for invalid sorting, and default string length limits. Developer-focused updates enforce required relations and media on publishing when enabled, resolve MySQL admin-query issues, add SendGrid EU support, and expand TypeScript, data-transfer, GraphQL, lifecycle-event, and OpenAPI capabilities, alongside translation contributions and 366 merged pull requests.

Strapi 5 includes a built-in Model Context Protocol server, introduced in version 5.47.0 and later made generally available, that lets Cursor IDE agents manage CMS content through natural-language prompts without switching to the Strapi Admin Panel. After enabling MCP in Strapi’s server configuration, creating a permission-scoped Admin token, and adding a streamable HTTP connection to Cursor’s MCP configuration, users can list, create, update, delete, publish, unpublish, and discard drafts for supported Collection and Single Types. Access is controlled by Strapi’s existing Admin permissions, including tool visibility, field and locale restrictions, and runtime conditions, encouraging separate least-privilege tokens for different agents or workflows. Cursor discovers available tools automatically and generally asks users to approve calls, while Strapi supports extensions through plugins that can register additional MCP tools. Common setup problems include using Content API rather than Admin tokens, failing to restart Strapi, incorrect transport settings, and expired or revoked tokens. Limitations include no direct media uploads, weak typing for Dynamic Zones, no nested relation population, restricted sorting, and a reported JSON Schema compatibility issue for some strict MCP clients.

Strapi’s MCP server enables AI clients to perform bulk content creation, updates, publishing, deletion, and migrations by orchestrating single-document tools in a repeatable “list, act, verify” loop rather than using batch endpoints. Safe operation depends on precise scalar-field filters, stable sorting, pagination capped at 100 entries, narrow dry runs, and small batches that reduce timeout risks and make results easier to inspect. Creation workflows should use explicit UID values such as slugs and idempotency checks against unique source identifiers to prevent duplicate drafts, while updates should favor relation operators like connect and disconnect over set to avoid unintentionally replacing existing relations. A recommended migration process maps source data to Strapi schemas, imports media separately because MCP cannot upload files, creates drafts in verified chunks, handles locales explicitly, reconciles counts and spot-checks content before publishing, and resumes interrupted runs by comparing existing identifiers with the source data. Recovery differs by content state: never-published drafts can be deleted, bad drafts on published items can be discarded, and mistakenly published entries may need to be unpublished before removal. Longer MCP timeouts can support migration work, but small units of work remain important, while dedicated least-privilege Admin tokens, restricted permissions, and available audit logs help limit the impact and traceability of destructive AI-driven operations.

Strapi’s MCP server, available from version 5.47.0, enables AI agents to create, update, delete, and publish CMS content through a stateless `/mcp` endpoint authenticated with Admin tokens, making careful permission design essential. Each request is independently authorized, and Strapi applies four layers of protection—tool visibility, field filtering, locale filtering, and runtime document checks—so agents only see and access capabilities permitted by their token. The guidance emphasizes issuing separate, tightly scoped tokens for each AI client or use case, favoring read-only access, restricting publishing rights, and using ownership-based conditions where writing is necessary to limit the impact of token theft, prompt injection, or agent mistakes. Tokens should be stored outside source control in environment variables or dedicated secrets managers, rotated regularly, and served only over HTTPS behind a reverse proxy with network restrictions, while development servers should remain local and unexposed. Revocation and permission changes apply on the next request because no session state persists, and teams can monitor agent-originated content changes through Enterprise Audit Logs tagged with `origin: mcp` or through proxy logging where those logs are unavailable.

Strapi 5.47.0 and later includes a built-in Model Context Protocol server, generally available from version 5.49.0, that lets Windsurf’s Cascade agent manage CMS content through Strapi’s `/mcp` endpoint rather than requiring repeated use of the Admin Panel. Setup requires enabling MCP in Strapi’s server configuration, creating a narrowly scoped Admin token, and adding a `serverUrl` plus Bearer authorization header to Windsurf’s `mcp_config.json`, after which Cascade discovers only the tools allowed by that token. Depending on Content-Type settings and permissions, Cascade can list, retrieve, create, update, delete, publish, unpublish, and discard drafts through natural-language prompts, while Strapi enforces access controls for tools, fields, locales, and individual runtime actions. The guidance recommends dedicated least-privilege tokens, environment-variable storage for secrets, and testing first on staging with read-only access; Enterprise users on Strapi 5.52.0 or later can also identify MCP activity in audit logs. Common issues include failing to restart or refresh applications after configuration changes, using unsupported request methods on the POST-only endpoint, and missing token permissions, while current limitations include no media uploads, untyped Dynamic Zones, no nested relation population, and potential schema degradation for some custom or circular component fields.

Strapi’s built-in Model Context Protocol server, available from version 5.47.0 and generally available in 5.49.0, enables AI assistants such as Claude, Cursor, and Windsurf to perform routine headless CMS tasks through natural-language prompts. After engineering enables the opt-in server, configures an endpoint, and issues a tightly scoped Admin token, marketing or content teams can create, update, draft, publish, unpublish, and localize approved content without relying on development sprint schedules. Engineering retains ownership of content schemas, integrations, and governance, while Strapi applies four layers of permissions covering tool availability, fields, locales, and runtime authorization; token changes and revocations take effect on subsequent requests. Draft-first workflows can preserve editorial review, and organizations can withhold publishing rights when human approval is required. Limitations include no direct media uploads, manual review of structured block fields, and no automatic slug generation. The recommended adoption path is a low-risk pilot involving tasks such as typo corrections and metadata updates before expanding to multi-entry, multilingual campaign workflows.

Strapi 5.47.0 or later includes a built-in Model Context Protocol server that can connect a Strapi CMS to Claude Desktop and other MCP-compatible clients, allowing authorized users to create, read, update, delete, publish, unpublish, and discard draft changes through natural-language requests. Setup requires enabling MCP in Strapi, creating a suitably scoped Admin token rather than a Content API token, and adding the server URL and token to Claude Desktop’s configuration file before restarting the application. Once connected, editors can handle routine text tasks such as creating drafts, finding entries, correcting titles, managing localized content, and changing publication status, while more complex visual work and new media uploads still require Strapi’s Admin Panel or upload API. The system relies on precise prompts, entry identifiers, field names, locale instructions, and review before publication to reduce unintended edits. Access is constrained by Admin token permissions at the tool, field, locale, and action levels, with permissions rechecked for every request, and Enterprise audit logs can record MCP-originated write actions.

AI content management systems enable AI agents to manage CMS content through the Model Context Protocol (MCP), with their practical differences centered on hosting, available tools, permissions, and whether generation is built into the CMS. Strapi provides an open-source, self-hosted MCP server that generates content-operation tools from each project’s schema and applies detailed Admin-token RBAC across tools, fields, locales, and individual documents, but it lacks native MCP media uploads and bulk operations. Contentful offers managed remote and local MCP options, OAuth-based access with cautious read-only defaults and configurable space-level controls, plus Skills that help coding agents with SDK setup, migrations, Draft Mode, and personalization. Cosmic provides the simplest hosted setup, a fixed set of 18 tools, bucket-level read/write credentials, and native MCP tools for generating text, images, video, and audio. Strapi is positioned for teams prioritizing ownership, flexible deployment, and granular governance; Cosmic for teams seeking quick hosted agent integration and in-platform generation; and Contentful for existing Contentful users wanting managed, controlled AI workflows.