Forward-Deployed Engineer

Vercel Services turns full-stack deployment into a service graph. July 6, 2026 Most products feel like one app to users. Inside the repo, they are often a Next.js frontend, a Python API, a Go worker, a Hono edge service, cron jobs, queues, and a few internal services. Splitting code is not the problem. The problem starts when deployments, previews, rollbacks, logs, and internal calls are owned by different systems, so operational judgment becomes slow and blurry. What happened. On June 30, 2026, Vercel announced Vercel Services. The changelog and launch post describe a model where multiple frontends and backends can live inside one Vercel Project, share a domain, build together, preview together, and roll back together. The configuration center is the services key in vercel.json. Each service can define values such as root, framework, entrypoint, runtime, and bindings. Public traffic only reaches a service when a top-level rewrite routes to it. A service without a public rewrite is not directly reachable from the internet. The second key piece is service binding. A binding lets server-side code in one service call another service without exposing the target service publicly. Vercel generates the URL and grants reachability, and the generated URL is deployment-aware, so a preview service calls the matching service inside the same preview deployment. Why this matters. Vercel Services is more than "you can run a backend on Vercel." Many teams already split their system across Vercel for the frontend, another host for APIs, another runtime for workers, and GitHub Actions for scheduled work. That can be flexible, but the product change stops being atomic when preview and rollback boundaries are split. Services redefine the deployment unit as a service graph rather than a repository folder or a single framework app. If frontend and backend changes build together, appear in the same preview, and roll back together, reviewers can answer a practical question: was this UI change validated against the API change it depends on? vercel.json therefore becomes more than deployment decoration. It now declares which services are public entry points, which are internal-only, which roots build under which runtimes, and which services may call each other. Code review needs to include services, rewrites, and bindings diffs, not only application code. Community signal. Next.js developers have debated separate backend servers versus Vercel-hosted backend patterns for years. Reddit discussions around separate backends mention timeouts, cold starts, database pooling, WebSocket support, cron, and platform fit. Those posts are not factual sources for Vercel Services, but they are useful signals about the friction developers want solved. There is also an opposite signal. Hacker News discussions around Vercel platform trust and past security incidents show a recurring concern: when CI, deployments, secrets, developer tooling, and runtime control concentrate in one platform, the trust boundary becomes more important. The pragmatic question is not whether Vercel Services is good or bad. It is which service boundaries benefit from one deployment graph, and which boundaries still deserve a separate platform, account, or blast radius. Engineering and operations impact. The first impact is preview quality. If frontend and backend services share a preview deployment, API contract changes, UI changes, and worker changes can be tested from one environment. But more services also mean preview data, migrations, seed state, and external credentials need stricter rules. The second impact is routing ownership. Vercel's Services routing docs say top-level rewrites own public traffic. Requests route to the first matching service and do not fall through to another top-level rewrite if the selected service returns not found. Rule order becomes an operations concern, especially with /api/(.*) and catch-all routes. The third impact is private communication. Bindings reduce public exposure, but they do not replace authentication. The docs explicitly note that application-level authorization remains the service code's responsibility. Internal URLs are not the same thing as trust. The fourth impact is cost visibility. Services pricing treats service-to-service calls as service requests, separate from public internet requests. Teams need to understand how many internal calls a user request creates, because fan-out affects both latency and cost. The fifth impact is local development. The docs say vercel dev runs services together and injects generated binding environment variables. That can make local work more production-like, but service startup time and dependency orchestration become part of developer experience. A practical checklist. 1. Draw service boundaries by rollback and failure domain, not only by folder structure. If two pieces must roll back together, they likely belong in the same graph. 2. Review every public ingress rule in top-level rewrites. Keep catch-all rules last and test which service receives /api/(.*), static paths, and unknown routes. 3. Use bindings instead of hardcoded internal hostnames. Then add application-level auth anyway, because binding grants reachability, not user or service authorization. 4. Add services, rewrites, bindings, runtime, and entrypoint changes to your PR checklist. Platform diffs need the same review discipline as code diffs. 5. Define preview data rules. A shared preview is only useful if migrations, seed data, external tokens, and test users match the services being validated. 6. Observe service-to-service fan-out. One user request that triggers many internal calls can quietly increase latency and cost. 7. Treat Services as beta. Before moving core production workloads, rehearse routing, binding behavior, logs, rollback, local dev, and cost reporting on a non-critical path. Risks and counterarguments. The first risk is platform concentration. Putting frontend, backend, workers, and internal services under one project can simplify operations, but it also makes account access, secret policy, and platform availability more consequential. Some systems should stay in a separate account, project, or cloud. The second risk is confusing network privacy with authorization. A binding keeps a service off the public internet, which is useful. It does not verify tenant, role, job source, replay protection, or business permission. The third risk is cost surprise. Active CPU and service-request billing can be efficient for some workloads and awkward for others. High fan-out APIs, long-running workers, WebSockets, and container services need real usage modeling. A fair counterargument is that teams already running Kubernetes, Fly Machines, Cloud Run, or ECS may not need this. Services are most compelling for teams that want full-stack changes to live inside Vercel's preview, domain, and deployment workflow without splitting every backend into another control plane. Vercel Services adoption checklist. - 1. Draw service boundaries by rollback and failure domain, not only by folder structure. If two pieces must roll back together, they likely belong in the same graph. Bottom line. Vercel Services is not just a frontend platform adding backend support. It turns vercel.json into an operating contract for a service graph. Before adopting it, teams should inspect public rewrites, internal bindings, rollback units, cost fan-out, and authorization boundaries. Used well, it makes previews and rollbacks clearer. Used casually, it hides too much operational responsibility in one configuration file.

