BRIEF DELIGHTS

💡 WHY THIS MATTERS FOR YOUR ROLE

To a user, an app with a Next.js frontend and a FastAPI backend feels like one product, and the same should be true for the engineers who build it. Instead, the two pieces are often deployed across different clouds with different development and deployment workflows.Today we're introducing Vercel Services in public beta, which lets you run multiple frameworks in one Vercel Project. This unlocks:Atomic deployments: Your frontend, backend, and other services stay in sync and deploy or roll back togetherShared preview deployments: See how any change affects all your servicesInternal service communication: Services can talk to each other without routing through the public InternetVercel handles the rest: routing, builds, deployments, and auto-scaling in production. The developer experience you already know from Vercel now covers your entire application.Compose applications with Vercel ServicesDeclare your services under the services key in vercel.json keeping the routing configuration explicit:Services can be mounted to a shared routing table without the need for a reverse proxy or CORS.The services configuration is recognized at multiple levels of the Vercel platform:The Deployments panel shows a visualization of services graphThe Logs UI allows filtering by individual serviceThe vercel dev CLI automatically runs all services giving you a production-like environment locallyService bindingsServices can talk to other services internally, without routing through the public Internet. Here's an example how the new bindings configuration key enables that:Now the JavaScript frontend code can talk to the Python service internally via the URL stored in the BACKEND_INTERNAL_URL environment variable:Service-to-service traffic stays on the Vercel network rather than egressing to the public internet. Many independent services can become one application connected by the same wiring, rather than separate deployments that you stitch together across hosts.Framework-defined infrastructureMost frameworks run on Vercel with zero configuration. Framework-defined infrastructure means that each service's framework is auto-detected and auto-provisioned, from FastAPI and Flask for Python to Express and Hono for TypeScript, with first-class support for Go and Rust servers.Services run on Fluid compute, autoscaling with traffic, while you pay only for active CPU time. But framework-defined optimizations go even deeper. With Django, for example, we automatically detect where static assets live and serve them from the CDN.The full stack platformVercel Services gives Vercel a structured way to build and run your application.Those services run on a platform that includes everything any backend could need, whether you're building APIs, agents, or background workers: compute, data, networking, background work, and secure connections to external services.Isolated compute for agent servicesAgents can read files, run commands, and write code. But that capability needs to be secure. Vercel Sandbox gives each agent its own Linux computer: a filesystem, a shell, Docker support, and its own kernel, completely isolated from your deployments. Agents can execute code, grep files, and spin up Redis or Postgres as dependencies. Nothing inside the sandbox can touch your production environment.With automatic persistence, state carries between sessions, and on Pro, sandboxes can run for up to 24 hours.Real-time backends with WebSocket supportVercel Functions handle persistent WebSocket connections in every Vercel runtime, whether your backend is written in Node.js, Python, or Go. They work with standard WebSocket libraries like Socket.IO, and because connections run on Fluid compute with Active CPU pricing, you only pay for the time spent processing messages, not the time a connection sits idle.Reach external services with Vercel ConnectAgents and backends need to reach services outside your project (Slack, GitHub, managed databases), which usually means storing a long-lived secret in your environment. Vercel Connect replaces that with a short-lived credential your app requests at runtime, scoped to the task in front of it. There is no long-lived secret left to leak.Databases and storage for your servicesYou can provision a database from the Vercel Marketplace in a few clicks, with credentials injected for you, from providers like Neon, Supabase, and from AWS with Aurora PostgreSQL, Aurora DSQL, and DynamoDB. Amazon OpenSearch Serverless adds full-text and vector search, and Vercel Blob handles object storage. You can query and manage any of it without leaving Vercel, and both Blob and the AWS integrations authenticate with short-lived OIDC tokens rather than stored secrets.Run durable workflows and background jobsVercel Queues processes background jobs off the request path. Vercel Workflow handles durable multi-step processes that survive crashes and redeploys. And Vercel Cron runs work on a schedule. This is the part of a backend that outlives a request, and it runs on the same platform as everything else, so the long-running side of your backend needs no separate infrastructure.Connect privately and run on the right computeWhen a backend needs to reach a private database or an internal network instead of a public service, Secure Compute, static IPs, and VPC peering open that path.Functions run for up to 30 minutes on Pro and Enterprise, and Python backends deploy with up to 500mb of dependencies.Underneath all of it, Fluid compute is the default for new projects, and Active CPU pricing bills for the time your code is actually running rather than the time it waits, the right shape for idle-heavy backend and AI work.A single platform for everything you shipVercel Services brings your frontend, backend, and supporting services into one project. They build together, preview together, deploy together, and communicate internally by default.Combined with Vercel's built-in primitives for compute, data, queues, workflows, cron, secure networking, and sandboxed agent environments, you can run the full stack without stitching together separate platforms.To start composing services, read the Vercel Services documentation and the routing and communication guide. If you are new to running a backend on Vercel, the zero-config backends post is the place to begin. Read more

