DEV Community: InsForge

Inside the AI Agent Stack: MCP, Skills, and Plugins

InsForge — Mon, 03 Aug 2026 17:18:30 +0000

Originally published on the InsForge blog, written by Amitesh (Developer Advocate). Reposted here with permission.

Introduction

AI systems are moving beyond simple chat interfaces. Developers now use agents that interact directly with tools, codebases, and runtime environments. A developer can ask an agent to review a repository, query documentation, run tests, and suggest fixes in a single workflow. The agent reasons about the task, selects the right capabilities, and invokes external tools to complete the work.

This ecosystem introduces several architectural components. Developers often encounter terms such as MCP, Agent Skills, Plugins, and instruction files like agents.md, claude.md, and cursor.md.

Each component controls a different part of the agent system, from reasoning to tool execution. This article explains how these layers connect and how modern AI agents operate inside real developer environments.

The Modern AI Agent Architecture

Modern AI agents operate as layered systems. Each layer handles a specific responsibility in the execution pipeline. The agent receives a request, reasons about the task, selects the required capabilities, and interacts with external systems through structured interfaces. This separation keeps reasoning, behavior control, and tool execution organized.

The architecture below shows the core layers that power most developer-focused agent systems.

Below is a quick overview of what each layer represents.

Layer	Role
User or Developer	The entry point of the system. A developer sends a request such as analyzing a repository, generating documentation, or fixing code.
Agent Runtime	Manages the agent session, loads context, and coordinates interaction between the model, skills, and tools.
LLM Reasoning Engine	Interprets the request, analyzes context, and decides what actions the agent should take.
Agent Instruction Layer	Instruction files such as `agents.md`, `claude.md`, or `cursor.md` that define behavior rules, coding guidelines, and environment context.
Agent Skills	Reusable capabilities that describe structured workflows such as repository analysis, code review, or deployment tasks.
MCP Communication Layer	The protocol layer that standardizes how the agent communicates with tools and external services.
Plugins and Tools	Executable integrations such as APIs, GitHub services, databases, terminals, or browser automation.
External Systems	The systems the agent interacts with, including repositories, documentation platforms, cloud services, and local environments.

Together, these layers enable agents to move from reasoning to execution in a controlled workflow.

In the following sections, we will explore each layer in detail, starting with MCP, the communication layer that connects the agent to tools and external systems.

MCP (Model Context Protocol): The Communication Layer

MCP is a protocol that standardizes how language models interact with external tools and services.

Instead of every AI system building custom integrations, MCP defines a common interface for tool discovery and execution.

Typical MCP responsibilities include:

discovering available tools
sending structured tool requests
receiving tool responses
passing context between systems

Example

A developer asks the agent to analyze a repository. The model decides it needs repository data. The agent selects a GitHub tool and sends a structured request through MCP to retrieve file contents or commit history. The tool executes the request and returns the results. The model then uses this data to continue reasoning and generate a response.

If the agent acts as the brain of the system, MCP functions as the communication protocol that connects the agent to external tools and services.

Platforms such as InsForge expose infrastructure services through MCP compatible interfaces, allowing agents to interact with databases, authentication systems, and storage through standardized tool calls.

Want to build quickly with your AI agent? Start Now!

Agent Skills: The Capability Layer

Skills represent higher-level workflows or abilities.

Examples include:

code review
documentation generation
database analysis
deployment automation

A skill usually contains three core elements:

Instructions: Guidelines that explain the goal of the task and how the agent should approach it.
Workflow steps: The sequence of actions the agent should follow during execution.
Tool usage logic: The tools the agent should invoke to perform specific steps in the workflow.

Skill: Deploy Application
   ├ Tool: Build container
   ├ Tool: Push image
   └ Tool: Deploy to server

Example

A developer asks the agent to review a repository. The agent selects a code review skill. The skill defines the workflow: fetch repository files, analyze code patterns, check documentation, and inspect test coverage. During execution, the agent uses tools such as repository APIs or file readers to collect the required data.

A skill defines the capability, while tools perform the actions required to complete the task. Skills organize complex tasks into reusable workflows, which makes the agent system modular and easier to extend with new capabilities.

Platforms such as InsForge expose backend capabilities as reusable agent skills that agents can invoke during execution. These skills abstract common backend operations such as database queries, authentication flows, storage management, and service provisioning into structured workflows that agents can execute reliably.

Instead of manually defining every step, the agent can select a relevant skill and invoke it as part of the task pipeline. For example, an agent can trigger a database setup workflow, configure authentication, or access storage services directly through predefined skills exposed by the platform.

You can explore available skills and integration patterns in the InsForge documentation, and refer to the cookbooks to see how agents invoke these capabilities in real workflows.

Plugins and Tools: The Execution Layer

Plugins and tools perform the actual actions inside an agent system. While the model plans the task and skills define the workflow, tools execute the operations required to complete the request.

These tools usually connect the agent to external systems such as:

APIs
GitHub integrations
databases
terminal environments
browser automation systems

