DEV Community: Lukas Mauser

Deploy Django on a VPS with Docker: Step-by-Step Guide

Lukas Mauser — Fri, 26 Dec 2025 16:54:21 +0000

Deploying a Django application on a Virtual Private Server (VPS) is a cheap, privacy friendly and flexible way to host your projects. In this guide, we'll walk you through the process of deploying a Django app on a VPS using Docker. We'll cover everything from setting up your Django app for Docker, choosing a VPS provider, configuring the server, and deploying the app.

Who is this guide for?

This guide is for you if you:

are curious about self-hosting and want to learn some fundamentals
want to run small projects or side projects
want to save money on hosting costs

This guide is not for you if you:

are looking for the absolute fastest way to get started
want to avoid ongoing maintenance
need to run mission-critical workloads and don't know what you're doing

For a simple, managed way to get started, check out our product: sliplane.io

Prerequisites

A Django application, ready to be deployed
An account on Hetzner (or other your preferred VPS provider)
A domain name

In a nutshell

We will use Docker to containerize our Django app and Postgres as a database. Then, we'll choose a VPS provider, set up the server, and deploy the app using Docker Compose and a reverse proxy (Caddy) for SSL termination.

Dockerize the Django app

Why Docker?

Docker makes it easy to run custom software in the cloud. You can define everything your Django app needs in a Dockerfile and then spin up the app in an isolated container with all dependencies installed.

For example, our Django app requires a specific version of Python and a web server (like Gunicorn) to handle requests. We can define all of that in a Dockerfile and then build an image from it. Once the image is built, we can run it on our server.

We can also run a Postgres database in another container and connect our Django app to it without running into dependency conflicts. Docker gives you access to a huge ecosystem of prebuilt images for databases, caches, web servers, and much more.

Setting up Docker for Django

If you want a detailed introduction, check out my Django in Docker tutorial.

TL;DR: Create two files named Dockerfile and docker-compose.yml in the root of your Django project and add the following content:

Dockerfile:

# Stage 1: Base build stage
FROM python:3.13-slim AS builder

# Create the app directory
RUN mkdir /app

# Set the working directory
WORKDIR /app

# Set environment variables to optimize Python
ENV PYTHONDONTWRITEBYTECODE=1
ENV PYTHONUNBUFFERED=1 

# Upgrade pip and install dependencies
RUN pip install --upgrade pip 

# Copy the requirements file first (better caching)
COPY requirements.txt /app/

# Install Python dependencies
RUN pip install --no-cache-dir -r requirements.txt

# Stage 2: Production stage
FROM python:3.13-slim

RUN useradd -m -r appuser && \
   mkdir /app && \
   chown -R appuser /app

# Copy the Python dependencies from the builder stage
COPY --from=builder /usr/local/lib/python3.13/site-packages/ /usr/local/lib/python3.13/site-packages/
COPY --from=builder /usr/local/bin/ /usr/local/bin/

# Set the working directory
WORKDIR /app

# Copy application code
COPY --chown=appuser:appuser . .

# Set environment variables to optimize Python
ENV PYTHONDONTWRITEBYTECODE=1
ENV PYTHONUNBUFFERED=1 

# Switch to non-root user
USER appuser

# Expose the application port
EXPOSE 8000 

# Start the application using Gunicorn
CMD ["gunicorn", "--bind", "0.0.0.0:8000", "--workers", "3", "myproject.wsgi:application"]

docker-compose.yml:

services:
  web:
    build: .
    ports:
      - "8000:8000"
    env_file:
      - .env
    depends_on:
      - db

  db:
    image: postgres:17
    volumes:
      - postgres_data:/var/lib/postgresql/data
    env_file:
      - .env

volumes:
  postgres_data:

To test locally, make sure Docker is installed and running. Install Docker.
You can test locally if everything works by running:

docker compose up

This spins up the django app and a postgres database. You can access the django app at http://localhost:8000. Before you deploy your Django app, make sure everything works locally.

Build and push the Django Docker image

The compose file above is great for local development, but not ideal for production, because it requires the server to build the image every time a new version is deployed. In production, you want to prebuild your Django app and store it in a container registry, so your server can simply pull the image and run it (just like the Postgres container).

You can build your image using this command:

docker build -t my-django-app .

After the image is build, we will push it to a container registry - a warehouse for Docker images.

Push to a container registry:
I recommend GitHub Container Registry (GHCR) because it's free for private images. To get started, create a personal access token in GitHub first.

Make sure the token has write:packages, read:packages, and delete:packages scopes. See GitHub's docs for details.

You can then use this token to authenticate which is required to push images to your private workspace:

Authenticate with GHCR:

echo $GITHUB_TOKEN | docker login ghcr.io -u YOUR_GITHUB_USERNAME --password-stdin

Tag and push your image:

docker tag my-django-app ghcr.io/YOUR_GITHUB_USERNAME/YOUR_REPO_NAME:latest
docker push ghcr.io/YOUR_GITHUB_USERNAME/YOUR_REPO_NAME:latest

Here we use the latest tag for simplicity, but you can use semantic versioning or git commit hashes for better version control and rollbacks.

Every time you make changes to your Django app, rebuild and push the image. You might see how this can get tedious with frequent deployments, which is why these steps are often automated in a CI/CD pipeline. I won't go into the details in this tutorial, but I created a seperate post about how to create a CI/CD pipeline with GitHub Actions.

When the image is pushed, it's time to set up the server.

Choosing a VPS

1. What VPS to choose?

We compared some popular providers in this post on the top 5 cheap VPS providers and have had great experiences with Hetzner. They're affordable, reliable, and we've deployed thousands of servers with them. If you use our Hetzner affiliate link, you'll get €20 in credit.

2. How big does my VPS need to be?

Start with the smallest option available and scale up as needed. You'd be surprised how far a basic VPS can get you — a Postgres database and a small Django app can run on as little as 1GB of RAM. You can always resize your server later. Start simple: run both the database and Django app on the same server (see our guide on running multiple apps on a single VPS). Only worry about more complex setups when you actually need to scale.

3. Where do I want my VPS to be located?
Choose a location close to your users for best performance. If latency isn't a big concern, pick the cheapest location. Prices vary due to electricity, taxes, etc. Hetzner, for example, has data centers in Germany and Finland that are usually cheaper than other locations.

4. What processor architecture - x86 or arm?

Arm is getting more popular because it's cheaper, but we've run into availability issues and some software compatibility problems. We usually stick with x86. If you develop on x86 and deploy on arm, you might hit unexpected issues. The good thing about VPSs: you only pay for the time your server runs, so you can test an arm server for a few cents and switch back to x86 if needed.

5. Shared or dedicated?

Start with shared and upgrade if necessary. Shared is generally slower and can sometimes be unpredictable, so provider choice matters. With Hetzner, we've had good experiences and shared server performance has been consistent and reliable.

6. What OS to choose?
Linux is the way to go for servers: it's free, secure, and reliable. The most popular distributions for servers are Ubuntu, Debian, CentOS, Fedora, and Arch Linux.

I use Ubuntu because that's what I learned on—use the latest LTS version available. Differences between distributions are mostly a matter of preference. If you're unsure, go with Ubuntu. If you have specific requirements, you'll know what to do.

In general, stick with what's popular so you can find help online when needed.

Setting up the server

Connect to your server

After your server is set up and running, connect to it via SSH. By default, most providers give you a root user and password, but you can often provide your SSH public key during setup for more security.

Open a terminal on your local machine and run:

ssh root@your-server-ip

Replace your-server-ip with the IP address of your server. You can usually find it in your VPS provider's dashboard or in a welcome email.

If you're new to SSH, check out this guide from github about how you can generate ssh keys and add them to your agent.

Hardening the server

Hardening means making it harder for attackers to compromise your server. This should be the first thing you do after setup. Measures include disabling root login, using SSH keys instead of passwords, setting up a firewall, keeping your system updated, using fail2ban, etc. It's good practice to use a hardening script so you don't forget anything important. I don't want to provide an outdated script here, but you can find plenty of good hardening scripts online or write your own. If you use a script from the internet, make sure you understand what it does and trust the source.

Firewall

Hetzner offers a simple firewall you can configure via their dashboard. Only allow traffic on ports 22 (SSH), 80 (HTTP), and 443 (HTTPS).

It's recommended to use the Hetzner firewall in addition to a local firewall like UFW or iptables, since it blocks traffic before it reaches your server. This saves resources and adds an extra layer of protection (especially since Docker can sometimes bypass local firewalls).

Install Docker

Follow the official Docker install guide to install Docker on your server.

Now we're ready to deploy our Django app.

Run the django app on your server

We'll use Docker Compose again to run both the Django app and the Postgres database. However, we need to modify the compose file slightly for production.

First, set up your environment variables. You can use Docker secrets or .env files to store sensitive data like database passwords. For a simple setup, create a .env file in the project directory on the server:

