Use the Amazon Bedrock AgentCore runtime to preview web applications live as your coding agent builds them.

For developers building coding agents with Amazon Bedrock AgentCore, Session endpoints turn an agent's running web preview into a browser-accessible live workspace. The sample keeps a Vite website running on port 8090 inside an isolated session, lets a user send prompts from a chat pane, and updates the preview as the agent edits files, without a full deployment step.

Why the preview loop matters

Coding agents now build working web apps such as dashboards, product pages, and prototypes. The fastest review path is to open the app, use it, ask for a change, and check the result. That loop works when the app keeps running where the agent edits it, so changes appear in the browser within seconds. If the app must be copied out and deployed elsewhere, every change waits for deployment and review slows down.

Amazon Bedrock AgentCore is a platform to build, connect, and optimize agents at scale, using a chosen agent framework and foundation model. AgentCore runtime, a capability of Amazon Bedrock AgentCore, runs each agent session in its own isolated microVM. Session endpoints give each session an authenticated URL that forwards each request's HTTP method, path, query string, and body, and WebSocket connections, to allowed ports. A reviewer can watch the page update as the agent saves each file.

How Session endpoints reach the running app

Each session gets its own Session endpoint, and six details shape how it is used:

• Port choice: allowedPorts is set in CreateAgentRuntime and can contain 1 to 5 entries, each a single port or a range within 8000 to 12000, excluding reserved platform ports. Allowing a port does not start a server; the application must listen on it, bound to 0.0.0.0.
• URL delivery: the InvokeAgentRuntime response carries the endpoint in the X-Amzn-Bedrock-AgentCore-Runtime-Session-Endpoint-Url header, which compatible software development kits expose as sessionEndpointUrl.
• Authentication: every request is authenticated. For AWS Identity and Access Management runtimes, each HTTP request, HTTP/2 stream, and WebSocket handshake carries a Signature Version 4 signature, and the caller needs bedrock-agentcore:InvokeAgentRuntimeProxy on the runtime and its runtime endpoint. For inbound JSON Web Token authorizers, requests carry bearer tokens. Knowing the URL does not grant access.
• Port selection: clients connect on port 443, and a host-name prefix selects the session port. An 8090 prefix can reach index.html, while an 8081 prefix can reach /status.
• Protocol support: HTTP/1.1 and HTTP/2 requests, including server-sent events and gRPC, and WebSocket connections pass through. The sample uses HTTP/1.1 and WebSocket.
• Session scope: the URL needs credentials on every request and lasts only as long as the session. It is meant for building, testing, and reviewing agent output. To serve users, deploy the app to a hosting service such as AWS Amplify Hosting.

A browser cannot add a Signature Version 4 signature or a bearer token to page requests on its own, so the Session endpoint client in the bedrock-agentcore software development kit can open a local endpoint on the developer's machine. The browser opens http://localhost:8088, and the local endpoint adds credentials before forwarding requests and WebSocket handshakes.

A Session endpoint is different from a runtime endpoint, such as DEFAULT. A runtime endpoint reaches the agent and controls which version callers will reach; InvokeAgentRuntime calls resolve through it, allowing development and production versions to be promoted or rolled back without changing callers. A Session endpoint shows what the agent runs in its session, reaches only allowed ports, works with whichever version the session runs, and stops working when the session ends.

How to deploy and review the preview

The sample has four parts. A coding agent runs in the session on port 8080 and edits website 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. PreviewApp serves the preview page, sends prompts to InvokeAgentRuntime, and opens a local endpoint for the website. Before the first visible step, PreviewApp has already called InvokeAgentRuntime once to start the session, read the Session endpoint URL, and open a local endpoint for port 8090.

For one change request, the site pane loads the website from localhost:8088. The local endpoint adds credentials to each request and WebSocket handshake and forwards them to the Session endpoint. The Session endpoint checks the signature and port against allowedPorts, then forwards the request to port 8090. The page keeps the Vite hot-reload WebSocket open.