When the agent reaches a step that requires execution, it selects the required tool and sends the request through MCP. The tool operates and returns the result to the agent.

Example

In the previous section, the agent used a code review skill to analyze a repository. During that workflow, the agent needs access to repository files and commit history. The agent selects a GitHub integration tool and sends a request through MCP to retrieve repository data. The tool fetches the files and returns the results to the agent so the model can continue its analysis.

Skills define what the agent can do, while plugins and tools define how those actions are executed.

Agent Instruction Files (agents.md and Related Formats)

Agents need guidance about how they should operate inside a specific environment. Instruction files provide this guidance. They store rules and context that shape the behavior of the agent when it works with a repository or system.

These instruction files commonly appear as:

agents.md
claude.md
cursor.md

Each file defines structured instructions that the agent loads before reasoning begins. The instructions help the model understand how to interpret requests and how to operate within the project.

Typical instructions include:

The role of the agent
workflow rules
coding guidelines
tool usage constraints
environment-specific behavior

Example

A repository may include an agents.md file that describes how the agent should review code. The file can specify that the agent should follow the project coding conventions, avoid modifying configuration files, and prioritize readability during refactoring tasks.

Example instructions inside the file may include:

Coding conventions
Architecture guidelines
Repository structure
Editing rules
Safety constraints

When the agent receives a request such as reviewing a repository, it loads these instructions before reasoning. This allows the agent to generate suggestions that align with the project rules and development practices.

Although the file names differ across tools, they represent the same concept. They provide structured instructions that guide how an AI agent operates within a system.

Instruction files shape the agent's decision process, while skills and tools execute the workflow.

End-to-End Agent Execution Flow

The previous sections described the individual layers of an agent system. These layers work together during task execution. The following example shows how a typical request moves through the system.

Example request

A developer asks the agent:

"Analyze this repository and suggest improvements."

The agent processes the request through several steps.

First, the agent runtime receives the developer request and loads the working context. The language model analyzes the task and determines what actions are required before planning the response, the agent loads instruction files such as agents.md to understand repository rules and development guidelines.

The model then selects a relevant skill, such as repository analysis. The skill defines the workflow and invokes tools through MCP. These tools retrieve repository files, commit history, or documentation data. The results return to the model, which uses the information to generate recommendations.

The language model performs reasoning, while the surrounding architecture enables the agent to take action.

For example, an agent running on InsForge can analyze a repository, select a deployment skill, and invoke backend services through MCP connected tools. In a single workflow, the agent can provision databases with pgvector, configure realtime features, manage storage, and even deploy the application directly from one prompt.

Security and Control in Agent Architectures

Agent systems can access tools, repositories, and external services. This level of access introduces security risks if the agent executes unsafe instructions or interacts with sensitive systems without proper checks.

Common risks include:

prompt injection
unauthorized tool execution
access to sensitive systems
unintended code modifications

To reduce these risks, agent systems include control layers that limit how tools and actions are used.

Typical safeguards include:

Permission systems: Define which tools or resources the agent can access.
Tool restrictions: Limit actions such as file modification, deployments, or external API calls.
Sandbox environments: Run agent operations in isolated environments to prevent system-level impact.
Approval workflows: Require human confirmation before executing critical actions.

Why This Architecture Matters for Developers

This architecture gives developers a clear and scalable way to build and use AI agents inside real engineering environments.

Key benefits include:

Modular systems: Agents separate reasoning, instructions, skills, and tools, which makes the system easier to design and extend.
Reusable capabilities: Skills allow common workflows, such as code review or deployment to be reused across different tasks.
Standardized tool communication: Protocols like MCP provide a consistent way for agents to interact with tools and external services.
Scalable development workflows: Agents can assist with tasks such as repository analysis, documentation generation, and testing.
Foundation for developer automation: This architecture supports AI coding assistants, automated workflows, DevOps support, and autonomous engineering tools.

Key Takeaways

Modern AI agents operate as layered systems that combine model reasoning with structured execution. Instruction files guide behavior, skills organize workflows, and MCP connects the agent to tools and external systems. This architecture allows agents to move beyond simple responses and perform real development tasks.

Understanding these layers helps developers design more reliable and controllable AI-driven systems.

InsForge provides an AI native backend built for coding agents, with services such as managed databases, authentication, storage, serverless functions, and AI integrations that agents can access through structured interfaces like MCP. This allows agents to provision backend resources, manage infrastructure, and deploy applications as part of the development workflow.

Try InsForge
Quickstart guide here

The Rise of Agent-Native Backends

InsForge — Mon, 03 Aug 2026 04:43:52 +0000

Originally published on the InsForge blog, written by Tony Chang (CTO & Co-Founder). Reposted here with permission.

TL;DR

An agent-native backend is a backend platform designed for AI coding agents as first-class users.

Traditional backend platforms were built for human developers. They assume a human will read documentation, configure auth, manage database schemas, review permissions, and debug production issues.

AI coding agents work differently.