💡 WHY THIS MATTERS FOR YOUR ROLE

Notion Workers let you write and deploy code to give Custom Agents new powers: sync external data, trigger automations, call any API. With Workers, developers can build agents that sync CRM data on a schedule, open issues when error rates spike, and turn Slack threads into formatted content. Under the hood, every Worker runs on Vercel Sandbox.The problem: safely running code from any developer or agentNotion wanted to let anyone extend their platform with custom code. That's a hard infrastructure problem, but an even bigger security problem. Every Notion Worker runs arbitrary code generated by a third-party developer or agent, on behalf of a Notion user, potentially inside an enterprise workspace.Without proper isolation, a Worker would run in the same environment as the Custom Agent, with access to its secrets, permissions, and everything else in that execution context. A single prompt injection could exfiltrate credentials or access another user's data.The requirements were clear:Hard isolation: One Notion Worker can never access another's data or stateCredential security: Notion Workers need API keys to talk to external services, but those secrets can never be exposed to the code itselfNetwork controls: Enterprise customers need guarantees about the external services a Worker is allowed to reachScale: Workers need to support millions of users running concurrent executions without performance degradationState preservation: Workers need fast cold starts, which require the ability to snapshot and restore filesystem stateEconomics: A billing model that is built for agents with low CPU utilization ratesWhy Vercel SandboxVercel Sandbox runs each Notion Worker in an ephemeral Firecracker microVM. Every VM boots its own kernel, providing stronger isolation than containers. Each execution gets its own filesystem, its own network stack, and its own security boundary. When the Notion Worker finishes, the microVM is either destroyed or snapshotted for later retrieval.To support workloads like Notion Workers at scale, Vercel Sandbox provides several critical capabilities:Credential injection. Sandbox's firewall proxy can intercept and inject API keys into outbound requests at the network level, so credentials never enter the execution environment. For agent-driven workloads, this eliminates the most dangerous prompt injection vector: an agent being tricked into exfiltrating secrets. (We wrote about this architecture in depth in security boundaries in agentic architectures).Network policies. Sandbox supports dynamic network policies that can be updated during runtime without restarting the process: start with internet access to install dependencies, then lock down egress before running untrusted code. Platform builders can pass these controls through to their own customers.Snapshots. Install dependencies once, snapshot the filesystem state, and resume from that snapshot on subsequent invocations. Combined with active-CPU billing, where CPU costs only accrue when your code is actually executing, not waiting on I/O, this keeps costs predictable as usage scales.The bigger picture: Notion as a developer platformNotion Workers isn't a one-off feature. It's the beginning of Notion becoming a developer platform.This shift requires infrastructure that Notion shouldn't have to build. Secure code execution, credential management, network isolation, file-sytem based snapshotting: these are hard problems that compound as the platform scales. Vercel Sandbox handles the infrastructure complexity so Notion can focus on the developer experience. What developers are building with Notion WorkersNotion Workers support three main patterns: third-party data syncing, custom automations, and AI agent tools. Developers use them to sync external data, such as CRM records, analytics, and support tickets, into Notion on a schedule. A Worker can also be attached to a button, triggering arbitrary code with a single click. And when Notion's custom agents invoke Workers as tool calls, they become far more capable than agents limited to pre-built integrations.Extend your platform with Vercel SandboxNotion Workers requires the same capabilities as other agent platforms. Any platform that wants to let users or agents run custom code faces the same set of problems: isolation, credential security, network controls, and scale.Vercel Sandbox provides these as capabilities out of the box. If you're building a platform that needs to run untrusted code, whether for AI agents, developer plugins, or workflow automation, then this is how you do it. Read more

💡 WHY THIS MATTERS FOR YOUR ROLE

