Every new SaaS seems to embed ChatGPT these days.
Most AI support solutions rely on third-party platforms, monthly subscriptions, and vendor lock-in. While they're great products, I wanted something different.
I wanted complete ownership.
I wanted to deploy everything on my own server, use my own OpenAI API key, customize every part of the experience, and embed the widget into any website with a single script tag.
So I built my own self-hosted AI support widget using Spring Boot and Vanilla JavaScript.
Why I Built It
When building small products and websites, I realized that customer support quickly becomes a problem.
Users have questions about pricing, features, returns, or simply get stuck.
Most developers solve this by integrating services like Intercom, Crisp, or Tidio.
Those platforms are excellent, but they also mean:
Monthly subscription costs
Vendor lock-in
Customer conversations stored on third-party platforms
Limited customization
Another external dependency
I wanted something that developers could completely own.
The Goal
The goal was simple.
Build an AI-powered customer support widget that developers can deploy on their own server and integrate into any website in less than a minute.
The widget should:
Answer customer questions using AI
Learn from a custom knowledge base
Match the company's branding
Store conversation history
Allow human handoff
Be easy to deploy
Require only one script tag to embed
Technology Stack
Java 17
Spring Boot 3
Spring Security
Spring Data JPA
Thymeleaf
Vanilla JavaScript
H2 Database (MySQL supported)
OpenAI API
Architecture
The overall architecture is intentionally simple.
Visitor
│
▼
AI Chat Widget
(Vanilla JavaScript)
│
▼
Spring Boot REST API
│
▼
OpenAI API
│
▼
Database
(H2 / MySQL)
Keeping the frontend framework-free makes the widget lightweight and easy to embed into virtually any website.
One-Line Integration
Adding the widget to a website only requires a single script.
<script src="/widget/widget.js" data-api-base=""></script>
No React.
No Vue.
No npm packages.
Just one script.
Features I Built
The project includes:
✅ AI-powered customer support
✅ Spring Boot backend
✅ Secure admin authentication
✅ Custom knowledge base
✅ Conversation history
✅ Brand customization
✅ Human handoff with email notification
✅ OpenAI API configuration
✅ H2 support with MySQL production configuration
✅ One-line website integration
The Admin Dashboard
Instead of hardcoding prompts inside the application, administrators can configure everything from the dashboard.
They can update:
Company name
Greeting message
Brand color
OpenAI API key
Knowledge base
Notification email
Changes take effect immediately without restarting the application.
Why I Didn't Use RAG
One interesting design decision was intentionally not implementing Retrieval-Augmented Generation (RAG).
Instead, administrators maintain a simple knowledge base that is included in the AI's system prompt.
For small and medium-sized businesses, this approach keeps deployment extremely simple while still delivering accurate responses.
If the project grows, adding vector search later is straightforward.
Sometimes simplicity is the better engineering decision.
Human Handoff
AI can't answer everything.
Whenever visitors need human assistance, they can submit their email.
The system:
Stores the lead in the database
Sends an email notification (if SMTP is configured)
Lets administrators continue the conversation manually
This ensures users never hit a dead end.
Lessons Learned
Building the OpenAI integration wasn't actually the hardest part.
The real engineering challenges were:
Designing a flexible architecture
Authentication and authorization
Conversation persistence
Prompt management
Making the widget framework-independent
Creating an admin experience that non-developers can use
Those pieces ended up being much more interesting than simply calling an AI API.
Things I Intentionally Left Out
Every project needs boundaries.
I intentionally skipped:
Multi-tenancy
Stripe subscriptions
Vector databases
Multiple AI providers
Complex AI orchestration
The goal was to build a clean, understandable codebase that developers can deploy quickly and extend however they like.
What's Next?
I'm considering adding:
Streaming AI responses
Multiple AI providers
RAG support
File uploads
Conversation analytics
Multi-tenant architecture
Final Thoughts
This project reminded me that building AI products isn't just about connecting to an LLM.
The real engineering happens around it:
authentication
configuration
deployment
usability
persistence
developer experience
Those are the parts that transform an API call into a real product.
I'd love to hear how you're building AI applications with Java or Spring Boot, and what features you would add to a self-hosted support widget.
Interested in the Full Project?
I built this as a complete, production-ready Spring Boot project. If you'd like the full source code, setup guide, and deployment instructions, you can find it here:
👉(https://swarnalata25.gumroad.com/l/supportai-springboot)
I'm also building more self-hosted Java & Spring Boot products, so feedback and suggestions are always welcome.
Top comments (6)
the simple embed and human handoff make the project easy to try. for a public deployment, i would add tenant isolation, rate limits, request timeouts, and a clear retention setting for conversation history. keep the openai key on the server and redact personal data before logs or support emails. a small test page with slow, failed, and unsafe requests would also show how the widget behaves when the model is unavailable.
Thanks! I appreciate the detailed feedback. 🙌 I intentionally kept this as a lean single-tenant MVP focused on simplicity and self-hosting, but I completely agree with your points. Features like tenant isolation, rate limiting, configurable retention, and better resilience testing are all great next steps. The OpenAI key already stays server-side, and I'm also looking into improving PII redaction and handling model failures more gracefully. Thanks again for taking the time to review it!
that sounds like a good next step. tenant isolation and retention rules will make the base easier to extend. keeping the key server side is also important. clear pii tests and graceful model failure paths should make the widget safer to run.
Thanks! I appreciate the suggestions. 🙌 I deliberately optimized the first version for simplicity and ease of self-hosting, but those production-focused improvements are definitely on my roadmap. Feedback like this helps shape the next iteration, so thanks for taking the time to share it.
that makes sense. keeping the first version simple should make the next changes easier to measure. i would add tenant isolation and retention as separate milestones, then test failure paths before adding more model features. thanks for sharing the roadmap.
Thanks! I completely agree. Breaking those into separate milestones will make it much easier to measure the impact of each change while keeping the codebase maintainable. I appreciate all the feedback, it’s given me some great ideas for future iterations. 🙌