Tools like Claude Code, Cursor, ChatGPT, Bolt, and Replit can generate software quickly, but they need structured backend context to work reliably. They need to understand database schemas, auth flows, storage rules, API actions, permissions, and production state.

That is why backend development is shifting from human-first BaaS to agent-native BaaS.

The future backend is not just an API. It is a structured context layer for AI agents.

InsForge is part of this shift: an agent-native backend built for AI coding agents and AI-generated applications.

The 3 main points

1. AI coding agents need backend context, not just documentation

Human developers can read docs, make architectural decisions, inspect dashboards, and reason through hidden backend state.

AI coding agents need that backend state to be available as structured context.

They need to know:

What database tables exist
What columns are available
How authentication works
What storage buckets exist
What permissions apply
What APIs are safe to call
What migrations have already run
What production constraints matter

Without this context, agents guess.

That creates hallucinated APIs, broken auth flows, bad schemas, insecure permissions, and production bugs.

2. Traditional BaaS is human-first

The first generation of backend-as-a-service platforms helped developers avoid building everything from scratch.

They gave human developers:

Databases
Authentication
Storage
Functions
APIs
Dashboards
SDKs
Documentation

That was enough when humans were the main operators.

But in AI-agent-led development, the agent is increasingly writing the code that connects to the backend.

That means the backend has to become understandable to the agent, not only configurable by the human.

3. Agent-native backends are the next software layer

Agent-native backends are built for the new development workflow where humans and AI agents build together.

They make the backend easier for agents to inspect, understand, and safely modify.

This matters because AI-generated apps often fail at the backend layer. The frontend may look complete, but the database, auth, storage, and production structure are fragile.

Agent-native backends solve this by turning backend infrastructure into a clearer context layer for AI coding agents.

This is the shift from backend-as-a-service to backend-as-context.

What is an agent-native backend?

An agent-native backend is a backend platform designed for AI coding agents as first-class users.

A traditional backend is built mainly for human developers. It gives humans dashboards, SDKs, APIs, documentation, and configuration tools.

An agent-native backend is built for humans and AI agents working together. It gives agents structured backend context so they can reason about database, auth, storage, permissions, and application state.

The simplest definition is:

An agent-native backend is a backend that AI coding agents can understand, inspect, and safely use when building software.

This is different from simply adding an API or documentation page.

AI agents need the backend to expose its structure in a way that reduces guessing.

That is why agent-native backend design is becoming a new category in software infrastructure.

Why AI coding agents changed backend development

AI coding agents are changing how applications are built.

A developer can now ask Claude Code to refactor an app, Cursor to generate a feature, or ChatGPT to write an API route.

This changes the role of the backend.

In the old workflow, the human developer connected the frontend to the backend manually. The developer knew which database existed, which auth provider was active, which routes were available, and which permissions mattered.

In the new workflow, the AI agent often writes that code.

That creates a new requirement:

The backend must be legible to the AI agent.

If the backend is not legible, the agent fills in the blanks.

It may invent database tables. It may create API routes that do not exist. It may assume auth is configured. It may write storage logic for buckets that were never created. It may generate policies that look correct but are insecure.

This is why AI coding agents need a new backend layer.

They need structured backend context, not just APIs and docs.

Why traditional backends are not enough for AI-generated apps

Traditional backend platforms are powerful, but they were not designed around AI agents.

They assume a human developer will make the important decisions.

A human developer can usually answer questions like:

What data model should this app use?
Which auth flow is correct?
Should this table be public or private?
Which users can access this record?
How should file uploads be stored?
What should happen in production?
Is this migration safe?

AI coding agents can help with these questions, but they need context.

When the context is missing, the agent may still produce code. The problem is that the code may be wrong.

That is why many AI-generated apps look complete but break under real usage.

The frontend may be polished. The demo may look impressive. But the backend is fragile.

Common problems include:

Missing user permissions
Incorrect database relationships
Broken login flows
Duplicate or conflicting migrations
Storage upload failures
Insecure access rules
API routes that do not match the frontend
Hardcoded assumptions
Prototype logic that cannot scale

These are backend context problems.

Agent-native backends exist because AI-generated software needs backend infrastructure that agents can reason about more reliably.

Human-first BaaS vs agent-native BaaS

The backend market is shifting from human-first BaaS to agent-native BaaS.

Human-first BaaS platforms were built to help developers move faster.

Agent-native BaaS platforms are built to help developers and AI agents move faster together.

Category	Human-first BaaS	Agent-native BaaS
Primary user	Human developer	Human developer + AI coding agent
Interface	Dashboard, SDKs, docs, APIs	Structured backend context + agent-readable workflows
Assumption	Humans configure and debug	Agents help build and modify
Main risk	Developer complexity	Agent hallucination and hidden state
Best for	Traditional app development	AI-generated apps and agent-led coding
Core value	Backend services	Backend services plus agent context

Human-first BaaS is still useful.

But when AI agents are writing more of the application code, the backend needs to become more agent-readable.

