# Running Typesense in Production

In addition to performance and ease-of-use, Typesense is also designed to have low operational overhead in Production.

When running Typesense in Typesense Cloud (opens new window), running in production is as simple as flipping a switch to enable "High Availability" and you'll have a distributed multi-node cluster that is production-ready and ready-to-use.

Typesense is a single self-contained binary with no runtime dependencies. So when self-hosting, running Typesense in Production involves simply installing Typesense, starting the Typesense process as a daemon, either via Docker or a process manager (our DEB and RPM packages do this for you) and configuring High Availability as needed.

# Production Best Practices

Here are a couple of pointers to ensure that you get an optimal experience from Typesense in Production.

TIP

Most of the server infrastructure related items are not applicable to Typesense Cloud clusters, since we manage the infrastructure for you.

# Configuration

  • Ensure that you have picked the right system configuration for your dataset and traffic patterns.
  • Typesense comes built-in with a high performance HTTP server (opens new window) that is used by likes of Fastly (opens new window) in their edge servers at scale. So Typesense can be directly exposed to incoming public-facing internet traffic, without the need to place it behind another web server like Nginx / Apache or your backend API.
  • Run a Highly-Available cluster when serving Production traffic (optional, but highly recommended).
  • Configure a minimal amount of swap space for safety reasons, but if you see swap being used, that will start affecting performance and is a sure sign that you'd need to upgrade RAM capacity.
  • If you're integrating Typesense with a mobile app, we highly recommend that you store the Typesense hostnames and API Key(s) on your backend, and have your app dynamically fetch the remote configs on load, instead of hard-coding these in the app. This is helpful if you need to change the hostnames / API keys for any reason. With remote configs, you can change these values without having to go through a round of app store review processes.

# Monitoring

  • Monitor the /health API endpoint for uptime.
  • Monitor RAM usage to ensure that it is below 85% of total RAM - you want to ensure that the OS has sufficient RAM to do its thing.
  • Monitor the /stats.json API endpoint for request rate and latency.
  • Monitor CPU usage to ensure that it is below 90% on average. If it spikes beyond that, you might need to upgrade to higher CPU capacity.
  • When using the import API to ingest large batches of data, make sure that you have configured a sufficiently high timeout value to let your large imports complete, since all write operations are synchronous in Typesense.

# Search Relevance

  • Setup search analytics.
    • Monitor the search terms users are using, and setup synonyms as appropriate.
    • Monitor the search terms users are using, and curate results as needed.
  • While Typesense's default relevance parameters work out-of-the-box for majority of use cases, you can also fine-tune search relevance parameters as needed.
    • While default_sorting_order is optional, it is highly recommended especially if you have a field in your documents that is a proxy for how popular a document is within your dataset.

# Security

  • Set --api-port server parameter to 443 and use HTTPS in production.
    • Ensure that your firewall only allows inbound public traffic via this port.
    • Configure your SSL certificate and key using the --ssl-certificate and --ssl-certificate-key parameters.
  • When running a Highly-Available cluster, ensure that the --peering-address parameter is an IP Address on your INTERNAL private network.
  • Ensure that you have a strategy for expiring and rotating API keys regularly, using the expires_at parameter.
  • If you are storing multi-tenant data in a single collection, ensure that you have configured your Scoped Search API Keys correctly, to include the logged-in user's ID in the embedded filter.
    • Scoped Search API Keys need to be generated in your backend stack, and passed on to the frontend which should then send that to Typesense in API Calls.
    • Be sure to never expose your parent Search API Key to users, since that key has unrestricted access to all records.
  • On Typesense Cloud, set up a team account to manage access and setup Single Sign-On.

# Schema Management

  • Set up a collection alias and use the alias to access the collection and documents from your application.
    • This is especially helpful when you need to update the schema of a collection. You'd create a new timestamped collection, re-index your data in it and then swap the alias to point to it.
  • Prefer a pre-defined schema when possible, since with auto-schema detection, you might end up accidentally indexing fields that you might not be using for search purposes in memory, taking up RAM unnecessarily (unless you explictly set index: false on those fields). But you can also use Regex fields name and auto schema detection especially when field names are dynamic.
  • Ensure that fields you're using only for display purposes (eg: image URL, links, etc) are not specified in the schema (or set as index: false when using auto-schema detection), in order to set these fields as unindexed fields and save memory. You can still send these unindexed fields in the documents when adding them to the collection - they will just be stored on disk, and will not take up any memory. Then when that document is a hit, these unindexed fields will be fetched from disk, and stuffed into the search API response for you to use for display purposes.

# Staying Up-To-Date

# Support

We've strived to keep Typesense as self-service and out-of-the-box as possible, with fully public documentation.

But if you need help or have any questions, here are a couple of ways to seek additional help:

Edit page (opens new window)
Last Updated: 9/24/2024, 3:25:48 PM

← Search Analytics →