Preview web apps live as your coding agent builds them with Amazon Bedrock AgentCore runtime

Coding agents now build working web apps: a dashboard, a product page, a prototype that a product team wants to try. The fastest way to review that work is to open the app, use it, ask for a change, and check the result. That loop works well when the app keeps running where the agent edits it, so each change shows up in the browser within seconds. When the app must be copied out and deployed somewhere else first, every change waits for a deployment, and the review slows down to that pace. Amazon Bedrock AgentCore is a platform to build, connect, and optimize agents at scale, with your choice of agent framework and foundation model (FM). AgentCore runtime , a capability of Amazon Bedrock AgentCore, runs each agent session in its own isolated microVM. With Session endpoints , you can open an app running in that session from your own browser. Session Endpoints give each session an authenticated URL that forwards each request’s HTTP method, path, query string, and body, and WebSocket connections, to the ports you allow. You can watch the page update as the agent saves each file. In this post, you deploy a coding agent that keeps a Vite website running in its session, then open one local page with a chat on the left and the live website on the right. You ask the agent to switch the site to a dark color theme, follow its steps as they stream in, and watch the website change without a refresh. Finally, you look at what happens internally: a second port in the same session, and the requests the Session endpoint refuses. The complete sample, including the notebook this post follows, is in the 14-remote-access folder of the agentcore-samples GitHub repo . How Session endpoints work Each session gets its own Session endpoint, and six details shape how you use it. You choose which ports it reaches. You set allowedPorts when you call CreateAgentRuntime : 1–5 entries, each a single port or a range within 8000–12000, excluding the reserved platform ports . Allowing a port doesn’t start a server, so your application must listen on it, bound to 0.0.0.0 . The URL arrives with the session. The InvokeAgentRuntime response carries it in the X-Amzn-Bedrock-AgentCore-Runtime-Session-Endpoint-Url header, which SDKs that model it expose as sessionEndpointUrl . Every request is authenticated. For a runtime that uses AWS Identity and Access Management (IAM) , each HTTP request, HTTP/2 stream, and WebSocket handshake carries a Signature Version 4 (SigV4) signature. The caller also needs bedrock-agentcore:InvokeAgentRuntimeProxy on the runtime and its runtime endpoint. For a runtime with an inbound JSON Web Token (JWT) authorizer , each request carries a bearer token instead. Knowing the URL doesn’t grant access. The host name selects the port. Your client connects on port 443 regardless of the target port, and a prefix on the host name chooses the port inside the session: https://8090-- .runtime.bedrock-agentcore. .on.aws/index.html https://8081-- .runtime.bedrock-agentcore. .on.aws/status It carries the protocols your server speaks. HTTP/1.1 and HTTP/2 requests, including server-sent events and gRPC, and WebSocket connections all pass through. This walkthrough uses HTTP/1.1 and WebSocket. It’s scoped to one session. The URL needs credentials on every request and lasts only as long as the session, so use it to build, test, and review what your agent produces. To serve an app to your users, deploy it to a hosting service such as AWS Amplify Hosting . A browser can’t add a SigV4 signature or a bearer token to the requests a page makes on its own, so the Session endpoint client in the bedrock-agentcore SDK can open a local endpoint on your machine. Your browser opens http://localhost:8088 , and the local endpoint adds your credentials to each request and WebSocket handshake before forwarding it. A Session endpoint is different from a runtime endpoint , which AgentCore runtime already provides. Use a runtime endpoint, such as DEFAULT , to reach your agent, which controls which version of it callers will reach. InvokeAgentRuntime calls resolve through it, so you can keep development and production on different versions and promote or roll back without changing callers. Use a Session endpoint to see what your agent runs in its session, such as a web preview. It’s an authenticated URL that reaches only the ports you allow, works with whichever version the session runs, and stops working when the session ends. For complete documentation, refer to Connect to runtime sessions through a session endpoint . Solution overview The sample has four parts. A coding agent runs in the session on port 8080 and edits the website’s files with four tools: list, read, write, and edit. The agent starts a Vite development server on port 8090, which serves the website and pushes each saved change to the browser over its hot-reload WebSocket. On your machine, PreviewApp serves the preview page, sends your prompts to InvokeAgentRuntime , and opens a local endpoint for the website. As Figure 1 shows, the preview page loads the website from the Vite development server on port 8090 through the local endpoint and the Session endpoint, and sends your prompts through InvokeAgentRuntime to the agent on port 8080. The numbers show the order of the steps for one request. Figure 1: Solution architecture Before step 1, PreviewApp has already called InvokeAgentRuntime once to start the session, which starts the agent and the Vite development server. PreviewApp read the Session endpoint URL from that response and opened a local endpoint for port 8090. The numbered steps in Figure 1 then follow one request for a change: The site pane of the preview page loads the website from the local endpoint on localhost:8088 . The local endpoint adds your credentials to each request and the WebSocket handshake, and forwards them to the Session endpoint. The Session endpoint checks the signature and the port against allowedPorts , then forwards them to the Vite development server on port 8090. The page keeps the Vite hot-reload WebSocket open. You send a prompt from the chat pane. PreviewApp sends it to InvokeAgentRuntime as a standard AWS API call signed with your AWS credentials, and the runtime delivers it to the agent on port 8080. The agent’s steps stream back to the chat pane as it works. The agent calls Claude Haiku 5.5 in Amazon Bedrock to decide what to change. The agent reads the site’s files and saves the ones it changes. The Vite development server serves those files and watches them for changes. When a file is saved, Vite pushes the change over the WebSocket opened in step 1, back through the Session endpoint and the local endpoint, and the site pane updates without a refresh. From the notebook, PreviewApp reads the agent’s /status route on port 8081 through the same Session endpoint. Only the port changes. Port 8080 isn’t in allowedPorts , because InvokeAgentRuntime reaches the agent without going through the Session endpoint. Prerequisites To follow the walkthrough, you need: An AWS account in an AWS Region where AgentCore runtime Session endpoints are available, with credentials configured. Permissions to create an AWS Identity and Access Management (IAM) role, upload to Amazon Simple Storage Service (Amazon S3) , and create a runtime, plus bedrock-agentcore:InvokeAgentRuntime and bedrock-agentcore:InvokeAgentRuntimeProxy on that runtime and its DEFAULT runtime endpoint. For details, refer to IAM permissions for AgentCore runtime . Python 3.10 or later, with bedrock-agentcore 1.25.2 or later and boto3 1.43.122 or later. Git , to clone the sample repo, and a Jupyter environment, such as JupyterLab or Visual Studio Code with the Jupyter extension, to run the notebook. Access to Claude Haiku 5.5 in Amazon Bedrock. For model availability by Region, refer to Regional availability by models . Node.js 22 or later with npm , which the deployment script uses to package the agent and the website. The sample deploys the agent a