A while back I uploaded a video explaining what InsForge is, the open source alternative to Supabase that has its own MCP, a gateway with all AI models, and lets you build complete applications with backend, authentication, and database directly from the IDE with a simple prompt. And well, the video was pretty well received. But in the comments there was one thing that kept coming up: teach you how to install it on your own server.
And it makes total sense. It’s open source, so it can be done. And if you host it yourself, it’s free. No monthly subscription. So that’s what this post is about: installing InsForge on your own server, step by step, leaving nothing out. And when I say nothing, I mean everything that nobody explains properly in these tutorials: environment variables, Google login, GitHub login… all of it.
First things first: where do you install it?
This is actually flexible. InsForge is deployed with Docker, so you can install it wherever you want: on your computer, on a VPS, on a Raspberry Pi… the machine doesn’t matter.
That said, if you’re going to use it for real applications that other people will use, your personal computer is not the best idea. Think about it: InsForge will be your database and the entire backend of your application. If you shut down the computer, everything goes down. So for something serious, a VPS is the way to go.
I’m going to use one from Hostinger for this tutorial, but seriously use whichever you want. If you have an Oracle Cloud free-tier server, those work perfectly too. I explained in another video how to get one for free with 4 cores, 24GB of RAM and 200GB of disk. If you haven’t seen it, it’s on the channel. Just be aware, that server’s architecture is ARM and it can cause issues. You’ve been warned!
The minimum you need is a machine with 2GB of RAM. That’s more than enough to get started.
🎁 Exclusive offer: To access your server on Hostinger, go to hostinger.es/devknives and use the code DEVKNIVES to get a 10% discount.
Step 1: Connect to your server and install Docker
I’m assuming you already know how to connect via SSH to your server. If not, it’s as simple as opening a terminal and running:
ssh user@your_server_ipOnce inside, the first thing is to install Docker. Copy and paste this block of commands and run them all at once:
sudo apt update && sudo apt upgrade -y
sudo apt install ca-certificates curl gnupg lsb-release
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-compose-pluginTo verify it was installed correctly:
docker --versionIf it returns the version, great. Let’s continue.
Step 2: Clone the InsForge repository
The InsForge repository is public. You just need to clone it on your server:
git clone https://github.com/InsForge/InsForge.git
cd insforgeStep 3: Configure environment variables
Here’s the real meat of it. The repository includes an example file with all the variables. What you need to do is copy it and start filling it in:
cp .env.example .envOpen it with nano to edit it directly from the server:
nano .envOr if you have VS Code Remote SSH access, open it that way since it’s easier to read. Either way, we’re going to go through each variable because without this the application simply won’t start.
Port
PORT=7130Leave it as is. Before starting, make sure you don’t have anything running on that port. On a fresh server you won’t, but just in case you can check with sudo lsof -i :7130.
PostgreSQL
POSTGRES_USER=postgres
POSTGRES_PASSWORD=postgres
POSTGRES_DB=insforgePlease change this. The defaults are “postgres” and “postgres” which is the first thing someone would try in an attack. Generate something random. You can use this command to generate a secure password:
openssl rand -base64 32Copy what it returns and use it as the user or password. Each time you run the command it generates a different one, so go ahead.
Base URLs
API_BASE_URL=http://localhost:7130
VITE_API_BASE_URL=http://localhost:7130Leave them as they are for now. Once you have your domain configured, change them to your URL. (For example https://db.yourdomain.com) But for the first installation and test, localhost is fine.
JWT Secret
JWT_SECRET=your-hash-hereThis is the secret used to encrypt authentication tokens. It needs to be a long, random hash. To generate it:
openssl rand -base64 64Copy the result and paste it there. The longer the better - the harder it is to break.
Admin
ADMIN_EMAIL=your@email.com
ADMIN_PASSWORD=very-secure-passwordThis is the access to the InsForge admin panel. The email doesn’t need to actually exist, but use one you’ll remember. And the password: generate another hash with the same command and use it as the password. That way they never repeat and are impossible to guess.
Encryption Key
ENCRYPTION_KEY=another-different-hashTechnically you could use the same value as JWT_SECRET, but the right thing to do is have a different key for each purpose. Generate a new one with the same command and you’re done.
Access API Key
ACCESS_API_KEY=ik_your-hash-hereAnother hash. But pay attention to this: it must mandatorily start with ik_. If it doesn’t start with ik_, it won’t work. So you generate the hash, copy it, and prepend ik_ to it:
# Generate it like this
openssl rand -base64 32
# And paste it as: ik_GENERATED_HASHCloud API Host
CLOUD_API_HOST=Leave it empty. This is for the cloud version of InsForge but we’re doing self-hosted, we don’t need it.
Storage with Cloudflare R2
Now comes file storage. By default the example file is set up for AWS S3, and you can use it if you want. But I personally prefer Cloudflare R2 because it has a very generous free tier and I’ve been using it on various projects for a while without paying anything.
R2’s free tier includes 10GB of storage, 1 million write operations and 10 million read operations per month. For most projects that’s more than enough without spending a dime.
The good news is that R2 is compatible with the S3 API, so even though the variables are called S3_*, they work perfectly with Cloudflare. Same API, different provider, and free.
How to create the bucket and credentials step by step
1. Go to your Cloudflare dashboard (dash.cloudflare.com) and look for R2 Object Storage in the side menu. If it’s your first time you’ll be asked to activate the service, just click activate.
2. Create a new bucket. Click Create bucket, give it a name (for example insforge-storage) and select the region closest to you. In Europe the most common is WEUR (Western Europe). Click Create bucket and you’re done.
3. Get the endpoint URL. Once the bucket is created, go inside it and at the top you’ll see something like:
Endpoint: https://abc123def456.r2.cloudflarestorage.comThat abc123def456 is your Cloudflare Account ID. Copy it, that’s what you’ll put in S3_ENDPOINT_URL.
4. Generate API credentials. Go back to the R2 main page and at the top right you have the Manage R2 API tokens button. Click it and then Create API token.
- Give it a descriptive name, for example
insforge-token - Under permissions select Object Read & Write (read and write)
- Under Specify bucket select the bucket you just created
- Click Create API Token
It will show you the credentials only once. Don’t close that screen until you’ve copied them.
Now you have everything to fill in the three variables:
S3_ACCESS_KEY_ID=the-access-key-id-cloudflare-gave-you
S3_SECRET_ACCESS_KEY=the-secret-access-key-cloudflare-gave-you
S3_ENDPOINT_URL=https://YOUR_ACCOUNT_ID.r2.cloudflarestorage.comImportant: The endpoint doesn’t include the bucket name at the end, just the Account ID. Also note that you need to set
AWS_S3_BUCKETto the name of the bucket you created:
AWS_S3_BUCKET=insforge-storage
Logs
LOGS_DIR=Empty. By default InsForge saves logs in a ./logs folder and you don’t need to touch anything.
OpenRouter
OPENROUTER_API_KEY=This is for the unified AI gateway that InsForge includes. If you don’t plan to use it, leave it empty. If you want to use it, go to openrouter.ai, create an account and generate an API key. With the free models you don’t need to put any money in, and if you want paid ones it’s like any other platform: load credits and spend.
PostHog (development mode)
VITE_PUBLIC_POSTHOG_KEY=Empty. This is only needed if you run InsForge in development mode. We’re deploying in production, so it doesn’t affect us.
OAuth: social login
And here we get to the part everyone wanted. Login with Google, GitHub, Microsoft, Discord, LinkedIn, X and Apple. I’ll explain how to do each one. The good thing is you don’t have to configure all of them, only the ones you’re interested in. The ones you leave empty simply won’t appear as a login option.
GOOGLE_CLIENT_ID=
GOOGLE_CLIENT_SECRET=For Google login you need to create an OAuth application in Google Cloud Console. It looks intimidating but it’s quite guided.
1. Go to Google Cloud Console and sign in with your Google account. If it’s your first time you might see a welcome screen with a free trial, they ask for a card but won’t charge you. If you can avoid it, do so, but if you have no other option to get in, know that it won’t charge you as long as you don’t use paid services.
2. Create a new project. At the top left you have the project selector. Click it and then New Project. Give it a name, for example InsForge, and click Create.
3. Configure the OAuth consent screen. In the side menu look for APIs & Services > OAuth consent screen. This is where you configure how the login screen will look to your users.
- Select External (so anyone can sign in, not just people in your organization)
- Fill in the App name (for example
InsForge), a support email and the developer email (can be the same as yours) - Under Authorized domains add your domain (for example
yourdomain.com, without the https) - Click Save and continue until the end, the rest of the fields are optional
4. Create credentials. Go to APIs & Services > Credentials, click Create Credentials and select OAuth 2.0 Client IDs.
- Under Application type select Web application
- Give it a name, for example
InsForge Web - Under Authorized redirect URIs click Add URI and enter exactly this with your real domain:
https://yourdomain.com/auth/callback/googleClick Create.
A window will appear with the Client ID and Client Secret. Copy them and paste them into the .env variables.
An important note about Testing mode: when you create the OAuth app in Google, it starts in Testing mode and you can only add up to 100 test users manually in the Test users section. If you want anyone to sign in without restrictions, you need to publish the app by going to OAuth consent screen and clicking Publish App.
Google will ask you to go through a verification process where you justify why you’re using the login. For InsForge you basically explain that it’s a personal project management tool. It’s not complicated but it can take a few days. In the meantime, with Testing mode you can test it by adding your own email as a test user and it works perfectly.
GitHub
GITHUB_CLIENT_ID=
GITHUB_CLIENT_SECRET=This is the easiest of all and the one I recommend configuring no matter what because you can have it done in two minutes.
1. Sign in to GitHub, go to your profile picture (top right) > Settings.
2. In the side menu, scroll down to the bottom and click Developer settings.
3. Inside Developer settings, click OAuth Apps and then New OAuth App.
4. Fill in the form:
- Application name: InsForge (or whatever name you want)
- Homepage URL: the URL of your InsForge, for example
https://yourdomain.com - Application description: optional, you can leave it empty
- Authorization callback URL: this is the important one, enter exactly this:
https://yourdomain.com/auth/callback/githubClick Register application.
5. Once the app is created, you can see the Client ID directly on the screen. For the Secret you need to click the Generate a client secret button. It shows it to you only once so copy it right then, don’t lose it.
Copy both values, paste them into the .env variables and you’re done. No verifications, no waiting, no one reviewing anything. It’s instant. That’s why it’s my favorite one to configure.
Microsoft
MICROSOFT_CLIENT_ID=
MICROSOFT_CLIENT_SECRET=Head over to the Azure Portal, to Azure Active Directory > App registrations, register a new application and get the Client ID and create a Client Secret from there. It’s a bit more involved than GitHub because Azure is always like that, but it’s not complicated. The redirect URL would be:
https://yourdomain.com/auth/callback/microsoftDiscord
DISCORD_CLIENT_ID=
DISCORD_CLIENT_SECRET=Go to the Discord developer portal, create a new application, go to OAuth2 and you have the credentials there. Quick and easy. The callback URL:
https://yourdomain.com/auth/callback/discordLINKEDIN_CLIENT_ID=
LINKEDIN_CLIENT_SECRET=Go to the LinkedIn developer portal, create an app and give it Sign In with LinkedIn permissions. The credentials are given to you directly in the app settings.
X (Twitter)
X_CLIENT_ID=
X_CLIENT_SECRET=Go to the X Developer Portal, create a project and an app. It always asks you to explain what you want the app for, which is a bit tedious, but nothing major. The callback URL:
https://yourdomain.com/auth/callback/xApple
APPLE_CLIENT_ID=
APPLE_CLIENT_SECRET=This is the most painful of all and I say that from experience. To use it you need an Apple Developer Account, which already costs $99 per year. Then you have to create a Services ID, a Key, and APPLE_CLIENT_SECRET is not a regular key: it has to be a JSON with the teamId, keyId and the private key in PKCS#8 format.
If you don’t have apps published on the App Store and don’t plan to, I wouldn’t bother with this at all. Leave it empty.
Cloud and Deno variables
DEPLOYMENT_ID=
PROJECT_ID=
APP_KEY=
DENO_SUBHOSTING_TOKEN=
DENO_SUBHOSTING_ORG_ID=All empty. The first three are only for the official InsForge cloud version. The Deno ones aren’t needed either because Docker already spins up its own Deno instance internally.
And with that… we’re done with environment variables. I know it seems like a lot, but most of them stay empty. The important ones are PostgreSQL, the JWT Secret, the admin and the storage. Everything else is optional depending on what you need.
Step 4: Launch the container
Now we’re actually doing it. With everything configured, let’s start InsForge. The important detail here is that a plain docker compose up won’t work. You need to use the production-specific file:
docker compose -f docker-compose.prod.yml up -dThis downloads the necessary images and starts all the services in the background. The first time it can take a few minutes depending on your connection. You can watch the logs in real time with:
docker compose -f docker-compose.prod.yml logs -fWhen you see that all services are healthy, everything is working.
Alternative option: deploy with Coolify
If you have Coolify installed on your server, the installation is even simpler than through terminal. Coolify already comes with Traefik to handle HTTPS, so you skip the domain part.
What you need to do is create a new resource in Coolify of type Git with public URL, enter the InsForge repository URL and tell it to use docker-compose.prod.yml as the configuration file.
One important detail: you need to convert all repository files to “file” in the Coolify files section, because otherwise InsForge won’t start. And then you need to manually copy the functions folder to the application directory:
cp -r /path/to/repo/functions /data/coolify/applications/YOUR_APP_ID/functionsEnvironment variables are edited directly from the Coolify variables panel, exactly the same ones we went through before. Much more visual and comfortable.
Step 5: Assign a domain
Accessing InsForge by IP and port is not suitable for real use. Let’s give it a domain.
If you use Coolify, it’s a breeze. In the application configuration you enter your domain or subdomain, and in your DNS manager (for example Cloudflare) you create an A record pointing that domain to your server’s IP. Coolify handles HTTPS automatically with Traefik.
If you installed it through terminal, you need to install Caddy, which is a very simple web server that manages HTTPS automatically without extra configuration:
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddyOnce installed, edit the Caddyfile:
sudo nano /etc/caddy/CaddyfileAnd put this:
insforge.yourdomain.com {
reverse_proxy localhost:7130
}Save it, reload Caddy:
sudo systemctl reload caddyAnd now configure the DNS so that your domain points to the server. I explain it right below.
How to configure DNS to point to your server
You need to know two things: your server’s public IP and where your domain’s DNS is managed (usually in the same place where you bought the domain, or in Cloudflare if you’ve pointed it there).
How to find your server’s IP:
If you have terminal access to your server, run:
curl ifconfig.meIt returns the public IP directly. Note it down.
If you bought it on Hostinger, DigitalOcean or similar, the IP is also in your provider’s control panel next to your VPS information.
Configure the DNS record in Cloudflare:
If you manage your DNS in Cloudflare (which is the most common and what I recommend), go to dash.cloudflare.com, select your domain and go to the DNS > Records tab.
Click Add record and fill it in like this:
| Field | Value |
|---|---|
| Type | A |
| Name | insforge (or whatever subdomain you want) |
| IPv4 address | your server’s IP |
| Proxy status | DNS only (grey cloud, not orange) |
| TTL | Auto |
Important: If you leave it in Proxied mode (orange cloud), Cloudflare acts as an intermediary and can break the WebSocket connections that InsForge uses for real-time. With grey it goes directly to your server without going through Cloudflare.
Click Save. DNS propagation in Cloudflare is almost instant, usually working in less than a minute.
If you have DNS with another provider (GoDaddy, Namecheap, Hostinger itself…) the process is the same: create a type A record with the subdomain name and your server’s IP. The interface varies slightly between providers but it’s always the same thing.
Once propagated you can reload Caddy and access your InsForge with the domain:
Step 6: Verify everything works
Go to your domain in the browser and you should see the InsForge login screen. If something fails, the first thing to do is check the logs:
docker compose -f docker-compose.prod.yml logs appIf everything is fine, sign in with the admin email and password you set in the ADMIN_EMAIL and ADMIN_PASSWORD variables. And you’re in.
Connect the MCP to your IDE
Once inside the dashboard, InsForge gives you the command to add the MCP to your IDE directly. Copy it, paste it into your IDE settings (Cursor, Claude Desktop, VS Code with Copilot…) and your agent is connected to your own instance.
To test it’s working, ask the agent something like: “what can you do with InsForge?” and it should respond describing the MCP capabilities. If you see it can access the dashboard and responds with real information, everything is working.
From there you can create tables, configure authentication, manage serverless functions… all from your IDE chat, with your own InsForge instance running on your server. Without paying anything per month.
What if I prefer to migrate from Supabase?
If you currently have projects on Supabase and want to move them to InsForge, there are ways to do it. If you’d like me to make a specific tutorial on how to migrate data from Supabase to InsForge, leave it in the comments. Personally I think InsForge works considerably better, especially in the self-hosted version, and I haven’t had the problems that Supabase gave me.
Also, if you want an in-depth comparison between the two to help you decide, let me know. Happy to do it.
That’s it. I know it seems long written out like this, but the actual process is quite fast. What takes time is the first time you fill in all the environment variables and understand what each one does. After that, the installation itself is a matter of minutes.
If this helped you, give the video a like, it doesn’t cost anything, and subscribe if you haven’t already. And any questions you have, leave them in the comments - I try to respond to everything.
What do you think?
Leave your opinion, question or suggestion. Comments are synced with GitHub Discussions .