The reviewer sends a prompt from the chat pane. PreviewApp sends it to InvokeAgentRuntime as a standard AWS API call signed with AWS credentials, and the runtime delivers it to the agent on port 8080. The agent's steps stream back to the chat pane. The agent calls Claude Haiku 5.5 in Amazon Bedrock to decide what to change, reads the site's files, and saves the ones it changes. The Vite development server watches those files. When a file is saved, Vite pushes the change over the WebSocket, back through the Session endpoint and local endpoint, and the site pane updates without a refresh.

From the notebook, PreviewApp can also read the agent's /status route on port 8081 through the same Session endpoint. Only the port changes. Port 8080 is not in allowedPorts, because InvokeAgentRuntime reaches the agent without the Session endpoint, and the endpoint refuses that port.

To follow the walkthrough, a user needs an AWS account in a Region where AgentCore runtime Session endpoints are available, with credentials configured. Required permissions include creating an AWS Identity and Access Management role, uploading to Amazon Simple Storage Service, creating a runtime, and using bedrock-agentcore:InvokeAgentRuntime and bedrock-agentcore:InvokeAgentRuntimeProxy on that runtime and its DEFAULT runtime endpoint. The environment needs Python 3.10 or later, bedrock-agentcore 1.25.2 or later, boto3 1.43.122 or later, Git, a Jupyter environment such as JupyterLab or Visual Studio Code with the Jupyter extension, access to Claude Haiku 5.5 in Amazon Bedrock, and Node.js 22 or later with npm.

The sample deploys the agent as a zip file in Amazon S3 with direct code deployment for Node.js, so Docker or an Amazon Elastic Container Registry repository is not needed. Session endpoints work with microVM runtimes, not with the Instances compute type. Session endpoint URLs are reachable over public HTTPS, and AWS PrivateLink is not supported for inbound connections.

The deployment script bundles the agent into one file, adds the website and its dependencies for the runtime's Linux on Arm64 system, uploads the zip to Amazon S3, and creates the runtime. In deploy.py, agentRuntimeArtifact sets runtime NODE_22 and entryPoint app.js. protocolConfiguration sets serverProtocol HTTP, port 8080, and path /invocations. allowedPorts lists 8090 for the website and 8081 for the status route. The Vite configuration listens on 0.0.0.0 at port 8090 and leaves server.allowedHosts true, because requests arrive under a runtime-assigned host name rather than localhost. The Session endpoint authenticates each request before it reaches the server, so the server does not need its own host check.

1. Clone https://github.com/awslabs/agentcore-samples.git and change to agentcore-samples/01-features/02-host-your-agent/01-runtime/03-advanced/16-session-endpoints.
2. Open session_endpoints_preview.ipynb.
3. Run the install cell to install Python dependencies.
4. Run the %run deploy.py cell. Deployment takes a few minutes, mostly waiting for the runtime to reach READY status.

With the runtime ready, start PreviewApp. One call starts a session, opens a local endpoint for port 8090 to local_port 8088, and serves the preview page on localhost:8087. Open http://localhost:8087. The page shows the website on the right, served from port 8090 in the session, and a short guide with suggested requests on the left. 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.

Common mistakes and what changes

The most common setup mistake is treating allowedPorts as a server manager. Allowing 8090 or 8081 does not make a server start; the Vite development server must listen on 0.0.0.0 at port 8090. Another mistake is assuming a known URL grants access. The endpoint checks credentials on every request, so the browser needs the local endpoint helper, not direct access to the Session endpoint URL.

A third mistake is confusing endpoint types. InvokeAgentRuntime should reach the agent on port 8080 without the Session endpoint. The Session endpoint is for viewing what the session runs, not for controlling which agent version callers use. That role belongs to the runtime endpoint, such as DEFAULT.

For teams, the practical effect is that review moves from waiting for deployment to watching an authenticated live preview while the session is active. When the work is ready for users, it still needs to be deployed to a hosting service such as AWS Amplify Hosting. The complete sample, including the notebook, is in the 14-remote-access folder of the agentcore-samples GitHub repo.

Meta Description: Amazon Bedrock AgentCore Session endpoints let developers preview a coding agent's Vite app live on port 8090 without deploying each change.
Tags: Amazon Bedrock AgentCore, Session endpoints, coding agents, Vite, port 8090
Featured image: Abstract friendly illustration of a secure agent session previewing a live web app on port 8090, with no people, logos, or text.