POSTGRES_DB=mydb
POSTGRES_USER=myuser
POSTGRES_PASSWORD=mypassword
DATABASE_URL=postgres://myuser:mypassword@db:5432/mydb
DJANGO_SECRET_KEY=your-secret-key

If you're a bit more serious about security, consider using Docker secrets instead.

Here are 2 changes we need to make to the docker-compose.yml for production:

Change the web service to pull the prebuilt image from your container registry instead of building from source. We'll also introduce a third service: a reverse proxy.
Add a reverse proxy service. The reverse proxy is necessary in production, because it handles SSL termination and forwards requests to your Django app running in Docker. Most reverse proxies can also do some other cool tricks, like caching requests, compressing responses, and more. I compared 5 different reverse proxies in this post. One of the simplest is Caddy, which comes with automatic SSL via Let's Encrypt and is very easy to configure.

Your final docker-compose.yml will look like this:

services:
  web:
    image: ghcr.io/YOUR_GITHUB_USERNAME/YOUR_REPO_NAME:latest
    ports:
      - "8000:8000"
    env_file:
      - .env
    depends_on:
      - db

  db:
    image: postgres:17
    volumes:
      - postgres_data:/var/lib/postgresql/data
    env_file:
      - .env

  caddy:
    image: caddy:2.10.2
    restart: unless-stopped
    cap_add:
      - NET_ADMIN
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - $PWD/conf:/etc/caddy
      - caddy_data:/data
      - caddy_config:/config

To configure Caddy, create a conf directory in the same location as your docker-compose.yml file and add a Caddyfile inside it:

yourdomain.com {
  reverse_proxy web:8000
}

This will make sure Caddy forwards all requests from your domain to the Django app running on port 8000. It's important to provide your actual domain name here, as Caddy uses it to obtain SSL certificates automatically. Use A/AAAA records to point your domain to your server's IP address so requests reach your server.

Once your domain is setup and points to your server, you can spin up the services. On the server, authenticate with your container registry first (see previous section), then run:

docker compose up -d

That's it! Your Django app should now be running on your VPS.

To deploy a new version of your app, pull the new image and restart the web service:

docker compose pull web
docker compose up -d web

As mentioned before, you can automate deployments with a CI/CD pipeline.

Summary

Deploying Django on a VPS is cheap and a great way to learn about infrasturcture.

What we used in this guide:

Docker to containerize the Django app
Postgres as the database
Caddy as a reverse proxy for SSL termination
Hetzner as the VPS provider
GitHub Container Registry to store the Docker image

There are endless ways to improve this setup: add backups, monitoring, logging, scaling, and more. When you start your self-hosting journey, prepare to learn a lot! If you want to save yourself some hassle, check out our product: sliplane.io, which comes with all of this out of the box. It's a middle ground that gives you the best of self-hosting without the pain of ongoing server maintenance.

5 easy ways to deploy Docker containers

Lukas Mauser — Wed, 05 Nov 2025 10:39:15 +0000

It's easy to spin up containers locally. However, if you want to deploy them it can be a bit intimidating. But the hosting landscape drastically changed in recent years — now there are plenty of options available that make hosting containers simple. Let's look at 5 different options ranked by complexity, starting with the easiest way to deploy your containers!

At a glance - ordered by simplicity:

Sliplane provides the easiest solution for deploying containerized applications at a reasonable price.
Render offers advanced scaling features and is also simple and straightforward to use, but it comes at a premium price point.
Digital Ocean's App Platform can be seen as a middleground between Sliplane and Render in terms of simplicity, pricing and scalability.
Coolify simplifies hosting containers on virtual private servers. It's open source and therefore a cheap option but on the other hand requires some ongoing maintenance effort.
Hetzner provides plain virtual private servers - it offers the most flexibility, but also requires the most setup and maintenance effort

1. Sliplane

Sliplane is arguably one of the easiest ways to deploy containerized applications. It's a European hosting platform focused on one thing and one thing only: containers.

You can quickly spin up containers from a registry like Docker Hub or GitHub Container Registry or build and deploy your own code directly from a GitHub repository.

attach persistent volumes
automatic daily volume backups
automatic build and deployment pipelines
secrets management
custom domains
SSL
and much more...

One of the key selling points is the fact that you don't pay extra for every service that you deploy. Instead, you pay per server and you can deploy as much as your server can handle.

If you are looking for a simple and cost-effective way to deploy your containers with minimal overhead, Sliplane is the way to go.

2. Render

Looking at simplicity, Render is a great option as well — it comes with an intuitive UI to make deploying containers buttery smooth.

Additionally, Render offers some advanced scaling features that allow you to handle huge traffic and also offers additional features like fully managed databases, for example.

The main difference in comparison to Sliplane: the price point.

While Render is also very simple to use and abstracts many of the infrastructure-level tasks, it comes at a premium price point. Depending on your configuration, compute, storage, and bandwidth costs can be up to 10x higher than Sliplane's, and you will be charged extra for collaborators.

3. DigitalOcean

DigitalOcean is a classic. They provide a wide range of services from bare metal to managed Kubernetes to their fully managed App Platform that you can use to deploy containers.

Looking at simplicity, App Platform is their easiest product to get started. It's a higher-level abstraction on top of Kubernetes and can be categorized as the middle ground between Sliplane and Render.

In comparison to Render, DigitalOcean's App Platform is cheaper but lacks some convenience features here and there, although the differences are nuanced.

Compared to Sliplane, DigitalOcean's App Platform is more expensive but has more advanced scaling features. A key differentiator is Sliplane's focus on containers, which makes the transition from local development to deploying the container more seamless, while you might have to spend a thought more about how to wrap your app in DigitalOcean concepts.

4. Coolify

Coolify is an open-source PaaS. As stated on the website, it's a self-hostable alternative to popular commercial PaaS providers like the three mentioned above. In addition to the self-hosted version, they also provide a managed plan for Coolify.

The big difference: you bring your own servers. This means you can rent virtual private servers from a cloud provider of choice and Coolify handles the deployments.

The big benefit: it's cheap! You can rent a powerful VPS from $5 per month and only pay for the compute resources. In addition to that, you get full control over your servers and you can reduce third-party dependencies.

The downside: you still need to manage these servers — keep the operating system up to date, install the latest patches and make sure to keep them secure. While Coolify is a big improvement in comparison to a plain VPS, the setup and maintenance are still more complicated compared to a fully managed PaaS.

5. Hetzner

Hetzner is a cloud provider that is known for cheap and reliable infrastructure. They provide virtual private servers with a great price-to-performance ratio.

When it comes to deploying Docker containers, using a plain VPS is still a great choice.

To be fair, it's not the easiest way to deploy a container, but it gives you the flexibility that you need to deploy anything.

Compute prices are unbeatable, but you're trading time for money.

You can use our affiliate link to get a 20€ discount.

Summary

Sliplane is aguably the easiest way to get your containers running in the cloud for an affordable price. Render and Digital Ocean are also great managed solutions, they are more scalable but more expensive and don't have the same focus on containers as Sliplane. Coolify is an honorable mention, as an affordable open source option. If you want full control, I recommend Hetzner as a VPS provider.

Disclaimer: The options listed above have been carefully handpicked by a human and are carefully chosen. I do get a kickback from Hetzner if you signup through the link and as a co-founder, I'm biased with Sliplane.

Does it Make Sense to Run WordPress in Docker?

Lukas Mauser — Thu, 07 Aug 2025 10:30:33 +0000

I've had my ups and downs with WordPress, I'm not a hardcore fan to be honest, but you can't deny it's popularity.

You can use Docker to spin up an instance of WordPress on your local computer and in the cloud. But does it make sense to use WordPress in Docker?

When it doesn't make sense to run Wordpress in Docker

For non technical users, running Docker locally is usually too much overhead. It comes with a learning curve and there are other tools that make getting started much easier:

Local development tools like XAMPP, MAMP, or Local
Managed hosting - ditch the local setup and go straight to a managed WordPress platform like WordPress.com, WP Engine, or Kinsta
Traditional shared hosting: still the cheapest option for basic WordPress sites

You can still use Docker of course, there is nothing inherently wrong with a WordPress in Docker setup. In fact, there are some good reasons to...

When it makes sense to run WordPress in Docker

If you are a developer on the other hand and maybe even work in a team with frequent WordPress deployments, running WordPress in Docker makes a lot of sense. It is really useful to mirror the production environment on your own machine for development and easily share it with the team so all developers have consistent environments, especially if you work on multiple sites with different PHP versions, databases, or OS plugins.

In combination with Sliplane, you can easily deploy your containerized apps and share progress internally and with clients, integrate the deployment into a QA pipeline or run it in production.

I know a lot of developers who don't want to deal with Docker at all and I used to be that guy as well. In the beginning it can feel like a lot of painful overhead to get the setup going. However, there will be a turning point, after you got your head wrapped around some basic Docker concepts and at that point you don't want to go back!

Can you run WordPress in Docker in production?

Absolutely. Running WordPress in Docker is possible in a production setting as well.

