DEV Community: Theodore Kelechukwu Onyejiaku

10 Tips for Writing Technical Blog Posts Developers Actually Read

Theodore Kelechukwu Onyejiaku — Tue, 27 Oct 2026 17:26:26 +0000

10 Tips for Writing Technical Blog Posts Developers Actually Read

Developers skim. Your job is to make skimming rewarding.

Lead with the outcome. Tell readers what they'll build in the first paragraph.
Show the finished code early. People want to know if it's worth their time.
One idea per section. Headings should read like a table of contents.
Keep code blocks runnable. Copy-paste should just work.
Explain the why, not just the how.
Use real names. fetchPosts() beats foo().
Add screenshots for UI steps.
State your versions. "Strapi 5, Node 20" saves hours of confusion.
Link to the repo.
End with next steps. Give readers somewhere to go.

Bonus

Read your post out loud before publishing. If you stumble, your readers will too.

Why Every Developer Should Own Their Content

Theodore Kelechukwu Onyejiaku — Tue, 27 Oct 2026 17:16:09 +0000

Why Every Developer Should Own Their Content

Platforms come and go. Algorithms change. Paywalls appear. If your writing only lives on someone else's site, you're renting your audience.

The POSSE approach

Publish (on your) Own Site, Syndicate Elsewhere. Your site holds the original; Medium, Dev.to, and social networks get copies that link back.

Benefits

Longevity. Your posts survive platform shutdowns.
SEO. Links and authority accumulate on your domain.
Control. You decide the design, the ads (or lack of them), and the license.

Getting started

You don't need anything fancy. A headless CMS plus a static site generator is plenty. Add a publishing plugin, and syndication becomes a button click.

Securing API Keys in a Strapi Plugin

Theodore Kelechukwu Onyejiaku — Mon, 26 Oct 2026 07:05:13 +0000

Securing API Keys in a Strapi Plugin

A publishing plugin needs tokens for Medium, Dev.to, and Bluesky. Here's how to keep them safe.

Never hard-code secrets

Keep them out of your source code and out of git.

Option 1: Environment variables

DEVTO_API_KEY=xxxx
MEDIUM_TOKEN=xxxx

// config/plugins.ts
export default ({ env }) => ({
  'content-publisher': {
    config: { devtoApiKey: env('DEVTO_API_KEY') },
  },
});

Option 2: A settings page

If admins should manage keys from the UI, store them with the plugin store and protect the route with admin permissions. Never return the raw key to the browser — send back a masked value like ••••1234.

Checklist

[ ] .env is in .gitignore
[ ] Settings routes require an admin permission
[ ] Keys are masked in API responses
[ ] Tokens are rotated if leaked

Posting to Bluesky Programmatically with the AT Protocol

Theodore Kelechukwu Onyejiaku — Mon, 26 Oct 2026 07:02:45 +0000

Posting to Bluesky Programmatically with the AT Protocol

Bluesky is built on the AT Protocol, and the official @atproto/api package makes posting straightforward.

Install

npm install @atproto/api

Log in and post

import { AtpAgent, RichText } from '@atproto/api';

const agent = new AtpAgent({ service: 'https://bsky.social' });
await agent.login({ identifier: 'you.bsky.social', password: process.env.BSKY_APP_PASSWORD });

const rt = new RichText({ text: 'New post: https://mystite.com/my-article' });
await rt.detectFacets(agent);
await agent.post({ text: rt.text, facets: rt.facets });

Tips

Use an app password, not your main password.
Posts are limited to 300 characters — share a teaser plus a link.
detectFacets turns URLs and mentions into clickable links.

Tracking Publishing Status Across Multiple Platforms

Theodore Kelechukwu Onyejiaku — Fri, 23 Oct 2026 16:48:25 +0000

Tracking Publishing Status Across Multiple Platforms

Once you publish to several platforms, a new question appears: where has this post actually gone?

Model the state

Give each post a record per platform:

{
  "blog": "sr3qxtvl2q275rq59udaihac",
  "medium": { "status": "published", "url": "https://medium.com/..." },
  "devto": { "status": "pending" },
  "bluesky": { "status": "failed", "error": "Invalid token" }
}

Show it in the admin

A badge per platform (green = published, grey = not yet, red = failed).
A filter so editors can see only posts not yet on Medium.
A retry button for failed attempts.

Store the returned URLs

Every platform returns a URL after publishing. Save it — it's how you link back, update later, or detect duplicates.

Wrapping up

Visible status turns a black-box button into a workflow your editors can trust.

What Are Agent Skills and How To Use Them

Theodore Kelechukwu Onyejiaku — Fri, 13 Mar 2026 09:59:47 +0000

TL;DR

Agent Skills are an open standard for packaging reusable workflows, domain expertise, and new capabilities into portable folders that any AI agent can discover and use — think of them as "saved prompts" on steroids
Skills use a three-tier progressive disclosure model to protect the context window: only the name and description load at startup (~30-50 tokens per skill), the full SKILL.md loads when triggered, and reference files load only when needed during execution
Originally created by Anthropic, skills are now an open standard at agentskills.io, adopted by 26+ platforms including Claude, OpenAI Codex, Gemini CLI, GitHub Copilot, Cursor, and VS Code
A skill is just a folder with a SKILL.md file (YAML frontmatter + markdown instructions) plus optional scripts/, references/, and assets/ directories — you can build one in minutes
Skills are composable: combine custom skills with built-in document skills and MCP servers to build complex, predictable workflows that produce consistent output every time

What Are Agent Skills?

If you find yourself typing the same prompt across conversations — a weekly report format, a code review checklist, a data analysis pipeline — you've already felt the problem that skills solve. Agent Skills are folders of instructions that package repeated workflows, specialized knowledge, or new capabilities for your AI agent. Instead of copying and pasting lengthy prompts every session, you write them once as a skill and reuse them across every conversation.

But skills go far beyond "saved prompts." They're an open standard originally created by Anthropic and now governed as a cross-platform specification at agentskills.io.

On December 18, 2025, Anthropic released Agent Skills as an open standard, publishing the specification and SDK for any AI platform to adopt. This means a skill you build for Claude works identically in OpenAI Codex, Gemini CLI, GitHub Copilot, Cursor, VS Code, and over 20 other platforms that have adopted the standard.

The simplest way to think about it: MCP gives your agent access to external tools and data. Skills teach your agent what to do with those tools and data.

Filesystem (left) — Skills that provide instructions and domain knowledge to the agent
Agent (center) — Contains the LLM and Tools working together
MCP Servers (right) — External tools and data connections
Subagents (bottom) — Spawned by the main agent for parallel/specialized work

Skills flow into the agent as knowledge, MCP connects bidirectionally for external capabilities, and Subagents are dispatched from the agent. This visually reinforces the point: MCP gives your agent access to external tools and data. Skills teach your agent what to do with those tools and data.

Why Skills Matter: From Prompts to Packages

The Prompt Repetition Problem

Consider a content creator who publishes blog posts every week. Without skills, every conversation starts the same way:

Paste the blog post structure rules (TL;DR section, heading hierarchy, citations format)
Paste the SEO guidelines (keyword density, meta description format, internal linking rules)
Paste the brand voice instructions (tone, audience, formatting preferences)
Paste or describe the topic and source material
Hope the output actually follows all those rules consistently

Now multiply that across a team of five writers, each with their own slightly different version of those instructions. The output quality varies from session to session and person to person.

This approach has three fundamental issues:

Context window pollution — Every piece of instruction you paste consumes tokens that could be used for actual content. The more instructions you front-load, the faster your context fills up and the higher the likelihood of degradation in response quality
No portability — Your workflow lives in your clipboard or a shared doc somewhere, not in a versioned, shareable artifact that can be installed and used consistently
No consistency — Without a standardized format, different people will interpret and paste those instructions differently, and you can never guarantee the agent follows every rule every time

How Skills Fix This

Skills address all three problems:

Progressive disclosure — Only the skill's name and description are loaded at startup (roughly 30-50 tokens per skill). The full instructions load only when the skill is triggered. Referenced files, scripts, and assets load only when needed during execution. You can have hundreds of skills installed without any impact on performance
Portability — A skill is a folder. Share it as a zip file, push it to a Git repository, or publish it to a marketplace. Since it's an open standard, it works across Claude, Codex, Gemini CLI, and every other platform that supports the spec
Repeatability — The same instructions execute the same way every time, for every team member, across every platform. In a non-deterministic system where you can never fully predict the model's output, skills provide the structure to make workflows as predictable as possible

Anthropic frames the context window as a public good — the more data you add, the more tokens you consume, the faster it fills, and the greater the risk of context degradation. Progressive disclosure is what makes skills fundamentally different from just pasting a big prompt. Skills are intentional about what information goes into the context window and what stays on disk until it's actually needed.

The Anatomy of a Skill

Every skill follows the same structure, defined by the Agent Skills Specification:

my-skill/
├── SKILL.md              # Required — YAML frontmatter + markdown instructions
├── scripts/              # Optional — executable code (Python, Bash, JS)
├── references/           # Optional — additional documentation
└── assets/               # Optional — templates, images, logos, data files

The SKILL.md File

This is the only required file. It has two parts:

1. YAML Frontmatter — metadata that tells the agent what this skill is and when to use it:

---
name: analyzing-marketing-campaign
description: ">-"
  Analyze weekly marketing campaign performance from CSV or BigQuery data.
  Use when the user asks about campaign metrics, funnel analysis, ROAS,
  or budget reallocation.
---

The name and description are the only two required fields. The name must be 1-64 characters, lowercase with hyphens, and should match the folder name. The description (up to 1,024 characters) is mission critical — it's how the agent detects when to activate the skill. Include trigger keywords and describe not just what the skill does, but when to use it.

Optional frontmatter fields include license, compatibility (environment requirements), metadata (arbitrary key-value pairs like author and version), and allowed-tools (pre-approved tool list for security-conscious environments).