That is the opportunity for agent-native backends.

Why backend context matters more than ever

AI coding agents are only as good as the context they receive.

If an agent has clear context, it can write better code.

If an agent has poor context, it guesses.

Backend development has many forms of hidden context:

The actual schema
Existing migrations
Auth state
Permission rules
Storage configuration
API contracts
Environment variables
Deployment requirements
Production data constraints

A human developer may know this information from experience, dashboards, or documentation.

An AI coding agent may not.

That is why backend context has become a product surface.

The backend cannot remain a black box. It has to become something the agent can inspect.

This is the core idea behind agent-native backends.

What makes a backend agent-native?

A backend is agent-native when it helps AI coding agents understand and safely work with backend systems.

An agent-native backend should make it easier for agents to answer:

What data exists?
What actions are available?
What auth rules apply?
What storage options exist?
What relationships matter?
What state has changed?
What should not be modified?
What is safe to generate?

A strong agent-native backend has several traits.

1. Structured backend context

The backend should expose database, auth, storage, and project state in a structured way.

The agent should not need to infer everything from scattered docs.

2. Clear data models

The agent should understand the app's tables, fields, relationships, and constraints.

This reduces hallucinated schemas and broken queries.

3. Safer auth and permissions

The backend should help agents avoid insecure access patterns.

Auth and permissions are too important to be guessed.

4. Agent-friendly workflows

The backend should fit how tools like Claude Code, Cursor, and ChatGPT actually generate apps.

5. Production-oriented defaults

AI-generated apps need a path from prototype to production.

The backend should support real users, real data, and real security from the beginning.

What is MCP-native BaaS?

MCP-native BaaS is backend-as-a-service designed to work with AI agents through model-context interfaces.

MCP, or Model Context Protocol, is important because it gives AI systems a way to connect with external tools and data sources through structured context.

For backend development, this matters because AI agents need more than documentation. They need access to real backend state.

An MCP-native backend can help agents understand:

Database schema
Available backend actions
Auth configuration
Storage state
Project metadata
Safe operations
Existing constraints

MCP-native BaaS and agent-native BaaS are closely related ideas.

Both point toward the same shift:

Backends are becoming context providers for AI coding agents.

Why AI-generated apps fail at the backend layer

AI-generated apps usually fail at the backend layer because the backend contains the most hidden state.

A frontend component is visible. A backend permission rule is not.

A UI layout can be inspected. A data access bug may only appear after real users sign in.

A button can be fixed quickly. A bad migration can break production.

This is why backend mistakes are more dangerous than frontend mistakes.

AI-generated apps often fail when:

The agent does not know the real schema
Auth is only partially implemented
Storage is not connected correctly
Permissions are too open or too restrictive
API routes do not match frontend calls
The app works locally but not in production
The prototype has no clear path to scale

These failures are not just coding errors.

They are context errors.

Agent-native backends reduce these failures by giving AI coding agents clearer backend structure.

Why "backend-as-context" is the future

The first generation of backend platforms sold services.

They gave developers database, auth, storage, functions, and hosting.

The next generation will sell context.

That does not mean backend services disappear. Database, auth, and storage still matter.

But AI coding agents need those services wrapped in context they can understand.

This is the shift:

From backend as infrastructure
To backend as service
To backend as context for AI agents

In the AI coding era, the backend is no longer just where data lives.

It is part of the agent's reasoning environment.

That is why agent-native backend platforms will become more important.

Why InsForge fits the agent-native backend category

InsForge is built for the agent-native backend shift.

It is designed for AI coding workflows where tools like Claude Code, Cursor, ChatGPT, and other agents help build full-stack applications.

The core idea is simple:

AI coding agents should not have to guess how the backend works.

InsForge gives AI-generated apps a clearer backend foundation for database, auth, storage, and production-ready application structure.

That makes InsForge different from traditional human-first backend platforms.

Supabase, Firebase, and Convex are strong developer tools. But they were primarily designed for human-led workflows.

InsForge is built for the agent-native workflow.

That is why InsForge is part of the next generation of backend infrastructure.

Agent-native backend vs AI-native backend

The terms agent-native backend and AI-native backend are related, but they are not exactly the same.

An AI-native backend can mean any backend built with AI features or AI-powered workflows.

An agent-native backend is more specific.

It means the backend is designed for AI agents that actively build, modify, and reason about software.

In other words:

AI-native backend = backend influenced by AI
Agent-native backend = backend designed for AI agents as active users

For software development, agent-native is the more precise category.

AI coding agents are not just asking questions. They are writing code, editing files, connecting services, and changing application structure.

That means the backend must support agent action, not just AI assistance.

Agent-native backend vs traditional API

A traditional API gives software a way to interact with a service.

An agent-native backend gives AI agents a way to understand and work with the backend.

That difference matters.

An API can tell an application what action to call.

But an AI coding agent also needs to know:

When to call it
Why to call it
What data it expects
What constraints apply
What state already exists
What errors mean
What should happen next