If you are familiar with Docker, it's fairly easy to spin up small to medium sized WordPress-in-Docker setups, the harder thing is keeping it secure and performing consistent maintenance. If you don't want to deal with that it's probably a good idea to go with a managed Docker hosting solution.

Some benefits of running WordPress in Docker:

very flexible, you can add and install anything
affordable: you get big compute for little money
portable, you can easily move to a different host
it's widely adopted

Running WordPress in Docker can get challenging, once you reach a certain size with tens of thousands of pages, millions of monthly active users and hundreds of Gigabytes of file storage. But even then, with a few tweaks the setup can scale very large. Here are some things to think about, although I usually recommend to only add these components, once you really need them (and you can feel that: slow site, storage full, crashes, ...)

Persistent storage, it's okay to store themes on your server, however when it comes to media, you're better of with choosing an object storage provider. There are plugins like Media Cloud that make the switch very easy.
Caching, at a certain scale it makes sense to add caching to speed up requests, for example use Redis via the Redis Cache plugin
Separate Database: move the database to a separate machine. It makes sense to keep the database in the same network though and use private connections if possible.
Load Balancing: If vertical scaling does not do the trick any more, you can add a load balancer in front of your WordPress instance and spread the load to multiple instances. This requires your WordPress containers to be stateless though

How to Run WordPress in Docker

We need to setup two containers:

Database container (MySQL/MariaDB) - stores your WordPress content, users, settings, etc.
WordPress container - runs the PHP application and serves your website

Using Docker CLI

Let's start by creating a network, so the containers can communicate with each other:

# Create a network
docker network create wordpress-network

Next, spin up the database container, we'll use MySQL:

# Run MySQL
docker run -d \
  --name wordpress-db \
  --network wordpress-network \
  -e MYSQL_DATABASE=wordpress \
  -e MYSQL_USER=wp_user \
  -e MYSQL_PASSWORD=wp_pass \
  -e MYSQL_ROOT_PASSWORD=root_password \
  -v mysql_data:/var/lib/mysql \
  mysql:9.4

Breaking down this command:

docker run -d - Runs the container in detached mode (in the background)
--name wordpress-db - Gives the container a friendly name we can reference
--network wordpress-network - Connects the container to our custom network
-e MYSQL_DATABASE=wordpress - Creates a database called "wordpress"
-e MYSQL_USER=wp_user - Creates a MySQL user for WordPress to use
-e MYSQL_PASSWORD=wp_pass - Sets the password for that user
-e MYSQL_ROOT_PASSWORD=root_password - Sets the MySQL root password
-v mysql_data:/var/lib/mysql - Creates a persistent volume to store database data
mysql:9.4 - Uses the official MySQL 9.4 Docker image

Now that our database is running, we can deploy the WordPress container:

# Run WordPress
docker run -d \
  --name wordpress-site \
  --network wordpress-network \
  -p 8080:80 \
  -e WORDPRESS_DB_HOST=wordpress-db:3306 \
  -e WORDPRESS_DB_NAME=wordpress \
  -e WORDPRESS_DB_USER=wp_user \
  -e WORDPRESS_DB_PASSWORD=wp_pass \
  -v wordpress_data:/var/www/html \
  wordpress:latest

Breaking down this command:

docker run -d - Runs in detached mode
--name wordpress-site - Names the container for easy reference
--network wordpress-network - Connects to the same network as our database
-p 8080:80 - Maps port 8080 on your computer to port 80 in the container
-e WORDPRESS_DB_HOST=wordpress-db:3306 - Tells WordPress where to find the database (using the container name)
-e WORDPRESS_DB_NAME=wordpress - Specifies which database to use
-e WORDPRESS_DB_USER=wp_user - Database username (must match what we set in MySQL)
-e WORDPRESS_DB_PASSWORD=wp_pass - Database password (must match what we set in MySQL)
-v wordpress_data:/var/www/html - Persists WordPress files and uploads
wordpress:latest - Uses the official WordPress Docker image

Your WordPress site will be available at http://localhost:8080.

Using Docker Compose

You can also use Docker Compose to simplify the process:

Create a docker-compose.yml file:

services:
  wordpress:
    image: wordpress:latest
    ports:
      - "8080:80"
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_NAME: wordpress
      WORDPRESS_DB_USER: wp_user
      WORDPRESS_DB_PASSWORD: wp_pass
    volumes:
      - wordpress_data:/var/www/html
    depends_on:
      - db

  db:
    image: mysql:9.4
    environment:
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wp_user
      MYSQL_PASSWORD: wp_pass
      MYSQL_ROOT_PASSWORD: root_password
    volumes:
      - db_data:/var/lib/mysql

volumes:
  wordpress_data:
  db_data:

Then run:

docker-compose up -d

Deploy WordPress in Docker

There are a few providers that you can deploy your containers to. If you are looking for a solution with minimum overhead, I recommend Sliplane.

Step 1: Create a New Project

Visit Sliplane and sign in with your GitHub account.
Click "Create Project" and give your project a name (e.g., WordPress). This project will serve as the container environment where you’ll deploy two services: one for MySQL and one for WordPress.

Step 2: Deploy a MySQL Service

Inside the project dashboard, click "Deploy Service."
Create a new server to host your MySQL service. You can select the location and server type, the base server should be strong enough to get started.
Choose the "MySQL" preset from the available services. This preset uses the bitnami/mysql image under the hood and comes with sensible default configurations. You can also use other database containers like MariaDB, which work similarly with WordPress.
Review Configuration: The MySQL preset comes preconfigured and can be deployed as is, but you can customize it further if needed. I recommend turning off public access to the database for security reasons.
Click "Deploy Service" and wait a few seconds for the deploy to finish.

Step 3: Deploy a WordPress Service

After your MySQL service is successfully deployed and running, the next step is to deploy the WordPress CMS container. This container will connect to your MySQL database to store and retrieve data.

Inside your "WordPress" project, click "Deploy Service" again.
Select the server that your MySQL service is running on.
Select "Registry" as the deploy source
In the "Image URL" field, type "wordpress" and choose the official WordPress image from the dropdown. We go with latest version, but you can choose a specific tag if wantet.
In the Environment Variables section, configure the following:

   WORDPRESS_DB_HOST=internal-mysql-hostname
   WORDPRESS_DB_NAME=wordpress
   WORDPRESS_DB_USER=wp_user
   WORDPRESS_DB_PASSWORD=wp_pass

Important: Make sure these values match exactly with what you configured in your MySQL service. The WORDPRESS_DB_HOST should use the internal host name of your MySQL container.

Add a new volume with a name of your choice and set the mount path to "/var/www/html". This is where your WordPress files and uploads will be stored.
Finally, give the service a name and hit "Deploy Service".

After the deploy is finished, you can access your WordPress site at the URL that has been assigned and continue with the installation.

Summary

For non-technical users, traditional hosting is easier, however, for developers who want to maintain consistent environments and work as close to production as possible, using WordPress in Docker is a great choice.

You can also run WordPress-Docker setups in production, but it requires some technical knowledge and if you don't want to deal with deal with the overhead, a managed solution like Sliplane is the way to go.

[Boost]

Lukas Mauser — Fri, 25 Jul 2025 05:29:49 +0000

How to Run Payload CMS in Docker

Lukas Mauser ・ Jul 21

#webdev #docker #programming #javascript

Best FREE Secrets Manager - Deploy Infisical on Sliplane with Docker

Lukas Mauser — Thu, 24 Jul 2025 07:37:56 +0000

Infisical is an open-source secrets management platform that helps you securely store, sync, and manage your application secrets across your entire development lifecycle. It provides a secure vault for API keys, database credentials, certificates, and other sensitive data with features like secret versioning, audit logs, and integrations with popular development tools.

We've been using this secrets manager at our company for a while and all I can say is: I am impressed! The product is rock solid and it's super simple to setup your own instance.

In this guide, I'll show you how to deploy your own Infisical instance in the cloud using Docker and Sliplane.

Overview

Our Infisical deployment will consist of three services:

PostgreSQL - Main database for storing secrets and metadata
Redis - Caching layer for improved performance
Infisical - The main application server

Deploy in the Cloud

Step 1: Create a New Project

Log in to Sliplane with your GitHub account
In the Dashboard, click "Create Project" and name it "infisical"

Step 2: Deploy PostgreSQL Database

Navigate to your new project and click "Deploy Service"
Select a server or create a new one if you don't have one yet. To create a new server, click "Create Server", then choose the location and server type. The base server type should be enough to get started - you can scale up later if needed
Choose Postgres from the presets
In the settings:
- Disable the public toggle for additional security
- You can change the default database name, user, and password if desired, you'll need these credentials later for deploying Infisical
Click "Deploy" and wait a few seconds for your database to deploy

Step 3: Deploy Redis