The best way to learn is by shipping product to users in production, and that's why we don’t treat our interns as temporary guests. Every intern at Vercel is expected to operate like a core part of our engineering team from day one.This past winter, we welcomed a small cohort of those interns to our headquarters in San Francisco. Over an intense four months, they contributed to some of our most important products: the CDN, v0, financial infrastructure, AI Gateway, and more. They shipped features used by millions, helped close the gap for enterprise deals, and in more than a few cases, left a mark that will outlast their time here.Meet the Winter '26 intern cohortYash Kothari, CDN TeamUniversity of WaterlooWhat Yash shipped:Yash's internship spanned the full CDN stack, from infrastructure to CLI to UI in the dashboard.His first major project was Project-level routing, which is part of the new CDN tab in the Vercel dashboard. This feature lets customers update routing rules, including redirects, rewrites, and header transforms, from the dashboard, API, CLI, or SDK, without needing to redeploy their project or touch a single line of code. Yash built the underlying API endpoints (including a staging/publish workflow), the vercel routes CLI commands, and contributed AI-powered route generation. Right after launch, hundreds of teams immediately adopted it and created thousands of rules."One of my favorite things about my internship was that at Vercel you get a lot of autonomy and ownership," Yash said. "I hopped on calls with enterprise customers, saw my work featured on Vercel's changelog, and demoed my work in a live YouTube community session." In the second half of his internship, Yash worked on Vercel's Firewall and Security products. He shipped the vercel firewall CLI command, enabling users and AI agents to configure custom rules, IP blocks, and firewall controls directly from the terminal. He also built an AI-powered Firewall Rule Builder that lets users describe a desired rule in natural language and generates a WAF custom rule automatically.Kavin Valli, v0 TeamUniversity of WaterlooWhat Kavin shipped:Kavin worked across the full v0 platform over four months, taking on projects that ranged from user-facing features to cost efficiency for the system’s backend infrastructure.He started by building Folders and v0 Projects end-to-end: core CRUD operations, a library page redesign, favoriting, visibility controls (private/team/public), and folder sharing. He also closed a critical gap in v0's version history by shipping the manual commit button, which ensured that manual edits in the VM editor properly created commits and blocks, which closed the loop between manual edits and v0's iteration model.His highest-leverage work came later in the term, when he focused on VM and sandbox infrastructure. By splitting VMs into tiered pools and routing smaller projects to a cost-efficient default pool, Kavin significantly reduced memory usage and infrastructure cost for roughly 80% of sandboxes."I worked on v0 and got thrown into the deep end pretty quickly, especially around the v1 launch," remembered Kavin. "It was a bit chaotic at times, but that's something I actually enjoyed."His final and most involved project was taking ownership of the v0 Slack agent. He shipped Slack preview deployments for safe testing, rebuilt the router agent with improved thread history and SAML re-auth resume, redesigned project context tracking, and built out the full PR flow including v0 labels, Slack thread links, and merged/closed state tracking. The result was an agent that went from rough around the edges to something teams can genuinely rely on.Mingchung Xia, Financial Infrastructure TeamUniversity of WaterlooWhat Mingchung shipped:Mingchung pushed over 250 PRs in four months and became one of the top contributors on Vercel's central control systems monorepo.His most externally visible project was the v1/billing/charges API endpoint and the vercel usage CLI command, which let users view their usage and costs in the standardized FOCUS v1.3 FinOps format. Originally scoped as a full-internship project, Mingchung completed it early and expanded its scope into a joint launch with Vantage. The work was subsequently adopted by Meta, Notion, Porsche, and other prominent companies to analyze their Vercel spend in a modern, compliant format.His most technically complex project was designing and building Vercel's core entitlements system, which is the infrastructure that enables granting, revoking, and provisioning entitlements across project-based monetization, add-ons, enterprise, and marketplace work streams. The system architecture incorporated strong and eventual consistency guarantees, async and synchronous derivations, transactional outboxing, write-ahead logs, plan change manifests, stale-validation sentinels, and materializations. It was rolled out to production and backfilled across all active subscriptions."Most companies don't give interns or even existing engineers the opportunity to touch payment systems or billing infrastructure, let alone own it end to end," explained Mingchung. "Correctness is imperative when you're working with money, and I got to experience that firsthand at Vercel."He finished his internship by shipping Vercel Buy, a new billing service supporting frictionless purchasing for agent credits, gateway credits, v0 credits, and pro subscriptions, complete with a CLI surface.Mingchung will be joining Vercel full-time on the Financial Infrastructure team after completing his degree.Kevin Thomas, v0 TeamUniversity of WaterlooWhat Kevin shipped:Kevin's work spanned ML infrastructure, enterprise features, reliability engineering, and incident response, often simultaneously.His most ambitious self-directed project was v0's auto model routing system: a full pipeline that automatically routes user prompts to the right model tier based on complexity. Kevin proposed the system, built the labeling pipeline, experimented with multiple classifier architectures (embedding-based MLP classifiers, TF-IDF baselines, fine-tuned TinyBERT), and integrated everything into TypeScript-only functions for production deployment. By launch, the system had processed over 1.4 million v0 messages and became the default for all non-enterprise users, reducing decision fatigue and latency for a very large share of v0's user base."From working on on-call incidents and vulnerabilities in month one to working directly with enterprise customers in April, I've gotten to work on an unusually wide range of meaningful problems," Kevin said at the end of his internship. In the latter half of his internship, Kevin focused on enterprise work, most notably the v0 × Snowflake integration. He built enterprise admin controls for model access, RBAC for team skill management, resolved issues in SAML and isolated tenant environments, and shipped the integration itself. This work directly unblocked enterprise customers, supported renewals, and addressed live customer issues.Kevin also served as a primary investigator for several incidents around signup, billing, auth, and account access, staying at the center of v0's reliability work throughout his term.Sylvie Zhang, AI Gateway TeamUniversity of PennsylvaniaWhat Sylvie shipped:Sylvie worked across the AI Gateway service, contributing to everything from database and backend logic to observability, the frontend, and documentation.Her first project was Price Strikethrough, surfacing provider MSRP as a strikethrough price alongside Gateway pricing, making provider discounts visible to end users. It touched the full stack and gave her a complete view of the AI Gateway product from the start."All that sounded daunting to a student like me with little experience," Sylvie said, "but it was the best learning experience I could have asked for." Her most impactful and technically demanding project was the AI SDK v5 → v6 endpoint migration for AI Gateway's OpenAI-compatible and Anthropic-compatible endpoints. As the AI provider landscape had grown significantly more complex since v5 was designed, maintaining the legacy version had become a bottleneck, especially for handling token usage granularity differences across providers. Sylvie led the migration with a disciplined approach: deep cross-provider knowledge to catch incorrect AI-generated assumptions, systematic multi-turn and cross-provider testing scripts, concurrency testing to surface race conditions, proactive customer communication, and a deliberate fallback strategy that left legacy code in place until the migration proved stable.The result was a cleaner, more maintainable Gateway service better equipped to handle the continued evolution of AI providers and models.Advice for future internsWe asked these interns to share their top advice for future cohorts.Take ownership from day oneVercel gives interns real autonomy, but that means it's on you to use it well. Don't wait to be assigned work. Take initiative, identify what needs to be done, and start shipping.Ask questionsEvery intern said the same thing: no one at Vercel makes you feel like a burden for asking. The team genuinely wants you to succeed, so use that to your advantage and ask.Work in publicShare your PRs in team channels. Post updates. Present at Demo Days. The feedback loop is fast, and the visibility helps you iterate and build trust faster.Talk to people outside your teamSome of the best conversations happen across team lines with engineers, designers, finance, and people in roles you've never considered. Go to the office. Grab lunch with someone new.Give yourself time to ramp upThe codebase, the culture, and the pace can be a lot at once. Don't rush. The first few weeks are for absorbing, not sprinting. Take time to ramp well, and you will be able to run fast.Apply to become a Vercel internThere are additional internship opportunities coming soon. If you want to join our next cohort, check our career site in September to apply. Read more

