blog: App Hosting and Compute Platforms for AI Agents in 2026

apps/blog/content/blog/app-hosting-compute-platforms-for-ai-agents-2026/index.mdx

@@ -0,0 +1,124 @@
+---
+title: "App Hosting and Compute Platforms for AI Agents in 2026"
+slug: "app-hosting-compute-platforms-for-ai-agents-2026"
+date: "2026-06-19"
+authors:
+  - "Martin Janse van Rensburg"
+metaTitle: "App Hosting and Compute Platforms for AI Agents in 2026"
+metaDescription: "A field guide to the 2026 wave of app-hosting and compute platforms (Prisma Compute, Neon, Cloudflare Containers, Hosting.com, Unkey, and Insforge) and how close each gets to one coherent stack for agents."
+heroImagePath: "/app-hosting-compute-platforms-for-ai-agents-2026/imgs/hero.svg"
+heroImageAlt: "Field guide, 2026: app hosting and compute for AI agents. Prisma Compute, Hosting.com, Cloudflare Containers, Unkey Deploy, Neon Compute, and Insforge."
+metaImagePath: "/app-hosting-compute-platforms-for-ai-agents-2026/imgs/meta.png"
+tags:
+  - "platform"
+  - "ai"
+excerpt: "A field guide to the 2026 wave of app-hosting and compute platforms, and how close each gets to one coherent stack for agents."
+---
+
+During the first half of 2026, companies that were never "hosting companies" started shipping app hosting. A managed Postgres provider. An API-keys company. A CDN. A backend-as-a-service. Within months of each other, they all converged on the same realization: the place your code runs should sit next to the place your data lives.
+
+The rise of agentic development made the problem obvious. A coding agent can spin up a backend super fast, but as soon as it needs to deploy, wire up a database, handle stateful workloads, and iterate reliably, it hits a brick wall of disparate vendors that weren't designed to play nicely together. Co-locating compute and data removes those sources of friction, but once everyone has done it, it stops being a differentiator. It seems that compute next to your data is rapidly becoming table stakes.
+
+So when you can run your app anywhere, what's the difference? Is being quick the whole ball-game? The real differentiator is whether your agent can build, deploy, observe, and iterate across the stack with far less stitching and context loss. Tools like [MemContext](https://memcontext.in/) can help reduce the context issues, but the platforms that win will be the ones that turn code, schema, data, and runtime into one coherent system, something both humans and agents can actually reason about together.
+
+So, here is a field guide to who shipped what recently, and how close they get to solving this problem.
+
+## 1. Prisma Compute
+
+**Public beta:** June 2026
+
+<TweetColumns tweetId="2064674357075759281" side="left">
+
+[Prisma Compute](/blog/launching-prisma-compute-public-beta) is TypeScript app hosting that runs in the same regions as [Prisma Postgres](https://www.prisma.io/postgres), so app-to-database queries stay low-latency. It targets the workloads typical serverless still struggles with: WebSockets, background jobs, cron tasks (first-class in `prisma.config.ts`), and agents that need to stay warm and stateful.
+
+Deployments are versioned with preview URLs. [Prisma Next](/blog/prisma-next-early-access-write-your-contract-prompt-your-agent-ship-your-app) (early access) adds a contract-first ORM with a machine-readable `contract.json`, so the ORM, Postgres, and Compute now share one schema.
+
+On the agent side, `SKILL.md` files, agent rules, and native MCP support give the AI a clean interface for the full loop: init, schema changes, data access, deploy, logs, and redeploy. pgvector and extensions make feeding structured context easier with less manual ETL.
+
+</TweetColumns>
+
+## 2. Neon Compute
+
+**Launched:** June 2026
+
+<TweetColumns tweetId="2066597406859555017" side="right">
+
+[Neon](https://neon.com/) added Compute alongside Object Storage and an AI Gateway, joining its Postgres and Auth products to create what it calls a "complete backend for apps and agents." Every service follows the same instant, branchable, serverless model that made Neon Postgres popular.
+
+[Branching](https://neon.com/branching) is genuinely excellent. A standout feature for development, previews, and agent experimentation. The focus on agents as first-class citizens is well executed.
+
+The main trade-off is integration depth. Neon's services are strong on their own but remain discrete pieces. There's no native ORM (you bring Prisma ORM, [Kysely](https://kysely.dev/) etc), so moving from schema changes to a deployed app still spans separate tools without a shared source of truth.
+
+</TweetColumns>
+
+## 3. Cloudflare Containers
+
+**Generally available:** 13 April 2026
+
+<TweetColumns tweetId="1937544770752045168" side="left">
+
+[Cloudflare Containers](https://www.cloudflare.com/products/containers/) graduated from beta in April 2026. You define a container, build it with Docker, and `wrangler deploy` it across more than 320 cities worldwide.
+
+You're billed only for actual CPU usage. It gives you real Linux containers that run any language, delivering maximum flexibility and the full power of Cloudflare's massive global edge network. This makes it especially strong for performance-sensitive or highly custom workloads.
+
+The trade-off is the same flexibility. Being language-agnostic and database-agnostic means you're responsible for choosing, connecting, and managing your database, ORM, and all the surrounding infrastructure. Enormous power, but full assembly required. The clear opposite of an opinionated, integrated stack.
+
+</TweetColumns>
+
+## 4. Hosting.com
+
+**Launched:** March 2026
+
+<TweetColumns tweetId="2036456606561411501" side="right">
+
+[Hosting.com](https://hosting.com/) launched an AI Application Hosting platform built on Cloudflare Enterprise. It addresses the gap between easy AI-generated code and secure, reliable deployment.
+
+Developers get one-click deploys with Git integration for code from tools like Cursor and Windsurf, while non-technical users can build apps through Nova, their natural-language builder.
+
+The launch shows that the push toward simpler hosting has expanded beyond specialized infrastructure startups into the broader hosting market.
+
+The main limitation is focus. Hosting.com prioritizes broad accessibility and general-purpose use cases over deep integration and agent-native workflows. It's a wider, more approachable net rather than a specialized stack optimized for developer-led, agent-driven teams.
+
+</TweetColumns>
+
+## 5. Unkey Deploy
+
+**Launched:** April 2026
+
+<TweetColumns tweetId="2046999421771030951" side="left">
+
+[Unkey](https://www.unkey.com/)'s pitch is straightforward: push a Dockerfile and get a production API.
+
+Their Deploy product offers multi-region rollouts, instant rollbacks, automatic domains, and preview environments. Every request routes through Unkey's auth and rate-limiting layer before hitting your code. The backstory is interesting. Unkey [publicly ditched serverless in late 2025](https://www.unkey.com/blog/serverless-exit) after hitting performance issues, then built Deploy on top of warm, predictable servers. It works well for straightforward API workloads.
+
+However, it's essentially compute plus an API gateway. There's no database, no ORM, and no deeper stack integration. You'll still need to bring your own database and handle all the context switching for your agent.
+
+</TweetColumns>
+
+## 6. Insforge
+
+**Iterated through 2026 (currently early-stage)**
+
+<TweetColumns tweetId="2062935372703629402" side="right">
+
+[Insforge](https://insforge.dev/) is the purest agent-native entrant: an [open-source](https://github.com/InsForge/InsForge), MCP-driven backend that bundles database, auth, storage, edge functions, an AI gateway, and hosting. It's language-agnostic and positions itself as "the agent-native alternative to AWS," built from the ground up so agents can directly manage the full stack.
+
+The vision is strong but the challenges are significant. Being language-agnostic forces a lowest-common-denominator approach, which hurts overall developer experience: generic interfaces, weaker type safety, and more boilerplate compared to opinionated stacks.
+
+Combined with its broad Supabase-shaped scope, this might lead to shallower features, more bugs, and slower polish. Early-stage + open-source adds the usual issues around scaling, security, and production maturity. Most teams won't trust it yet. Insforge has the boldest long-term vision, but the farthest to go.
+
+</TweetColumns>
+
+## Why might all of this be happening?
+
+The products look somewhat different but they seem to be pointing in the same direction. Agents struggle to hold a thought for long, and the more they try, the more it costs you.
+
+METR's Time Horizon research points in a related direction: the tasks models can complete reliably keep getting longer. But longer tasks only pay off if the agent can hold onto what it learned along the way.
+
+Then there's the money. Frontier models are expensive right now, and getting more so: as recently as 16 June 2026, reports emerged of [Microsoft eyeing DeepSeek for Copilot](https://www.axios.com/2026/06/16/microsoft-copilot-cowork-tokenmaxxing-cowork), with cost cited as a major reason. Models may get cheaper eventually, but not soon. So efficiency walls are closing in from both sides, wasted tokens cost real money, and wasted context costs success rates.
+
+A unified stack attacks both at once: keep code, schema, data, and runtime coherent, and the agent (and your finance department) stops paying the re-reading tax on every turn. That's probably one explanation for why this whole crop of hosting providers showed up at the same time.
+
+---
+
+_Disclosure: I work at Prisma, so I had a front-row seat for one of these launches, which is also why I think the integration story matters more than raw speed. If you want to feel what "one coherent system" is like, [Prisma Compute](/blog/launching-prisma-compute-public-beta) runs your app next to [Prisma Postgres](https://www.prisma.io/postgres) in a single project._

apps/blog/src/components/TweetBoundary.tsx

@@ -0,0 +1,33 @@
+"use client";
+import { Component, type ReactNode } from "react";
+
+// Safety net around react-tweet's <EmbeddedTweet>. enrichTweet() still runs on
+// the client during hydration; if it throws on an unexpected payload, contain
+// the failure to this one embed instead of blanking the whole page, and fall
+// back to a plain link to the post on X.
+export class TweetBoundary extends Component<
+  { tweetId: string; children: ReactNode },
+  { failed: boolean }
+> {
+  state = { failed: false };
+
+  static getDerivedStateFromError() {
+    return { failed: true };
+  }
+
+  render() {
+    if (this.state.failed) {
+      return (
+        <a
+          href={`https://x.com/i/status/${this.props.tweetId}`}
+          target="_blank"
+          rel="noopener noreferrer"
+          className="block w-full rounded-xl border border-gray-200 bg-gray-50 p-6 text-center text-sm text-gray-600 no-underline hover:border-gray-300 dark:border-gray-700 dark:bg-gray-900/40 dark:text-gray-300"
+        >
+          View this post on X →
+        </a>
+      );
+    }
+    return this.props.children;
+  }
+}

apps/blog/src/components/TweetColumns.tsx

@@ -0,0 +1,96 @@
+import type { CSSProperties, ReactNode } from "react";
+import { getTweet, type Tweet } from "react-tweet/api";
+import { EmbeddedTweet } from "react-tweet";
+import { TweetBoundary } from "./TweetBoundary";
+
+const isTweetId = (value: string) => /^\d+$/.test(value);
+
+// react-tweet 3.3.0's getEntities() iterates entities.hashtags / user_mentions
+// / urls / symbols without guarding undefined, so a tweet whose syndication
+// payload omits one of those (common on newer tweets with media or cards)
+// throws "undefined is not iterable" and crashes the page. Backfill the arrays
+// before handing the tweet to <EmbeddedTweet>.
+function sanitizeTweet(tweet: Tweet): Tweet {
+  const entities = tweet.entities ?? ({} as Tweet["entities"]);
+  return {
+    ...tweet,
+    entities: {
+      ...entities,
+      hashtags: entities.hashtags ?? [],
+      user_mentions: entities.user_mentions ?? [],
+      urls: entities.urls ?? [],
+      symbols: entities.symbols ?? [],
+    },
+  };
+}
+
+async function TweetCard({ tweetId }: { tweetId: string }) {
+  let tweet: Tweet | undefined;
+  try {
+    tweet = await getTweet(tweetId);
+  } catch {
+    tweet = undefined;
+  }
+
+  if (!tweet) {
+    return (
+      <a
+        href={`https://x.com/i/status/${tweetId}`}
+        target="_blank"
+        rel="noopener noreferrer"
+        className="block w-full rounded-xl border border-gray-200 bg-gray-50 p-6 text-center text-sm text-gray-600 no-underline hover:border-gray-300 dark:border-gray-700 dark:bg-gray-900/40 dark:text-gray-300"
+      >
+        View this post on X →
+      </a>
+    );
+  }
+
+  return (
+    <TweetBoundary tweetId={tweetId}>
+      <EmbeddedTweet tweet={sanitizeTweet(tweet)} />
+    </TweetBoundary>
+  );
+}
+
+// Two-column layout that mirrors the Notion source: prose on one side and a
+// tweet on the other on wide screens, stacked (prose first, tweet below) on
+// mobile. `side` controls which side the tweet sits on at desktop width.
+//
+// DOM order is always prose-then-tweet so the mobile (single-column) stack
+// reads prose first; `md:flex-row-reverse` flips the visual order on desktop
+// when the tweet should sit on the left.
+// `md:items-start` top-aligns the prose with the tweet header rather than
+// vertically centering it against the (usually taller) embed.
+const wrapperBase = "flex flex-col gap-6 md:gap-10 my-10 md:items-start";
+
+export async function TweetColumns({
+  tweetId,
+  side = "right",
+  children,
+}: {
+  tweetId: string;
+  side?: "left" | "right";
+  children: ReactNode;
+}) {
+  const direction = side === "left" ? "md:flex-row-reverse" : "md:flex-row";
+
+  return (
+    <div className={`${wrapperBase} ${direction}`}>
+      <div className="flex-1 min-w-0 [&>p:first-child]:mt-0 [&>p:last-child]:mb-0">
+        {children}
+      </div>
+      <div
+        className="w-full md:w-[360px] md:shrink-0 flex justify-center [&_.react-tweet-theme]:!my-0"
+        style={{ "--tweet-container-margin": "0" } as CSSProperties}
+      >
+        {isTweetId(tweetId) ? (
+          <TweetCard tweetId={tweetId} />
+        ) : (
+          <div className="w-full rounded-xl border border-dashed border-gray-300 bg-gray-50 p-6 text-center text-sm text-gray-500 dark:border-gray-700 dark:bg-gray-900/40 dark:text-gray-400">
+            Tweet embed pending — set <code>tweetId</code> to <code>{tweetId}</code>
+          </div>
+        )}
+      </div>
+    </div>
+  );
+}

apps/blog/src/mdx-components.tsx

@@ -28,6 +28,7 @@ import {
 } from "@prisma/eclipse";
 import { Youtube } from "@prisma-docs/ui/components/youtube";
 import { TweetEmbedComp } from "@/components/TweetEmbed";
+import { TweetColumns } from "@/components/TweetColumns";
 import { Meetup, MeetupList } from "@/components/Meetup";
 import { Employee } from "@/components/Employee";
 import { AutoplayYoutubeEmbed } from "@/components/AutoplayYoutubeEmbed";
@@ -57,6 +58,7 @@ export function getMDXComponents(components?: MDXComponents): MDXComponents {
     CodeBlockTabsTrigger,
     CodeBlockTab,
     TweetEmbedComp,
+    TweetColumns,
     Youtube,
     Meetup,
     MeetupList,