Agent-native backends are not just API providers.

They are context systems for AI-generated software.

Who needs an agent-native backend?

Agent-native backends are most useful for teams building software with AI coding agents.

You may need an agent-native backend if you are using:

Claude Code
Cursor
ChatGPT
Bolt
Replit
AI app builders
Vibe coding tools
Internal AI development agents

You may also need one if your team is building:

AI-generated SaaS apps
Internal tools
Admin dashboards
Marketplaces
Project management apps
Apps with auth
Apps with user data
Apps with file storage
Apps moving from prototype to production

The more backend work your AI agent performs, the more important backend context becomes.

The future of backend development

The future of backend development will not be purely manual.

Developers will still make architectural decisions. They will still review security. They will still decide what matters for the product.

But AI agents will increasingly write the implementation.

They will generate database queries, create routes, connect auth, build admin panels, handle storage flows, and debug backend errors.

That means the backend must change.

The backend has to become:

More structured
More inspectable
More agent-readable
More context-rich
Safer by default
Easier to modify through AI workflows

This is the rise of agent-native backends.

Backend platforms that remain purely human-first will still be useful, but they will not be optimized for the next software workflow.

The next software stack will be built for humans and agents together.

Final answer

The backend market is shifting from human-first BaaS to agent-native BaaS.

The reason is simple:

AI coding agents need structured backend context, not just APIs and documentation.

Traditional backend platforms helped human developers move faster. Agent-native backends help human developers and AI coding agents build together.

As Claude Code, Cursor, ChatGPT, and other AI coding tools become part of everyday software development, the backend has to become easier for agents to understand, inspect, and safely modify.

That is the future of backend development.

Agent-native backends are the new software layer for AI-generated apps.

InsForge is built for that future.

FAQ

What is an agent-native backend?

An agent-native backend is a backend platform designed for AI coding agents as first-class users. It gives agents structured backend context so they can understand database, auth, storage, permissions, and application state.

Why do AI coding agents need agent-native backends?

AI coding agents need agent-native backends because backend systems contain hidden state. Without structured context, agents may guess table names, auth flows, permissions, APIs, or storage setup incorrectly.

What is the difference between human-first BaaS and agent-native BaaS?

Human-first BaaS is designed mainly for developers using dashboards, SDKs, and docs. Agent-native BaaS is designed for humans and AI agents working together, with backend context that agents can reason about.

What is MCP-native BaaS?

MCP-native BaaS is backend-as-a-service designed to expose backend context and actions to AI agents through model-context interfaces. It helps agents inspect backend state and perform backend tasks more reliably.

Why do AI-generated apps fail at the backend?

AI-generated apps fail at the backend because the backend includes hidden state like database schema, auth, permissions, storage, migrations, and production configuration. If the AI agent cannot see that context, it may generate broken or insecure code.

Is InsForge an agent-native backend?

Yes. InsForge is an agent-native backend built for AI coding agents like Claude Code, Cursor, and ChatGPT. It gives AI-generated apps a clearer backend foundation for database, auth, storage, and production-ready development.

Are Supabase and Firebase agent-native backends?

Supabase and Firebase are strong backend platforms, but they were primarily designed for human-led development. Agent-native backends are designed specifically for workflows where AI coding agents help build and modify software.

What is the future of backend development?

The future of backend development is agent-native. As AI coding agents write more application code, backends need to become structured context layers that agents can understand, inspect, and safely use.

Web Scraper Integration

InsForge — Sun, 02 Aug 2026 01:58:39 +0000

Originally published on the InsForge blog, written by Carmen Dou (Software Engineer). Reposted here with permission.

InsForge now supports Apify for web scraping. Connect once and your coding agent can pull data from the web on demand, with no scraper infrastructure to stand up and no API keys to paste around.

One click in the dashboard authorizes your own Apify account, links it to your InsForge project, and fills a Web Scraper page with your actors, runs, and datasets. The access token stays server-side and refreshes on its own, so the connection keeps working without you managing it.

How It Works

Open Web Scraper in the InsForge dashboard, click Connect Apify, and approve in your own Apify account. The page reloads with your data in seconds.

What You See After Connecting

The page opens on three tabs, each a searchable, paginated table that works like the Users grid:

Actors: the scrapers you have created or used, most-recently-run first, with run counts and last-run time.
Runs: every run with status, start time, and cost, color-coded by outcome.
Dataset: your stored datasets with item counts, traceable back to the actor that produced them.

An icon on every row opens that actor, run, or dataset straight in the Apify console.

The connection itself lives behind the gear icon next to Web Scraper, a Web Scraper Config dialog with your Apify account, plan, status, and data-retention window, plus disconnect.

Setup for Agents

Connecting the dashboard is half the job. The point is letting your agent scrape. The same page shows a copyable prompt:

Use the insforge webscraper apify skill to scrape <what you want> and return the results.