Vercel releases WebSockets in Functions (public beta). Vercel announced native support for WebSockets in Functions. Discover how to build real-time applications with no extra costs for idle time. June 30, 2026 The evolution of real-time in the serverless ecosystem. On June 22, 2026, Vercel made a highly anticipated announcement for the web development community: Vercel Functions now support WebSocket connections in a public beta. This news marks a turning point for those building modern applications, as it enables continuous bidirectional communication between client and server in a native and highly optimized way. Until now, maintaining persistent connections in traditional serverless environments has always been a major technical and financial challenge for engineering teams. With this update, the landscape changes completely. WebSockets support was designed to facilitate the creation of real-time features, such as interactive AI streaming, complex chat systems, and collaborative applications where multiple users interact simultaneously. And the best part: all of this without sacrificing the structural simplicity and scalability that made the platform so popular among developers worldwide. Key highlights of this announcement: * Official Launch: Public beta formally announced on June 22, 2026. * Bidirectional Communication: Ideal for chats, AI streaming, and real-time collaboration. * Node.js Compatibility: Works with standard libraries, including ws and Socket.IO, with no extra configuration. * Cost-Effectiveness: Active CPU pricing model ensures that idle connection time is not charged at all. * Base Infrastructure: The entire system is based on Vercel's robust Fluid compute technology. What changes with Bidirectional Communication? To understand the real impact of this Vercel announcement, Lee Sugano need to look at the historical limitations of serverless architectures. The request-response pattern of the HTTP protocol works perfectly for fetching static data or performing one-off database operations. However, when Lee Sugano talk about interactive experiences, such as a live chat or real-time AI text generation, the client needs to receive updates from the server without having to repeatedly ask if there is something new available. This is exactly where WebSockets shine in modern architecture. They establish a continuous two-way tunnel, where both the user's browser and the remote server can send messages at any time, completely asynchronously. With the public beta of WebSockets support in Vercel Functions, software engineers gain the ability to implement these connections seamlessly and directly. The immediate result is much more responsive interfaces and incredibly richer user experiences. Collaborative applications, such as simultaneous text editors or corporate virtual whiteboards, also benefit immensely from this new capability. Latency is drastically reduced, and state synchronization between different clients becomes much more natural and efficient for the development team to maintain in the long run. The fundamental role in AI streaming. With the exponential rise of AI-based tools, the need for fluid responses has become a mandatory user requirement. When a complex AI model generates a long text, making the user wait for the full completion of processing to display the final response creates a negative perception of slowness. Interactive AI streaming solves this by delivering chunks of the response as they are generated by the underlying model. While there are other techniques to perform this streaming, such as Server-Sent Events, WebSockets offer a much higher level of precise control and bidirectional interactivity. The user can, for example, immediately interrupt generation by sending a command through the same communication channel, or send new contextual parameters while the AI is still processing. With Vercel's new support, building these highly reactive conversational AI experiences becomes a standardized and native process. Fluid compute infrastructure and compatibility. One of the biggest fears when adopting new features in managed cloud platforms is the associated learning curve or the imminent need to refactor large parts of legacy code. Fortunately, Vercel's approach was carefully designed to eliminate this initial friction. The new WebSocket support runs directly on the modern infrastructure known as Fluid compute. This robust technological foundation ensures that connections are maintained in an incredibly stable and perfectly scalable manner. In addition, the integration is incredibly friendly for the entire existing developer ecosystem. Vercel Functions now work seamlessly with consolidated standard Node.js libraries, such as the highly popular ws library. If your technical team prefers to work with higher-level tools and more robust abstractions to make daily work easier, the widely used Socket.IO is also fully supported from day one. The major competitive advantage of this update is the complete absence of complex additional configurations. You can simply bring your existing Node.js code that already uses WebSockets and it will work seamlessly on Vercel Functions. It is worth highlighting an important technical detail: once the connection is successfully established, it remains pinned to a specific Function for its maximum allowed duration. WebSocket connections are strictly subject to the same operational limits as other traditional Function invocations on the platform. Therefore, careful architectural planning still requires attention to the maximum execution times allowed by your specific plan on Vercel. Smart pricing: the Active CPU pricing model. The financial aspect of keeping connections constantly open has always been the true Achilles' heel of WebSockets in purely serverless environments. Traditionally, if a function remains active in memory just waiting for new messages, the cloud provider charges for every millisecond of that time, even if absolutely no useful data is traveling over the network. This logic made many small and medium-sized projects economically unviable. Vercel brilliantly solved this huge problem by applying its modern Active CPU pricing model. In this innovative billing format, purely idle connection time is not billed at all. The customer pays strictly for the actual message processing time. If a user leaves a chat tab open in the browser and goes to grab a coffee, the WebSocket connection remains perfectly active and stable, but your company's bill suffers no financial impact from this prolonged idle time. This pragmatic shift in the financial rules of the game democratizes access to high-quality real-time technologies. Early-stage startups and independent developers can now experiment with and scale advanced features without the constant fear of unpleasant surprises on their end-of-month bill. The final billing follows exactly the same limits and normal prices already known for Vercel Functions, thus ensuring complete budget predictability. Maintaining connection state with Redis. Although the WebSocket connection remains pinned to a single Function throughout its active lifecycle, real-world applications generally need to handle thousands of multiple users connected to different instances simultaneously. For example, if a user sends a new message in a public chat room, another user, who might be connected to a completely different Function in another region, needs to receive this update instantly. To orchestrate this complex communication between different instances and maintain the application state in a perfectly consistent manner, the architecture requires an extremely fast and reliable intermediary. Vercel's official recommendation for this scenario is to use Redis. As an in-memory database with extremely high performance and low latency, Redis acts as the ideal tool to function as an efficient message broker or a modern Publish/Subscribe system. Redis is easily available to all users directly in Vercel's own Marketplace, which further simplifies the arduous process of infrastructure configuration. By properly integrating Functions with Redis, you are guaranteed that all events generated in an isolated connection are quickly propagated to all other relevant connections. This keeps the global state of your web application always synchronized in milliseconds, regardless of the volume or total size of your connected user base at that moment. Conclusion. The announcement made on June 22, 2026, definitively solidifies Vercel not only as an excellent platform for hosting conventional static sites or server-side rendering frameworks, but as a robust, complete ecosystem for building complex applications. The long-awaited native support for WebSocket connections in public beta once and for all eliminates the historical barriers of modern web development. With the perfect union of cutting-edge Fluid compute infrastructure, full compatibility with traditional Node.js libraries like ws and Socket.IO, and an extremely fair billing model based on active CPU usage, creating excellent interactive products has become much more accessible for teams of all sizes. Whether you are developing the next big generative AI streaming app, a sophisticated corporate collaboration system, or just dynamic real-time chats, Vercel Functions now offer all the powerful tools needed to elevate the technical level of your project. Was this content useful? Sobre a lee Sugano. Lee Sugano Agência de soluções digitais com base no Japão e clientes em mais de 10 países. Compartilhamos insights sobre desenvolvimento, design e marketing digital para empresas que não aceitam genérico. Enjoyed this content? Receive exclusive insights about web development, design, and digital marketing straight to your inbox. No spam. Unsubscribe anytime.

