aws-lex-web-ui: a Vue chat widget for Amazon Lex, deployable by CloudFormation

One component, two integration shapes

The sample provides a chatbot UI component that can be integrated into a website, and it ships in two forms. There is a full page chatbot UI, and there is an embeddable widget that sits inside an existing site as an iframe. The README shows both as animated gifs, which is the fastest way to understand the difference in practice. The feature list describes a mobile ready responsive UI with full page or embeddable widget modes, so the same component handles both. The topics attached to the repository include iframe, web and widget, which confirms that the embeddable mode is the primary use case rather than an afterthought. For a team evaluating whether to write their own Lex front end, the practical question is how much of the standard interaction they would end up reimplementing, and this repository is a reasonable answer to that question for the baseline case.

Voice means silence detection, transcription and interruption

The voice support is where the work is, and the README describes three specific capabilities rather than a general claim. Voice support provides automatic silence detection, transcriptions, and the ability to interrupt responses and replay recordings. Support for both voice and text comes with the ability to switch seamlessly from one mode to the other. The repository topics include webrtc and polly-voice, which is consistent with a browser microphone stream and a speech service behind the recognition, and the dependency list in package.json supports the browser-side story with amazon-cognito-auth-js, @aws-sdk/client-cognito-identity, @aws-sdk/credential-providers, jwt-decode and jsdom. That is a Cognito-based authentication path for the identity the browser needs in order to talk to Lex at all, which is the part a sample most often leaves unexplained.

Two build pipelines, one for the app and one for the widget bundle

The package.json shows two build paths that are easy to confuse. The root scripts delegate into a subpackage for the dev and library builds, with serve, build, build:dev, build:lib-dev, build:lib-prod and build-dist all prefixed by cd lex-web-ui &&. Separately, the app itself is built at the root with Vite, where build-prod is cross-env NODE_ENV=production vite build and build-dev is the same with development. The main entry point is lex-web-ui/dist/bundle/lex-web-ui.js, and the module type is set to module, so the package ships as ES modules. The Makefile explains why both exist. It is used to configure and deploy the sample app, it is used in CodeBuild by the CloudFormation stack, and it can also be run from a local dev environment, and it can either deploy a full build or use the prebuilt library in the dist directory. So there is a path where you take the shipped bundle as is, and a path where you rebuild everything from source, and the deployment tooling is written to support both.

Upgrades merge your config rather than overwrite it

The Makefile is worth reading even if you never run it, because it shows how the project treats a deployed stack that a customer has customised. Two variables are defined for exactly that purpose. CURRENT_CONFIG_FILE points at ./lex-web-ui/current/user-lex-web-ui-loader-config.json with the comment that it merges existing user modified config during an upgrade, and USER_CUSTOM_CSS_COPY points at ./lex-web-ui/current/user-custom-chatbot-style.css with the comment that user custom files are replaced during upgrade. The load-current-config target downloads the loader config from s3 if it exists and falls back to the default file in the config directory, and it does the same for the custom CSS. The environment comes from a config/env.mk file that the Makefile includes, so the S3 bucket and other parameters are injected at build time. This is the pattern you want in a sample that people will actually change in place, and it is more careful than most.

CloudFormation in nine regions, one template each

The fastest way to test the interface is stated up front: deploy it using the AWS CloudFormation templates provided by the project, and once the stack is launched you get a fully working demo site hosted in your own account. The README then lists the currently supported regions with a launch button and a template link for each. They are Northern Virginia, Oregon, Ireland, Sydney, Singapore, Seoul, London, Tokyo and Frankfurt, each with its own region code, us-east-1, us-west-2, eu-west-1, ap-southeast-2, ap-southeast-1a, ap-northeast-2, eu-west-2, ap-northeast-1 and eu-central-1. Note the naming in the links, a master.yaml template served from S3 with a bootstrap bucket parameter. This is a genuinely useful property of the sample. A single template deployed into your account gives you the whole stack, the bot, the Lambda functions behind it and the site, without you having to work out what the pieces are.

The features are documented as separate READMEs

The repository splits the documentation by feature, and the file listing is more informative than the feature bullets. There is README-connect-live-chat.md, README-css-style.md, README-file-upload.md, README-qbusiness.md and README-streaming-responses.md, alongside the main README.md. Two of these point at features beyond the basic chat loop. Connect interactive messaging support is listed in the main feature list with a link to the AWS documentation, and the qbusiness file suggests Amazon Q Business chat integration. Streaming responses is the one that changes how you build against it, because it changes the shape of the reply handling rather than adding a button. The CSS style file is the one to read first if you care about the visual result, since the component is meant to be styled to match your site rather than shipped with a fixed look.

A sample, with the licence that comes with it

The package.json gives the licence as SEE LICENSE IN LICENSE, with a LICENSE file and a NOTICE file at the repository root, and GitHub lists its licence as a custom one that cannot be classified. For a sample repository under an aws-samples organisation this is normal, and it is still the thing to read before you put the code in a product, because the terms are not one of the standard permissive licences you can assume. The project is not archived and the last push was on 2026-10-22, and the release history is steady: 0.24.0 on 2026-04-20, 0.24.1 on 2026-05-12 and 0.24.2 on 2026-07-29. The repository URL in the manifest points at the awslabs organisation while the project lives under aws-samples, and the issues link does the same, which is the kind of detail that saves a confused contributor an hour.

Editorial conclusion

Adopt aws-lex-web-ui if you are building a Lex bot and want a working web interface with voice and text rather than designing one from scratch, and you are willing to work inside the CloudFormation stack it deploys. Do not adopt it if you need a supported product with an SLA, since this is a sample under a custom licence, or if your voice requirements go beyond WebRTC microphone access, since that is the transport the browser side relies on. Before you commit, read the separate README files in the repository for the areas that matter to you, because the features are documented individually, including streaming responses, file upload, Connect live chat, Amazon Q Business chat and CSS customisation.

Frequently asked questions

Official sources

1. aws-samples/aws-lex-web-ui on GitHub
2. Issues
3. README
4. Releases