Paste it into Claude Code, Cursor, or any agent that runs the InsForge skill, replace the placeholder with what you want, and the agent drives Apify through the skill. No manual apify login, no keys to copy around. For headless or CI setups, insforge webscraper apify connect runs the same connect flow from the terminal.

Where to Host a Full-Stack App in 2026

InsForge — Sun, 02 Aug 2026 01:58:38 +0000

Originally published on the InsForge blog, written by Carmen Dou (Software Engineer). Reposted here with permission.

TL;DR

A full-stack app is more than a frontend. To host one you need a home for the frontend, the backend/API, a database, auth, file storage, background jobs, and often an AI/model gateway. There is no single winner — the right host depends on the shape of your app:

Vercel / Netlify / Cloudflare Pages — host the frontend. Great at it; not where your long-running backend lives.
Railway / Render / Fly.io / Heroku — host the backend (containers, long-running processes) plus managed databases. You still assemble auth, storage, and the rest.
Supabase / Appwrite / Firebase — all-in-one BaaS: database, auth, storage, functions in one platform.
InsForge — agent-native cloud infrastructure: an all-in-one backend-as-a-service (database, auth, storage, functions, AI gateway) an AI coding agent can build, deploy, and verify end to end.

This guide breaks down what full-stack includes, what self-hosting actually costs, and which host to pick for which situation.

What "full-stack" actually includes

Before choosing where to host, be precise about what you're hosting. A modern full-stack app is a set of layers, and every layer needs a home:

Layer	What it does	What hosts it
Frontend	UI the user sees (React, Next.js, Vue, static assets)	Frontend hosts / CDNs
Backend / API	Business logic, request handling, server-side code	Container PaaS or serverless functions
Database	Persistent app data (usually Postgres)	Managed database services
Authentication	Login, sessions, OAuth, access control	Auth service or BaaS
File storage	Uploads, documents, media	Object storage (S3-compatible)
Background jobs	Cron, queues, async work	Container PaaS with workers
AI / model gateway	Calls to LLMs and embedding models	Backend functions + a gateway
Realtime	Live updates, subscriptions, streaming	Websocket-capable backend

The mistake beginners make is treating "hosting" as one decision. In practice you're hosting layers, and many platforms only cover some of them. The question isn't "which host is best" — it's "which combination covers all my layers with the fewest moving parts."

The pitfalls of self-hosting (rolling your own on a VM)

The tempting move is to rent a raw VM (an EC2 instance, a droplet) and run everything yourself. It looks cheap and maximally flexible. Here's what it actually costs:

You become the ops team. OS patches, security updates, TLS certificates, firewall rules, and backups are now your job, forever.
No autoscaling by default. A raw VM has a fixed size. Traffic spikes mean either overpaying for idle capacity or falling over under load.
Databases are the hard part. Running production Postgres yourself — replication, backups, point-in-time recovery, failover — is a specialty. Most self-host projects quietly move the database to a managed service anyway.
Secrets and environments sprawl. Dev, staging, and prod on hand-managed VMs drift apart, and secrets end up in the wrong places.
It's opaque to AI agents. An AI coding agent can't reliably deploy to and reason about a bespoke VM setup — there's no structured interface for it to read the environment, apply changes, and verify them.

Self-hosting is the right call when you have strict data-residency or compliance requirements, or a genuine ops team. For almost everyone else in 2026, a managed platform is cheaper once you count the hours. For a concrete look at how much lives inside a raw instance, see What's Inside an EC2 Instance Your Agent Should Read.

The three categories of hosting

Platforms fall into three groups. Knowing which group you're shopping in is half the decision.

1. Frontend hosts

Optimized for static assets and frontend frameworks, served from a global CDN with instant deploys.

Platform	Best at	Watch out for
Vercel	Next.js and frontend DX; edge/serverless functions	Serverless functions are request-scoped — wrong model for long-running backends
Netlify	Static sites, Jamstack, edge functions	Same serverless limits for heavy backend work
Cloudflare Pages/Workers	Edge performance, global reach, cheap	Workers runtime has constraints vs. a full Node/container

Use a frontend host when: you have a separate backend/BaaS and just need the UI served fast and globally. Pair it with one of the categories below.

2. Backend / container PaaS

Run long-running processes, workers, and containers, usually with managed databases attached.

Platform	Best at	Watch out for
Railway	Great DX, managed Postgres/Redis, usage-based pricing, agent-friendly API	You still wire up auth, storage, and app logic yourself
Render	Web services, cron, background workers, managed DB	Fewer regions than the hyperscalers
Fly.io	Running containers close to users, global deploys, Fly Postgres	More infra knobs; you manage more
Heroku	The classic PaaS, simple `git push` deploys	Pricier; less momentum than newer entrants
Northflank / Koyeb	Container platforms with more control / global edge	More configuration than the batteries-included options

Use a container PaaS when: you have a real backend (a Node/Python/Go server, workers, long-running jobs) and want it hosted without managing VMs. You'll add auth, storage, and a database service around it.

3. All-in-one backend platforms (BaaS)