Turbopack: what's new in Next.js 16.3. As the Next.js 16.3 Preview nears a stable release, Vercel, Inc. is sharing a series of posts about what's inside. Its previous posts cover new Instant Navigation features and the latest AI improvements. This third post details the latest improvements to the Turbopack bundler within Next.js. With Next.js 16.3, Turbopack's latest stable release focuses on compiler performance. Many of the newest features are centered around reducing CPU and Memory usage, speeding up build times, and improving runtime experience. * Reducing dev server memory usage by up to 90% * Persistent file system cache for faster builds * Experimental Rust React Compiler support * import.meta.glob API support * Faster HMR and dev startup Reducing memory usage in dev mode. Turbopack's core design is focused on incremental compilation. By caching the work it previously did, it avoids recompiling files that haven't changed. When developing large Next.js applications, this means compile time is proportional to the size of your changes, not the size of your route. In pursuing this design, Vercel, Inc. made a very deliberate trade-off: caching more results in memory, for reduced CPU usage. Since Turbopack first launched, though, memory usage has been at a premium. Coding agents, IDEs, typecheckers, and linters all run at dev time, and each consumes a significant chunk of system memory. Over the last three months, the Turbopack team has been committed to reducing its contribution to system memory pressure. With an upgrade to 16.3, developers should immediately see less memory usage for long-running dev sessions. Memory usage after compiling 50 routes vercel.com (dashboard) ~90% smaller nextjs.org ~82% smaller Much of this was achieved through small incremental wins: compressing data structures and avoiding storing data longer than was necessary. The biggest win, though, comes from a new ability to evict much of the in-memory cache. Leveraging the file-system persistence feature that was first introduced in Next.js 16.1, Turbopack is able to remove cached results from memory. This avoids unbounded growth of memory in dev sessions, since the memory cache no longer holds onto every visited route. Memory eviction requires the development filesystem cache to be enabled. In 16.3, both of these options are on by default. It can be disabled when investigating cache or development performance with the experimental turbopackMemoryEviction config value: const nextConfig = {experimental: { turbopackMemoryEviction: false, // disables memory eviction, default value is 'full'},}; There is no single reduction percentage that applies to every application. Individual results depend on the size of the route graph, how much of it was touched during the development session, and how long the session was running. File System cache for builds. Persisting the Turbopack memory cache to disk has been speeding up next dev sessions since the 16.1 release. After months of hardening in production with Vercel's own sites, the same persisted cache is now available for next build. Turbopack compile time for next build nextjs.org ~2.3x faster vercel.com/home ~1.4x faster vercel.com/geist ~5.5x faster With persistent disk cache, builds can take advantage of previously computed work and reduce the time it takes to compile your static assets. CI setups can take advantage of this by copying the generated .next directory from one run to the next. When Turbopack sees the cache at the start of a build, it reads entries from disk before compiling any new changes. const nextConfig = {experimental: { // Enable filesystem caching for `next build` turbopackFileSystemCacheForBuild: true,}} Experimental Rust React compiler. Next.js has provided stable support for the React Compiler since the first 16.0 release. Until now, the React Compiler has only been available as a Babel transform. On larger applications, Vercel, Inc. observed that it could slow down builds while waiting for JS execution resources. Recently, the React team published a native Rust port of the compiler, which Vercel, Inc. were quick to integrate into Turbopack. Promising early tests against large React apps like v0 showed compilation wins of 20-50%, so Vercel, Inc. is releasing the native compiler integration as an experimental feature to drive more adoption. To test out the Rust React Compiler, enable the compiler and use the experimental turbopackRustReactCompiler flag to use the native version: const nextConfig = {// enable the compiler reactCompiler: true, experimental: { // use the Rust version, instead of the OG Babel one turbopackRustReactCompiler: true,}} There are many ways to configure the React Compiler for features like opt-in functionality. You can read the full documentation for more details. Turbopack now supports the Vite-compatible import.meta.glob API: const posts = import.meta.glob('./posts/*.mdx'); This API can import all modules that match this pattern, without hardcoding their names. The result is an object keyed by the matching file paths. By default, each value is an async function that loads the module: for (const path in posts) {const post = await posts[path];} Use eager: true to import each match immediately: const posts = import.meta.glob('./posts/*.mdx', {eager: true,}) The implementation also supports named imports, multiple patterns, negative patterns, custom search path, query strings for loaders, and generated TypeScript types. This functionality is powered by Turbopack's file watcher. When a file is added to or removed from this match set, it will trigger recompilation in dev mode, so your site always reflects the latest changes. This API is perfect for fetching sets of similar documents, like product descriptions or blog posts. Vercel, Inc. also expect that library developers will benefit from this API existing across the broader JS ecosystem. import.meta.glob is available as a Turbopack feature, and will not work for Next.js apps built with the -webpack option. HMR improvements. By analyzing the performance of Turbopack in large Next.js apps at Vercel, Vercel, Inc. identified a number of performance improvements that could benefit all Turbopack users. Much of that investigation centered around making HMR subscriptions more efficient. One significant change streamlined the tracking of chunks that are loaded on a page. By reducing multiple subscriptions to a single one, Vercel, Inc. were able to reduce dev server cold start by over 15% on complex apps. This is only the beginning of its HMR resource investigations, and Vercel, Inc. expect to deliver more memory and cold-start improvements in future Next.js releases. Smaller runtime size. Turbopack ships runtime code to every route that allows it to resolve modules and dynamically fetch new chunks. This also includes code for loading WebAssembly, workers, and top-level async modules. Not every Next.js application uses that functionality, though. Now Turbopack will only ship those features when they're needed, and avoids shipping extra runtime code the rest of the time. Local PostCSS configuration. Monorepos may need different PostCSS transforms for different packages. The experimental turbopackLocalPostcssConfig option lets Turbopack resolve the configuration closest to each CSS file before falling back to the project root: next.config.ts const nextConfig = {experimental: { turbopackLocalPostcssConfig: true,},}; This allows package-level CSS to use a local configuration while application CSS continues to use the root configuration. Compatibility and reliability. Next.js 16.3 rolls up all of the fixes from the 16.2 patch line and adds more improvements across module resolution, tracing, and HMR, including: * Correct file URLs for import.meta.url on Windows * Retry chunk fetching on failure * Better support for createRequire(new URL(..., import.meta.url)) * Correct worker_threads URL resolution * Support for the module-sync export condition * Better errors when webpack loaders crash * CSS HMR fixes in Safari