In the same project, click "Deploy Service" again
Select the same server where PostgreSQL is running
Choose Redis from the presets
In the settings:
- Disable the public toggle for additional security
- Like in PostgreSQL, you can change the default password if desired, which you will need later for deploying Infisical
Click "Deploy" and wait a few seconds for Redis to come live

Step 4: Deploy Infisical

In the infisical project, click "Deploy Service" again
Select the same server where PostgreSQL and Redis are running
Choose Registry as the deploy source
In the "Image URL" field, enter: docker.io/infisical/infisical:v0.137.0-postgres
Add the following environment variables, but make sure to replace the placeholders with your actual Postgres and Redis connection details!

AUTH_SECRET="q6LRi7c717a3DQ8JUxlWYkZpMhG4+RHLoFUVt3Bvo2U="
DB_CONNECTION_URI="pg://postgres:s2H8ivfQidmNzfA4@postgres-wxzi.internal:5432/infiscal"
ENCRYPTION_KEY="f40c9178624764ad85a6830b37ce239a"
HOST="0.0.0.0"
REDIS_URL="redis://:qclE92PDoGjNg3rP@redis-t9x2.internal:6379"
SITE_URL="$SLIPLANE_DOMAIN"

Important: You need to update the following values:

Replace s2H8ivfQidmNzfA4 with your PostgreSQL password
Replace postgres-wxzi.internal with your PostgreSQL internal hostname
Replace infiscal with your database name (if you changed it)
Replace qclE92PDoGjNg3rP with your Redis password
Replace redis-t9x2.internal with your Redis internal hostname

To find these values:

Navigate to your PostgreSQL service in a new tab - you'll see the internal hostname and connection details in the environment variables section
Navigate to your Redis service in another tab - you'll see the internal hostname and password in the environment variables section

Click "Deploy" and wait for the deployment to complete. Once deployed, you can access Infisical at your ...sliplane.app domain

Summary

Infisical provides a flexible, open-source alternative to commercial secrets management platforms like HashiCorp Vault or AWS Secrets Manager. Self-hosting gives you complete control over your sensitive data and the freedom to customize as needed.

This straightforward three-service setup with PostgreSQL and Redis containerized approach makes it simple to replicate across different environments or adapt to your specific requirements.

You now have a functional secrets management platform that you can easily extend or integrate with your existing tools. For deployment, we used Sliplane which simplified the Docker orchestration and inter-service networking.

A FREE and Open Source Airtable Alternative - How to Spin Up NocoDB Using Docker

Lukas Mauser — Wed, 23 Jul 2025 08:00:52 +0000

NocoDB is an open-source Airtable alternative. On their site they claim that it "allows building no-code database solutions with ease of spreadsheets." You can turn any database into a smart spreadsheet interface, create forms, build APIs, and collaborate with your team.

In this guide, I want to show you how easy it is to spin up your own instance of this free database management tool in the cloud using Docker and Sliplane.

Local Testing
Run in the Cloud
Summary

Local testing

You can test the setup locally on your computer. Just make sure Docker Desktop is installed and running on your machine. However its even easier if you do it directly in Sliplane, what I will describe in the next section.

With SQLite

Open a terminal and run:

docker run -d --name nocodb \
    -v "$(pwd)"/nocodb:/usr/app/data/ \
    -p 8080:8080 \
    nocodb/nocodb:0.263.8

What happens here:

We use docker run to spin up a new container
We name it nocodb, you can choose a different name
We mount a new volume to /usr/app/data, this means everything nocodb saves in this directory will be stored outside the container and persist even if the container gets shut down or destroyed at some point. Nocodb will create our SQLite database file in here
We map port 8080 inside the container to 8080 on our host
We specify the image to run: nocodb/nocodb along with the version of the image (here: 0.263.8, but you can use a different version if needed)

You can test if the app is running by navigating to http://localhost:8080 in your web browser. Documentation for how you can configure NocoDB can be found on Dockerhub.

With Postgres

If you want to use postgres as the underlying database, you need to run a postgres container first:

Create a new network

docker network create nocodb-net

Start a postgres container with the following command:

docker run --name nocodb-postgres \
  -e POSTGRES_PASSWORD=mysecretpassword \
  -e POSTGRES_DATABASE=nocodb \
  -v "$(pwd)"/postgres:/var/lib/postgresql/data \
  --network nocodb-net \
  -d postgres:17.2

What happens here:

We use docker run to spin up a new container
We name it nocodb-postgres, you can choose a different name
We set a database and password with the -e envs
We mount a new volume to /var/lib/postgresql/data, this means everything postgres saves in this directory will be stored outside the container and persist even if the container gets shut down or destroyed at some point. Note: Postgres changed this mount path after version 18 - please always refer to the docs, depending on what version you are using
We specify the image to run: postgres along with the version of the image

In this case, I used 17.2 as the version. Make sure to check the postgres documentation on Docker Hub to find configurations that matches the pg version you are using.

Next, start the nocodb container and connect it to the postgres database:

docker run -d --name nocodb \
  -v "$(pwd)"/nocodb:/usr/app/data/ \
  -p 8080:8080 \
  --network nocodb-net \
  -e NC_DB="pg://nocodb-postgres:5432?u=postgres&p=mysecretpassword&d=nocodb" \
  -e NC_AUTH_JWT_SECRET="your-jwt-auth-secret" \
  nocodb/nocodb:0.263.8

What happens here:

We use docker run to spin up a new container
We name it nocodb, you can choose a different name
We mount a volume -v to /usr/app/data/
We set a JWT auth secret and the database URI in order to connect to our postgres database using the postgres user and password
We specify the image to run: nocodb/nocodb along with the version of the image (0.263.8)

You can now access nocodb on http://localhost:8080 on your own host.

Using docker compose

You can also use Docker Compose instead. Create a file called docker-compose.yml:

services:
  postgres:
    image: postgres:17.2
    container_name: nocodb-postgres
    environment:
      POSTGRES_DB: nocodb
      POSTGRES_PASSWORD: mysecretpassword
    volumes:
      - postgres_data:/var/lib/postgresql/data
    networks:
      - nocodb-net
    restart: unless-stopped

  nocodb:
    image: nocodb/nocodb:0.263.8
    container_name: nocodb
    depends_on:
      - postgres
    environment:
      NC_DB: "pg://postgres:5432?u=postgres&p=mysecretpassword&d=nocodb"
      NC_AUTH_JWT_SECRET: "your-jwt-auth-secret"
    ports:
      - "8080:8080"
    volumes:
      - nocodb_data:/usr/app/data
    networks:
      - nocodb-net
    restart: unless-stopped

volumes:
  postgres_data:
  nocodb_data:

networks:
  nocodb-net:

Then just run:

docker-compose up -d

Run in the cloud:

We use Sliplane to run it in the cloud. Sliplane makes running containers very easy and affordable in the cloud.

In general, we just follow the steps like in our local setup, but with a few simple changes, in fact, it is even easier on Sliplane.

1. Deploy a Postgres Database

Note: If you want to use SQL Lite you can skip this part and continue with step 2

Log in to Sliplane with your GitHub account. In the Dashboard, click "Create Project" and name it "nocodb".
Click "Deploy Service".
Select a server or create a new one if you don't have one yet. To create a new one, click "Create Server", then choose the location and server type. The base server type should be enough to get started, you can scale up later if you need to.
Choose Postgres from the presets. In the settings, disable the public toggle for additional security. You can also change the default database name, user, and password if you want. Then click deploy and wait for your database to deploy.

2. Deploy Nocodb

In the project we created in step 1, click "Deploy Service" again.
Select the server where Postgres is running and in the "Deploy From" section select "Registry".
In the "Image URL" field, search for nocodb and choose the nocodb/nocodb image and a tag from the list.
Add the following environment variables, but make sure to change the password, database, and internal host to match the settings from your Postgres database. I recommend you open a new tab with the Postgres service on Sliplane to grab these values from:

NC_DB="pg://[postgres.internal]:5432?u=postgres&p=[password]&d=[database]"
NC_AUTH_JWT_SECRET="your-secure-jwt-secret"

Add a volume to your nocodb service, give it a name of your choice and set the mount path to /usr/app/data
Click "Deploy" and wait for the deploy to finish.

You can now access nocodb through your ...sliplane.app domain that is showing in the dashboard!

Summary

NocoDB is a solid free alternative to Airtable (although Airtable now has more product offerings beyond turining databases into spreadsheets). By self-hosting it, you get your own data and control, and pretty much the same functionality at a fraction of the cost compared to commercial SaaS options.

Setting it up with Docker on Sliplane is possible within minutes.

How to Run Payload CMS in Docker

Lukas Mauser — Mon, 21 Jul 2025 21:01:39 +0000

Payload is an open source backend framework and it is mainly used as a content management system.

You can use Docker to run your own instance of Payload on Sliplane, however, when I tried using the Dockerfile that gets created using the pnpx create-payload-app it did not work for me right away and I had to apply a few tweaks and settings in order to get payload running.

Here's how you can run Payload with Docker:

Prerequisites