2. Markdown Body — the actual instructions, as detailed as you need:

# Weekly Campaign Analysis

## Input Requirements
- Campaign data with columns: date, campaign_name, impressions, clicks, conversions
- Date range must be specified

## Step 1: Data Quality Check
- Verify no missing values in required columns
- Flag any anomalies (CTR > 20%, negative values, etc.)

## Step 2: Funnel Analysis
Calculate against these benchmarks:
| Metric | Benchmark |
|--------|-----------|
| CTR    | 2.5%      |
| CVR    | 3.0%      |

## Budget Reallocation
Only when the user asks about budget reallocation, read:
`references/budget_reallocation_rules.md`

Notice that last line — the budget reallocation rules live in a separate file that only loads when the user asks about it. That is progressive disclosure in action. Instead of cramming everything into the context window upfront, the skill tells the agent where to find additional information and when to fetch it.

Optional Directories

Directory	Purpose	Examples
`scripts/`	Executable code loaded and run on demand	Python data analysis, Bash automation, JS utilities
`references/`	Additional documentation loaded when needed	Domain-specific rules, style guides, API docs
`assets/`	Templates, images, and data files	Output templates, logos, schema files, sample data

Skills aren't limited to text — they can include scripts in Python, Bash, or JavaScript that the agent executes as part of the workflow. A PDF processing skill might include Python scripts for form extraction. A data analysis skill might include diagnostic scripts and visualization code. The agent loads and runs these only when the workflow requires it.

Where Skills Fit in the Agent Ecosystem

With so many technologies in the AI toolkit — MCP, skills, tools, subagents — understanding when to use what is essential. Here is how they all fit together:

The analogy from the course captures it perfectly: tools are the hammer, saw, and nails. Skills are the knowledge of how to build a bookshelf. The tools provide the raw capabilities (filesystem access, bash execution, API calls). Skills provide the procedural knowledge and domain expertise to use those tools in a specific, repeatable way.

Component	Role	Best For
Prompts	Atomic unit of communication	One-off instructions
Tools	Low-level capabilities (bash, filesystem, APIs)	The building blocks that power everything
MCP	Connects agents to external systems and data	Database access, Google Drive, Slack, any external service
Skills	Packaged workflows with domain expertise	Repeatable tasks, team-wide processes, predictable output
Subagents	Isolated execution with own context window	Parallel tasks, specialized analysis, fine-grained permissions

How They Compose Together

The real power emerges when you combine these components. Consider a workflow that chains three skills with an MCP server:

In this flow, the MCP server provides the connection to BigQuery. The marketing analysis skill defines how to analyze the data (benchmarks, formulas, allocation rules). The brand guidelines skill defines how things should look (colors, typography, logos). The built-in PowerPoint skill handles the document generation. Each skill loads only its own context, only when needed.

You can also dispatch subagents alongside skills. A main agent can spawn subagents — each with their own context window and specific skill access — to parallelize work. For instance, one subagent analyzes customer interviews while another processes survey data, both using the same "customer insights" skill but running in parallel. The parent agent collects and synthesizes their results.

When to Use What

Scenario	Reach For
Need data from an external database or API	MCP
Need a repeatable, documented workflow	Skills
Need to teach the agent your company's specific process	Skills
Need parallel execution with isolated context	Subagents
Need real-time access to Google Drive / Slack / etc.	MCP
Need specialized analysis that shouldn't pollute main context	Subagents + Skills
Need a one-off quick task	Just a prompt

Use skills for procedural, predictable workflows. Use subagents for full agentic logic only when necessary for specialized or parallel tasks. Use MCP for any external data or tooling. And remember — skills, subagents, and MCP are composable. The sweet spot is usually a combination of all three.

Built-In Skills and the Skills Repository

Anthropic ships several production-ready skills at github.com/anthropics/skills:

Document Skills (built into Claude AI, always active):

Skill	What It Does
Excel	Create, edit, and analyze `.xlsx` spreadsheets with formatting and charts
PowerPoint	Generate presentations with custom layouts, colors, typography
Word	Create formatted `.docx` documents
PDF	Extract text, fill forms, merge PDFs, convert to images

Example Skills (can be toggled on in Settings > Capabilities):

Skill	What It Does
Skill Creator	Meta-skill that programmatically creates new skills following best practices
Code Review	Structured code review with configurable standards
Data Analysis	Statistical analysis workflows

The skill-creator is particularly useful — it's a skill that creates skills. It includes Python scripts for initializing the folder structure, packaging into a zip, and validating against best practices. It is enabled by default and can save significant time when building new skills.

In Claude Code, you can install skills from the marketplace:

# Add the Anthropic skills marketplace
/plugins marketplace add anthropics/skills

# Verify installed skills
/skills

Partner-built skills from companies like Atlassian, Figma, Canva, Stripe, Notion, and Zapier are also available through the skills directory.

How to Build a Skill: Architecture Walkthrough

The best way to understand how all the pieces of a skill fit together is to look at a real-world example. Let's walk through the architecture of a Strapi Configuration Skill — a skill that scaffolds fully configured Strapi CMS projects with content types, seed data, public API access, and auto-populate middleware.

The goal here is not to recreate this skill step-by-step, but to understand the architectural decisions and moving parts so you can apply these patterns to your own skills. For the full source code, check out the repository.

The Directory Structure

strapi-configuration/
├── SKILL.md                  # Core instructions (480 lines)
├── CLAUDE.md                 # Development context for contributors
├── README.md                 # User-facing documentation
├── scripts/                  # Empty — reserved for future helpers
├── references/               # Empty — reserved for future docs
└── templates/                # Domain-specific data files
    ├── blog.json             # ~22KB preset definition
    ├── ecommerce.json        # ~23KB preset definition
    ├── portfolio.json        # ~25KB preset definition
    └── restaurant.json       # ~24KB preset definition

This structure shows several important patterns:

Standard directories are present even when empty. The scripts/ and references/ directories exist as placeholders — they signal to other developers (and the agent) that the skill follows the standard layout and may grow into these directories.

Domain-specific directories are allowed. The templates/ directory isn't part of the standard spec (scripts/, references/, assets/ are), but skills can include any additional directories that make sense for the domain. Here, each JSON template is a ~23KB definition containing content types, components, middleware configs, seed data, and permission rules for a specific project type.

Progressive disclosure is baked into the architecture. Those four template files total ~94KB of data. None of it loads until the agent actually needs a specific template. When the user picks "blog," only blog.json enters the context — the other three templates stay on disk. That's ~70KB of tokens saved.

The Frontmatter: Your Skill's Elevator Pitch

---
name: strapi-configuration
description: >-
  Create a fully configured Strapi project with preconfigured content types,
  seed data, public API access, and route-based middleware for default
  population. Use when the user wants to scaffold a new Strapi project for
  a specific use case such as blog, e-commerce, portfolio, or restaurant.
  Supports preset templates and custom project descriptions.
compatibility: Requires Node.js and access to the strapi-core monorepo.
allowed-tools: Bash Read Write Edit Glob Grep
metadata:
  author: strapi
  version: "0.1.0"
---

Key decisions worth noting:

The description is packed with trigger keywords: "scaffold", "Strapi project", "blog", "e-commerce", "portfolio", "restaurant", "content types", "seed data." When a user says any of these words, the agent knows this skill is relevant
compatibility declares the runtime requirements upfront — the agent (and the user) knows this needs Node.js before it even starts
allowed-tools explicitly declares which tools the skill will use. In security-conscious environments, this allows pre-authorization rather than prompting for each tool at runtime

The Instruction Body: A Deterministic Workflow

The body of this SKILL.md is structured as 9 sequential steps, each with clear entry/exit criteria. Here is the high-level flow:

