Open-source alternative to custom GPTs in ChatGPT Enterprise: the short answer
A team whose internal assistants live as custom GPTs in ChatGPT Enterprise can move that work onto infrastructure it controls with two main open-source options: LibreChat agents with MCP tools and Open WebUI knowledge collections, functions and model presets. LibreChat is the closer match when the assistant needs to call internal systems through Model Context Protocol servers, since its agent framework is built around tools. Open WebUI fits better when the assistant is mostly instructions plus a document collection, with functions added for custom logic. Both run in your own Docker or Kubernetes environment, and both connect to several model providers, so the choice of model no longer depends on one vendor.
The gaps are real and should shape the plan. Neither platform imports a GPT definition directly, so each custom GPT must be rebuilt by hand: its instructions, its attached files, its actions and its tool configuration. Sharing also works differently. A custom GPT is shared through the ChatGPT Enterprise workspace, while LibreChat agents and Open WebUI models are shared according to the groups, roles and per-resource permissions your deployment defines. Before you start, confirm exactly how each platform exposes sharing, who can publish an agent or model, and whether a shared assistant can be restricted to a group. Also confirm how each one stores the instructions and files that define an assistant, because that is the content you will need to export from ChatGPT Enterprise.
Plan for the rebuild as the main effort, not the software install. Inventory every custom GPT in use, record its owner, audience, knowledge files and external actions, and decide which ones need MCP tools and which only need a knowledge collection. Check the Open WebUI License before you deploy, because its branding clause applies above 50 users in a rolling 30-day period unless you hold an enterprise license or written permission. For the version you intend to deploy, confirm the current release notes on each project's GitHub page, since both projects ship frequently.
Which custom GPT capabilities map to which open-source features
This table maps the main custom GPT capabilities, including instructions, files, tools, group sharing, admin visibility and model choice, to the closest feature in LibreChat agents and Open WebUI. Each cell is marked full, partial or needs confirmation based on documented behavior. Treat every needs confirmation item as a test for your own version, since agent and permission details change between releases and a pilot with one sample group settles them quickly.
| Custom GPT capability | LibreChat agents | Open WebUI |
|---|---|---|
| Instructions | Full: agents take instructions in a no-code builder, so non-developers can define behavior. | Partial: model presets carry system prompts. Confirm how presets are shared and versioned in your release. |
| Uploaded files | Partial: file uploads and a separate RAG API service exist. Confirm which files an agent can reach and how they are scoped. | Full for retrieval: knowledge collections index files in 13 vector databases with hybrid search. Confirm binding to a preset. |
| Actions and tools | Full for MCP: agents connect to Model Context Protocol servers. Confirm the tool list each agent is allowed to call. | Partial: functions extend the interface and tool integrations are available. Confirm the function types your version supports. |
| Sharing with groups | Partial: multi-user sign-in uses OAuth2, LDAP or email. Confirm whether agents can be shared to a specific group. | Full: role-based access uses groups and per-resource permissions, with SCIM 2.0 group provisioning. Test agent and model sharing. |
| Admin visibility of GPT records | Partial: the admin panel manages users and configuration. Confirm whether admins can list every agent and its owner. | Needs confirmation: you control the database, but confirm which admin views list models, collections and owners. |
| Model choice | Full: OpenAI, Azure OpenAI, Anthropic, Google, Bedrock, Ollama and custom OpenAI-compatible endpoints. | Full: Ollama, OpenAI, Anthropic and any OpenAI-compatible provider from one interface. |
| Export of assistant definitions | Needs confirmation: conversation import and export are listed. Confirm whether agent definitions export cleanly. | Needs confirmation: confirm whether presets, functions and collections can be exported and restored between instances. |
Choosing between LibreChat agents and Open WebUI presets
Custom GPTs bundle instructions, files and tools into one assistant. Self-hosted replacements split that bundle differently, so the right choice depends on whether your GPT calls external tools, draws on a document library or mostly answers questions over company content. The three cards below separate those cases and flag the Open WebUI licensing clause that applies once your user count grows.
LibreChat no-code agents with MCP
LibreChat agents are configured in the interface with instructions, tools and files, and they can call tools through Model Context Protocol servers. This fits GPTs whose value comes from actions against internal systems, such as ticket lookups or database reads. The trade-off is operational: each MCP server is another service you must authenticate, monitor and patch. Check how each tool passes user identity, because an agent that runs with a shared service account can expose data that the requesting user should not see. LibreChat is MIT licensed, so no branding clause applies to your deployment.
Open WebUI knowledge collections and presets
Open WebUI groups uploaded files into knowledge collections and saves model presets with system prompts, which covers most custom GPTs built around a reference library. Access follows its role-based controls with groups and per-resource permissions, and SCIM 2.0 can keep those groups in step with your directory. The trade-off is that Functions extend behavior with Python code your team must review and maintain. Above 50 users in a rolling 30-day period, the Open WebUI License forbids removing or altering branding unless you hold an enterprise license or written permission, so budget that decision before rollout.
Onyx or AnythingLLM for document search
When the GPT is mainly a search tool over company content, a retrieval-first product fits better than a general chat interface. Onyx indexes sources such as SharePoint, Confluence and Slack with their permissions, and its Community Edition is MIT licensed, with code under ee directories covered by the Onyx Enterprise License. AnythingLLM is MIT licensed and suits smaller multi-user workspaces over ingested documents. The trade-off is that connector coverage and permission sync become your problem to test, so confirm them against your actual sources before retiring a GPT.
How sharing and permissions work when you host custom GPT replacements
In a self-hosted deployment, sharing is set by your own identity and role configuration, not by a workspace setting in a vendor console. LibreChat supports multi-user authentication with OAuth2, LDAP and email login, and includes an admin panel for user and configuration management. Your directory or identity provider decides who can sign in at all. Before you rely on agent sharing, confirm in the release you plan to deploy whether agents can be shared with named users or groups, who can edit them, and whether that control sits in the admin panel or with the agent's owner. The latest tagged release, v0.8.8, is marked as a pre-release, so pin a version you have tested. Run a two-account test to confirm what a non-admin user can see and change.
Open WebUI takes a more explicit model. It provides role-based access control with groups and per-resource permissions, so access to models, knowledge collections and tools can be granted to a group rather than to individuals. It supports SSO through OIDC or LDAP and SCIM 2.0 user and group provisioning, so group membership can come from your identity provider and removal can follow from the directory. The administrator must still map identity provider groups to Open WebUI groups, decide the default role for newly provisioned users, and grant each knowledge collection and model to the right group. Check the Open WebUI features documentation for the current permission options in your version, and test deprovisioning by disabling a test account in the directory.
ChatGPT Enterprise keeps GPT sharing inside OpenAI's workspace, where workspace admins can review GPTs through the Enterprise Compliance API. A self-hosted replacement moves that responsibility to your team: you design the permission matrix, configure the groups, and decide how changes are logged and reviewed. Write the matrix before rollout. List each assistant or knowledge collection, the groups allowed to use it, the people allowed to edit it, and the review cadence. Then confirm that your chosen platform records who created, shared and changed each assistant. That audit trail is the piece most often left unplanned in a migration.
Moving custom GPT instructions, files and tools to a self-hosted agent
This sequence turns each custom GPT into a documented, owned assistant in a self-hosted interface, with its instructions, knowledge and tool access checked against the original before anyone is moved off ChatGPT. It also keeps the audit record of what the GPTs were and who used them.
Inventory every custom GPT and its owner
A workspace admin lists each custom GPT in the ChatGPT Enterprise workspace, recording the builder, the intended users, the sharing scope, the attached files, the actions or connected tools, and how often it is used. Admins can pull GPT records through the Enterprise Compliance API, which is also the audit export that covers conversations and GPTs, so the inventory can be checked against that export. The step is done when every GPT has one owner, one business purpose and an agreed keep, merge or retire decision.
Export instructions, files and action definitions
Each GPT owner copies its instructions, starter prompts and model settings into a working document, and the admin collects the uploaded knowledge files and any action or API schema definitions. Confirm with your administrator what the Compliance API and workspace tools return for GPT configuration and attached files, since the exact fields are a point to verify in your own tenant. The output is a versioned folder per GPT that a reviewer can read without access to the original workspace.
Recreate each GPT as an agent or model preset
In LibreChat, the platform team builds an agent with the same instructions, a model from the configured provider list and the exported files attached as knowledge. In Open WebUI, the equivalent is a model preset with a system prompt, plus a knowledge collection for the files, which can be grouped and permissioned by team. Use one target per GPT and avoid merging unrelated assistants into one. The step is done when each recreated assistant opens with the same instructions and can retrieve from its own files.
Connect tools through MCP servers or functions
Tool-using GPTs are rebuilt with the connectors they actually need. LibreChat agents can call tools exposed through Model Context Protocol servers, while Open WebUI uses its functions and tool integrations. Each connection gets a service account with the narrowest read or write scope, and any credential is stored in the platform's secret handling rather than in the prompt. The output is a tool list per agent with an owner, a scope and a test call that returns the expected result.
Test with pilot groups against the originals
Choose a pilot group per assistant and run a fixed set of real business questions through both the original GPT and the self-hosted version, comparing answers, source citations and tool actions. Users note differences and the owner decides whether each gap is a prompt change, a missing file or a model limitation. Access groups for the pilot should mirror your identity provider configuration. The step is done when the pilot owner signs off in writing for each assistant.
Set sharing, permissions and logging before cutover
Define who can use, edit and share each assistant in the self-hosted platform, using role-based access, groups or per-resource permissions, and confirm that the platform's logs capture who used which assistant and which tools it called. Record the retention period for conversations and uploads, since the self-hosted platform controls that setting and its backups. The output is a permission matrix reviewed by the security owner before any user moves over.
Retire the original GPTs and archive records
Announce a cutover date to affected users, switch them to the self-hosted assistants and then unshare or delete the original GPTs according to the retention decision made in the inventory. Keep the Compliance API export and the inventory folder as the record of what was retired and when. Confirm with OpenAI's current documentation how deletion timing applies to removed conversations and GPTs before deleting anything that is still needed for audit. The step is complete when the workspace lists no active GPTs that were scheduled for retirement and the archive is stored under your control.
Questions buyers ask about replacing custom GPTs
Can custom GPTs be imported automatically into LibreChat or Open WebUI?
No supplied source documents an automatic converter from custom GPTs to either platform, so plan on a manual rebuild. Each GPT's instructions, knowledge files and action definitions have to be copied into the target format: LibreChat agents with their MCP tools, or Open WebUI knowledge collections, functions and model presets. Conversation history is a separate question. Confirm with each vendor which import paths exist for your export format, and test them on a sample of GPTs before you commit to a schedule. The ChatGPT Enterprise export guidance covers what admins can retrieve, which is the starting inventory for the rebuild.
How much rebuild effort do custom GPTs need, and who does it?
Effort depends on how many GPTs exist, how complex their instructions are, and whether they call external actions. Simple GPTs with a system prompt and a few files usually map to a single assistant or preset. GPTs with API actions need the tool definitions rebuilt, and LibreChat's agents support MCP tools, which means you need an MCP server for each external system. Your own staff can rebuild prompts and knowledge sets, while an implementation partner can take on tool integration, access controls and testing. Ask any partner for a written scope listing each GPT, its tools and the acceptance tests before work starts.
How does sharing and permission control compare with custom GPT sharing?
Custom GPT sharing in ChatGPT Enterprise is managed inside OpenAI's workspace, where admins control who can use and build GPTs. In a self-hosted setup you define the equivalent yourself. LibreChat provides multi-user sign-in through OAuth2, LDAP and email with an admin panel for user and configuration management. Open WebUI documents role-based access control with groups and per-resource permissions, plus SCIM 2.0 provisioning so group membership follows your identity provider. Confirm which resource types each platform can restrict, whether shared assistants can be limited to a group, and how you audit who changed a shared assistant.
What drives the running cost of a self-hosted assistant?
The main cost lines are model usage, hosting, SSO integration and upgrades. Model usage is the largest variable: API tokens are billed by the provider, while local models need GPU capacity you buy or rent. Hosting covers the application, database, search and, for Open WebUI, Redis and shared storage when you run multiple replicas. Its scaling guide requires PostgreSQL rather than SQLite for multi-instance deployments. SSO integration and upgrades are mostly labor. Open WebUI's enterprise license is quoted only after contacting sales with an expected seat count, and the Open WebUI License branding clause applies above 50 users in a rolling 30-day period. Ask for each line separately in any quote.
Can a small internal team run custom assistants without outside help?
A team with Docker, identity and database experience can deploy a single instance and build a first set of assistants alone. The work gets harder when you add SSO and SCIM provisioning, multiple replicas, shared file storage, backups and a patch schedule. Open WebUI's scaling documentation lists PostgreSQL, Redis and shared storage as requirements for multiple replicas, and LibreChat's reference deployment includes MongoDB, Meilisearch and a RAG API service. Decide which parts your staff will own after go-live, and whether you want a retainer for upgrades and support. Confirm the support model in writing with any vendor or partner you consider.
How long does a pilot to replace custom GPTs take?
The duration depends on the number of GPTs in scope, how many use external actions, the identity integration and the review process your organization requires. No supplied source gives a reliable timeline, so treat any estimate as a planning input, not a commitment. A useful pilot covers a small set of representative GPTs, one identity integration, a defined user group and written acceptance tests for answer quality and access rules. Ask any implementation partner for a fixed-scope plan with milestones, and ask the platform vendor which release you should pin for the pilot, since LibreChat's latest tagged release v0.8.8 is marked as a pre-release.
What licensing questions should I settle before a custom GPT pilot?
Settle licensing before users are onboarded, because it changes what you can deploy and rebrand. LibreChat is MIT licensed. Open WebUI code from v0.6.6 onward uses the Open WebUI License, which forbids removing or altering branding in deployments above 50 users in a rolling 30-day period unless you hold an enterprise license or written permission from the copyright holder. Code through v0.6.5 remains BSD-3-Clause. Ask legal to review the license text for your user count and any white-label plans, and confirm which model provider terms apply to the API keys you use.
Will the rebuilt assistants keep the same answers as the original GPTs?
Not automatically. Answers depend on the model, the system prompt, retrieval settings and tool definitions, and changing any of them changes output. Plan a parity test that runs a fixed set of prompts against the original GPTs and the rebuilt assistants, and records where answers differ. Open WebUI's retrieval features include hybrid BM25 plus vector search and reranking, which you should tune against your own documents rather than accept defaults. Ask your implementation partner to document the acceptance criteria and the test set before cutover, so the decision to go live rests on evidence.
Running custom GPT replacements alongside ChatGPT Enterprise
Most teams do not switch off ChatGPT Enterprise in one step. They keep it for general use, move internal assistants to a self-hosted platform team by team, and keep identity and audit records consistent while both run. The cards below cover the decisions that make that coexistence workable.
Split general use from internal assistants
Decide which work stays on ChatGPT Enterprise and which moves. General drafting and research can remain on the hosted workspace, while assistants that hold internal instructions, files or tools, such as a policy helper built from custom GPTs, are candidates for LibreChat agents or Open WebUI models. Write the split down as a routing rule so users know where to go. Check whether any moved assistant depends on a GPT feature you have not yet mapped.
Retire by team, not by tool
Move one team's custom GPTs at a time, starting with a group that has a small, well-documented set of assistants and a willing owner. Each move should have an agreed cutover date, a rollback path to the GPT until sign-off, and a list of users who lose access to the old assistant. Keep the ChatGPT Enterprise seat until the last dependency is confirmed, since removing seats early is the most common cause of lost work.
Keep one identity source for both
Both products should authenticate against the same directory so a person has one account and one group membership across the hosted and self-hosted tools. Confirm how the self-hosted platform receives groups: Open WebUI documents OIDC, LDAP and SCIM 2.0 provisioning, while LibreChat supports OAuth2, LDAP and email login. Mismatched groups during the transition are the usual source of users seeing assistants they should not.
Export ChatGPT audit records before cutover
Ask your OpenAI account team and compliance owner which conversation and GPT records the Enterprise Compliance API can return, and in what format, before a team's GPTs are retired. Store that export under your own retention policy, because the hosted workspace's deletion window does not govern your copy. Record the export date and scope so auditors can see what was preserved and when.
Build a single audit trail across both
During coexistence, the self-hosted platform must log who used which assistant, which model answered and which documents were retrieved, in the same log system used for the hosted workspace. Define the common fields first, such as user ID, group, assistant name, model and timestamp, and confirm that the self-hosted logs are shipped to central storage. Without this, reviewers will need two separate investigations for one access question.
Set a retirement exit criteria
Define when the hosted assistant for a team is switched off: all named users migrated, exports completed, access reviews passed, and at least one owner has signed off on behavior parity. Track open exceptions, such as assistants that rely on a feature still under evaluation, and assign each one a decision date. Confirm the end state with your security and compliance leads before the final seat reduction, not after.
What to confirm with each vendor before you commit
Start with the LibreChat release status. The latest tagged release on GitHub is v0.8.8, published on October 1, 2026 and marked as a pre-release after release candidates in September 2026. Ask the maintainers, or check the LibreChat releases page, which tag they recommend for production, whether a stable release is planned, and how they handle breaking changes to agents, MCP configuration and the admin panel. ClickHouse acquired LibreChat and said existing deployments continue unchanged, so ask ClickHouse or the maintainers what the commercial relationship means for roadmap, support and licensing of the MIT code you plan to run.
Next, confirm Open WebUI version behavior and branding terms. Current code falls under the Open WebUI License, which restricts altering or removing branding above 50 users in a rolling 30-day period unless you hold an enterprise license or written permission. Count your expected active users per month, not just licensed seats, and ask Open WebUI enterprise sales how they price that threshold. Confirm which release you will pin, since code through v0.6.5 remains BSD-3-Clause, and ask how often minor releases such as v0.12.3 change knowledge, group or permission behavior that your custom assistants depend on.
Finally, test whether MCP tool behavior fits your workflow and get enterprise license quotes in writing. Ask which MCP servers each platform calls, whether tool calls run under the signed-in user's identity or a shared service account, and how tool outputs are logged. For quotes, ask Open WebUI for the scope of its enterprise license, the support response terms and the seat count it assumes, and ask any integrator for a written fixed scope covering upgrades, backups and sign-in setup. Request the results of a pilot with your own assistants before signing anything.