NodeJs and Docker should be installed on your system. For the demo I use pnpm as a package manager so make sure to install it as well or tweak the installation instructions to use your package manager of choice.

In my case I used:

Node version: v22.12.0
pnpm version: 9.13.2

Create a new Payload App

Open a new terminal in the parent folder where your Payload project should be created. Run the install wizard with:

# npx
npx create-payload-app

# or pnpx
pnpx create-payload-app

You will be guided through a series of short questions, I'll use:

"Payload Demo" as my project name
setup a blank project
go with MongoDB as my database and use the default connection setting to begin with
and pnpm as the package manager

To install payload into an existing project, please follow the installation instructions on the official payload documentation.

After the wizard has finished, we can see that the project includes a Dockerfile out of the box. However, when I tried to use this Dockerfile, I ran into several issues that prevented it from working properly in my environment.

Issues I Encountered

When trying to run the generated Dockerfile, I encountered a few problems:

Unpinned pnpm version - The Dockerfile didn't specify a specific pnpm version, which caused my Docker builds to fail
Missing standalone mode - My builds also failed because Next.js wasn't configured for standalone output
Public folder issues - The Dockerfile tried to copy a public folder that didn't exist in my setup in the beginning
Database connection issues - I missed the authSource connection parameter in the MongoDB connection URI
File upload permissions - Media uploads failed due to incorrect folder permissions

Let me show you how I fixed these issues one by one.

My Fixed Dockerfile

Here's the corrected Dockerfile that resolved the issues I encountered:

# To use this Dockerfile, you have to set `output: 'standalone'` in your next.config.mjs file.
# From https://github.com/vercel/next.js/blob/canary/examples/with-docker/Dockerfile

FROM node:22.12.0-alpine AS base

# Install dependencies only when needed
FROM base AS deps
# Check https://github.com/nodejs/docker-node/tree/b4117f9333da4138b03a546ec926ef50a31506c3#nodealpine to understand why libc6-compat might be needed.
RUN apk add --no-cache libc6-compat
WORKDIR /app

# Install dependencies based on the preferred package manager
COPY package.json yarn.lock* package-lock.json* pnpm-lock.yaml* ./
RUN \
  if [ -f yarn.lock ]; then yarn --frozen-lockfile; \
  elif [ -f package-lock.json ]; then npm ci; \
  elif [ -f pnpm-lock.yaml ]; then corepack enable pnpm && corepack prepare pnpm@9.13.2 --activate && pnpm i --frozen-lockfile; \
  else echo "Lockfile not found." && exit 1; \
  fi


# Rebuild the source code only when needed
FROM base AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .

# Next.js collects completely anonymous telemetry data about general usage.
# Learn more here: https://nextjs.org/telemetry
# Uncomment the following line in case you want to disable telemetry during the build.
ENV NEXT_TELEMETRY_DISABLED 1

RUN \
  if [ -f yarn.lock ]; then yarn run build; \
  elif [ -f package-lock.json ]; then npm run build; \
  elif [ -f pnpm-lock.yaml ]; then corepack enable pnpm && corepack prepare pnpm@9.13.2 --activate && pnpm run build; \
  else echo "Lockfile not found." && exit 1; \
  fi

# Production image, copy all the files and run next
FROM base AS runner
WORKDIR /app

ENV NODE_ENV production
# Uncomment the following line in case you want to disable telemetry during runtime.
ENV NEXT_TELEMETRY_DISABLED 1

RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs

# Remove this line if you do not have this folder
COPY --from=builder /app/public ./public

# Set the correct permission for prerender cache
RUN mkdir .next
RUN chown nextjs:nodejs .next



# Automatically leverage output traces to reduce image size
# https://nextjs.org/docs/advanced-features/output-file-tracing
COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static

RUN mkdir -p media && chown -R nextjs:nodejs media

USER nextjs


EXPOSE 3000

ENV PORT 3000

# server.js is created by next build from the standalone output
# https://nextjs.org/docs/pages/api-reference/next-config-js/output
CMD HOSTNAME="0.0.0.0" node server.js

Building and Running

Here's how you can build and run your Payload CMS application:

# Build the Docker image
docker build -t payload-cms .

# Run the container 
docker run -p 3000:3000 \
  -e DATABASE_URI=mongodb://your-mongo-host:27017/payload?authSource=admin \
  -e PAYLOAD_SECRET=your-secret-key \
  payload-cms

Note: If you want to persist uploaded files, you can mount a volume to /app/media, however in a more production-ready setup, you might want to use an object storage solution

Pinning the pnpm Version

To fix the pnpm version issue, I pinned the specific version in the Dockerfile in the deps and builder stages:

RUN corepack enable pnpm && corepack prepare pnpm@9.13.2 --activate

This ensures the same pnpm version is used consistently across all environments.

Configuring Next.js for Standalone Output

You'll also need to update your next.config.mjs file to enable standalone output mode:

/** @type {import('next').NextConfig} */
const nextConfig = {
  output: 'standalone',
  // ... other configuration options
}

export default nextConfig

This tells Next.js to create a standalone version of your application that includes all the necessary dependencies.

Setting up the Public Folder

If your project doesn't have a public folder yet, create one:

mkdir public
echo "" > public/.gitkeep

This helps ensure the COPY command in the Dockerfile doesn't fail.

Database Configuration

I used MongoDB in a container, and had to include the authSource=admin parameter in the connection URI in order to connect:

DATABASE_URI=mongodb://username:password@localhost:27017/payload?authSource=admin

File Upload Permissions

I attached the media folder to the Docker container using a volume mount. This allows you to persist uploaded files outside the container.

For uploads to work correctly, I had to ensure the media folder had the right permissions, which I set in the Dockerfile with:

RUN mkdir -p media && chown -R nextjs:nodejs media

This creates the media directory and sets the proper ownership so the nextjs user can write uploaded files to it.

Object Storage for Media Files

At some point, you might want to configure object storage for media files instead of storing them in a volume:

// payload.config.ts
import { s3Adapter } from '@payloadcms/plugin-cloud-storage/s3'

export default buildConfig({
  plugins: [
    cloudStorage({
      collections: {
        media: {
          adapter: s3Adapter({
            config: {
              endpoint: process.env.S3_ENDPOINT,
              region: process.env.S3_REGION,
              credentials: {
                accessKeyId: process.env.S3_ACCESS_KEY_ID,
                secretAccessKey: process.env.S3_SECRET_ACCESS_KEY,
              },
            },
            bucket: process.env.S3_BUCKET,
          }),
        },
      },
    }),
  ],
  // ... rest of your config
})

Deploy to Sliplane

You can deploy your Payload CMS instance to Sliplane by following a few simple steps:

Create a new project and give it a name of your choice
Next we will deploy a MongoDB database
Navigate into the project and click "Deploy Service" choose a server and select the MongoDB preset. You can make the service "private" since we don't want to expose it to the public internet
Deploy the database, alternatively, you can tweak the connection settings like user, password and database name
Next we will deploy Payload CMS and connect it to the MongoDB instance we just created
In the project, click "Deploy Service" again, choose the same server, where your database is running on and select "Repository" as the deployment method
In the repository URL field, look for your Payload CMS repository. If it does not show up in the list, make sure you granted Sliplane access to the repo using the "Configure Repository Access" button
Add a volume, give it a name of your choice and mount it to /app/media
Add the PAYLOAD_SECRET and DATABASE_URI environment variables. PAYLOAD_SECRET is an arbitrary password. The database URI should look like this: mongodb://username:password@mongodb:27017/payload?authSource=admin - You can find all connection settings like user, password, database and internal host name in the MongoDB service settings
Click "Deploy" and wait for the deployment to finish

Conclusion

Running Payload CMS in Docker requires a few configuration tweaks beyond the default setup.

The key fixes include pinning the pnpm version, enabling Next.js standalone mode, setting proper file permissions, and optionally configuring object storage for production use.

Guide: Deploy Ghost with Docker on Sliplane

Lukas Mauser — Sun, 13 Jul 2025 17:56:55 +0000

Ghost is an open source blogging and newsletter platform designed for professional publishers. In this guide, I want to show you, how you can spin up and deploy your own instance of Ghost using Docker and Sliplane.

You can find a detailed guide on how to use ghost in the official docs: https://ghost.org/help/manual/

Getting started

Login at Sliplane using your GitHub account.
Click on "Create Project", choose a name for the project and click "Create Project".

Spin Up a MySQL Database

Click on the new project and then click on "Deploy Service".
If you don't have a server yet, click on "Create Server". Select a location, instance type and name for your server and click on "Create Paid Server". The Base server type is selected by default and it should be plenty strong to run your Ghost app. You can always upgrade your server later, if you need more computing power.

After the server has been created, it will show up in the servers list. Click on your server, in order to continue.

In the pre configured images section, click on the MySQL preset card.

For additional security, scroll down to "Expose Service" and switch off the "Public" toggle.

Optionally, you can rename the database service and customize the other settings as well, but we will stick with the defaults.
Click "Deploy" and wait for the deploy to finish