[video-steps.mp4](https://delicate-dawn-ac25646e6d.media.strapiapp.com/video_steps_10379ccc12.mp4) Your browser does not support the video tag.

Several patterns make this workflow reliable:

Explicit branching. Step 1 presents a selection menu and routes to either Step 2 (preset template) or Step 2b (custom generation). The branching is clearly marked — the agent never has to guess which path to follow.

Code templates, not descriptions. Rather than saying "create a controller," the skill provides the exact TypeScript code:

import { factories } from '@strapi/strapi';

export default factories.createCoreController('api::<name>.<name>');

This eliminates guesswork and ensures the generated code actually works with the target framework. The skill includes templates for controllers, services, routes (with and without middleware), middleware files, component schemas, and the entire seed script.

Progressive file loading. Step 2 says "Read the template JSON file at templates/<preset>.json." It doesn't embed the template data in the SKILL.md — it tells the agent where to find it and what structure to expect:

The template contains:
- `contentTypes` - Collection types and single types (schemas)
- `components` - Reusable component definitions
- `middlewares` - Route-based populate middleware configs
- `seedData` - Sample data entries for each content type
- `publicPermissions` - Which API endpoints to make publicly accessible

The custom path generates data dynamically. Step 2b is a mini-workflow within the workflow — it gathers requirements, designs a content model following patterns from existing templates, generates seed data, configures middleware, sets permissions, and optionally saves the result as a reusable template for next time. This demonstrates how skills can handle both deterministic paths (presets) and creative ones (custom generation) within the same workflow.

Supporting Files: CLAUDE.md and README.md

This skill includes two additional files that aren't part of the agent skills spec but demonstrate good practice:

CLAUDE.md captures development context — the directory structure, key conventions for the Strapi schema format, CLI testing commands, common pitfalls (like draftAndPublish needing to be nested inside options, not at the top level), and future improvements. This is valuable for both the agent when it needs to modify the skill and for human developers maintaining it.

README.md is user-facing documentation — installation instructions, quick start examples, usage for each preset, and what gets generated. It explains how to install the skill at project scope (<project>/.claude/skills/) or globally (~/.claude/skills/).

What Makes This Skill Work Well

Looking at the architecture holistically, several design decisions stand out:

The description is rich with trigger keywords — the agent can match user intent to this skill reliably
Steps are numbered and sequential — there is no ambiguity about execution order
Code templates are exact, not described — pattern matching produces reliable output
Large data lives in files, not instructions — 94KB of template data stays on disk until needed
Branching is explicit — preset vs. custom paths are clearly defined
The skill stays under 500 lines — keeping the main instructions concise and deferring detail to external files
Edge cases are handled — what if no path is provided? What if the user picks custom? What if they want to save the result as a template?

Here is the skill in action.

[video-steps.mp4](https://delicate-dawn-ac25646e6d.media.strapiapp.com/video_steps_10379ccc12.mp4) Your browser does not support the video tag.

note: this is still work in progress, but once it is ready, I will share the repo here.

Best Practices for Building Your Own Skills

Based on the official specification, Anthropic's engineering blog, and patterns observed across production skills:

Naming and Description

Name: Use lowercase letters, numbers, and hyphens. Follow the verb-ing + noun pattern: analyzing-marketing-campaign, generating-practice-questions. Don't use reserved keywords like "claude" or "anthropic." Max 64 characters
Description: This is how the agent decides when to use your skill. Describe both what it does and when to use it. Include trigger keywords. Max 1,024 characters

Structure and Content

Keep SKILL.md under 500 lines. Move detailed content into references/, scripts/, or assets/
Use step-by-step instructions. Number your steps. Specify edge cases. Be clear about what to skip and why
Provide code templates, not descriptions. Agents produce more reliable output when they can pattern-match against exact examples
Use progressive disclosure aggressively. If a piece of information is only needed 20% of the time, put it in a reference file
Use forward slashes in all file paths, even on Windows

Degree of Freedom

Think about how much freedom to give the agent:

Low freedom for processes that must be followed exactly (compliance checks, data pipelines, test procedures)
High freedom for creative outputs where variety is desirable (design, writing, brainstorming)

Testing and Evaluation

Run your skill through the skill-creator skill to score it against best practices
Write test cases like unit tests: define input queries, expected behaviors, and output formats
Test across all models you plan to use — different models may interpret instructions differently
Gather human feedback and iterate

Where Skills Can Live

Scope	Location	Use Case
Project	`<project>/.claude/skills/`	Team-specific workflows tied to a codebase
User	`~/.claude/skills/`	Personal skills available across all projects
Claude AI	Settings > Capabilities > Skills	Upload as zip, available in the web UI
Marketplace	`anthropics/skills` on GitHub	Community and official skills

The Open Standard: Cross-Platform Portability

Agent Skills follow the same playbook Anthropic used with the Model Context Protocol: build a specification that solves a real interoperability problem, release it as an open standard, and let ecosystem adoption create network effects.

The platforms that have adopted the standard now include Claude, Claude Code, OpenAI Codex, Gemini CLI, GitHub Copilot, VS Code, Cursor, Roo Code, Amp, Goose, Mistral AI, Databricks, and many others — over 26 at last count. Partner-built skills from Atlassian, Figma, Canva, Stripe, Notion, and Zapier are available at launch.

The specification and reference library live at github.com/agentskills/agentskills. The reference library includes a validation tool you can use to check your skills against the spec:

skills-ref validate ./my-skill

Getting Started: Your First Skill in 5 Minutes

1. Create the folder:

mkdir -p .claude/skills/my-first-skill

2. Create SKILL.md:

---
name: my-first-skill
description: >-
  Describe what your skill does and when to trigger it.
  Include keywords that users are likely to say.
---

# My First Skill

## Steps

### Step 1: [First thing to do]
[Detailed instructions...]

### Step 2: [Second thing to do]
[Detailed instructions...]

## Output Format
[What the final result should look like]

3. Test it by starting a new session and asking a question that matches your skill's description.

4. Iterate. Run it through the skill-creator for best-practice feedback, or validate it with the reference library. Refine based on actual usage.

Whether you're automating a weekly report, encoding your team's code review process, building a project scaffolding tool, or packaging brand guidelines for consistent design output — skills transform one-off prompts into durable, shareable, composable knowledge that works everywhere.

Citations

Agent Skills Specification: https://agentskills.io/specification
Introducing Agent Skills (Anthropic): https://www.anthropic.com/news/skills
Equipping Agents for the Real World with Agent Skills: https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
Skill Authoring Best Practices (Claude Docs): https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices
Agent Skills Overview (Claude API Docs): https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview
Agent Skills GitHub Repository: https://github.com/anthropics/skills
Agent Skills Open Standard Repository: https://github.com/agentskills/agentskills
OpenAI Codex Skills Documentation: https://developers.openai.com/codex/skills/
VS Code Agent Skills: https://code.visualstudio.com/docs/copilot/customization/agent-skills

How to Build a Strapi Plugin That Extends the Admin and Backend

Theodore Kelechukwu Onyejiaku — Fri, 13 Mar 2026 09:49:03 +0000

Whether you’re building a product solo, working with clients, or maintaining a CMS for a growing team, the starting point is usually the same.

You define content types, expose them through APIs, and consume that content in your application. Editors work in a structured interface, developers get predictable data, and the CMS stays focused on content.

That already covers a lot — but rarely everything.

Real products quickly introduce needs that go beyond content modeling: custom backend logic, admin workflows, or UI extensions that reflect how content is actually created and reviewed. When that happens, it’s important to know whether the CMS can adapt to additional requirements and scale with the product. This is about avoiding situations where small needs later force difficult architectural decisions.

This is where Strapi starts to matter.

Strapi is designed to be extended through plugins. Plugins are the mechanism Strapi provides to adapt the CMS to your project: adding backend logic, extending APIs, and customizing the admin interface when needed — without pushing those needs outside the CMS you already rely on.

In this article, we’ll make this concrete by building a small but real Strapi plugin: a todo list that integrates directly into the admin panel and attaches itself to any content type.

Let’s get started!

Installing Strapi

To get started, you'll need a Strapi project to work with.
You can follow the official quick-start guide, or simply run the following command:

npx create-strapi-app@latest my-strapi-project

Once the installation is finished you can navigate into the newly created folder and start Strapi in development mode:

cd my-strapi-project && npm run develop

When Strapi starts, it will open in your browser at http://localhost:1337/admin/auth/register-admin. The first screen prompts you to create an admin user for your application. Once that’s done, you’ll land in the Strapi admin and can start building.

At this point, you have a working Strapi project and a clean starting point for plugin development.

Bootstrapping a Strapi plugin with the Plugin SDK

After you’ve installed Strapi and created your admin user you are now ready to start developing your plugin!

Strapi provides an official plugin SDK that takes care of structure and conventions for you. From the root of your project, run:

npx @strapi/sdk-plugin init todo

This command launches an interactive CLI that asks a few questions about your plugin. Based on your answers, it generates a blank plugin inside src/plugins/todo.

Once the plugin has been bootstrapped, you can enable it by updating ./config/plugins.ts

export default () => ({
  // ...
  'todo': {
    enabled: true,
    resolve: 'src/plugins/todo'
  },
  // ...
})

With that in place, Strapi will load your plugin at startup.

Building your plugin

At this point, Strapi is running and your plugin is enabled — but there’s one important detail to be aware of before you start writing code.

When you run strapi develop, Strapi does not compile plugin code for you. Plugin code is built separately, which means that while developing your plugin you’ll need to run an additional build process.

From the plugin directory, start the watch command:

cd src/plugins/todo && npm run watch

This watches your plugin files and rebuilds them as you make changes.

This separation is intentional. In Strapi, plugins are treated as isolated units, with their own dependencies and build lifecycle, rather than as hidden parts of the main application. Keeping plugin builds explicit makes the boundary between the application and its extensions clear, and avoids coupling plugin development to the core dev process.

Creating a content type

In Strapi, everything you store is a content type. Whether it’s an Article, a Product, or a User profile, the data lives in a model with a schema — and Strapi uses that schema to generate the database structure, admin behavior, and API layer.

A plugin doesn’t change that. Even if the UI and logic live inside the plugin, the data still needs a place to live.

So if our todo plugin is going to store tasks, we need a content type for them — and we’ll define it inside the plugin, so the whole feature (UI + backend + data model) stays self-contained.

The easiest way to do this is with the Strapi generator CLI:

npm run strapi generate content-type

Running this command will open up another interactive CLI. In there you can specify the name of the content type as well as add some attributes.

When prompted:

name the content type task
add attributes: name (text) and done (boolean)
choose to add it to the existing todo plugin
allow the CLI to generate API-related files

Don’t forget to select the option to add the model to your existing todo plugin and to bootstrap API related files.

Once the generator finishes, you’ll see new files for the task content type: a schema, service, controller, and routes — all scoped to the plugin.

By default, every content type in Strapi is exposed through the Content API. That’s usually what you want: content types are meant to be queried by frontends and external consumers.

In this case, it’s not.

Tasks are an internal, admin-only concern. They exist purely to support editors while working in the admin panel, and should not be reachable from the public Content API.

For that reason, we’ll move the generated routes from the Content API to the Admin API, making the task content type accessible only inside the admin context.

To do that:

Move the generated route file src/plugins/todo/server/src/routes/content-api/task.ts to the src/plugins/todo/server/src/routes/admin folder. You will then end up with the following file src/plugins/todo/server/src/routes/admin/task.ts

/**
 * Task router
 */

import { factories } from '@strapi/strapi';

export default factories.createCoreRouter('plugin::todo.task');

Update src/plugins/todo/server/src/routes/admin/index.ts file to register those routes as admin routes

import task from './task';
export default () => ({
  type: 'admin',
  routes: [...task.routes],
});

Update src/plugins/todo/server/src/routes/content-api/index.ts to replace the content API routes with an empty definition

export default () => ({
  type: 'content-api',
  routes: [],
});

This keeps the task API private to the admin context, which is exactly what we want.

Known issue with generated routes

When generating content types with the CLI, you may run into a small TypeScript edge case when registering admin routes.

You might see an error like:

[ERROR] server/src/routes/admin/index.ts:4:15 - TS2488:
Type'Route[] | (() => Route[])' must have a'[Symbol.iterator]()' method that returns an iterator.

This is a typing issue only — the routes work correctly at runtime. You can safely fix it by adding a @ts-expect-error when spreading the routes:

import task from'./task';

exportdefault () => ({
type:'admin',
// @ts-expect-error
routes: [...task.routes],
});

Polymorphic relation

Each task should be associated with whatever content entry it belongs to — articles, pages, users, or any other type. To support that, the relation needs to be polymorphic.

In this context, polymorphic simply means the relation isn’t tied to one specific content type. A task can point to different kinds of entries, depending on where it’s created in the admin panel.

Update the src/plugins/todo/server/src/content-types/task/schema.json schema to add a morphToMany relation called related,

{
    "kind": "collectionType",
    "collectionName": "tasks",
    "info": {
        "singularName": "task",
        "pluralName":"tasks",
        "displayName":"Task"
    },
    "options": {
        "draftAndPublish": false
    },
    "pluginOptions": {
        "content-manager": {
            "visible": false
        },
        "content-type-builder":{
            "visible": false
        }
    },
    "attributes": {
        "name": {
            "type": "text"
        },
        "done": {
            "type": "boolean"
        },
        "related": {
            "type": "relation",
            "relation": "morphToMany"
        }
    }
}

At this point, the task content type has three fields:

name
done
related

That’s all we need.

Fetching related tasks with a custom admin API route

Now we need a way to fetch all tasks linked to the entry currently being edited. The catch is that Strapi doesn’t support filtering on polymorphic relations out of the box (see the FAQ).

So we’ll add a custom service method that:

looks up task IDs in the polymorphic relation table, then
fetches the matching task documents.

Open server/src/services/task.ts and extend the core service with findRelatedTasks:

/**
 * Task service
*/

import { factories } from '@strapi/strapi';

export default factories.createCoreService('plugin::todo.task',({ strapi }) => ({
    async findRelatedTasks(relatedId:string,relatedType:string) => {
        const taskIds = await strapi.db.connection('tasks_related_mph')
            .select('task_id')
            .where({
                related_id: relatedId,
                related_type: relatedType,
            });
        return strapi.documents('plugin::todo.task').findMany({
            filters: {
                id: { $in: taskIds.map(({ task_id }) => task_id) },
            },
        });
    },
}));

Next, expose this method through a custom controller action. Open server/src/controllers/task.ts and add findRelatedTasks:

/**
 * Task controller
 */

import { factories } from '@strapi/strapi';

export default factories.createCoreController('plugin::todo.task',({ strapi }) => ({
asyncfindRelatedTasks(ctx) {
    const { relatedId, relatedType } = ctx.params;
    const tasks = await strapi
      .service('plugin::todo.task')
      .findRelatedTasks(relatedId, relatedType);

    ctx.body = tasks;
  },
}));

Finally, register an admin route that calls this controller. Update server/src/routes/admin/index.ts:

import task from'./task';

export default () => ({
    type:'admin',
    routes: [
        // @ts-expect-error
        ...task.routes,
        {
            method:'GET',
            path:'/tasks/related/:relatedType/:relatedId',
            handler:'task.findRelatedTasks',
        },
    ],
});

With this in place, the admin panel can request related tasks for the current entry using a single endpoint — which we’ll use later when building the sidebar UI.

Cleaning up the admin UI

Now that the backend pieces are in place, it’s time to prepare the admin side.

The generated content type appears in the Content Manager and Content-Type Builder by default.

Because tasks are meant to be managed through the plugin UI (not as standalone entries), we’ll hide the Task content type from the Content Manager and the Content-Type Builder. You can do this by updating the schema of the Task content type at src/plugins/todo/server/src/content-types/task/schema.json:

{
    "pluginOptions": {
        "content-manager": {
            "visible": false
        },
        "content-type-builder": {
            "visible": false
        }
    }
}

The plugin also comes with its own menu entry and page. Since this plugin only adds functionality inside the Content Manager, you can remove:

the plugin icon by removing src/plugins/todo/admin/src/components/PluginIcon.tsx file
the plugin pages by deleting src/plugins/todo/admin/src/pages/ folder
the corresponding menu registration from the src/plugins/todo/admin/src/index.ts file

Creating the sidebar panel

The core of this plugin lives in the Content Manager edit view. We’ll add a custom sidebar component that will appear within the edit screen of a content document and will list all the tasks related to it.

To do so, you’ll have to create a new component in your plugin. We’ll create that at src/plugins/todo/admin/src/components/TodoPanel.tsx:

import React from "react";
import { unstable_useContentManagerContext as useContentManagerContext, type PanelComponent } from '@strapi/content-manager/strapi-admin';

const TodoPanel: PanelComponent = () => {
  return {
      title: "Todo list",
        content: (
            <div> All my todos will be here. </div>
        ),
    };
};

export default TodoPanel;

Once we’ve created the panel component we can now register it using the addEditViewSidePanel API provided by the Content Manager plugin. We do this in the bootstrap function of src/plugins/todo/admin/src/index.ts:

import TodoPanel from './components/TodoPanel';

export default {
    bootstrap(app: any) {
        app.getPlugin('content-manager').apis.addEditViewSidePanel([TodoPanel]);
    },
};

Once registered, the panel shows up automatically when editing entries.

Fetching and displaying tasks

At this point, the plugin has everything it needs on the backend:

a content type, admin-only routes, and a custom endpoint to fetch tasks related to a specific entry.

What’s missing is the admin-side logic that ties it all together.

Inside the Content Manager edit view, we want to:

fetch the tasks related to the currently edited entry,
display them inline in the sidebar,
and update their state without reloading the page.

To handle data fetching, caching, and updates cleanly, we’ll use @tanstack/react-query. It fits well here because it lets us express “this list depends on the current document” and takes care of refetching when data changes.

First, install it as a dependency of the plugin:

npm install @tanstack/react-query

Wiring React Query into the panel

React Query works through a shared QueryClient. We'll create one and wrap the panel content in a QueryClientProvider by editing ./plugin-todo/admin/components/TodoPanel.tsx, then move the task-specific logic into a dedicated TaskList component.

// ./plugin-todo/admin/components/TodoPanel.tsx

import React from 'react';
import { unstable_useContentManagerContext as useContentManagerContext, type PanelComponent } from '@strapi/content-manager/strapi-admin';
import {
  QueryClient,
  QueryClientProvider,
} from '@tanstack/react-query'
import TaskList from './TodoList';

const queryClient = new QueryClient();

const TodoPanel: PanelComponent = () => {
  return {
    title: 'Todo',
    content: (
      <QueryClientProvider client={queryClient}>
        <TaskList />
      </QueryClientProvider>
    ),
  };
};

export default TodoPanel;

Fetching and updating tasks

The TaskList component is responsible for:

determining which entry is currently being edited,
fetching its related tasks via the custom admin endpoint,
rendering them as a checklist,
and updating task state when a checkbox is toggled.

// ./plugin-todo/admin/components/TodoList.tsx

import * as React from 'react';
import { unstable_useContentManagerContext, useFetchClient } from '@strapi/strapi/admin';
import { useQuery, useMutation, useQueryClient } from '@tanstack/react-query';
import { Checkbox } from '@strapi/design-system';

const TaskList = () => {
  const { get, put } = useFetchClient();
  const { id, slug } = unstable_useContentManagerContext();
  const queryClient = useQueryClient();

  const { data, isLoading } = useQuery({
    queryKey: ['tasks', id],
    queryFn: async () => {
      return get(`/todo/tasks/related/${slug}/${id}`);
    },
  });

  const updateTaskMutation = useMutation({
    mutationFn: async ({ documentId, done }: { documentId: string; done: boolean }) => {
      return put(`/todo/tasks/${documentId}`, { data: { done } });
    },
    onSuccess: () => {
      queryClient.invalidateQueries({ queryKey: ['tasks', id] });
    },
  });

  const handleCheckboxChange = (taskId: string, currentDone: boolean) => {
    updateTaskMutation.mutate({ documentId: taskId, done: !currentDone });
  };

  if (isLoading) {
    return null;
  }

  return (
    <ul>
      {data?.data.map((task: { documentId: string; name: string; done: boolean }) => (
        <li style={{ marginTop: '12px' }} key={task.documentId}>
          <Checkbox 
            checked={task.done || false}
            onCheckedChange={() => handleCheckboxChange(task.documentId, task.done)}
          >
            {task.name}
          </Checkbox>
        </li>
      ))}
    </ul>
  );
}

export default TaskList;

At this stage, the request to /todo/tasks/related is working — but the list is empty. That’s expected: we haven’t created any tasks yet.

Creating tasks from the admin panel

To add tasks directly from the Content Manager, we’ll use a modal built with the Strapi Design System.

The modal contains a small form that:

captures the task name,
associates it with the currently edited document,
creates the task through the plugin’s POST route,
and refreshes the task list when the operation succeeds.

Create a new component at admin/src/components/TodoModal.tsx:

// ./plugin-todo/admin/components/TodoModal.tsx

import { useState } from 'react';
import { Button } from '@strapi/design-system';
import { Field } from '@strapi/design-system';
import { Modal } from '@strapi/design-system';
import { unstable_useContentManagerContext, useFetchClient } from '@strapi/strapi/admin';
import { useMutation, useQueryClient } from '@tanstack/react-query';

type Props = {
  isOpen: boolean;
  onOpenChange: (open: boolean) => void;
}

const TodoModal = ({ isOpen, onOpenChange }: Props) => {
  const [taskName, setTaskName] = useState('');
  const { id, model } = unstable_useContentManagerContext();
  const { post } = useFetchClient();
  const queryClient = useQueryClient();

  const createTaskMutation = useMutation({
    mutationFn: async (data: any) => {
      return post('/todo/tasks', { data });
    },
    onSuccess: () => {
      queryClient.invalidateQueries({ queryKey: ['tasks', id] });
      setTaskName('');
      onOpenChange(false);
    },
  });

  const submitForm = () => {
    createTaskMutation.mutate({ 
      name: taskName, 
      related: [{
        __type: model,
        id,
      }],
    });
  };

  return (
    <Modal.Root open={isOpen} onOpenChange={onOpenChange}>
      <Modal.Content>
        <Modal.Header>
          <Modal.Title>Create task</Modal.Title>
        </Modal.Header>
        <Modal.Body>
          <Field.Root name="task" required>
            <Field.Label>Task</Field.Label>
            <Field.Input 
              value={taskName}
              onChange={(e: React.ChangeEvent<HTMLInputElement>) => setTaskName(e.target.value)}
            />
          </Field.Root>
        </Modal.Body>
        <Modal.Footer>
          <Modal.Close>
            <Button variant="tertiary">Cancel</Button>
          </Modal.Close>
          <Button 
            onClick={submitForm} 
            loading={createTaskMutation.isPending}
            disabled={!taskName.trim() || createTaskMutation.isPending}
          >
            Confirm
          </Button>
        </Modal.Footer>
      </Modal.Content>
    </Modal.Root>
  );
}

export default TodoModal;

The important detail here is the related field: we attach the task to the current document using its model type and ID, which makes the polymorphic relation work seamlessly across content types.

Connecting everything in the panel

Finally, we add a button to the sidebar panel that opens the modal and renders the task list below it:

// ./plugin-todo/admin/components/TodoList.tsx

import * as React from 'react';
import { unstable_useContentManagerContext as useContentManagerContext, type PanelComponent } from '@strapi/content-manager/strapi-admin';
import { TextButton } from '@strapi/design-system';
import { Plus } from '@strapi/icons';
import TaskList from './TodoList';
import {
  QueryClient,
  QueryClientProvider,
} from '@tanstack/react-query'
import TodoModal from './TodoModal';

const queryClient = new QueryClient();

const TodoPanel: PanelComponent = () => {
  const [modalOpen, setModalOpen] = React.useState(false);
  const { id } = useContentManagerContext();
  return {
    title: 'Todo List',
    content: (
      <QueryClientProvider client={queryClient}>
        <div>
          <TextButton
            onClick={() => setModalOpen(true)}
            startIcon={<Plus />}
            disabled={!id}
          >
            Add todo
          </TextButton>
          {id && (
            <>
              <TodoModal isOpen={modalOpen} onOpenChange={setModalOpen} />
              <TaskList />
            </>
          )}
        </div>
      </QueryClientProvider>
    )
  }
}

export default TodoPanel;

With that in place, the plugin comes together:

tasks appear next to content,
tasks can be created and updated inline,
and all the logic stays scoped to the plugin.

Refreshing the admin panel now shows a fully functional todo list embedded directly in the Content Manager.

Deploying to production with Strapi Cloud

So far, everything we’ve done has been running locally. The final step is making sure the plugin is built and available in production — and then actually seeing it live.

Because plugin code is built separately from the main Strapi app, it needs to be compiled as part of the deployment process. A simple way to ensure this happens automatically is to add a postinstall script to the root package.json of your Strapi project:

{
    "scripts":{
        "postinstall":"cd src/plugins/todo && npm install && npm run build"
    }
}

This guarantees that whenever your project installs dependencies — locally, in CI, or in production — the plugin is installed and built as well.

If you’re using Strapi Cloud, you don’t need any additional setup.

Once your project is connected to Strapi Cloud, every push triggers a deployment where dependencies are installed and build steps are executed. With the postinstall script in place, your plugin is compiled automatically during that process.

After the deployment finishes, open your Strapi Cloud project, navigate to the Content Manager, open any entry, and you should see your todo sidebar panel — just like in local development.

At this point, the plugin is running in production, inside the same admin your editors use every day.

GitHub Repo

The complete code can be found here: https://github.com/strapi-community/plugin-todo

Final words

This plugin is intentionally small, but it mirrors how real Strapi extensions are built and shipped.

You defined a data model, scoped it to a plugin, exposed only the APIs you needed, and extended the admin interface where editors actually work. Nothing lives outside the system, and nothing special is required to deploy it.

That’s the core idea behind Strapi plugins: they let you adapt the CMS to your product without turning customization into a separate project.

If you want to explore further, the full plugin code is available on GitHub, and the Strapi community is always a good place to go deeper — whether you’re refining an internal workflow or building something meant to be reused by others.

Building Production-Ready Strapi + Next.js 16 Applications: Lessons from NOTUM Technologies

Theodore Kelechukwu Onyejiaku — Fri, 06 Feb 2026 12:56:51 +0000

TL;DR

Who: NOTUM Technologies is a digital agency based in Brno, Czech Republic, and has been a Strapi partner for 5+ years.

What: They created an open-source Next.js + Strapi starter template that saves 3-4 weeks of development time per project.

Key Highlights:

Monorepo architecture with full TypeScript type safety between Strapi and Next.js
Supports projects from small startups to enterprise clients with billions of visitors
Includes automatic page hierarchy with recursive full-path generation
Built-in redirect management when page structures change
Docker-ready deployment for any platform (Azure, AWS, Heroku, etc.)
Uses PNPM for better dependency management and smaller build sizes
Server-side populate logic to avoid frontend complexity and URL length limitations

Notable Plugins Created: Location picker for maps, Record locking for multi-user editing

This article is based on the follwing discussion. Just in case you don't have the time to watch you can do a quick read instead.

Introduction: From Pain Point to Production Solution

Every agency knows the struggle: a new client comes in, and you're starting from scratch—again. Copy the old project, strip out the irrelevant components, implement new ones, and hope you haven't introduced any bugs along the way. For NOTUM Technologies, this cycle became unsustainable once they hit a critical mass of clients.

The solution? A comprehensive starter template that distills years of production experience into a single, battle-tested package. But this isn't just another tutorial project—it's the foundation that has powered enterprise applications serving billions of visitors.

Why Strapi? A Five-Year Partnership

NOTUM's journey with Strapi began around 2018-2019 when they were evaluating CMS options. After extensive internal discussions, Strapi emerged as the winner for several compelling reasons:

Flexibility at Scale: Strapi works beautifully out of the box for simple websites, but it also allows deep customization through plugins and custom code. This dual nature makes it suitable for the wide variety of projects an agency encounters.

Plugin Ecosystem: NOTUM has contributed significantly to the Strapi ecosystem, creating plugins like the location picker (for map-based selection and proximity filtering) and record locking (preventing users from accidentally overwriting each other's changes).

Community Building: Beyond code contributions, NOTUM actively nurtures the local Strapi community through in-person meetups, including a V5 launch party. These gatherings provide valuable opportunities to share learnings and collect feedback directly from Strapi's team.

The Architecture: Why a Monorepo?

One of the most consequential decisions in the template is its monorepo structure, powered by Turborepo. This wasn't a trendy choice—it was driven by a real technical need.

The Type Safety Problem

Strapi doesn't automatically expose TypeScript types to frontend applications. In traditional setups, developers either manually maintain duplicate type definitions or accept the risk of runtime errors when schemas change. Neither option scales well.

By using a monorepo, NOTUM solved this elegantly: auto-generated types from Strapi are exposed to the entire workspace. When you change a content schema, those changes automatically propagate to the frontend application. No more runtime surprises, no more manual syncing.

note: the Strapi team actively is working on improving DX experience to allow users to expose Strapi types to their frontend project. We will keep you posted with updates.

Package Structure

The monorepo contains two main workspaces:

Apps Workspace:

strapi - The backend CMS application
ui - The Next.js frontend application

Packages Workspace:

Shared ESLint and TypeScript configurations
A shared data package for configuration variables (like supported locales)
The Strapi types package (recently separated to reduce build dependencies)
Design system with Tailwind configuration

This structure means you have a single source of truth for everything from linting rules to locale configurations.

Why Next.js 16? The Jack of All Trades

While the template specifically chose Next.js 16 for the frontend, the decision came from practical experience rather than hype.

Versatility: Agencies encounter everything from statically generated marketing sites to dynamic admin dashboards. Next.js handles all these use cases with the same framework.

Team Adoption: React's dominance in the job market means easier hiring and onboarding. The entire team could standardize on one framework.

Enterprise Deployment: Despite internet discourse about Next.js being tied to Vercel, NOTUM has successfully deployed to Azure, AWS S3, Heroku, and other enterprise hosting platforms without significant issues.

The recent migration to Next.js 16 and React 19 did require switching from Yarn v1 to PNPM (due to multiple React version requirements with Strapi still on React 18), but this change actually improved build sizes and developer experience.

The Editting Experience: Where V5 Shines

The template's primary focus is creating an exceptional page editing experience, both for developers and content editors.

Strapi V5's preview and content history features were game-changers here, solving the long-standing headless CMS problem of not seeing what you're editing.

Automatic Page Hierarchy

One standout feature is the automatic full-path generation system. Instead of manually managing URL paths, the template uses a parent-child relationship system:

Create a root page (the homepage)
Create child pages with just a slug and parent reference
The system automatically computes full paths recursively
Change any slug in the hierarchy, and all child paths update automatically

This isn't a plugin—it's built using Strapi's lifecycle hooks and the DB query builder. The implementation required some SQL magic since lifecycle hooks don't always provide references to current relation versions, but the result is seamless path management.

Automatic Redirects

When page paths change, the system automatically generates redirect entries. No more broken links when restructuring your site's information architecture.

Solving the Population Problem

Anyone who's worked with Strapi at scale knows the populate challenge. With dynamic zones containing dozens (or hundreds) of components, the populate object becomes unwieldy.

The URL Length Limit

Here's a problem most tutorials don't mention: when you have many components, your populate query parameters can exceed URL length limits. The frontend simply cannot request everything it needs.

Server-Side Population

NOTUM's solution moves population logic to Strapi itself using document middleware:

The middleware detects specific request patterns (like fetching a single page)
It checks for a custom middleware_populate query parameter
If conditions are met, it replaces the client's populate object with a pre-defined server-side version

This approach keeps the frontend lean, avoids URL length issues, and provides a security benefit—you explicitly control what data can be populated.

They originally used the popular "populate deep" plugin but abandoned it due to performance issues at scale.

You can also accomplish this via route middleware to allow route based population, you can learn more about it here

Developer Experience Features

Scripts for Common Tasks

The template includes utility scripts for developer quality of life:

Remove all node_modules across the monorepo
Clear build caches for all applications
Quickly reset to a clean state when dealing with stale cache issues

GitHub Integration

Husky for commit message formatting (enforcing company-wide standards)
GitHub Actions for build verification
Dependabot configuration for automated dependency updates

VS Code Configuration

Recommended extensions and workspace settings come pre-configured, though this area continues to evolve.

Real-World Deployment

The template ships with Docker support for maximum deployment flexibility. This wasn't added for theoretical completeness—it came from actual enterprise client requirements.

Tested Platforms:

Azure (used extensively on multiple projects)
AWS S3 (for statically generated applications)
Heroku (for teams preferring simpler deployment)

The containerized approach means you're not locked into any specific hosting provider, a crucial requirement for enterprise clients with existing infrastructure preferences.

This a super power of Strapi, you can decide where and how you want to deploy it. My favorite place is Strapi Cloud. But you can decide which approach works best for you.

Lessons Learned: Strapi V5 Lifecycle Gotchas

NOTUM offered valuable feedback for developers diving deep into Strapi customization:

Lifecycle Changes in V5: The introduction of content history changed how lifecycles work. Publishing a new version now triggers the create lifecycle, which can cause unexpected behavior if you're not prepared for it.

Relation Data Availability: When making adjustments that don't change relations, those relations won't be present in the lifecycle payload. This is technically correct but not always obvious.

Admin Panel vs API Payloads: Calling the same endpoint from the admin panel versus a custom API client produces different lifecycle payloads. This inconsistency can trip up even experienced developers.

The takeaway isn't that these behaviors are wrong—they often have valid technical reasons—but they're not always well documented. NOTUM recommends approaching lifecycles with caution and always checking actual behavior against assumptions.

note: Did you know, you can alway provide feedback and feature request here or continue the conversation in GitHub discussions.

AI-Assisted Development: The Evolving Workflow

NOTUM is actively exploring AI integration in their development workflow, particularly for documentation:

Building an internal knowledge base in Markdown
Experimenting with AI agents that understand the template's specifics
Working toward publishable "skills" for AI tools that understand their codebase

Their philosophy aligns with broader industry observations: there's no one-size-fits-all AI workflow. Each developer should find what makes them productive rather than copying someone else's setup.

Getting Started

The template is designed for quick setup:

Clone the repository
Ensure you're using the correct Node version (the repo includes version configuration)
Run pnpm install
Start Docker (required for the database)
Run pnpm run dev:strapi to start the backend
Create an API token in Strapi's admin panel
Add the token to your Next.js .env.local file
Run the frontend

Check out this video on how to set the project up.

Conclusion: Why Templates Matter

The difference between a tutorial template and a production template is measured in months of real-world usage. NOTUM's starter represents the accumulated wisdom from dozens of client projects, from startup landing pages to enterprise applications.

Every time they complete a project—or even mid-project when something important emerges—they backport those learnings into the template. This continuous improvement cycle means you're not just getting a starting point; you're getting a documented history of what works (and what doesn't) in production.

Whether you use the template directly or study it as a reference for your own architecture, there's value in learning from a team that has shipped—and maintained—this stack at scale.

You can also checkout out our official Strapi Stater project called Launchpad

Resources

NOTUM Technologies: For companies needing development partners with deep Strapi expertise
GitHub Repository: Open-source starter template (link in video description)
Strapi Community: Join local meetups to connect with other developers

Did you know?
Strapi hosts Open Office Hours on Discord Monday through Friday at 12:30 PM CST (running until about 1:30 PM CST). It's a great way to connect, get help, and share your feedback directly with the team.

This article was created based on a conversation with Dominic from NOTUM Technologies about their Next.js + Strapi starter template.

Originally published at strapi.io

Building Native Apps With Expo and React Native

Theodore Kelechukwu Onyejiaku — Fri, 06 Feb 2026 12:52:43 +0000

This post is based on our livestream conversation with Kadi Kraman, Developer Experience Engineer at Expo.

TL;DR

Expo is the Next.js of React Native — it handles all the complex native tooling so you can focus on building your app
Start with Expo Go for learning and prototyping; switch to development builds for production (no limitations)
CNG (Continuous Native Generation) means you never commit native folders — they're auto-generated and disposable
React Native renders actual native components, unlike Flutter which draws its own UI
Three styling options: Built-in StyleSheet, NativeWind (Tailwind), or Unistyles (best for theming)
EAS services handle building, submitting, and updating your apps — no Mac required for iOS builds
You can write server code directly in your React Native app with +api.ts files
Meta officially recommends Expo for React Native development

Why Choose Expo for Mobile Development?

Think of Expo as the Next.js of React Native. Just as you wouldn't manually configure Webpack and bundlers when building a React web app, Expo eliminates the complexity of native mobile development tooling.

The Problem Expo Solves

React Native by itself is a toolkit of APIs and a JavaScript runtime, but it doesn't provide a complete framework for building apps. For example, navigation between screens isn't included out of the box.

Without Expo, you'd need to:

Manually configure native build tools (Xcode, Android Studio)
Research and choose from dozens of libraries for basic functionality
Manage native iOS and Android folders manually
Handle complex upgrade paths when React Native versions change

What Expo Provides

Expo is a collection of libraries, utilities, bundlers, and a complete ecosystem that makes building React Native apps pleasant and straightforward. Key benefits include:

Expo SDK: A curated set of native libraries guaranteed to work together (video, audio, haptics, push notifications, etc.)
Expo Router: File-based routing similar to Next.js
Expo Go: Test your app instantly on your phone without building native binaries
CNG (Continuous Native Generation): Native folders are generated automatically and can be thrown away and regenerated

React Native vs. Flutter: Understanding the Difference

A common question is how React Native compares to Flutter. The key distinction is in rendering: Flutter renders on Skia (a graphics engine), essentially drawing its own UI that hooks into native APIs. React Native, on the other hand, renders actual native components. When you build a button in React Native, it's a real native button, not a simulation. This is why React Native apps are often described as "native apps" — because they truly are.

Getting Started: Expo Go vs. Development Builds

Expo offers two approaches for development, each suited to different stages of your project.

Expo Go: Perfect for Learning and Prototyping

Expo Go is an app you download from the App Store or Play Store. It contains pre-built native code for the most common libraries, allowing you to start developing immediately without any native build tools. Simply write JavaScript/TypeScript, and your code runs instantly on your device.

Best for: Learning React Native, rapid prototyping, hackathons, and getting that first "app on your phone" moment. This instant feedback loop is why many AI-powered app builders (like Replit) use Expo under the hood.

Limitations: Not all libraries are included. Some Expo SDK libraries (like expo-video) and third-party packages won't work in Expo Go.

Development Builds: Production-Ready Flexibility

When you're ready for production or need libraries not included in Expo Go, you switch to development builds. Instead of using the Expo Go app, you create your own native shell with exactly the libraries you need.

Best for: Production apps, custom native code, any library from the React Native ecosystem.

Key insight: There are no limitations with development builds. Once you move past Expo Go, you have full access to native code. You can even write custom native modules in Swift or Kotlin using the Expo Modules API.

Continuous Native Generation (CNG): The Secret Sauce

One of Expo's most powerful features is CNG (also called "prebuild"). Traditional React Native development requires you to commit and maintain iOS and Android folders, managing native code directly. With CNG:

Your native folders are git-ignored
They're generated automatically from your package.json, app.json, and node_modules
Upgrades become trivial: delete the native folders, regenerate with new versions

If you need to modify native configuration (like editing Info.plist or the app delegate), you create config plugins instead of editing files directly. These plugins run during generation, making your changes repeatable and testable.

Styling Your App: Three Approaches

Coming from web development, you might wonder about styling options. React Native offers several approaches:

Approach	Description	Best For
StyleSheet (Built-in)	React Native's built-in styling API. Can be verbose for theming.	Projects that want zero dependencies
NativeWind	Tailwind CSS for React Native. Familiar utility classes.	Web developers wanting quick start
Unistyles	Like StyleSheet but with better theming support (light/dark mode).	Apps needing robust theming

Pro tip: If you want your app to look distinctly "native" rather than like a website, study the Apple Human Interface Guidelines and Google Material Design specs. Expo UI (currently in beta) is also exposing more native components like segmented controls and glass buttons.

Deployment: From Code to App Store

Deploying mobile apps is fundamentally different from web deployment. You need to handle code signing (certificates and provisioning profiles) and pass through a manual review process. Expo offers several services to streamline this:

EAS Build: Cloud-based CI/CD that builds your native apps. Particularly valuable because you need a Mac to build iOS apps — EAS Build provides that infrastructure.
EAS Submit: Uploads your built apps to the App Store and Play Store. Free to use and essential since Apple requires specific tools (Transporter) to upload apps.
EAS Update: Push JavaScript updates without going through app store review. Fix bugs instantly.
Expo Launch: A new beta product that takes a GitHub repo and handles everything — building, signing, and submission. Currently supports public repos and iOS (Play Store coming soon).

Writing Server Code in Your React Native App

A powerful recent addition is the ability to write API routes directly in your React Native codebase. Create files ending in +api.ts in your source folder:

// src/posts+api.ts
export function GET() {
  return Response.json({ message: "Hello from server!" });
}

Environment variables without the EXPO_PUBLIC_ prefix are only accessible in these server routes, keeping your secrets safe. Deploy with EAS Hosting and you have a full-stack mobile app with backend API routes.

AI-Assisted Development with Expo

The Expo ecosystem is particularly well-suited for AI-assisted development. With Expo Go's instant feedback loop, tools like Replit and various AI coding assistants can help users go from idea to working app in minutes.

However, there's an important distinction between "vibe coding" (letting AI write everything) and AI-assisted development. Even when using AI tools, you still own the code and are responsible for testing, iterating, and ensuring quality. AI can give you a starting point, but professional development still requires understanding what the code does.

Resources like MCPs (Model Context Protocols), cursor rules, and Claude rules allow experts to codify best practices that AI tools can use as a source of truth — resulting in much higher quality generated code than generic training data.

Coming Soon: Performance Observability

Expo is developing an observability product for monitoring app performance — think Lighthouse scores but for native apps. You'll be able to track metrics like JavaScript bundle load time, see how different app versions affect performance, and identify slow devices or sessions.

Quick Start Checklist

Install Node.js and create a new project with npx create-expo-app@latest
Download Expo Go on your phone for instant testing
Run npx expo start and scan the QR code
Read the Expo docs (docs.expo.dev) — they have an AI assistant built-in
Check React Native Directory (reactnative.directory) for community libraries

Additional Learning Resources

To continue your learning journey, here are some excellent resources:

Video Resources

Full Stack React Native Course by Tube Guruji: A comprehensive 4+ hour course building a local business directory app from scratch using React Native, Expo, and a full backend. Perfect for hands-on learning.

Written Tutorial

Building a React Native App with Expo and Strapi: A Complete Guide: A detailed step-by-step tutorial from the Strapi blog covering project setup, NativeWind styling, data fetching with React Query, and building a complete blog app with infinite scroll. Read it here.

Conclusion

Expo has transformed React Native development from a complex, native-tooling-heavy process into something that feels almost as simple as web development. For React developers, there's never been a better time to start building mobile apps.

The key takeaways: Start with Expo Go for learning, graduate to development builds for production, embrace CNG to avoid native folder maintenance, and leverage EAS services for painless deployment. With these tools, you can go from idea to app store in record time.

Meta officially recommends Expo for React Native development, and it's clear why: the developer experience is exceptional, the ecosystem is mature, and the path from prototype to production is smoother than ever.

Happy building!

Originally published at strapi.io

Bye 2025, Hello 2026! A year in review

Theodore Kelechukwu Onyejiaku — Fri, 06 Feb 2026 12:49:08 +0000

We’ve just wrapped up 2025 - and what a year it has been!
As we do every single year, let’s take a moment to celebrate all the achievements of the past 12 months, and share what’s coming next!

Before we go through the details, to all of you who have used Strapi: thank you! By being part of the community, you have contributed to elevating the Strapi open-source project to:

70K+ stars on GitHub (add yours!)
36K commits
9.4K pull requests merged
Thousands of customers, including Adidas, Airbus, Amazon, Cisco, Tesco, Toyota, PostHog, and CodeRabbit

These milestones are especially meaningful, as Strapi turned 10 this year!

12 months ago, we shared that we would focus on the Side Editor, the New Cloud Plan, the JavaScript/TypeScript SDK, the AI tools, and the first in-person StrapiConf. And that is exactly what we delivered!

Product improvements

More than ever before, the Strapi community shipped.

Strapi AI

AI is changing everyone’s job. You have to disrupt yourself, and so do we. Content Management Systems sit at the intersection of Developers and Marketers, who both have to reinvent their jobs with code generation (vibe coding and AI coding) and content creation (gen AI). The way CMSs are used continues to evolve at an incredible pace. What an exciting time to be building!

This is why we invested heavily in AI. In 2025, we unveiled a suite of strategic product enhancements designed to accelerate both developer workflows and content editor experiences.

AI Content-Type Builder

It all started with the AI Content-Type Builder that we announced at StrapiConf (see below). With the brand new AI Content-Type Builder, you can generate content types and components from natural language prompts or uploaded frontend apps/Figma designs. This eliminates redundant tasks, saving days of development time.

AI Media Library

Creating alt text and captions is another repetitive -and often overlooked- task. The AI Media Library handles this automatically whenever you upload an asset.

Your browser does not support the video tag.

AI Translations

If you manage a website in multiple languages, translating content can be a lengthy, costly, and error-prone process. The AI Translations feature has you covered. When enabled, it automatically translates your content into all the locales you selected. This marks an important step in Strapi’s evolution toward an agentic CMS. Merci beaucoup!

Your browser does not support the video tag.

These are the first steps into the Strapi AI journey. Stay tuned for more!

Editing Experience

Live Preview

The Headless architecture is a great separation of concerns between the frontend and the CMS. However, this separation often came at the cost of the editing experience. Non-technical people need - and deserve - to edit websites and apps in an intuitive and smooth manner. Combined with Strapi 5's Draft & Publish capabilities, Live Preview addresses this challenge.

Your browser does not support the video tag.

Responsive

Editing content for small screens has been a community request for several years. We must admit this comes later than expected, but Strapi is becoming responsive. We've released the first improvements and will keep rolling out additional updates.

Conditional Fields

At Strapi, we’ve always prioritized giving developers and content teams the flexibility to organize content as they see fit. So we introduced Conditional Fields.

With Conditional Fields, you can dynamically show or hide fields based on specific criteria like dropdown selections or checkbox values. This helps editors focus on the right fields at the right time.

Developer Experience

Strapi was created by developers, for developers. In 2025, we shipped a significant number of Developer Experience improvements:

Strapi Client Library: The brand new SDK allows you to easily request your Strapi content from your favorite frontend framework.
OpenAPI support: We’ve heard many users requesting the ability to benefit from typing when using the Strapi Client Library in a frontend project (Next.js, Tanstack, Astro, Nuxt.js, etc.). OpenAPI support will allow us to add this to the Strapi Client Library.
Homepage widgets: From now on, it is possible to display and create widgets on the Strapi homepage.
MCP prototype: The first MCP prototype was shipped. This will be a massive enabler in making Strapi fully agentic.

Integrations

A Headless CMS is often used in conjunction with other services, making it the foundation of a composable architecture. In 2025, in close collaboration with our partner VirtusLab, we launched official integrations for Shopify, BigCommerce, and Cloudinary.

Strapi Cloud

24 months after its launch, Strapi Cloud has become the leading platform for hosting Strapi projects, as it comes with everything you need: Node.js hosting, a Postgres database, asset storage, a CDN, GitHub/GitLab integrations, and more.

Until 2025, the most affordable plan was the Pro plan, at $99/month. Many of you have shared that this price was too high for small projects. This is why we introduced the Essential Plan, for $15/month (when billed annually). We even went a step further by launching a Free Plan, making Strapi Cloud accessible to everyone.

Based on your feedback, we released a bunch of other improvements, such as:

Ownership transfer: Give full access to a Strapi Cloud to anyone (ideally for agencies with clients, and vice versa).
Data migration: Easily migrate content from one environment to another.
Downloadable backups: Save your content and store it anywhere.

Community milestones

Strapi is so much more than an open-source project; it is a vibrant community of contributors, users, and partners who build faster, together.

StrapiConf

After organizing 3 online StrapiConf, we organized the first in-person StrapiConf on May 13, 2025. After years of chats on the Strapi Community Discord, it was fantastic to meet so many of you face-to-face!

Community members presented incredible plugins. Large organizations, including Adidas and Airbus, benefit from the unique customization capabilities that Strapi offers. We had a blast!

Thank you again to our amazing sponsors for empowering the Strapi ecosystem.

Community Calls and Events

We had some amazing calls with the community, one of which was a full-on conversation with Kent C. Dodds about the future of the web, AI agents, and why Model Context Protocol (MCP) might be as big a shift as the early days of the internet.

Here are some other talks and events you may have missed:

To join live streams & online meetings on the latest updates & discussions about Strapi, visit our events page: https://strapi.io/events

Tutorials

Among many amazing tutorials, we created a full tutorial on “Strapi 5 and Next.js 15 Full Stack Project Course”, which shows you how to build a fully functional summer camp website from start to finish, through hands-on practice.

Other great tutorials from the community that you may want to see include:

To see more tutorials, visit the Strapi Blog or our YouTube channel.

Marketplace

We introduced several improvements to the Strapi Marketplace:

The Plugins & Providers are now merged into one overview
The overview is sorted by the number of NPM downloads by default
The home page now directly shows the overview
Outdated plugins for Strapi v4 have been removed

Thank you to the top plugin creators:

Mateusz Ziarko - VirtusLab
Scherwan Al-Ahmad - MagicDX
Kevin Vugts - Headlockr
Tim Schipper - PluginPal
Nikita Shenderov - CKEditor plugin
Laurent Cazanove - Meilisearch

Partner Program

The Partner Program continues to become increasingly beneficial for both enterprises seeking trusted implementers and agencies expanding their client base.

Special shout-out to Notum, QBurst, Alloy, TenTwenty, and Thrillworks for becoming Enterprise Partners, totaling 5 Enterprise-level partners added in 1 year.

This year, we launched monthly live Partner Enablement sessions to keep our partners informed on Strapi best practices, product updates, and sales alignment.

Partners have consistently shared valuable feedback with our product and engineering teams. They've helped identify bugs, feature gaps, and opportunities to price the product more competitively. Thank you for that!

Looking ahead to 2026

As you have seen in this article, we have shipped numerous new features, just as we have for the past few years. This is great!

Over the past few months, you all have shared your opinions through the Community Survey and the pain point GitHub issue. A few improvement requests have been around for a long time on the Feedback page. This is largely because we needed to build a solid company to make the open-source project sustainable and navigate through 2 different business models.

We’ve heard you loud and clear. Although adding features is exciting, it is time to improve some of the foundations. That's why 2026 will be dedicated to User Experience. And it all starts with Quality - fixing bugs, improving data migration, and strengthening the foundations - while also encompassing both the Developer Experience (MCP, typing in the frontend) and the Editing Experience (Media Library enhancements, etc.). Regarding Strapi Cloud, we are migrating to a new infrastructure that will significantly enhance performance, but also allow us to provide you with direct database access and improved runtime logs.

We also plan to continue collaborating as a Strapi community, including creating plugins, contributing to the core, and hosting events.

A Heartfelt Thank You

Thank you so much for being part of the Strapi community. We are 10 years into this journey, and it feels like we are just getting started.

Str’happy New Year!

Originally published at strapi.io

Building a React Native App with Expo and Strapi: A Complete Guide

Theodore Kelechukwu Onyejiaku — Fri, 06 Feb 2026 12:45:51 +0000

This post is based on our livestream conversation with Kadi Kraman, Developer Experience Engineer at Expo.

TL;DR

Expo is the Next.js of React Native — it handles all the complex native tooling so you can focus on building your app
Start with Expo Go for learning and prototyping; switch to development builds for production (no limitations)
CNG (Continuous Native Generation) means you never commit native folders — they're auto-generated and disposable
React Native renders actual native components, unlike Flutter which draws its own UI
Three styling options: Built-in StyleSheet, NativeWind (Tailwind), or Unistyles (best for theming)
EAS services handle building, submitting, and updating your apps — no Mac required for iOS builds
You can write server code directly in your React Native app with +api.ts files
Meta officially recommends Expo for React Native development

Why Choose Expo for Mobile Development?

The Problem Expo Solves

Without Expo, you'd need to:

Manually configure native build tools (Xcode, Android Studio)
Research and choose from dozens of libraries for basic functionality
Manage native iOS and Android folders manually
Handle complex upgrade paths when React Native versions change

What Expo Provides

Expo is a collection of libraries, utilities, bundlers, and a complete ecosystem that makes building React Native apps pleasant and straightforward. Key benefits include:

Expo SDK: A curated set of native libraries guaranteed to work together (video, audio, haptics, push notifications, etc.)
Expo Router: File-based routing similar to Next.js
Expo Go: Test your app instantly on your phone without building native binaries
CNG (Continuous Native Generation): Native folders are generated automatically and can be thrown away and regenerated

React Native vs. Flutter: Understanding the Difference

Getting Started: Expo Go vs. Development Builds

Expo offers two approaches for development, each suited to different stages of your project.

Expo Go: Perfect for Learning and Prototyping

Limitations: Not all libraries are included. Some Expo SDK libraries (like expo-video) and third-party packages won't work in Expo Go.

Development Builds: Production-Ready Flexibility

Best for: Production apps, custom native code, any library from the React Native ecosystem.

Continuous Native Generation (CNG): The Secret Sauce

Your native folders are git-ignored
They're generated automatically from your package.json, app.json, and node_modules
Upgrades become trivial: delete the native folders, regenerate with new versions

Styling Your App: Three Approaches

Coming from web development, you might wonder about styling options. React Native offers several approaches:

Approach	Description	Best For
StyleSheet (Built-in)	React Native's built-in styling API. Can be verbose for theming.	Projects that want zero dependencies
NativeWind	Tailwind CSS for React Native. Familiar utility classes.	Web developers wanting quick start
Unistyles	Like StyleSheet but with better theming support (light/dark mode).	Apps needing robust theming

Deployment: From Code to App Store

EAS Build: Cloud-based CI/CD that builds your native apps. Particularly valuable because you need a Mac to build iOS apps — EAS Build provides that infrastructure.
EAS Submit: Uploads your built apps to the App Store and Play Store. Free to use and essential since Apple requires specific tools (Transporter) to upload apps.
EAS Update: Push JavaScript updates without going through app store review. Fix bugs instantly.
Expo Launch: A new beta product that takes a GitHub repo and handles everything — building, signing, and submission. Currently supports public repos and iOS (Play Store coming soon).

Writing Server Code in Your React Native App

A powerful recent addition is the ability to write API routes directly in your React Native codebase. Create files ending in +api.ts in your source folder:

// src/posts+api.ts
export function GET() {
  return Response.json({ message: "Hello from server!" });
}

AI-Assisted Development with Expo

Coming Soon: Performance Observability

Quick Start Checklist

Install Node.js and create a new project with npx create-expo-app@latest
Download Expo Go on your phone for instant testing
Run npx expo start and scan the QR code
Read the Expo docs (docs.expo.dev) — they have an AI assistant built-in
Check React Native Directory (reactnative.directory) for community libraries

Additional Learning Resources

To continue your learning journey, here are some excellent resources:

Video Resources

Full Stack React Native Course by Tube Guruji: A comprehensive 4+ hour course building a local business directory app from scratch using React Native, Expo, and a full backend. Perfect for hands-on learning.

Written Tutorial

Building a React Native App with Expo and Strapi: A Complete Guide: A detailed step-by-step tutorial from the Strapi blog covering project setup, NativeWind styling, data fetching with React Query, and building a complete blog app with infinite scroll. Read it here.

Conclusion

Happy building!

Originally published at strapi.io

Introducing Yearly Plans and New Limits for Strapi Cloud

Theodore Kelechukwu Onyejiaku — Fri, 06 Feb 2026 12:34:03 +0000

Back in March, we introduced a new pricing model, making Strapi Cloud more accessible. The intention was simple: reduce friction for builders. We simplified Strapi Cloud pricing by offering “hosting-only plans” (without CMS features), increasing included storage, and removing CMS seat and entry limits. The result was a pricing model that grows with your business, where you only pay for what you need when you need it. This approach makes it easier for you to scale, allowing you to focus less on infrastructure management and more on building products that matter.

Today, we’re taking the next step in that direction. We're introducing annual billing with 20% savings, alongside refined usage limits that ensure each plan serves its intended purpose.

TL;DR

20% discount for yearly billing compared to monthly billing
Refined usage limits: Updated API request limits for Free and Essential plans
Monthly quota resets: API requests and bandwidth renew monthly, even on yearly plans
Explore the Strapi Cloud Pricing page and Cloud billing & usage docs for complete details

What’s new and what it means for you

Introducing Yearly Pricing

We heard from many customers that they prefer annual billing for simplified budgeting and reduced administrative overhead. One annual invoice means less time spent processing payments for both developers and accounting teams.

You can now choose yearly billing on all paid Strapi Cloud plans and get a 20% discount compared to monthly billing, with one annual invoice instead of twelve.

Yearly plans offer the best value for teams that are ready to commit and plan ahead. Monthly billing remains available for teams that require maximum flexibility and the ability to cancel at any time, albeit at a higher monthly rate. This reflects the trade-off between flexibility and long-term savings, allowing you to choose what best suits your situation.

Existing monthly customers will continue on their current plans without any changes to their pricing. You're grandfathered in at your existing rates.

Monthly resets still apply on yearly plans too, regardless of how you’re billed:

API requests reset monthly
Bandwidth resets monthly
Asset storage remains an ongoing limit

If you're currently on a monthly plan, don't worry, you'll keep your current pricing. Your rates won't change, and you'll continue with the same limits you have today.

Updated API request limits

We’ve refined API request limits on two plans to better reflect how they’re typically used:

Free plan: 2,500 API requests/month (previously 10,000)
Essential plan: 50,000 API requests/month (previously 100,000) – applies to new subscriptions only

The Free plan remains ideal for personal projects, learning, and early prototypes. These refined limits enable you to build in a stable environment, knowing exactly when your project is ready to transition from proof of concept to production.

Existing Essential customers are protected. If you’re already on the Essential plan, nothing changes. You’ll keep your existing 100,000 API requests/month limit. No action required. No disruption. We believe trust is built by honoring existing commitments and protecting the way you’re already building.

Why we changed the limits

To be clear and honest, lower limits aren’t a direct benefit to individual users. These updates help keep Strapi Cloud reliable, sustainable, and aligned with how each plan is intended to be used:

Free plan: lower limits ensure stability and usability for everyone experimenting or learning.
Platform sustainability: helps maintain performance, prevent abuse, and fund continued investment in new capabilities.

If your project outgrows a plan, that’s a signal it’s ready for the next stage.

What’s next for Strapi Cloud

Alongside these pricing updates, we're continuously building new capabilities across all paid Strapi Cloud plans designed to give you more visibility, control, and speed as your projects grow.

This includes enhanced logging, monitoring, and other improvements focused on improving the developer experience. These initiatives are shaping the 2026 roadmap, and we'll share more details as they become available.

FAQ

Will yearly plans be available for the Growth (CMS) plan?

Yearly billing currently applies only to Strapi Cloud hosting plans (Essential, Pro, Scale). CMS feature licenses (Growth) remain separate for now and are available on a monthly basis.

Can I stay on the Free plan and pay overages?

No, overages don't apply to the Free plan. If you need additional resources, upgrading to a paid plan starting at just $18/month (or $15/month with yearly billing) gives you significantly more capacity.

Do monthly quotas reset monthly, even on yearly plans?

Yes. API requests and bandwidth renewals occur on a monthly basis on yearly plans. Unlike Asset storage, which is an ongoing limit. For example, an Essential customer with 100,000 API requests/month makes 125,000 requests in a given month. They exceeded their quota by 25,000 API requests and would be charged an additional $1.50.

Can I switch from monthly to yearly billing and vice versa?

Yes, you can adjust your billing frequency in your dashboard at any point in time. However, the change will take effect at the end of your current billing cycle. For yearly plans, this means the switch will occur after your 12-month commitment has been completed.

Is Strapi Cloud better than managing my own servers?

In most cases, yes, it greatly reduces operational overhead and lets you build faster. If you require full infrastructure control or want to keep both your frontend and backend on the same infrastructure, self-hosting remains an option.

What happens to existing Essential customers with the new limits?

Current Essential customers keep their existing 100,000 API requests/month limit and won't be affected by these changes. The new 50,000 API requests/month limit only applies to new Essential subscriptions created after December 22nd, 2025.

Originally published at strapi.io