Morphic: A Generative UI Search Engine You Self-Host

What Morphic Actually Replaces

Morphic is an answer engine, not a search engine in the index-building sense. The README describes it as an AI-powered search engine with a generative UI, and the feature list makes the shape clear: grounded, cited answers, a model selector, multiple search backends, chat history in PostgreSQL, shareable result URLs, file upload, Supabase Auth, and a guest mode. The intended user is someone who wants a chat interface over live web results and wants to control which model and which search provider sit behind it. That control is the point. A hosted answer engine decides your retrieval vendor and your model for you. Morphic exposes both as configuration. The repository is TypeScript and Next.js, licensed Apache-2.0, with the default branch on main and a public instance at chat.morphic.sh. Releases v1.4.0, v1.5.0 and v1.6.0 landed between May and August 2026, so the project is active rather than frozen.

The Generative UI Is the Distinguishing Mechanism

Most chat-over-search tools return markdown and let the client render it. Morphic's README states that answers render rich inline components (source-credited images, grids, headings) live from a streamed JSON spec, beyond plain markdown. That is the architectural claim worth understanding. The model does not emit prose that the frontend parses into something prettier. It emits a structured spec, and the frontend maps that spec onto React components as the stream arrives. The practical consequence is that the answer format is a contract between the model's output and a component registry. Adding a new answer shape means touching both sides. It also means a malformed or unexpected spec is a rendering problem, not a text problem, and the README does not document how spec validation failures are surfaced. If you are evaluating this project, that is the first thing to read in the source rather than the docs.

Search Modes, Providers and Model Routing

Two search modes are listed: Quick and Adaptive. The README names the modes but does not describe how they differ in retrieval depth or latency, so treat the distinction as undocumented until you read the implementation. Search providers are Tavily, SearXNG, Brave and Exa. Model providers are detected dynamically and include OpenAI, Anthropic, Google, Ollama, Vercel AI Gateway, and OpenAI-compatible providers. Ollama in that list matters: it means the whole stack can run without sending queries to a hosted model vendor, provided you have local inference capacity. The OpenAI-compatible entry is the escape hatch for anything not named explicitly. Note the asymmetry between the two paths. Docker Compose includes SearXNG, so the self-hosted route needs no search API key. The local development instructions set both OPENAI_API_KEY and TAVILY_API_KEY, which points at Tavily as the default hosted search provider for that path.

Getting It Running: Docker Versus bun dev

The README calls Docker the recommended path. Pull the image with docker pull ghcr.io/miurla/morphic:latest, then clone the repository, run cp .env.local.example .env.local, and set at least one AI provider key such as OPENAI_API_KEY=your_openai_key. Then docker compose up -d and visit http://localhost:3000. The README states that Compose starts PostgreSQL, Redis, SearXNG and Morphic automatically, and that no additional search API key is needed because SearXNG is included. For local development the sequence is git clone, bun install, cp .env.local.example .env.local, then set OPENAI_API_KEY and TAVILY_API_KEY, then bun dev. The README points at docs/CONFIGURATION.md for chat history, authentication, file upload and other features, and at docs/DOCKER.md for building from source and file upload configuration. The Vercel deploy button passes OPENAI_API_KEY, TAVILY_API_KEY and ENABLE_AUTH as environment variables. That is the whole documented surface. Anything about rate limits, token budgets or provider failover is not in the README.

The Operational Weight You Are Signing Up For

This is not a single binary. The Docker path runs four services: PostgreSQL for chat history, Redis (the topics list Upstash, which is the hosted Redis the project targets in production), SearXNG as the self-hosted metasearch backend, and the Next.js app. That is a real operational footprint for what looks like a search box. Redis is easy to overlook because nothing in the feature list mentions caching, but it appears in the Compose description and in the project topics, so the deployment expects it. The second constraint is authentication. Supabase Auth backs user authentication, and the README lists a guest mode for anonymous usage. If you want chat history and sharing, you are adding a Supabase dependency or a self-hosted equivalent. The third is that the README gives no sizing guidance, no memory requirements and no note on what happens when PostgreSQL or Redis is unavailable. You will find that out by running it.

Where Morphic Is the Wrong Tool

If your problem is retrieval quality over a private corpus, Morphic is aimed at the wrong layer. It searches the open web through Tavily, SearXNG, Brave or Exa. File upload is listed as a feature, but the README does not describe chunking, embedding, a vector store or a reranking stage. There is no vector database in the Compose service list. So document question answering over thousands of internal files is not what this codebase is built to do, and you would be adding the retrieval half yourself. The second wrong-tool case is a team that wants a stable, versioned answer format. Because the answer is a streamed JSON spec rendered by components, the output shape is coupled to the frontend build. If you are piping answers into a downstream system that expects text, you are either extracting text from the spec or fighting the design. The third case is anyone who cannot operate Postgres and Redis. The README's own framing puts chat history in PostgreSQL and the Compose file starts Redis, so a stateless single-container deploy is not the documented path.

How It Differs From Perplexity-Style and RAG-First Tools

The obvious comparison is a hosted answer engine in the Perplexity mould. The difference is not the feature list, which overlaps, but who holds the keys. Morphic lets you point the model selector at Ollama, which the README lists among dynamically detected providers, so inference can stay on your hardware. A hosted engine cannot offer that. The more interesting comparison is against RAG frameworks such as LlamaIndex or LangChain, which are libraries rather than applications. Those give you control over chunking, embedding models, vector stores and rerankers, and in exchange you build the interface, the auth, the streaming and the persistence layer yourself. Morphic inverts that trade. It hands you a finished Next.js application with Supabase Auth, PostgreSQL history, shareable URLs and a component-based answer format, and it gives you almost no knobs on the retrieval side. If your bottleneck is retrieval precision, the framework wins. If your bottleneck is shipping a working interface over web search this week, Morphic wins. Neither is a strict improvement on the other.

Licence, Upgrades and What to Check Before You Commit

Morphic is Apache-2.0, which permits commercial use, modification and redistribution provided you preserve the licence and notices. That is a permissive baseline, but it is not legal advice and the trademark and attribution terms in the LICENSE file govern, so read it if you plan to redistribute. Maintenance cost tracks the release cadence: v1.4.0 in May 2026, v1.5.0 in June, v1.6.0 in August, with the last push in September 2026. Three minor releases in four months is a moving target. Because the generative UI couples model output to frontend components, a model provider changing its streaming behaviour can break rendering without any change to your code, so pin your provider versions and your image tag rather than tracking latest. The concrete things to verify before adopting: whether your chosen search provider returns usable results for your query distribution, since the README documents four options with no comparison between them; whether your model's streamed output parses cleanly into the spec the components expect; and how the app behaves when PostgreSQL or Redis is down, which the README does not cover.

Editorial conclusion

Adopt Morphic if you want a self-hosted answer engine whose output is structured UI rather than markdown, and you are willing to run PostgreSQL, Redis and SearXNG alongside it. Do not adopt it if you need a retrieval stack you can tune at the chunk level, or if you cannot operate Postgres and Redis. Before committing, verify two things in your own environment: that your chosen search provider returns usable results for your queries, and that your model provider's streaming output survives the generative UI spec parsing. The Docker Compose path is the fastest way to check both, since it starts PostgreSQL, Redis, SearXNG and Morphic together with no search API key.

Official sources

1. License: Apache-2.0
2. miurla/morphic on GitHub
3. Project website
4. README
5. Releases