Spin Up Ghost

After your database has been deployed, navigate to the project where you created it and click "Deploy Service" again
Select the server, where the database is running on

Click on "Registry" as the deploy source

In the "Image URL" text field up top, type "Ghost" and choose the official Ghost image from the search results and the version that you want to deploy

Add the following environment variables, but make sure to replace placeholders in all caps with your actual config. All database connection settings can be found on the settings page of the database service, that you just deployed earlier.

database__client=mysql
database__connection__database=YOUR_DATABASE_NAME # replace
database__connection__host=INTERNAL_DB_HOSTNAME # replace
database__connection__password=DB_ROOT_PASSWORD # replace
database__connection__user=root
url=https://$SLIPLANE_DOMAIN # $SLIPLANE_DOMAIN is a variable that will be populated automatically. You can replace this with a custom domain later, if you plan to add one

Add a new Volume, give it a name of your choice and use /var/lib/ghost/content as the mount path

Click "Deploy" and wait for the deploy to finish.

After your deploy is done, you can access Ghost through the public domain that will be displayed in your dashboard.

That's already it!

5 Cheap Object Storage Providers

Lukas Mauser — Tue, 01 Jul 2025 17:30:21 +0000

Object Storage is an essential component of modern web development. For a long time, AWS S3 was the go-to option for most of us, but nowadays their competition is huge, offering reliable alternatives at a fraction of the price.

We researched some providers to use in our cloud platform Sliplane some time ago and I want to share our top picks with you.

Here are 5 cheap object storage providers you can consider as an AWS S3 alternative.

Disclaimer: You might have very specific requirements for your object storage solution. For this article, I only include providers in the list of known brands with overall good reputation and we are mainly comparing prices here.

Comparison Table

Provider	Storage Cost	Egress Cost	Durability	Availability SLA	Free Tier	Notes
Backblaze B2	$0.006 / GB / month	Free up to 3× storage, then $0.01 / GB	99.999999999% (11 nines)	99.9%	No	Widely adopted, solid reliability, easy S3 API
Wasabi	$0.00699 / GB / month	Free	99.999999999% (11 nines)	99.9%	No	Requires 90-day minimum retention, fully S3-compatible
Cloudflare R2	$0.015 / GB / month	Free	99.999999999% (11 nines)	depends on downtime	10 GB storage + 1M writes + 10M reads/month	Pays for read/write ops, strong edge caching network
Hetzner Object Storage	$0.00713 / GB / month	$0.00143 / GB	Not stated	Not stated	No	Great price/performance, limited data centers, restrictive account policy
MinIO	Depends on infra	Depends on infra	Depends on setup	Depends on setup	No	Self-hosted, open-source, requires setup and maintenance, durability is debatable

1. Backblaze B2

Backblaze B2 offers reliable, low-cost object storage with an easy-to-use S3-compatible API. The storage price is very affordable at $0.006/GB/month, and egress is free up to 3× your storage volume per month, then $0.01/GB for additional egress.

Backblaze is widely adopted and a solid choice when it comes to durability (99.999999999% annual durability) and general reliability (99.9% uptime SLA). We use it at sliplane.io for example for storing backups but also to store configuration and init scripts.

2. Wasabi

With $0.00699/GB/month, storage is only slightly more expensive than on Backblaze, but egress is completely free on Wasabi. Durability is given at 11 nines as well and in their SLA they start discounting you if availability of their service drops below 99.9%.

Wasabi is fully S3-compatible, but it requires a 90-day minimum retention period on stored data when using their pay-as-you-go pricing.

3. Cloudflare R2

Similar to Wasabi, Cloudflare R2 provides object storage with zero egress fees as well, which is ideal for applications with heavy outbound data transfers. Storage costs are higher than Wasabi's at $0.015/GB/month, but still much cheaper compared to AWS S3 which comes at $0.023/GB/month. They also have a free tier for the first 10GB of storage, making it ideal for small projects. While egress is free, you pay for read ($0.36 / M) and write ($4.50 / M) operations, although Cloudflare has a free tier of 1M writes and 10M reads per month as well.

A main benefit of R2 is access to Cloudflare's edge caching network, giving you fast global access to your data.

4. Hetzner Object Storage

Hetzner provides a great European alternative for Object storage. Although their service is comparably new and when we tested it in beta we stumbled into issues, which they probably got all sorted by now, Hetzner is known to provide great service at an exceptional price/performance ratio.

At $0.00713/GB/month storage costs are very competitive and especially their $0.00143/GB egress pricing can be an attractive alternative to AWS where egress costs are about 60x higher. Its downsides include limited global data center locations and it can be tricky to open an account at Hetzner since they are very restrictive as part of their effort to keep scammers in check.

5. MinIO

MinIO is a self-hosted, open-source object storage software fully compatible with the S3 API. Since it runs on your own servers or cloud, storage fees—costs depend on your infrastructure but you must also include the time it takes to set up and maintain your object storage solution.

Is it a good idea to self-host object storage? That's debatable. An important point of good object storage is high durability and achieving the same 11 nines (99.999999999%) as other providers offer at a similar price is going to be tough.

Conclusion

Hope any of that helped! Each of these providers offers different advantages depending on your specific needs:

Backblaze B2 is great for reliable, cost-effective storage with reasonable egress allowances
Wasabi excels when you need unlimited free egress but can commit to 90-day retention
Cloudflare R2 is perfect for applications that benefit from global edge caching
Hetzner offers excellent European-focused pricing with competitive egress costs
MinIO gives you complete control but requires significant setup and maintenance effort

When choosing an object storage provider, consider not just the storage costs but also egress fees, your geographic requirements, integration complexity, and the total cost of ownership including your time investment.

Cheers,

Lukas

Co-Founder sliplane.io

How to add Bug Tracking to your Apps (Free Open Source Tool) - Bugsink 🐞

Lukas Mauser — Wed, 25 Jun 2025 12:31:22 +0000

Bugsink is a free and open source bug tracking solution that allows you to collect all errors that are happening across your applications in a central place.

I tried a few open source bug trackers, but from what I found they look either very old (https://www.bugzilla.org/) or super heavy (https://sentry.io). Bugsink provides a nice middle ground so I encourage you to give it a try.

In this tutorial, we'll spin up our own instance of Bugsink using Sliplane.

Video Tutorial

Step 1: Spin up a Database

You can find detailed installation instructions in the docs. We will choose the Docker installation and use a MySQL database as a persistent data store.

We will start by spinning up a database:

1.) Go to sliplane.io and sign in with your GitHub account
2.) Click on "Create Project" and give it a name of your choice. I will choose "Bugsink" as a project name.

3.) Click on the project and hit "Deploy Service"
4.) If you don't have a server yet, click on "Create Server" and choose a location and server type. The default server type is plenty strong to run MySQL and Bugsink and you can scale it up later so I recommend starting with the default. Choose a name for your server and hit "Create Paid Server".

5.) Once the server has been created and shows up in the list, you can select it to continue
6.) Choose "MySQL" from the pre configured image list
7.) On the deploy settings screen, you can apply some optional settings: Disable "public" for more security, change the database name to "bugsink" and rename your service "Bugsink MySQL". These settings are optional but recommended.

8.) Hit deploy and wait for the deploy to finish until you see a green dot lighting up, which indicates that your MySQL database is ready to accept connections.

Step 2: Deploy Bugsink

Next up, we will deploy Bugsink.

1.) In the Bugsink project, click "Deploy Service" again.
2.) Choose the server, where your database is running on
3.) Click on deploy from "Registry"
4.) In the "Image URL" input, search for "bugsink" and choose the official bugsink image from the dropdown as well as the version of bugsink that you want to install. It's recommended to use a pinned version in production to avoid unintentional upgrades of the service.
5.) Add the following environment variables. Click on "from .env file" and paste in this content:

SECRET_KEY=[a 50 chars long secret key]
DATABASE_URL=mysql://[user]:[password]@[host]/[name]
CREATE_SUPERUSER=[admin username]:[admin password]
BEHIND_HTTPS_PROXY=true
BASE_URL=[your sliplane.app url]

Important: These environment values contain placeholders! you need to replace everything that is inside square brackets [ ] with actual values! You can find all database connection settings in the MySQL Sliplane service. The CREATE_SUPERUSER name and password are arbitrary. The SECRET_KEY as well, but it has to be 50 chars long and needs uppercase and lowercase characters and numbers. The BASE_URL can be found in the settings of your "Bugsink" app on Sliplane after your first deploy, so make sure to update this value after you deployed the app.

6.) Optionally, change the name to "Bugsink" and hit "Deploy".

After a little while, your application should be deployed and the green light should be visible.

Great!

We can test if everything is working, by navigating to the "Public Domain" that is displayed in your "Bugsink" Sliplane app and login with the superuser credentials that we passed as environment variables when we deployed the application.

Note: Once the superuser has been created, you can not overwrite the credentials via envs!