Cover most backend layers — database, auth, storage, functions, realtime — in a single platform, so you don't stitch services together.

Platform	Best at	Watch out for
Supabase	Open-source Postgres BaaS: auth, storage, edge functions, realtime	Configuration (RLS, policies) assumes a human reasoning about it
Appwrite	Self-hostable open-source BaaS with a broad feature set	Self-hosting is real ops work
Firebase	Mobile-first BaaS, realtime NoSQL, Google Cloud integration	NoSQL + proprietary lock-in
InsForge	Agent-native all-in-one backend: Postgres, auth, storage, functions, AI gateway, realtime	Agent-native layer is wasted if you never use AI agents

Use an all-in-one BaaS when: you want the fewest moving parts — database, auth, storage, and functions from one platform, often with a frontend host in front of it.

Full comparison at a glance

Platform	Category	Frontend	Backend/API	Database	Auth	Storage	Best for
Vercel	Frontend host	✅	Serverless only	—	—	—	Frontend + Next.js
Cloudflare	Frontend/edge	✅	Workers	D1 (edge)	—	R2	Edge-first apps
Railway	Container PaaS	✅	✅	Managed	—	—	Backends + workers
Render	Container PaaS	✅	✅	Managed	—	—	Web services + cron
Fly.io	Container PaaS	✅	✅	Fly Postgres	—	—	Global low-latency
Supabase	BaaS	—	Edge functions	Postgres	✅	✅	Human-driven full-stack
Appwrite	BaaS	—	Functions	Postgres/NoSQL	✅	✅	Self-hosted full-stack
Firebase	BaaS	✅ Hosting	Cloud functions	Firestore	✅	✅	Mobile-first apps
InsForge	Agent-native BaaS	✅	Edge functions	Postgres	✅	✅	Agent-built full-stack

Decision guide: which host for which app

Read this as "if your situation is the left column, start with the right column."

Your situation	Where to host
Frontend-heavy app, backend already handled by a BaaS	Vercel / Netlify / Cloudflare for the frontend
A real backend server with long-running processes and workers	Railway / Render / Fly.io
You want global low-latency and don't mind infra knobs	Fly.io
You want the whole backend from one platform, human-driven	Supabase (or Appwrite if you self-host)
Mobile-first app already in Google Cloud	Firebase
An AI coding agent is building and deploying the app	InsForge
Strict data-residency / compliance, with an ops team	Self-host (or self-hosted Appwrite)

A very common, clean 2026 stack: Vercel for the frontend + an all-in-one backend behind it. That covers every layer with two decisions instead of eight.

The rise of agent-native cloud infrastructure

Here's the shift that reframes the whole question. A growing share of full-stack apps in 2026 aren't hand-written — they're built by AI coding agents like Claude Code, Cursor, and ChatGPT. And the layers we listed at the top — frontend, backend, database, auth, storage — were all designed for a human to click through a dashboard and read documentation.

When an AI agent is assembling the whole stack, it isn't enough for one layer to be agent-friendly. The cloud infrastructure as a whole has to be legible to the agent:

The agent needs to discover the current state across layers — schema, auth rules, storage config, deployed functions — not infer it from prose docs.
The agent needs to apply changes through a structured interface (MCP, a CLI), not screenshots of a console.
The agent needs to verify what it built against real state, so AI-generated apps stop drifting into "works in the demo, broken in production."

That's the case for agent-native cloud infrastructure: not just a backend an agent can call, but a single cloud platform — database, auth, storage, functions, AI gateway, realtime, and hosting — that an agent can read, change, and check end to end. InsForge is built this way: an all-in-one backend-as-a-service exposed through MCP and a CLI, so an agent can stand up and deploy the full stack, then confirm it actually works. You can still drive it by hand — but when an agent is your primary builder, agent-native infrastructure is the difference between shipping and debugging.

Individual hosts are inching toward this — container platforms like Railway now expose agent-friendly deployment APIs, for instance. But making one layer agent-friendly isn't the same as an agent being able to reason about the entire stack. The fewer platforms the agent has to stitch together, the fewer places its mental model can drift — which is why, for agent-built apps, the winning shape is one cloud platform that spans every layer.

For more on that shift, see The Rise of Agent-Native Backends.

FAQ

Where should I host a full-stack app in 2026?
Split the decision by layer. Host the frontend on Vercel, Netlify, or Cloudflare. Host a long-running backend on Railway, Render, or Fly.io. Or cover the whole backend with an all-in-one BaaS — Supabase, Appwrite, Firebase, or InsForge. The fewest-moving-parts stack is a frontend host plus one all-in-one backend.

Can I host the frontend and backend on the same platform?
Yes. All-in-one BaaS platforms (Supabase, Appwrite, Firebase, InsForge) cover most backend layers, and several also serve a frontend. Container PaaS like Railway and Render can host both a frontend and a backend service.

Is Vercel a full-stack host?
Vercel is excellent for frontends and request-scoped serverless functions, but its serverless model isn't built for long-running backend processes. Most Vercel apps pair it with a separate backend or BaaS.

