How to Use Typesense: The Beginner's Guide (First Server, the API-Key Rule, First Collection, and the Typo-Tolerance Lesson)
CodexFuse Team · 2026-10-31T22:49:48.441Z · 15 min read
Learn how to use Typesense: one Docker command starts your server, then create a collection, index documents, and search with typo tolerance in minutes.
What is Typesense, exactly?
Typesense is an open-source, self-hosted search engine that gives any app typo-tolerant, instant search without the operational weight of Elasticsearch or the monthly bill of Algolia. This typesense tutorial answers how to use Typesense from zero: run your first server with one Docker command, learn the API-key rule that keeps your data safe, create your first collection, index real documents, and feel the typo-tolerance lesson firsthand — one complete beginner arc.
Four facts set expectations before you install. First, Typesense is genuinely open source for self-hosters: the server is GPL-3.0 (the repo's LICENSE.txt, confirmed on GitHub), while every client library is Apache 2.0 — the project's own FAQ explains it chose GPL, not AGPL, because the server runs as a separate daemon rather than being integrated into your code, and modifying and running it internally without distributing is allowed. Second, it is a real, current project: roughly 27,071 GitHub stars, 38 releases, and the docs anchor on v30.2 (with v31 in active development), while the Python client sits at 2.1.1 and the JS client at v3.0.0 for server v30 and up (sources: GitHub typesense/typesense and PyPI, fetched this run). Third, it is the self hosted search engine for teams that outgrow "good enough" database search but refuse Elasticsearch's cluster-tuning rabbit hole. Fourth, it is typesense for beginners in the best sense: one binary, one port, one API key, and you are searching.
If you are choosing between the two friendly self-host search engines, read this alongside our Meilisearch beginner guide — they are siblings, not rivals, and the comparison section below draws the line honestly.
How do you use Typesense for the first time?
You start the server once, then walk one small dataset through every stage: collection, index, search, and the typo test. Here is the complete arc this guide follows — about an hour, most of it waiting for Docker:
- Check the prerequisites: Docker, a machine to run it on, and curl (or any HTTP client).
- Export your API key and create a data directory:
export TYPESENSE_API_KEY=your-own-long-random-keyandmkdir "$(pwd)"/typesense-data. - Start the server with the official one-liner (image pinned to 30.2, the current docs anchor):
docker run -p 8108:8108 -v"$(pwd)"/typesense-data:/data typesense/typesense:30.2 --data-dir /data --api-key=$TYPESENSE_API_KEY. - Prove the server is alive:
curl http://localhost:8108/healthshould return{"ok": true}. - Learn the API-key rule: the key you just set is the admin key — it never goes into frontend code. You will mint a scoped search-only key later.
- Create your first collection with a schema (schema comes before indexing — the number-one beginner error).
- Index documents: one at a time with
POST /documents, or in bulk withPOST /documents/import. - Run your first search:
GET /documents/search?q=stork&query_by=company_name— and watch it match "Stark Industries" anyway. - Learn the typo-tolerance lesson: the defaults that forgive typos (and when to tighten them).
- Mint a scoped search-only key and wire the InstantSearch adapter into a frontend — the safe way to ship.
The rest of this guide walks through each step, including the security habit that separates a demo from a production setup.
What do you need before installing Typesense?
You need three things: Docker, one machine to run it on, and an HTTP client like curl. The official install guide also documents Debian, macOS, and Homebrew routes, but Docker is the path the docs lead with and the one this guide uses.
You do not need a cloud account or any paid service to practice. Run everything on your own machine for the first collection; if you later want an always-on box for a team setup, our what is VPS hosting guide explains the kind of machine a search server fits best. Typesense's own benchmarks note that a one-million-record dataset needs roughly 165 MB of RAM — a small VPS handles a serious workload (source: Typesense README benchmarks, fetched this run).
How do you install Typesense with Docker?
You run one command from the official install guide — typesense docker is the fastest path to a working server, and the typesense install stays the same one-liner on every platform Docker supports. Pinning the image tag keeps you off the stale-tag trap:
export TYPESENSE_API_KEY=your-own-long-random-key
mkdir "$(pwd)"/typesense-data
docker run -p 8108:8108 -v"$(pwd)"/typesense-data:/data typesense/typesense:30.2 \
--data-dir /data --api-key=$TYPESENSE_API_KEY
Three details matter. First, the port is 8108 — the API and the /health and /debug endpoints all live there, so confirm life with curl http://localhost:8108/health (expect {"ok": true}; /debug reports the running version). Second, the volume mount is your persistence: without it, your collections evaporate when the container stops. Third, pin the tag — 30.2 is the version the current docs anchor on (the docs' own install snippet uses it); reaching for latest is how beginners accidentally run a version no tutorial matches. (Source: typesense.org official install guide, fetched this run.)
If Docker itself is new to you, our Docker beginner guide covers the one-command server pattern this install relies on.
What is the Typesense API-key rule?
The rule is simple and absolute: the admin key you exported above must NEVER go into client-side code — and Typesense gives you a first-class mechanism for obeying it. This is the typesense api key lesson every production setup depends on.
Typesense keys come in flavors. The admin key you started the server with can do everything, so it stays on the server. For everything else you mint keys through POST /keys, scoping each one with an actions list (for example ["documents:search"]) and a collections list (for example ["companies"], which supports regex). The full key value is returned only at creation time — lose it and you regenerate, you do not recover (source: Typesense API-keys docs, fetched this run).
Then there are typesense scoped keys, the clever part: you embed search parameters (like a filter_by that restricts results to one tenant's data) into the key itself by signing an HMAC digest of those parameters with a search-scoped parent key — and you generate that scoped key locally, without calling the server at all. The embedded parameters cannot be overridden by the client, and revoking the parent key instantly invalidates every scoped key derived from it. That is the multi-tenant pattern: each user gets a key that can only ever search their own slice.
How do you create your first Typesense collection?
A collection is Typesense's name for an index, and the schema comes BEFORE any documents — sending documents first is the number-one beginner error. This is the typesense collections step, straight from the 30.2 API docs:
curl "http://localhost:8108/collections" \
-X POST -H "X-TYPESENSE-API-KEY: $TYPESENSE_API_KEY" \
-d '{"name": "companies",
"fields": [{"name": "company_name", "type": "string"},
{"name": "num_employees", "type": "int32"},
{"name": "country", "type": "string", "facet": true}],
"default_sorting_field": "num_employees"}'
Every collection needs a name and fields (each field declares a name and a type), plus a default_sorting_field — which must be an int32 or float, because it defines the default rank order. Marking a field "facet": true indexes it verbatim so you can filter and facet on exact values later; unmarked string fields get the full typo-tolerant treatment. Types include string, int32, float, arrays via the [] suffix, plus geo and vector types for the advanced use cases the OpenAI cookbook explores. (The docs also support schema-less auto-detection, but declaring the schema first is the habit that keeps beginners out of trouble.)
How do you index documents in Typesense?
You POST documents to the collection, one at a time or in bulk JSONL — indexing is a write against the schema you just declared. A single document goes to POST /collections/companies/documents:
curl "http://localhost:8108/collections/companies/documents" \
-X POST -H "X-TYPESENSE-API-KEY: $TYPESENSE_API_KEY" \
-d '{"company_name": "Stark Industries", "num_employees": 5215, "country": "USA"}'
For real datasets you use the bulk endpoint, POST /collections/companies/documents/import, with newline-delimited JSON — one document per line, the documented bulk format the community tutorials corroborate. The import endpoint is idempotent per document id, which makes re-running an import safe: fixing your dataset is just re-importing the corrected file. Authenticate with the X-TYPESENSE-API-KEY header, or the ?x-typesense-api-key= query parameter if your client makes headers awkward.
How do you run your first search?
You GET against the search endpoint with a query and the fields to search — the whole query language lives in URL parameters. Try the famous typo demo first:
curl "http://localhost:8108/collections/companies/documents/search?q=stork&query_by=company_name" \
-H "X-TYPESENSE-API-KEY: $TYPESENSE_API_KEY"
Searching stork still returns "Stark Industries" — that is the typo-tolerance lesson in one request. The full query shape the docs demonstrate adds filtering and sorting: ?q=stork&query_by=company_name&filter_by=num_employees:>100&sort_by=num_employees:desc. Note that filter_by works on the facet-marked fields from your schema — filtering on a field you forgot to mark as a facet is beginner mistake number six, and it fails loudly, which is a kindness.
How does Typesense typo tolerance actually work?
Typesense forgives typos with Damerau–Levenshtein distance — it counts how many single-character edits (insert, delete, substitute, or transpose) separate the typed word from the indexed word, and allows up to two by default. This is the typesense typo tolerance machinery, and the defaults are the whole lesson:
| Setting | Default | What it means |
|---|---|---|
num_typos | 2 | Max typos forgiven per word (Damerau–Levenshtein); per-field override like ?num_typos=0,1,1 |
min_len_1typo | 4 | Words shorter than 4 characters get no 1-typo correction |
min_len_2typo | 7 | Words shorter than 7 characters get no 2-typo correction |
max_candidates | 4 | How many typo-corrected candidates Typesense considers per word |
drop_tokens_threshold | 10 | Start dropping query words only after 10+ results exist |
per_page | 10 | Results per page |
The length floors are the subtle genius: short words get strict matching because a 1-typo correction on a 3-letter word matches everything, while long words get the full two-typo forgiveness. Tighten num_typos on fields where precision beats recall — product codes, SKUs, usernames — and leave the defaults alone on names and titles. (Source: Typesense 30.2 search API reference, fetched this run.)
How do faceting, filtering, and synonyms work?
Faceting is how search UIs get their sidebar filters, and it starts with the "facet": true marker you set at schema time. Querying &facet_by=country returns the distinct values with counts — the raw material for a "filter by country" panel — while filter_by=country:USA narrows the result set to exact matches.
Synonyms teach the engine your domain's vocabulary: multi-way synonyms let "sofa," "couch," and "settee" all match the same products, defined through the synonyms API on the collection. Combined with scoped search keys, this is how a store ships search that feels hand-tuned: synonyms handle the language, facets handle the navigation, and the scoped key handles who is allowed to see what.
How do you put Typesense search on a website?
You never call Typesense from the browser with the admin key — you ship a search-only scoped key and the official InstantSearch adapter. The frontend lesson has two halves: mint the scoped key server-side (the API-key rule above), then wire the adapter:
npm install typesense-instantsearch-adapter
# then:
import TypesenseInstantSearchAdapter from 'typesense-instantsearch-adapter';
const adapter = new TypesenseInstantSearchAdapter({
server: { apiKey: 'your-scoped-search-only-key',
nodes: [{ host: 'search.example.com', port: 8108, protocol: 'https' }] },
additionalSearchParameters: { query_by: 'company_name' }
});
// adapter.searchClient plugs into react-instantsearch SearchBox + Hits components
The adapter translates InstantSearch's widget state into Typesense query parameters, so the familiar SearchBox and Hits components just work — with typo tolerance, faceting, and your scoped key's guardrails all active. Your admin key never leaves the server; the browser only ever holds a key that can search one collection with parameters it cannot override.
Typesense vs Meilisearch vs Algolia vs Elasticsearch — which should you pick?
Pick by the constraint that hurts most — and be honest about which one that is. The typesense vs meilisearch question comes up constantly because they are the two friendly self-host options; the typesense vs algolia question is really "build vs buy":
| Typesense | Meilisearch | Algolia | Elasticsearch | |
|---|---|---|---|---|
| Model | Self-host open source (GPL-3.0) + hosted Cloud | Self-host open source + hosted Cloud | SaaS only | Self-host open source (SSPL/Elastic License) + Elastic Cloud |
| Typo tolerance | Yes, out of the box (2 typos default) | Yes, out of the box | Yes, the gold standard | Needs explicit fuzziness config |
| Scoped per-user keys | Yes — HMAC-derived, serverless minting | Yes — tenant tokens | Yes — secured API keys | Needs API-key + DLS setup |
| Operational weight | One binary, one port | One binary, one port | Zero (they run it) | Cluster tuning, JVM heap, shards |
| Best fit | Devs wanting Algolia-like search they control | Devs wanting the simplest possible search API | Teams buying search as a service | Log analytics + full-text at huge scale |
The honest line: if you want search as a utility bill, Algolia wins; if you want a search server you own, the choice is Typesense vs Meilisearch on taste and the exact features you need. Our Meilisearch guide walks the sibling engine end to end if you want to compare by doing.
Should you self-host Typesense or use Typesense Cloud?
Self-host when you have the machine and want zero marginal cost; use typesense cloud when you want someone else on pager duty. The server is free open source under GPL-3.0, so self-hosting costs exactly your VM — and with ~165 MB of RAM per million records, a modest box goes far.
Typesense Cloud prices by the hour for dedicated single-tenant clusters — no per-search or per-record charges — scaling to 1 TB of RAM and 960 vCPUs across 26 regions, with SOC 2 Type II and HIPAA on the compliance side and a Search Delivery Network for global latency. The free tier is 720 cluster-hours (about 30 days) plus 10 GB of bandwidth with no credit card required; independent analysis of the Cloud calculator puts the smallest config at about $0.03/hour (~$21.60/month), with bandwidth at $0.09/GB after the first 10 GB, and paid support add-ons from $160 to $1,900 per 28 days (sources: cloud.typesense.org and the Meilisearch team's calculator analysis, both fetched this run).
What mistakes do Typesense beginners keep making?
Every one of these comes from a real forum thread or a dated tutorial — the table is the cheat sheet I wish the quick-starts included:
| Mistake | Why it hurts | Do this instead |
|---|---|---|
| Indexing before declaring the schema | Auto-detected types guess wrong; facets missing | Create the collection with fields + facet markers first |
| Shipping the admin key in frontend JS | Anyone can read, write, and delete your data | Mint scoped search-only keys; admin key stays server-side |
| No volume mount on the container | Collections vanish on container restart | Always mount -v .../typesense-data:/data |
Using :latest instead of a pinned tag | Tutorials stop matching your server overnight | Pin typesense/typesense:30.2 (current docs anchor) |
default_sorting_field on a string field | Collection creation fails | Use an int32 or float field |
| Filtering on a non-facet field | filter_by errors | Mark filterable fields "facet": true in the schema |
| Full typo tolerance on codes/SKUs | "AB12" matches "AB13" — wrong product | Set num_typos=0 per field for identifiers |
Sources
- Typesense official install guide — typesense.org/docs/guide/install-typesense.html (Docker one-liner, port 8108, /health and /debug endpoints, version-30.2 image reference; fetched 2026-11-01)
- Typesense 30.2 API reference — collections, documents, search, and API-keys endpoints (schema fields, default_sorting_field rules, bulk import format, typo-tolerance defaults, scoped-key HMAC design; fetched 2026-11-01)
- GitHub typesense/typesense — releases, LICENSE.txt (GPL-3.0), README "Why the GPL license?" FAQ, 27,071 stars, 38 releases, v31 default branch (fetched 2026-11-01)
- PyPI typesense 2.1.1 (released Oct 23, 2026); typesense JS client v3.0.0 for server v30+ (fetched 2026-11-01)
- Typesense Cloud — cloud.typesense.org (hourly pricing, 720-hour free tier, 26 regions, SOC 2 Type II + HIPAA; fetched 2026-11-01)
- Meilisearch team's Typesense Cloud calculator analysis, Aug 2026 (smallest config $0.03/hour ≈ $21.60/month, $0.09/GB bandwidth after 10 GB, support tiers $160–$1,900/28 days; fetched 2026-11-01)
- dev.to — "Typesense Has a Free Open-Source Search Engine Built for Speed" (Docker quick-start arc; updated ~7 months ago; fetched 2026-11-01)
- Railway — "Deploy & Host Typesense" (Oct 2026 deploy guide; TYPESENSE_DATA_DIR / TYPESENSE_API_KEY env conventions; fetched 2026-11-01)
- OpenAI Cookbook — "Using Typesense for embeddings search" (vector-search notebook, port 8108, docker pattern; fetched 2026-11-01)
- Live SERP evidence for the topic brief — dev.to/greatsage_sh, f22labs.com, dev.to/satyammishradev, dev.to/0012303 (fetched 2026-10-29)
Frequently Asked Questions
Is Typesense really free and open source?
Yes — the Typesense server is GPL-3.0, confirmed in the repo's LICENSE.txt, and all client libraries are Apache 2.0. The project's own FAQ explains why it chose GPL over AGPL: the server runs as a separate daemon rather than being integrated into your code, and modifying plus running it internally without distributing is explicitly allowed. Typesense Inc. also sells paid support tiers if you want a vendor relationship on top.
Can I use Typesense without Docker?
Yes — the official install guide documents Debian packages, macOS, and Homebrew routes alongside Docker, plus release tarballs from dl.typesense.org. Docker is simply the path the docs lead with and the one this guide uses, because the one-command server is the fastest way to reach your first search.
How many documents can Typesense handle?
The index lives in RAM, so capacity follows memory: the project's benchmarks put a one-million-record dataset at roughly 165 MB of RAM, and Typesense Cloud reports serving 10B+ searches per month. For a first project, even a small VPS is plenty — scale the machine, not the architecture.
Is Typesense better than Meilisearch?
Neither is objectively better — they are the two friendly self-hosted search engines, and the honest choice is by taste and feature fit. Typesense leads on scoped per-user keys and Algolia-like instant search; Meilisearch leads on API simplicity. Try both beginner guides — this one and the Meilisearch beginner guide — and pick the one whose docs feel like home.
Do I need a credit card for the Typesense Cloud free tier?
No — the free tier is 720 cluster-hours (about 30 days) plus 10 GB of bandwidth with no credit card required. It exists so you can evaluate managed hosting against your self-hosted setup before spending anything.