Step 3: Instrument your App using the Sentry SDK

Instrumenting means, we will inject statements in our code, that send errors to our backend. Depending on your stack, there are tools that do this automatically for you, for example Sentry.

Sentry is an open source bugtracker itself, but it is pretty heavy and we can just use their client side SDK for instrumentation and send the data to Bugsink.

Before we can get started with instrumenting our apps, we need to create a new Team and a new Project in Bugsink first:

1.) Click on "Teams" and then "New Team". Give it a name and visibility setting of your choice and click on "Save"

2.) Click on "Projects" and then "New Project". Fill out the form and hit "Save" as well.

After saving your project, you should see some installation instructions to connect a Sentry client to your Bugsink instance.

Note: If you see "localhost" in the DSN, you need to update the "BASE_URL" in the environment variables of your Bugsink app on Sliplane first.

You will also see a link to https://docs.sentry.io/platforms/ where you can find instructions on how to add Sentry to the application that you want to instrument. Sentry has an SDK for almost all major frameworks, so choose the framework that you use in your application and make sure to follow their installation guide step by step.

No matter what SDK you are choosing, you want to configure:

The DSN that is displayed on the Bugsink installation instruction page
Configuration for uploading source maps which contains:

org: [your bugsink team name],
project: [your bugsink project name],
authToken: [auth token from bugsink],
url: [the public domain of your Bugink instance on Sliplane, including https],

You can generate authTokens in Bugsink by click on "Tokens" in the navbar on top.

It also makes sense to add a release version to the sentry config, but you can find out more about what's possible in their official documentation.

That's basically it! You can test your setup by throwing errors in your code like this for example in javascript:

throw new Error('Test')

The error should be collected in your Bugsink instance!

If you liked this little tutorial, feel free to like, comment and subscribe and I see you next time!

Lukas

Setup SSL/TLS for PostgreSQL in Docker

Lukas Mauser — Tue, 17 Jun 2025 16:02:26 +0000

The goal

If you want to run PostgreSQL in production, setting up Transport Layer Security (TLS) is a must in order to prevent man-in-the-middle attacks. In this step-by-step guide, I will show you how you can connect to your database securely using your own local Certificate Authority. If you need an in-depth explanation of all settings, you can check out the official documentation on how to set up TLS in PostgreSQL.

In this example, we will ONLY allow encrypted connections and we will set sslmode to verify-full, which is the strictest possible connection setting in PostgreSQL.

To follow along, check out the example repository over here: PostgreSQL with TLS repository

Prerequisites

You need Docker installed on your machine. If you are on a Mac or Windows, make sure to install Docker Desktop and have it running in the background. Verify Docker is running by typing docker ps in your terminal. You should see a list of running containers or at least no error if Docker is running.

Video Tutorial

Step 1: Generate Certificates

Generate a Certificate Authority (CA)

Note: All certificate files that are generated in the following steps (CA, server, and client) should be treated as secrets. Do not add them to your git repository, do not log them, and do not bake them into your Docker image (use runtime envs only). If necessary, add them to your .gitignore file.

First, we create a root CA key and certificate that will sign our server and client certs. You can change the name if you want. Our CA will be valid for 365 days and needs to be renewed after that.

openssl genrsa -out rootCA.key 2048
openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 365 -out rootCA.crt -subj "/CN=MyLocalCA"

Create Server Certificate Files

Generate a key and CSR (Certificate Signing Request), then sign it using the CA:

Important: Here you need to provide the domain name your PostgreSQL instance will be running on. In the example, I use localhost, but make sure to swap out the hostname if you use another one.

openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr -subj "/CN=localhost"
openssl x509 -req -in server.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out server.crt -days 365 -sha256

Create Client Certificate Files

This certificate will be used by the client to authenticate. Only certificates that have been signed by the same certificate authority as the server certificate will work.

To create the client certificate, we follow the same steps as for the server. As a common name, I chose the postgres user:

openssl genrsa -out client.key 2048
openssl req -new -key client.key -out client.csr -subj "/CN=postgres"
openssl x509 -req -in client.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out client.crt -days 365 -sha256

Step 2: Create Config Scripts to Enable TLS in PostgreSQL

Create a new file in the root of the project and name it ssl-config.sh. The script contains instructions to enable ssl in PostgreSQL and enforce TLS for all connections with sslmode set to verify-full.

If you want to allow insecure connections, you can omit the "Force SSL" section of the script or change the sslmode to something more forgiving.

#!/bin/bash
set -e

# Configure PostgreSQL to use SSL
echo "ssl = on" >> /var/lib/postgresql/data/postgresql.conf
echo "ssl_cert_file = '/var/lib/postgresql/server.crt'" >> /var/lib/postgresql/data/postgresql.conf
echo "ssl_key_file = '/var/lib/postgresql/server.key'" >> /var/lib/postgresql/data/postgresql.conf
echo "ssl_ca_file = '/var/lib/postgresql/rootCA.crt'" >> /var/lib/postgresql/data/postgresql.conf

# Enforce SSL for all connections
echo "hostssl all all all cert clientcert=verify-full" > /var/lib/postgresql/data/pg_hba.conf

Create another file in the root of the project and call it entrypoint.sh. This script copies our certificates into the container at runtime before the default entrypoint is executed.

#!/bin/bash
set -e

# Add certificate files
echo "$SERVER_CRT" > /var/lib/postgresql/server.crt
echo "$SERVER_KEY" > /var/lib/postgresql/server.key
echo "$ROOT_CA_CRT" > /var/lib/postgresql/rootCA.crt

# Update file permissions of certificates
chmod 600 /var/lib/postgresql/server.* /var/lib/postgresql/rootCA.crt
chown postgres:postgres /var/lib/postgresql/server.* /var/lib/postgresql/rootCA.crt

# Run the base entrypoint
docker-entrypoint.sh postgres

The script requires 3 environment variables:

SERVER_CRT
SERVER_KEY
ROOT_CA_CRT

The contents of these envs is the plaintext content of the 3 certificate files: server.crt, server.key, and rootCA.crt.

Step 3: Build a Docker Image with TLS Enabled

Create a new file in your project and name it Dockerfile. We will base the Docker image on postgres:17.5, then copy our custom ssl-config.sh and entrypoint.sh into the image, make it executable and replace the default entrypoint:

# Start from postgres 17.5 as a base image
FROM postgres:17.5

# Copy ssl-config script which runs on first startup
COPY ssl-config.sh /docker-entrypoint-initdb.d/ssl-config.sh

# Copy the entrypoint script to the image
COPY entrypoint.sh /usr/local/bin/entrypoint.sh

# Make the entypoint script executable
RUN chmod +x /usr/local/bin/entrypoint.sh

# Set the entrypoint
ENTRYPOINT [ "/usr/local/bin/entrypoint.sh"]

Step 4: Connect to the instance

To see if everything is working, we will try to build and run our image locally and try to connect to our instance. We will use the psql client to check if we can connect to our instance. If you have not installed it on your machine, make sure to add it first using your package manager of choice, e.g. brew install postgresql on macOS.

Note: This local test will only work if you previously set the common name of your server certificate to localhost. Otherwise, you need to create a new server certificate with localhost as a common name.

Build the docker image:

docker build -t postgres-tls .

Run the image:

docker run \
 -e POSTGRES_PASSWORD=secret \
 -e SERVER_CRT="$(cat server.crt)" \
 -e SERVER_KEY="$(cat server.key)" \
 -e ROOT_CA_CRT="$(cat rootCA.crt)" \
 -p 5432:5432 --name postgres-tls postgres-tls

Make sure to use the correct path to your server.crt, server.key, and rootCA.crt file if you moved these files around.

Test the connection:

# This command should get you into the PostgreSQL shell:
psql "host=localhost dbname=postgres user=postgres sslmode=verify-full sslrootcert=rootCA.crt sslcert=client.crt sslkey=client.key"

# This should fail, because we enforce tls:
psql "host=localhost dbname=postgres user=postgres sslmode=disable"

Important: Make sure to run this from the same directory where your certificates are, or update the file paths accordingly.
Also make sure the permissions on client.key are set to 600. You can update the permissions using chmod 600 client.key

Step 5: Deploy

In order to make the database available over the internet, we will deploy it on Sliplane.

Sliplane is an affordable cloud provider, that makes deployment and managing containerized applications very easy.

1.) Create a GitHub repository with the two files described above: entrypoint.sh from step 3 and Dockerfile from step 4. I created an example repo that you can fork here: PostgreSQL with TLS repository
2.) Log in to Sliplane with your GitHub account
3.) Create a new Project and click on "Deploy Service"
4.) Create a new Server, where your PostgreSQL instance will be running - you can easily start with the base server and scale up later if you need to
5.) Choose "Repository" as the deploy source
6.) Choose your PostgreSQL repository from the dropdown.

If the PostgreSQL repository does not show up in the list, you need to hit "Configure Repository Access" first in order to grant Sliplane access to deploy the repo