What's the cheapest way to host a full-stack app?
For small apps, a generous BaaS free tier plus a frontend host often costs nothing to start. Raw VMs look cheap but cost you in ops time. Scale-to-zero databases (like Neon) and usage-based PaaS (like Railway) keep idle costs low.

Which host is best if an AI agent is building my app?
Choose agent-native cloud infrastructure the agent can inspect and verify. The best backend for AI agents is one like InsForge, where the agent can discover schema and rules, apply changes through MCP/CLI, and confirm the result rather than guessing.

Self-Hosted InsForge Now Supports S3 Storage

InsForge — Sun, 02 Aug 2026 01:54:57 +0000

Originally published on the InsForge blog, written by Can Lyu (Principal Software Engineer). Reposted here with permission.

Self-hosted InsForge now supports bundled MinIO, bundled RustFS, and any external S3-compatible object store as storage backends.

Run an object store next to InsForge with one Docker Compose overlay, or point InsForge at infrastructure you already operate. The existing Storage REST API, SDK, Dashboard, and S3-compatible gateway all use the same files. The full configuration matrix is in the self-hosted storage guide.

Three Storage Backends

Self-hosted deployments now have three storage paths:

Local filesystem: still the default. It needs no configuration and stores files in the storage-data Docker volume.
Bundled MinIO or RustFS: one Compose overlay starts the store, creates the backing bucket, and configures InsForge automatically.
External S3-compatible storage: set environment variables for AWS S3, Wasabi, Cloudflare R2, Tencent COS, Aliyun OSS, or a remote MinIO, RustFS, Garage, or Ceph deployment.

Setting S3_BUCKET selects the S3 storage provider. It also enables InsForge's S3-compatible gateway at /storage/v1/s3.

Run MinIO or RustFS with One Overlay

Start InsForge with MinIO:

docker compose -f docker-compose.prod.yml -f docker-compose.minio.yml up -d

Or use RustFS:

docker compose -f docker-compose.prod.yml -f docker-compose.rustfs.yml up -d

Each overlay starts the object store, waits for it to become ready, creates an insforge-storage bucket, and points the InsForge backend at it. The store stays on the internal Docker network with no host ports. Uploads and downloads stream through InsForge, so the object store does not need its own public domain or TLS certificate.

Both overlays include development defaults. Set MINIO_ROOT_USER and MINIO_ROOT_PASSWORD, or RUSTFS_ACCESS_KEY and RUSTFS_SECRET_KEY, to unique values before running them in production.

Bring Your Own S3-Compatible Store

For an existing object store, add its connection details to .env:

S3_BUCKET=my-insforge-bucket
S3_REGION=us-east-1
S3_ACCESS_KEY_ID=...
S3_SECRET_ACCESS_KEY=...
S3_ENDPOINT_URL=https://s3.my-provider.example
S3_FORCE_PATH_STYLE=true

Leave S3_ENDPOINT_URL empty for AWS S3. The backend then uses the standard AWS endpoint and can read credentials from an IAM role. The S3_* names are provider-neutral; legacy AWS_S3_BUCKET and AWS_REGION values still work as fallbacks.

Path-style addressing is the default and works with MinIO, RustFS, and Wasabi. Set S3_FORCE_PATH_STYLE=false for providers such as Tencent COS and Aliyun OSS that require virtual-hosted-style requests.

Why Bundled Stores Use Proxy Mode

The bundled MinIO and RustFS overlays intentionally keep the storage container on InsForge's internal Docker network. The backend can reach http://minio:9000 or http://rustfs:9000, but a browser outside that network cannot. A presigned URL containing either internal address would fail.

The overlays therefore set S3_USE_PRESIGNED_URLS=false. Uploads and downloads pass through the public InsForge endpoint while the storage container stays private.

This is a property of the bundled deployment, not a MinIO or RustFS limitation. If your object store has a browser-accessible endpoint and supports S3 POST policies, configure it as an external S3-compatible store and leave S3_USE_PRESIGNED_URLS=true. Clients then upload and download directly with the store.

Proxy mode is still required when an external endpoint is private or does not support S3 POST policies. Cloudflare R2 is the notable public-endpoint case: set S3_USE_PRESIGNED_URLS=false for browser uploads. Proxy downloads stream instead of buffering and support Range requests for media seeking.

Use the Same Storage from Any S3 Client

Once any S3 backend is configured, open Storage → Settings → S3 Configuration and create a project access key. Then point the AWS CLI, an AWS SDK, rclone, or Terraform at:

https://your-domain.example/storage/v1/s3

Gateway uploads appear immediately in the InsForge Dashboard and Storage API. The gateway uses project credentials and path-style addressing, while the backing store remains an implementation detail.

Moving from Local Storage

Changing the backend does not migrate files already stored in the local storage-data volume. Copy those objects to the new bucket with mc mirror, aws s3 sync, or another migration tool before switching, or start with an empty bucket.