Morphik Core: A Multimodal Retrieval Engine You Can Self-Host, With a Licence That Changes on a Date
Open-source multimodal retrieval engine (Morphik Core). By Morphik — AI back office for skilled nursing & senior living (morphik.ai).
At a glance
- What is it?
- Morphik Core is the open-source retrieval layer behind Morphik's back-office AI products, published as a standalone platform for visually rich documents. The interesting parts are ColPali-based visual search and rules-based metadata extraction; the parts to check before adopting are the source-available licence and the vendor's own statement that self-hosted deployments get limited support.
- Who is it for?
- Morphik Core fits teams whose documents are visually dense (assembly diagrams, scanned charts, mixed text and image specifications) and who want a single ingest and query surface instead of wiring OCR, embeddings and a vector store themselves.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 7 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Morphik Core targets: documents where the layout carries the answer
The README is unusually direct about the failure it is aimed at. Traditional RAG pipelines, it argues, are assembled from separate systems for text extraction, OCR, embeddings, vector databases and retrieval, and each component brings its own APIs, configurations and failure modes. The specific claim is that these pipelines fail on visually rich documents: charts become meaningless text fragments, diagrams lose their spatial relationships, and tables get mangled into unreadable strings. The audience is developers building AI applications over PDFs, images and video who currently duct-tape several tools together. The README's own framing of the goal is to store, represent and search shallow and deep unstructured data end to end. A secondary signal sits in the repository metadata: the project is the retrieval engine behind Morphik's own back-office products for skilled nursing and senior living operators, covering AP, billing, collections and payroll. That origin explains the emphasis on forms, scanned paperwork and mixed text-and-image pages rather than on clean web text. If your corpus is markdown, HTML or plain prose, the multimodal machinery is weight you are paying for without using.
ColPali search and rules-based ingestion: the two mechanisms the docs name
The README names two techniques and links each to a concepts page. The first is ColPali, described as the basis for search that understands the visual content of documents, exposed through a single endpoint that covers images, PDFs and video. The README does not describe the architecture beyond that: there is no statement about which ColPali checkpoint is used, how the visual embeddings are stored, or what index sits behind the query endpoint. The second is rules-based ingestion, linked as rules-processing, which the README describes as fast and scalable metadata extraction covering bounding boxes, labeling and classification. That combination is the shape of the design: extraction is rule-driven and produces located regions, and retrieval is visual rather than dependent on an OCR text layer. The README also lists cache-augmented-generation among the repository topics, and complains that without it an LLM re-processes the same 500-page manual for every query. That is the only caching detail available; the material does not say what is cached, for how long, or where the cache lives. Treat the caching claim as a stated design intent rather than a documented mechanism.
Getting a document in and a question out: the SDK, REST and MCP surfaces
The README gives one worked example in Python. You import Morphik from the morphik package, construct a client with a URI, and call ingest_file on a path. The README shows morphik = Morphik("<your-morphik-uri>") followed by morphik.ingest_file("path/to/your/super/complex/file.pdf"). Querying is a second call, morphik.query, with a natural-language string; the README's example asks for the height of a specific screw in a chair assembly instruction. Two things are worth noting. The URI is a placeholder in the README, so where that endpoint comes from depends on whether you signed up at dev.morphik.ai or self-hosted. And the query call returns something the README does not show, so the response shape has to come from the SDK documentation rather than this page. Beyond the Python SDK there is a REST API, a web console for uploading files, connecting data sources and chatting with the data, and an MCP path documented under using-morphik/mcp for reaching the engine from an MCP client. The README also lists integrations with Google Suite, Slack and Confluence. No configuration keys, environment variables or docker-compose details appear in the README itself; those live in the self-hosting guide, which the README links out to rather than reproduces.
The support boundary on self-hosting is stated, not implied
This is the sentence that should shape a build-versus-buy decision. The README says that due to limited resources, full support for self-hosted deployments cannot be provided, that an installation guide and a Discord community exist to help, and that full support cannot be guaranteed. That is an honest disclosure and it is also a real constraint. If your team has no one who can debug a Python service, its dependencies and its storage layer from an installation guide and a community chat, the self-hosted path is a risk. The recommended path in the README is the opposite one: sign up at dev.morphik.ai, use the free tier, and pay compute-usage-based pricing when ingestion grows. So the project is effectively two products with different support levels, and the README is candid that the hosted one is the one it stands behind. There is a second limitation worth naming. The README describes the engine as the retrieval layer behind Morphik's own back-office products. That is a credible signal about production use, but it also means the roadmap is shaped by that business. The contributing section says current focus is speed, more tool integrations, and finding research papers of most value to users. Teams whose needs fall outside those three areas should not expect the open repository to move in their direction.
Where Morphik Core is the wrong tool, and what to use instead
If your documents are already clean text and your queries are keyword or semantic text search, a conventional text RAG stack is simpler and cheaper to operate. The comparison that matters is against assembling that stack yourself: an OCR or document parser, a text embedder, a vector database, and a retriever, wired together. The difference in approach is where the visual information is handled. In a typical assembled pipeline, the page is flattened to text early, so a chart or a diagram survives only as whatever the parser emitted, and spatial relationships between a label and a figure are gone before retrieval happens. Morphik Core keeps the visual representation as the retrieval substrate through ColPali and adds rules-based extraction that returns bounding boxes and classifications, so a match can point at a region on a page rather than a string of text. That is a genuine architectural difference, not a marketing one. It also means the trade is inverted: you give up the ability to inspect and tune a plain text index, and you take on a heavier ingestion path and a dependency on the project's own storage and serving choices. For a corpus of contracts in clean digital PDFs, that trade is usually not worth making. For a corpus of scanned forms, engineering diagrams and image-heavy specifications, it is the entire point.
Licence and upgrade cost: what the repository actually states
The README states that Morphik Core is source-available under the Business Source License 1.1, linking to ./LICENSE. It then lists terms: personal and indie use is free, and commercial production use is free if the deployment generates something, at which point the README text in the supplied material stops mid-sentence. That truncation is the single most important thing to resolve before adopting. The condition on commercial production use is not readable from this page, and the BSL 1.1 pattern normally involves a revenue or usage threshold plus a change date after which the licence converts to an open source licence. Do not assume either detail. Read the LICENSE file in the repository directly, and treat the answer as a business decision rather than a legal one. Two practical consequences follow. Because the licence is not OSI-approved, some organisations will be blocked by internal policy regardless of the terms. And because the licence can change on a date, the terms you build against today are not guaranteed to be the terms in force later, which matters if the deployment is long-lived. On maintenance: the README offers no release cadence, no versioning scheme and no upgrade path between self-hosted versions, and no releases were retrieved for this review. The commit-activity and closed-issue badges on the README are the only activity signals present, and badges are not a substitute for reading the commit history.
Who should adopt Morphik Core, and what to verify before writing code
Adopt it if your retrieval problem is genuinely visual and you want one ingest and query surface rather than a pipeline you maintain. The Python example in the README is short enough to evaluate in an afternoon against your own worst document. Start on the hosted free tier at dev.morphik.ai rather than self-hosting, because that is the path the README recommends and the one it supports; you will learn whether ColPali retrieval returns usable regions on your corpus before you take on an installation you have to maintain yourself. Do not adopt it if you need an OSI-approved licence, if you have no capacity to operate a self-hosted Python service, or if your corpus is plain text. Four things to verify first. Read LICENSE in full and get the commercial production condition in writing, since the README does not complete that sentence. Check the SDK reference for the actual return type of morphik.query, because the README shows the call and not the response. Confirm from the self-hosting guide which installation options exist, direct or docker, and whether either matches your infrastructure. And read the rules-processing concepts page to see whether the extraction rules can express the fields your application needs, since bounding boxes and classification are named but the rule syntax is not shown anywhere in the README.
Editorial conclusion
Morphik Core fits teams whose documents are visually dense (assembly diagrams, scanned charts, mixed text and image specifications) and who want a single ingest and query surface instead of wiring OCR, embeddings and a vector store themselves. It does not fit anyone who needs an OSI-approved licence, because the repository states Morphik Core is source-available under the Business Source License 1.1 with free personal and indie use and commercial production use free only under a condition the README truncates before finishing. Before committing, read LICENSE in full, confirm the exact commercial threshold, and check whether the self-hosted installation path in the getting-started guide covers your deployment target, since the project states it cannot guarantee full support for self-hosted installs.
Community notes