7.) In the "Expose Service" section, change the protocol to TCP

8.) In the "Environment Variables" section, add

POSTGRES_PASSWORD - arbitrary secret
SERVER_CRT - contents of your server.crt file
SERVER_KEY - contents of your server.key file
ROOT_CA_CRT - contents of your rootCA.crt file

9.) In the "Volumes" section, add a new volume with a name of your choice and choose /var/lib/postgresql/data as the mount path

10.) Hit "Deploy".

Here you can see an overview of how the settings should look:

After the deploy we get issued a sliplane.app domain that we can use in our server certificate. Alternatively, you could use a custom domain in your certificate and attach that domain to your service afterwards.

11.) Back in your terminal, create a new server certificate as described above and use your sliplane.app domain as a common name. You can find the domain in the service settings of your newly created service under Public Domain.

openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr -subj "/CN=...sliplane.app"
openssl x509 -req -in server.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out server.crt -days 365 -sha256

Note: Your service needs to be public when you create it. Otherwise, it won't get a public domain (see screenshot above)
Make sure to replace the \CN=... with your own sliplane.app domain.

12.) Replace the SERVER_CRT environment variable of your Sliplane service with the new certificate. After you hit save, a new deploy will be triggered.

That's it! You now have access to a PostgreSQL instance via a secure connection. You can test it by running:

psql "host=YOUR_APP.sliplane.app dbname=postgres user=postgres sslmode=verify-full sslrootcert=rootCA.crt sslcert=client.crt sslkey=client.key"

Note: Replace the sliplane.app domain that you have been issued and that is used in your certificate.

If you liked this tutorial, feel free to comment, like, and share.

Thanks!

Lukas

How Hard Can It Be? „Building a Photo Sharing App is easy!“ (*regrets 😓)

Lukas Mauser — Sat, 07 Jun 2025 18:11:59 +0000

Recently, I was looking for a simple way to share photos amongst friends and family. But no way I would pay $14.99 a month for a turnkey solution! - This goes against rule #422 of being a developer:

Rule #422: I'm a developer, I can build that myself - how hard can it be?

After all, it's just uploading and displaying some photos...

A friend already helped me out with a prototype, but things quickly started to break once I added 3000 high resolution images.

One important lesson before we get into it:

Just pay for the damn service! Don't be so cheap. I spend 5 days on what I estimated to be a 5 hour project.

Rule #675 of being a developer:

Rule #675: Your estimates will be wrong. By a lot.

Okay it was still fun, so here are some lessons:

1. Where to store your images

The prototype was build on Cloudflare's object storage R2. Cloudflare also offers an image service, that comes with compression and resizing - 5,000 transformations are included, after that it's $5 per 100,000 images stored per month and $1 per 100,000 images delivered per month. I won't pay for that - I'm a developer, I can do that myself, how hard can it be?

2. Smooth scrolling through thousands of images

The trivial solution - render 3000 images on your site.

<img v-for="image in images" :key="image.id" :src="image.src" />

In general, I'd recommend to always start with the trivial solution and work your way up. Btw. I am building this with Nuxt 3 - so example code will be Nuxt, Vue and TypeScript.

At a few hundred images the browser started to hickup and scrolling wasn't smooth anymore. In very large lists, it is common practice to work with a virtual dom and only render visible elements.

I found vue-virtual-scroller but for reasons I can't remember, it did not work immediately so I got frustrated and went back to rule #422:

I can build that!

I started with rendering empty divs instead of imgs. All devices i tested with had no issue to handle thousands of divs and scrolling through worked smoothly. Might be an issue on old devices, but we have to draw a line somewhere...

I used an intersection observer to keep track of visible elements on screen, and replaced my divs with imgs whenever they entered the viewport:

<template>
<div>
 <!--...-->

 <div v-for="(image,index) in images" :key="image.id" :data-index="index">
   <img v-if="intersectingIndices.has(index)" :src="image.src" />
</div>

</div>
<template>


<script setup lang="ts">

// ...

onMounted(()=>{
   const observer = new IntersectionObserver(handleIntersection, {
      root:null, // Use the viewport as the root
      threshold: 0.1, // Trigger when 10% of the image is visible
   });
})

const intersectingIndices = new Set<number>();
function handleIntersection(entries: IntersectionObserverEntry[]) {
  for (const entry of entries) {
    const indexAttr = entry.target.getAttribute("data-index");
    if (indexAttr == null) continue;
    const index = Number(indexAttr);
    if (entry.isIntersecting) {
      intersectingIndices.add(index);
    } else {
      intersectingIndices.delete(index);
    }
  }
}
</script>

It worked, but scrolling was stuttering. With the research and previous failed attempts, I am approaching the 5 hours deadline. Luckily, we live in modern times and ChatGPT pointed me towards batching DOM updates with requestAnimationFrame(applyPendingUpdates). It worked!

function handleIntersection(entries: IntersectionObserverEntry[]) {
  for (const entry of entries) {
    const indexAttr = entry.target.getAttribute("data-index");
    if (indexAttr == null) continue;
    const index = Number(indexAttr);
    if (entry.isIntersecting) {
      intersectingIndices.add(index);
    } else {
      intersectingIndices.delete(index);
    }
  }
  // Batch the update to visibleImages using requestAnimationFrame
  if (rafId === null) {
    rafId = requestAnimationFrame(applyPendingVisibleUpdates);
  }
}

Beautiful.

Scrolling now worked buttery smooth. Praise the AI lords!

3. Improve Image Load time

Next issue, I could scroll, but the unprocessed images were too large and load time was whack. I used Nuxt Image in order to compress and downsize the images on the fly. Nuxt Image ships with a builtin image transformation library that can be used locally, so F U Cloudflare image service!

Well, not so fast. CPU and Memory spiked on my server with frequent image transformations. For my limited user count the app handled it well, but at some point this is something to keep in mind.

I assumed Nuxt image would store transformed files in memory, so my strategy to keep the cache alive was: don’t code bugs so I don’t have to deploy and everything is fine.

4. Honorable Bug Mentions and Challenges

The Back Button

I knew ahead of time, that the app would probably be used 90% on mobile. What I did not know: Some phones have a back button and it get's used a lot. The app could show full res images, but it relied on in memory variables to trigger the detail view. A click on the back button sent users to the homepage and they had to navigate back to the images page and scroll through 1000 images again to get back to where they started. I had to rewrite that to show the detail view on a new page while still preserving the scroll position (also if the page was reloaded).

Swiping

Another mobile issues. Users are just used to swiping gestures on their phones. To view the next image, to close the detail view. I tried to make it work in the beginning, but it quickly turned out to be a bad idea, since gestures overlapped with browser native gestures (swipe down to reload, swipe right to navigate back). After a few hours of fine tuning I had my solution: Users need to unlearn their swiping behavior. It's a won't fix. Guess there still is some UX benefit in native apps compared to web.

Nuxt

I really like Nuxt and have been reliably using the framework for years. It's just natural, that before you assume a bug in your framework, you usually spent a lot of time to question your own capabilities and whether you chose the wrong career. I spent about 4 hours testing the app from front to back until I figured out, there was a bug in Nuxt, that caused my app to crash. Luckily, they released a new version just 2 days earlier, that fixed it!

Cloudflare Cache

To save on storage and bandwidth, I used a custom script to convert all of my images to webp before uploading them to Cloudflare. I used sharp for the image transformation. Every now and then you take a picture with your phone and it is rotated 90 degrees. The orientation is stored in the metadata of the image. Sharp strips all metadata by default. I only noticed this, after my images had been uploaded to Cloudflare, so I deleted the bucket, transformed everything again and reuploaded my images (side info: I was visiting relatives at that time. The router is in the basement, I was on first floor (European first floor, American second), I measured 2 MBit/s upload - You do the calculation for 10GB of images...).

After reuploading the images were still rotated and I spend hours comparing metadata, clearing browser cache and going through reuploading again and again (this time with smaller sample sizes) until I noticed, that the old images were still served from Cloudflare cache. Be smarter than I was. Don't forget the cache.

Photo Upload

I gave my friends an upload button. And they uploaded. Or at least they tried. Some of them tried to upload a lot of images at once - I had no restrictions. Who needs restrictions anyways? Aren't we all born as free human beings? If you asked me, I wouldn't put a restriction on your uploads. But I should have. These big uploads reliably pushed the server into memory limits and broke the application. How did I fix it? I ran the app on localhost and uploaded the images myself. LOL.

5. Deploying

Okay, I have to tell ahead of time, I am biased here. But this is just the perfect project to run on sliplane.io. Sliplane is a cheap and dead simple way to run Docker containers on a VPS - no DevOps required. This means we can basically run whatever we want (frontend and backend with image processing) and my cache in memory strategy can actually work for a while! (At least until the machine will be rebooted.) Take that serverless!

Summary

It's a rabbit hole and it's deeper than it looks from the outside. Don't be cheap. Pay for that damn photo sharing service.