Self-Hosting Typesense — My Experience and Lessons Learned
We needed a scalable, cost-effective search solution for our platforms, and I was tasked with self-hosting Typesense to power full-text search. While managed services offer ease of setup, they can quickly become expensive at scale.
After evaluating options, Typesense stood out
Typesense is an open-source, lightweight, and blazing-fast search engine, making it a great alternative.
However, self-hosting wasn’t as straightforward as expected. From networking issues between nodes to security group misconfigurations and load balancer struggles, this journey had many roadblocks.
One thing that helped me a lot was their official documentation: https://typesense.org/docs/guide/install-typesense.html#option-2-local-machine-self-hosting
In this blog, I’ll walk through the high-level setup, the issues I faced, and the solutions that finally made everything work.
Setting Up a 3-Node Typesense Cluster on AWS
To ensure high availability and fault tolerance, I deployed three EC2 instances in the same security group behind an AWS Application Load Balancer (ALB).
Step 1: Creating the EC2 Instances
I provisioned three Ubuntu EC2 instances with private IPs in the same VPC:
- Node 1:
192.168.1.15
- Node 2:
192.168.1.16
- Node 3:
192.168.1.12
This setup ensures that if one node goes down, the cluster remains functional.
The First Big Issue: Nodes Couldn’t Communicate
Once I started Typesense on all three nodes, I realized the nodes weren’t talking to each other.
This was unexpected, and debugging took a while.
The Problem:
- Each instance couldn’t reach the others on port 8107 (peering) and 8108 (API).
- Security groups were too restrictive, blocking internal communication
- Typesense was not correctly started to enable cluster communication.
The Fix:
I updated the AWS security group to allow inbound traffic from all internal nodes:
Custom TCP Rule | 8107-8108 | Source: 192.168.1.0/24
Now, all nodes could talk to each other.
Step 2: Installing Typesense on Each Node
After fixing the networking issues, I installed Typesense on all nodes:
curl -O https://dl.typesense.org/releases/0.25.0/typesense-server-0.25.0-linux-amd64.tar.gz
tar -xvzf typesense-server-0.25.0-linux-amd64.tar.gz
mv typesense-server /usr/local/bin/typesense
Step 3: Configuring Cluster Communication
Each node needed to know about the other two nodes.
I created a nodes file on each instance:
echo '192.168.1.10:8107:8108,192.168.1.11:8107:8108,192.168.1.12:8107:8108' | sudo tee /etc/typesense/nodes
Step 4: Starting Typesense on Each Node
On each node, I ran:
typesense-server \
--data-dir /var/lib/typesense \
--api-key=my_secure_key \
--api-address 0.0.0.0 \
--api-port 8108 \
--peering-address 192.168.1.X \
--peering-port 8107 \
--nodes=/etc/typesense/nodes
Now, all nodes were able to communicate and sync!
Enabling Auto-Restart
To ensure that Typesense automatically starts and restarts in case of failures, I set up a systemd service:
sudo nano /etc/systemd/system/typesense.service
Added this configuration:
[Unit]
Description=Typesense Server
After=network.target
[Service]
ExecStart=/usr/local/bin/typesense-server --data-dir /var/lib/typesense --api-key=my_secure_key --api-address 0.0.0.0 --api-port 8108 --peering-address 192.168.1.X --peering-port 8107 --nodes=/etc/typesense/nodes
Restart=always
User=root
[Install]
WantedBy=multi-user.target
Then ran:
sudo systemctl enable typesense
sudo systemctl start typesense
Now, Typesense restarts automatically if it crashes.
Deploying the Load Balancer
Step 5: Setting Up the AWS Load Balancer
I created an AWS Application Load Balancer (ALB) to distribute search requests across all three nodes.
Second Big Issue: Load Balancer Not Forwarding Requests
I hit another issue requests to the ALB weren’t reaching the nodes.
The Problem:
1️ALB’s security group didn’t allow traffic on port 8108.
2️ Health check was failing because it was using the wrong port.
Fix:
- Updated ALB security group to allow port 8108 from all sources.
- Set Health Check Path to
/health
.
Now, requests started going through the load balancer!
Final Fix: Enabling HTTPS
Since Typesense was running on HTTP, I needed to add HTTPS.
The Problem:
- Cloudflare doesn’t allow CNAME at root domains.
- I needed SSL/TLS encryption end-to-end.
Fix:
- Used AWS ACM to generate an SSL certificate for the ALB.
- Configured Cloudflare to enable HTTPS.
- set CNAME for
www.search.infinitypaul.com
. - Used A Record (Alias) for
search.infinitypaul.com
.
Now, all requests were encrypted!
After several networking issues, security group tweaks, and debugging, Typesense is now fully self-hosted and running!
Please use only Search Only API Keys If you intend to use this in your javascript application, Never expose your master API key in client-side code!
Would I Self-Host Again?
Would I do it again? Absolutely, but only if I needed full control. For small projects, managed Typesense is much easier.
Want help setting up Typesense? Hit me up!