💡 WHY THIS MATTERS FOR YOUR ROLE

Giving your agents access to your tools, data, and services is what makes them useful. As agents perform deeper work across systems, authenticating and authorizing that access becomes central to your application architecture.Today, agent access is usually granted through long-lived provider tokens stored in your environment variables, provisioned for everything your agent might need. These tokens are shared across every user, never expire, and give your agent full reach across every task, no matter how small the job.A vault makes that token harder to steal. It doesn't make it less dangerous. The problem is what happens when the token leaks: everything it can touch is now exposed.We built Vercel Connect to solve this problem. Now in Public Beta, Vercel Connect replaces the stored token with runtime credential exchange. You register a connector once. When your agent has work to do, your app proves its identity to Vercel Connect and gets back a short-lived credential, scoped to the task. Everything you used the token for still works. The agent just requests access each time instead of holding it.Register a connector once, then reuse it across projects and environmentsA connector is a reusable connection between your Vercel team and a provider like Slack or GitHub. You create it once from the dashboard or the CLI, then attach it to the projects and environments that need it, with project-level access controls.The relationship with the provider becomes a single entity you can see and manage, not something scattered across a dozen environment variable panels where a rotation means hunting down every copy.Your coding agent can run this setup too. Install the vercel-connect skill with npx skills add vercel/vercel-plugin --skill vercel-connect, and it can create and attach connectors for you.Request scoped tokens at runtimeWith a connector in place, the agent asks for a credential only when it has work to do. The @vercel/connect SDK returns a token you use immediately against the provider API, and no provider secret lives in your app.Tokens are short-lived, with a lifetime that depends on the provider. The SDK refreshes them automatically, so you never rotate a secret by hand. That leaves one question. If your app holds no secret, what proves it's allowed to ask?The app proves its identity with OIDCThe proof is an identity your app already has. Every deployment on Vercel gets an OIDC identity, and when your app or agent requests a token, the SDK presents that identity to Vercel Connect. Vercel Connect verifies it, checks that the project and environment are allowed to use the connector, and returns the provider credential. That round trip is the runtime credential exchange.The same identity is available during local development through vercel link and vercel env pull, and outside Vercel, the SDK accepts a Vercel access token. Either way, there is no provider secret in your app to leak, commit, or copy between environments.Scope each token to exactly what the task needsNot every task needs the same reach, even within a single agent. One step might read a repository while the next opens an issue. Each requests exactly the access it needs, and the request itself sets limits. A request can include:Provider scopesAn installation IDResource restrictionsProvider-specific authorization detailsGitHub is the sharpest example because it can restrict a token to specific repositories and permissions.The deployment agent can read that one repository and do nothing else. A fine-grained GitHub App install can be narrow too, but an install is a standing grant, set up once and trusted from then on. This limit exists for one request, one task. Least privilege becomes the shape of the request.Act on behalf of a specific user, with per-user token scopingA shared bot token gives every user's request the same identity and reach. Vercel Connect lets you set that identity. Switch subject from the app to a named user, and the token acts on that user's behalf, scoped to what that user authorized.When a user first grants access, startAuthorization runs the consent flow through a callback URL, a webhook, or a device code. After that, the agent requests tokens as that user.Contain access by environment, and revoke it when you need toA connector is attached to the projects and environments you choose, so you can run a separate connector for development, preview, and production instead of pointing one at all three. When each environment has its own connector with an authorization grant and scopes, a credential compromised in development cannot be replayed against production.Separate connectors limit where a credential works, but they don't pull back access already issued. That's normally the painful part. With a stored token, that means a rotation. You mint a new secret, update every place the old one lived, and redeploy whatever depended on it. With Vercel Connect, you revoke the connector's tokens, either your own or all of them.What revoking does depends on the provider. Where the provider supports revocation, Vercel Connect revokes the token at the provider. Where it does not, Vercel Connect stops issuing new tokens for that grant, and a token already issued stays valid at the provider until it expires. That is a real limit on any provider without a revocation API, and the shorter the provider keeps its tokens, the smaller that window is.Drive event-driven agents from verified Slack triggersSo far, your agent has been the one reaching out. It requests a token and calls a service when it has work to do. Triggers run the other way. A connected service sends an event to your app, and your agent responds.Vercel Connect receives the provider's webhook, verifies it, and forwards it to your project. Trigger forwarding is in beta and supports Slack, GitHub, and Linear today. A Slack connector can forward its verified webhooks to up to three of your projects, so a message in Slack can wake an agent that acts on it.The flow runs end to end without a provider secret in your app:A user posts a message in Slack.Slack sends the event to Vercel Connect.Vercel Connect verifies the event against the Slack signing secret it holds, then forwards it to your Vercel app, re-attested with its OIDC identity.Your app verifies that attestation, then requests a scoped runtime token.The agent acts and responds.The Slack signing secret does not disappear. It moves server-side to Vercel Connect, which verifies the upstream webhook and re-signs the forwarded request with an identity your app can check. Your app holds no bot token to act with and no signing secret to verify against.Vercel Connect meets your code where it already isUnderneath everything is one call. Whether your agent is built on the AI SDK, runs as a background job, or is a loop you wrote yourself, it asks for a token the same way, with getToken. Around that call are adapters for the stack you already run. Better Auth (@vercel/connect/betterauth) and Auth.js (@vercel/connect/authjs) get provider configs in the shape they expect, and @vercel/connect/ai-sdk and @vercel/connect/mcp do the same for AI SDK tools and MCP clients. The Nuxt starter gives you a working app to build on, with GitHub and Linear connected, no provider secret, and no OAuth refresh token stored in its database.Frameworks can take this further and make the connection itself declarative. In eve, the open-source agent framework by Vercel, a connection is one file, and the @vercel/connect/eve adapter supplies that connection's credential.There is no token handling in the agent's code, because connect maps the consent flow, refresh, and error cases onto eve. Any MCP server that supports OAuth can become a connector by its URL, which is how mcp.linear.app ends up with the same scoped-token model as Slack or GitHub.The same adapter wires a Slack channel. One connectSlackCredentials call covers both directions: the bot credentials for sending and the webhook verification for receiving.The two secrets a Slack integration usually keeps in your environment, SLACK_BOT_TOKEN and SLACK_SIGNING_SECRET, are gone from your app. There is nothing left to provision, store, or rotate.Access becomes something you request, scoped to the taskAn agent becomes more useful the more it can reach, which is exactly why access is the part to get right. Every system the agent can touch is a system someone could reach through a leaked token. With runtime credential exchange, nothing is provisioned for everything. Nothing is shared by every user. Nothing lasts forever. Nothing reaches past the task in front of it.Credential management used to be architecture. It was rotation scripts, secrets copied between environments, and bot tokens broad enough that you hoped no one leaked them. Now you store none of it. You request access the moment the agent needs it, scoped to the task.Start building with Vercel ConnectRegister a connector, request your first runtime token, and connect an agent to Slack or GitHub without storing a provider secret.Coding agents just need a prompt:Frequently asked questionsWhat is Vercel Connect?Vercel Connect lets your agents and services access external systems on behalf of your users and teams. Instead of storing provider credentials in long-lived environment variables, you request user-authorized tokens at runtime with project-level access controls.What problem does Vercel Connect solve?It removes long-lived third-party secrets from your runtime while still letting agents act on external APIs. You register a connector for a provider, link it to projects and environments, and request provider tokens at runtime.When should I use Vercel Connect instead of Integrations?Use Vercel Integrations for marketplace-managed installs and provider-managed products in the Vercel Marketplace. Use Vercel Connect when you need delegated runtime credentials and user authorization for agent workflows, such as an agent that needs project-scoped access to a Slack workspace.Which connectors are available?Vercel Connect supports generic OAuth and API key connectors, as well as managed connectors for Slack, GitHub, Linear, and other platforms. It also includes support for 100+ preset connectors, such as Notion, Shopify, Resend, Sanity, and Workday.How does pricing work?Pricing is based on token requests. The Hobby plan includes 5K token requests per month at no additional cost. On Pro and Enterprise plans, token requests are billed at $3 per 10K token requests.What are the current Beta limitations?Trigger forwarding is limited to Slack, GitHub, and Linear, connector branding fields cannot be fully cleared after you set them, and token revocation, token lifetime, and scope granularity depend on provider support. Read more

💡 WHY THIS MATTERS FOR YOUR ROLE

Core web app decisions tend to center the backend, due to its complexity and impact over huge swaths of the business.However, frontends have grown far more important and complex in their own right. When not prioritized, the intricate infrastructure around them can quickly spin out of control, dragging teams into untold amounts of tech debt.As decoupled architecture becomes more common, developers are turning to the Frontend Cloud to automate away the behind-the-scenes hassles of creating and growing dynamic websites.Instead of managing infrastructure as a separate step of the development process, the Frontend Cloud provisions global infrastructure for you, based on your existing application code. This approach to web development massively increases developer velocity, allowing your team to experiment safely and meet shifting market demands. Teams of all sizes can effortlessly scale global apps while maintaining the highest possible bars for performance, personalization, and security.You can think of the backend cloud as your cost center and the Frontend Cloud as your profit center. Read more

💡 WHY THIS MATTERS FOR YOUR ROLE

Amazon EC2 R9g and R9gd instances powered by AWS Graviton5 are now generally available, delivering up to 25% better compute performance than R8g, ideal for databases, in-memory caches, and real-time analytics.