My addictions

I am an addict. I know this since my teenage years when i could not quit gaming for meals or bedtime. It also surfaced in nicotine: i first was an occasional smoker, then pretty fast a heavy smoker. I smoked ~1 package a day. When not going out. When goin out i smoked… more. I luckily changed to snus after 2 years of smoking. Because i actually liked doing sports and knew it would hurt my lung capacity. So i snused obsessivly for ~14 years. And by obsessively i mean i slept with the snus in it. And i dont start talking about alcohol (luckily this episode was shorter, still too long, but definitely shorter).

Obviously there are also positive aspects if you are an addictive person: The sports i picked up i did quite intense. This was the case with climbing, bouldering, mounaineering, and cycling. But this is another story.

First Smartphone

These negative experiences were among others a reason why i got my first smartphone just at 27 when i started my first office job. Since then my screen time consistently increased. In the beginning it was only browsing on the phone. Alraedy this let my toilet time explode. First i also had no social media on the phone (i deleted my fb account in 2003 for other reasons). Then i made linkedin in ~2019. Another surge in screen time. Then came corona and i tried tiktok, snapchat, twitter, and installed youtube. Another surge in screen time. I only was a consumer on all of these platforms. And just doomscrolling on these platforms without having any output just left me empty and unfullfilled. In January 2024 i then made the first posts in twitter and started to post irregularily.

From Consumer to “Creator”

Changing from the passive to the active part on twitter (@mischeiwiller) changed something for me. It felt better. I got interactions. I had a goal, a measure, something to work on. Still it does obviously not helpt to reduce screen time (at least the screen time had some meaning to me). And also i lost consistency of posting and fell back to only consumerism. And this mostly on my phone.

The Dumb Phone

I then got across the concept of dumb phones. The first time i read it was probably from Simon here. Crossed the topic some times again, found it interesting but never really gave it a thought that it could be for me. Too radical. But it kept popping up in my head. Then i just saw recently dhh’s post about his dumb phone (although he compares it more to omarchy, in my view its the same concept). Dhh is anyway conquering my timeline lately with omarchy and i am this close to give it a try as well, but this is also another story. So this motivated me to give it a try.

Setup

To setup the dumb iphone i then installed the dumb phone app. It is quite easy to, takes about 5 minutes though. But the experience is just awesome. I love it! And when i realised it is an indieproject fom Michael Tigas i loved it even more!

What next?

I will keep testing the next month and see what happens to my screen time and if my enthusiasm sticks (which i really hope). I really want to reduce screen time, and this definitely feels like a good step in the right direction

[Original Text: https://www.michaelscheiwiller.com/blog/dumb-iphone]

While writing the People and Bookshelves pages and browsing some of these resources i kept seeing some technical blogs the writers referred to. So i want to keep track of the ones i see here. Let me know if you have other technical blogs you like!

• Netflix
• Spotify
• LinkedIn
• AWS
• Google
• Meta

Im curating the People page with people i like to keep on my radar for various reasons. Some of them have a separate page where they list their readings. Most do this under ‘Bookshelf’.

Last year i had the topic ‘Reading’ and figured i liked it a lot and am sticking with it since. I keep a list of books i want to read on goodreads. So i thought i can do the same with recommendations from the mentioned bookshelf concept above. This is also going to be a living list where i keep adding more. If you have some you like, i would love to know which ones.

If someon on the People site has a bookshelf type site, it is already included in the following list.

• https://guzey.com/favorite/media/#books
• https://karpathy.ai/books.html
• https://sive.rs/book
• https://notes.eatonphil.com/tags/books.html
• https://gwern.net/review/book
• https://minami.bearblog.dev/books/
• https://patrickcollison.com/bookshelf

I copied this idea from Patrick Collison who lists people who blog/write online and he likes to read from. I think this is a cool idea and will do the same here. It is going to be a living list where i add more people over time. If one of the people below has a subsite where they share their book recommendations, this site is listed on here.

- Alex Danco (X)
- Alexey Guzey (X)
- Andrej Karpathy (new blog], X)
- Andrew Ng (X)
- Balaji S. Srinivasan (X)
- Chip Huyen (X)
- Christopher Olah (X)
- Derek Sivers (X)
- Devon Eriksen (X)
- Eaton Phil (X)
- Elad Gil (X)
- Farza (X)
- Gian Segato (X)
- Greg Isenberg (X)
- Gwern Branwen (X)
- Iron Brands (X)
- José Luis Ricón Fernández de la Puente (blog), (X)
- Minami (X)
- Mitchell Hashimoto (X)
- Naval Ravikant (X)
- Patrick Collison (X)
- Patrick McKenzie (Bits about Money), (X)
- Paul Graham (X)
- Sahil Lavingia (X)
- Sasha Chapin (X)
- Scott Alexander (X)
- Sebastian Raschka (X)
- Seth Godin (X)
- Shane Parrish (X)
- Signüll (X)
- Steph Ango (X)
- Tyler Cowen](X)
- Yacine (X)

For some time i wanted to read the The Daily Stoic but i never got to start it. So i decided to build a simple website that would serve one stoic meditation per day. With this i could get some more practice with systemd and nginx.

If you are just looking for the code, you can find it here.

Disclaimer: The rest of this post is mostly copied from the [README](https://github.com/lappemic/366dailystoic/blob/main/README.md) of the project and AI generated. I just added some more details and explanations.

Project Overview

The Daily Stoic website is has a simple design:

• Purpose: Deliver one stoic meditation per day based on the current date
• Design Philosophy: Clean, readable interface
• Tech Stack: Minimal but robust — Node.js backend, SQLite database, vanilla HTML/CSS/JavaScript frontend
• Deployment: Production-ready setup on a VPS with proper SSL and caching

Tech Stack and Architecture

Backend

• Node.js + Express: Lightweight server framework
• SQLite: File-based database with 366 pre-populated meditations
• RESTful API: Clean endpoints for fetching meditations

Frontend

• Vanilla HTML/CSS/JavaScript: No frameworks, maximum performance
• Google Fonts (Crimson Text): Elegant typography for readability
• Responsive Design: Works seamlessly on mobile and desktop

Infrastructure

• Ubuntu VPS: Cost-effective hosting solution
• Nginx: Reverse proxy with SSL termination and static file caching
• Systemd: Process management and automatic restart capabilities
• Let’s Encrypt: Free SSL certificates with automatic renewal

Local Development Setup

1. Project Structure

366dailystoic/
├── server.js # Express server with API routes
├── package.json # Dependencies and scripts
├── daily-stoic.db # SQLite database (586KB)
├── public/ # Static frontend files
│ ├── index.html # Main page
│ ├── style.css # Styling (4KB)
│ └── script.js # Frontend logic (3KB)
└── README.md # Documentation

2. Dependencies

The project uses minimal dependencies:

{
  "dependencies": {
    "express": "⁴.18.2",
    "sqlite3": "⁵.1.6"
  }
}

3. Server Configuration

The Express server (server.js) handles:

• Static file serving from the public/ directory
• API endpoints for meditation data
• Database connections and queries
• Graceful shutdown handling

Key features:

// Serve static files
app.use(express.static('public'))

// API endpoints
app.get('/api/today', (req, res) => {
/* Today's meditation */
})

app.get('/api/meditation/:month/:day', (req, res) => {
/* Specific date */
})

app.get('/api/all', (req, res) => {
/* All meditations for navigation */
})

app.get('/api/health', (req, res) => {
/* Health check */
})

4. Running Locally

# Install dependencies
npm install

# Start development server
npm start

# Visit the application
open http://localhost:3000

Production Deployment on VPS

1. Server Preparation and repo clone

Check out my other posts on how to setup a vps and how to configure ssh for your vps so you can easily handle your vps.

2. Systemd Service Configuration

Create a systemd service for process management and automatic restarts:

File: /etc/systemd/system/daily-stoic.service

[Unit]
Description=Daily Stoic Website
Documentation=https://github.com/lappemic/366dailystoic
After=network.target

[Service]
Type=simple
User=devuser
WorkingDirectory=/home/devuser/projects/366dailystoic
ExecStart=/usr/bin/node server.js
Restart=on-failure
RestartSec=10
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=daily-stoic
Environment=NODE_ENV=production
Environment=PORT=3000

# Security settings
NoNewPrivileges=yes
PrivateTmp=yes

[Install]
WantedBy=multi-user.target

Key Configuration Points:

• User: Runs as non-root user (`devuser`) for security
• WorkingDirectory: Absolute path to your project
• Restart Policy: Automatically restarts on failure with 10-second delay
• Logging: Outputs to syslog with identifier for easy monitoring
• Security: Additional hardening with `NoNewPrivileges` and `PrivateTmp`

Service Management:

# Enable and start the service
sudo systemctl daemon-reload
sudo systemctl enable daily-stoic
sudo systemctl start daily-stoic

# Check status
sudo systemctl status daily-stoic

# View logs
sudo journalctl -u daily-stoic -f

For other systemd examples, check out the blog post Fast Private Streamlit Sharing with Systemd

3. Nginx Reverse Proxy Configuration

Nginx serves as a reverse proxy, handling SSL termination, static file caching, and security headers.

File: /etc/nginx/sites-available/daily-stoic

server {
    server_name 366dailystoic.com www.366dailystoic.com;

    # Security headers
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "no-referrer-when-downgrade" always;
    add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; connect-src 'self'" always;

    # Gzip compression
    gzip on;
    gzip_vary on;
    gzip_min_length 1024;
    gzip_proxied expired no-cache no-store private;
    gzip_types
        text/plain
        text/css
        text/xml
        text/javascript
        application/json
        application/javascript
        application/xml+rss
        application/atom+xml
        image/svg+xml;

    # Cache static assets and proxy to Node.js
    location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        expires 1y;
        add_header Cache-Control "public, immutable";
    }

    # Proxy to Node.js app
    location / {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_cache_bypass $http_upgrade;

        # Timeouts
        proxy_connect_timeout 60s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;
    }

    listen 443 ssl; # managed by Certbot -> this part will automatically be set after you run the certbot command in the next step
    ssl_certificate /etc/letsencrypt/live/366dailystoic.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/366dailystoic.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
}

# HTTP to HTTPS redirect
server {
    if ($host = www.366dailystoic.com) {
        return 301 https://$host$request_uri;
    }

    if ($host = 366dailystoic.com) {
        return 301 https://$host$request_uri;
    }

    listen 80;
    server_name 366dailystoic.com www.366dailystoic.com;
    return 404;
}

Key Configuration Features:

• Security Headers: Comprehensive security headers for XSS, clickjacking, and content type protection
• Gzip Compression: Reduces bandwidth usage for text-based files
• Static File Caching: 1-year cache for CSS/JS files with immutable cache-control
• Proxy Configuration: Proper headers for WebSocket support and real IP forwarding
• SSL Configuration: Managed by Certbot for automatic certificate management

Enable the Configuration:

# Create symlink to enable site
sudo ln -s /etc/nginx/sites-available/daily-stoic /etc/nginx/sites-enabled/

# Test configuration
sudo nginx -t

# Reload Nginx
sudo systemctl reload nginx

4. SSL Certificate Setup with Let’s Encrypt

# Install Certbot
sudo apt install certbot python3-certbot-nginx -y

# Obtain SSL certificate
sudo certbot - nginx -d 366dailystoic.com -d www.366dailystoic.com

# Test automatic renewal
sudo certbot renew - dry-run

Common Issues and Troubleshooting

Issue 1: Static Files Return 404 Errors

Problem: CSS and JavaScript files return `404 Not Found` errors when accessed via the domain.

Symptoms:

GET https://366dailystoic.com/style.css net::ERR_ABORTED 404 (Not Found)
GET https://366dailystoic.com/script.js net::ERR_ABORTED 404 (Not Found)

Root Cause: The Nginx location block for static files only sets cache headers but doesn’t include proxy_pass directive.

Solution: Add the proxy_pass directive to the static files location block:

location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ {
    proxy_pass http://localhost:3000;  # This was missing!
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    # ... other headers

    expires 1y;
    add_header Cache-Control "public, immutable";
}

Verification:

# Test locally
curl -I http://localhost:3000/style.css

# Test through Nginx
curl -I https://366dailystoic.com/style.css

Issue 2: Service Won’t Start

Common causes and solutions:

• Port conflicts: Ensure port 3000 isn’t used by another service
• Permission issues: Verify the service user has read access to project files
• Path errors: Double-check WorkingDirectory and ExecStart paths in service file
• Missing dependencies: Run npm install in the project directory

Issue 3: Database Connection Errors

Solution: Ensure the SQLite database file has proper permissions:

sudo chown devuser:devuser daily-stoic.db
chmod 644 daily-stoic.db

Performance Optimizations

1. Database Query Optimization

• Indexed date_key column for fast daily lookups
• Connection pooling handled by sqlite3 driver
• Graceful database connection management

2. Caching Strategy

• Static files: 1-year browser cache with immutable flag
• API responses: Consider adding ETag headers for future optimization
• Nginx: Gzip compression for text-based content

3. Security Measures

• Content Security Policy: Restricts resource loading to trusted sources
• Security headers: Protection against common web vulnerabilities
• HTTPS enforcement: All traffic redirected to secure connections
• Process isolation: Service runs with minimal privileges

Monitoring and Maintenance

Service Monitoring

# Check service status
sudo systemctl status daily-stoic

# View real-time logs
sudo journalctl -u daily-stoic -f

# Check Nginx status
sudo systemctl status nginx

# Monitor resource usage
htop

Conclusion

This setup provides a robust, production-ready deployment for a Node.js application with:

• High availability through systemd process management
• Performance via Nginx reverse proxy and caching
• Security through SSL, security headers, and proper permissions
• Maintainability through clear configuration and logging

The Daily Stoic website demonstrates that simple, well-architected solutions can be both powerful and maintainable. By leveraging proven technologies like Nginx, systemd, and Let’s Encrypt, we’ve created a deployment that’s secure, fast, and reliable.

The total setup takes about 30 minutes once you understand the components, and the result is a professional-grade web application that can handle significant traffic while remaining easy to maintain and monitor.

Want to build something similar for your team or business? Contact me

This post was originally published in michaelscheiwiller.com

This is the third post in a series on building and deploying a RAG Streamlit app. In this post, I cover how to automate the deployment. In the first post, I explained how to build the app itself, and in the second i go through how to share the app without making the code public.

Read the other posts here:

1. Building a Streamlit-Powered RAG App with ChromaDB and OpenAI
2. Fast Private Streamlit Sharing with Systemd

# 1. Introduction

In Fast Private Streamlit Sharing with Systemd i described how to setup streamlit and how to share it on a VPS with your customer. The issue with this approach is, you have to manually update the codebase on the vps. If you just want to share a ‘final state’ then this might be ok. But if you want to iterate and get feedback then this gets annoying and timeconsuming. This is why i automated this with a github webhook, flask, nginx and systemd.

# 2. Prerequisits

To be able to automate this you should have build or have access to:

- VPS (will be on Linux)

- Python, virtualenv and pip

- Nginx

- Your app hosted on github

- basic knowledge of Linux cli

- systemd

# 3. Project Structure Overview

The structure of my app is as follows (parts not relevant for this post are marked (Optional)):

├── app.py # Main Streamlit application
├── update_and_restart.sh # Script to pull latest code and restart Streamlit
├── webhook_listener.py # Flask app to handle GitHub webhooks
├── requirements.txt # Python dependencies
├── .env # (Optional) Environment variables for Streamlit/OpenAI
├── .venv/ # Python virtual environment
├── data/ # (Optional) Data files for your app
├── chroma_db/ # (Optional) ChromaDB vector store
├── scripts/ # (Optional) Helper scripts for data processing
└── README.md # Project documentation

# 4. Deployment Workflow

Below is an extensive chart on how the deployment workflow looks like. Broken down to the main parts:

1. The user pushes a new commit to the github repository

2. Github sends a webhook to the flask app

3. The flask app pulls the latest code from the github repository

4. The flask app restarts the streamlit app

In the next section each part is explained in detail.

# 5. Step-by-Step Setup

## 5.1 Setting Up the Streamlit App and Virtaul Environment

Clone your streamlit app to your VPS, create a virtual environment and install the dependencies.

git clone <your-repo-url>
cd <your-repo-name>
python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

## 5.2 Update Script

Create a bash script to pull the latest code from the github repository and restart the streamlit app (e.g. `update_and_restart.sh`). This script will be used to update the app on the VPS.

#!/bin/bash

# Update the repository
git pull

# activate the virtual environment
source .venv/bin/activate

# install the dependencies
pip install -r requirements.txt

# restart the application
sudo systemctl restart streamlit

## 5.3 Configuring Environment Variables

Create a `.env` file to store the environment variables for the streamlit app (e.g. `GITHUB_WEBHOOK_SECRET`).

GITHUB_WEBHOOK_SECRET=your-github-webhook-secret

> You can generate a random secret for the github webhook secret with `python3 -c “import secrets; print(secrets.token_hex(32))”`

## 5.4 Flask Webhook Listener

Create a flask app to handle the github webhook (e.g. `webhook_listener.py`). This app will be used to pull the latest code from the github repository and restart the streamlit app.

import hashlib
import hmac
import os
import subprocess

from flask import Flask, abort, request

app = Flask(__name__)

GITHUB_SECRET = os.environ.get("GITHUB_WEBHOOK_SECRET", "").encode()

def verify_signature(payload, signature):
    mac = hmac.new(GITHUB_SECRET, msg=payload, digestmod=hashlib.sha256)
    expected = "sha256=" + mac.hexdigest()
    return hmac.compare_digest(expected, signature)

@app.route("/github-webhook", methods=["POST"])
def github_webhook():
    signature = request.headers.get("X-Hub-Signature-256")
    if not signature or not verify_signature(request.data, signature):
        abort(403)
    event = request.headers.get("X-GitHub-Event")
    if event == "push":
        payload = request.json
        if payload and payload.get("ref") == "refs/heads/main":
            subprocess.Popen(
                ["/bin/bash", "/home/devuser/projects/test-rag/update_and_restart.sh"]
            )
    return "", 204

if __name__ == "__main__":
    app.run(host="127.0.0.1", port=9000)

## 5.5 Managing the Flask Listener with systemd

Create a systemd service to manage the flask listener (e.g. `streamlit-webhook-listener.service`). This service will be used to start the flask listener on boot. This file lives in `/etc/systemd/system/`.

  [Unit]
  Description=Flask GitHub Webhook Listener

  [Service]
  User=devuser
  WorkingDirectory=/home/devuser/projects/test-rag
  Environment=GITHUB_WEBHOOK_SECRET='<your-github-webhook-secret>'
  ExecStart=/home/devuser/projects/test-rag/.venv/bin/python3 webhook_listener.py
  Restart=always

  [Install]
  WantedBy=multi-user.target

## 5.6 Nginx as a Reverse Proxy

Nginx is used as a reverse proxy to handle the incoming requests to the flask app. This is done to protect the flask app from direct access from the internet. Create a nginx configuration file:

sudo vim /etc/nginx/sites-available/streamlit-webhook

and then add the following content:

server {
    listen 8080;
    server_name YOUR_VPS_IP;

    location /github-webhook {
        proxy_pass http://127.0.0.1:9000/github-webhook;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

The configuration file is then linked to the nginx sites-enabled directory:

sudo ln -s /etc/nginx/sites-available/streamlit-webhook /etc/nginx/sites-enabled/
sudo nginx -t # test the configuration
sudo systemctl restart nginx

**Test if the nginx configuration is working**

From your VPS try the following commands:

sudo systemctl status nginx
sudo netstat -tuln | grep 8080

You should see the following output:

tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN

and then try to send a request to the flask app:

curl -X POST http://127.0.0.1:9000/github-webhook
curl -X POST http://localhost:8080/github-webhook

- The first command should hit flask directly and return some html with an 403 error (not authorized)

- The second command should hit nginx and return as well some html with an 403 error (not authorized)

> 1. A reverse proxy is a server that sits in front of your application and handles the incoming requests. It can be used to protect your application from direct access from the internet. (in contrast to a forward proxy which is used to access the internet)

> 2. You can find the IP of your VPS with `curl -4 ifconfig.me`

## 5.7 Open your Firewall

If you are using a VPS provider like Hetzner, you might need to open the port 8080 in the firewall.

sudo ufw allow 8080/tcp
sudo ufw enable

## 5.8 Github Webhook

Create a github webhook to send a request to the flask app when a new commit is pushed to the repository.

1. Go to your github repository

2. Click on `Settings` > `Webhooks` > `Add Webhooks`

3. Set the payload URL to `http://YOUR_VPS_IP:8080/github-webhook`

4. Set the content type to `application/json`

5. Disable SSL verification

6. Set the secret to the same secret as in the `.env` file

7. Set the events to `Push`

8. Click on `Add webhook`

# 6. Test the Setup

Push a new commit to the github repository and check if the streamlit app is updated.

- Is your vps reachable from the internet?

On your local machine try to send a request to the vps:

curl -X POST http://YOUR_VPS_IP:8080/github-webhook

If you get a 403 error again, you should be good to go.

# 7. Conclusion

In this blog post i showed how to automate the deployment of a streamlit app on a VPS with github webhooks, flask, nginx and systemd. This is a great way to deploy your streamlit app and keep it up to date so you can iterate and get feedback from your customers.

Want to build something similar for your team or business? Let’s talk i am happy to help out

# 8. Resources

• Setting up a new VPS
• Streamlit Documentation
• Flask Documentation
• Nginx Documentation
• Systemd Documentation
• Github Webhooks Documentation

This post was originally published in michaelscheiwiller.com

This is the second post in a series on building and deploying a RAG Streamlit app. In this post, I cover how to share the app without making the code public. In the first posts, I explained how to build the app itself, and in the last i go through how to automate deployment.

Read the other posts here:

1. Building a Streamlit-Powered RAG App with ChromaDB and OpenAI
2. Automating Streamlit App Deployment with Github Webhooks, Flask, Nginx ans systemd

If you want to share a Streamlit app with someone who is not technical and can not clone and build the app on their own, you have to provide them somehow with a link they can access to use the app and give you feedback. For Streamlit apps whichs repos are public, this is easily done with Streamlit Cloud.

But if you want to keep the repo private, you have to host the app somewhere. One of the easiest ways to do this i found to use a VPS and run the app as a systemd service (check this post for a vps setup guide). This post details how i set it up.

Running as a systemd Service

To keep the Streamlit app running in the background and automatically restart it if it fails, you can set it up as a systemd service.

1. Create the service file directly in `/etc/systemd/system`:

sudo vim /etc/systemd/system/streamlit.service

2. Paste the following content (edit paths as needed):

[Unit]
Description=Streamlit App
After=network.target

[Service]
User=devuser
WorkingDirectory=/home/devuser/projects/test-rag
ExecStart=/home/devuser/projects/test-rag/.venv/bin/streamlit run app.py --server.port 8501 --server.address 0.0.0.0
Restart=always

[Install]
WantedBy=multi-user.target

3. Enable and start the service:

sudo systemctl daemon-reload
sudo systemctl enable streamlit
sudo systemctl start streamlit

4. Check the status:

sudo systemctl status streamlit

The app will now run in the background and restart automatically if it crashes. You can access it at `http://YOUR_VPS_IP:8501/`.

Want to build something similar for your team or business? Contact me

This post was originally published in michaelscheiwiller.com

This is the first post in a series on building and deploying a RAG Streamlit app. In this post, I cover how to build the app itself. In the following posts, I explain how to share it without making the code public, and how to automate deployment.

Read the other posts here:

1. Fast Private Streamlit Sharing with Systemd
2. Automating Streamlit App Deployment with Github Webhooks, Flask, Nginx ans systemd

1. Introduction

A friend of mine regularly runs into legal questions at work. These questions come from his clients. The thing is, he doesn’t have a legal background, and it’s not really his job to deal with these issues. But navigating laws and their connections gets messy fast. And if it’s not your core job, there’s almost no way to build up the experience to handle them confidently.

That’s why he, his team, and probably others rely on a lawyer to get answers. As you can imagine, these lawyers have a heavy workload, and sometimes it takes weeks to get a response.

When he told me about it, I figured this could be a great opportunity to dive into RAG (Retrieval-Augmented Generation) and build an MVP. So I started working on a RAG chatbot. This post is the first iteration, and there will likely be more as the app evolves and becomes more sophisticated.

2. What is Retrieval-Augmented Generation (RAG)?

LLM’s like ChatGPT have a vast amount of general knowledge. They can help you with everyday tasks in almost every domain. Regarding very specific and detailed knowledge they might have seen before but might have “problems” to remember. I imagine this has having kind of a “foggy mind” where they know the general direction but not every detail of it. In legal documents like laws these might be e.g. the number of a relevant article or the exact wording of a relevant passage.

This “foggy mind” shortcoming can be overcome with Retrieval-Augmented Generation (RAG). So the LLM does not have to answer out of memory but has a storage with the relevant documents and looks the information up. RAG is a hybrid architecture that has two stages:

1. **Retriever**: Given a query from a user the retriever searches the (document) storage to get the most relevant context (often via vector similarity using embeddings).

2. **Generator**: The retrieved context from stage 1 then is passed to an LLM, which uses it to base their answer on it.

3. Frameworks

I wanted to get something up and running as fast and simple as possible. This is why i went for a python only stack and no cloud database. This is what i used:

- Streamlit — Streamlit is a fast and light python frontend framework. It lets you easily generate a simple UI. It is mostly used to showcase early MVP’s or internal Dashboards. It lacks a lot of configuration options and SEO possibilities, but for a fast iteration without overhead it is perfect.

- ChromaDB — ChromaDB is an open source vector database on top of Sqlite. It also writes in a single file and can therefore easily be selfhosted on a vps (check this blogpost) to see how to set up a vps). It is designed for storing and querying embeddings.

- OpenAI API — Well, it is just easiest and for an MVP i did not bother setting up a local LLM. The OpenAI API is used as the main LLM as well as for the Retriever and Generator.

4. Architecture

This is how the different pieces fit together:

How it works:

1. The user asks a question in the Streamlit App
2. The app retrieves relevant law passages and articles form ChromaDB
3. The app sends the context and question to OpenAI
4. The LLM generates an answer, citing sources
5. The answer and sources are shown to the user

LangChain orchestrates the workflow:

• It takes the user’s question and retrieved context
• Formats them into a prompt using a template
• Sends this prompt to OpenAI
• Parses and returns the answer

5. Challenges & Learnings

Since i wanted to be able to cite the exact article from a certain law, i had to store the articles as chunks. Where the chunks would be too long i had to separate the chunk with the same article. Storing this together with the law as metadata in ChromaDB was initially not trivial. Especially having different laws and different formats had to make me different chunking functions.

Building such applications has gotten much easier in the age of coding agents and IDE’s (i only use cursor these days). But putting together different frameworks and libraries for this RAG app did not work by only prompting. Especially the metada storing in ChromaDB (which references the law and article number) was a struggle in the beginning. But once you go oldschool and visit the docs you are good to go.

Want to build something similar for your team or business? Contact me

This post was originally published in michaelscheiwiller.com.

Cronjobs are a way to schedule any jobs on your machine/server: run a script, remove files, copy data, make backups. It is a very convenient way to actually automate regular and tedious work. As explained motivation to do so, was the jobscraper of NextGenEnergyJobs.com.

Sidenote: if you need to set up a server first i also wrote

- How to set up a server and

- How to set up your ssh config file

I first thought this is going to be straight forward: I mean we have llm’s these days. But i actually ended up running into troubles with the setup and then always postboning. This is why i wanted to write it down so i get it right from the beginning the next time and maybe it is helpful for others as well.

So first things first: open the crontab file (on your server or unix machine with)

crontab -e

which opens the crontab file in edit mode in your defined texteditor (vim for me). The content then looks like this:

# Edit this file to introduce tasks to be run by cron.
#
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
#
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').
#
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
#
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
#
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
#
# For more information see the manual pages of crontab(5) and cron(8)
#
# m h dom mon dow command

So the content itself actually already tells us a lot about cron and cronjobs: The first 5 entries of the line are whitespace separated integers which indicate the

• minutes
• hour
• day of month
• month and
• day of week

For any of these entries you also can use ‘\*’ for ‘any’. After these schedule indicators come the actual command. What i first not was aware of, is that cronjobs run with a limited environment, and the `PATH` variable might not include the directories needed for e.g. `python` or even `echo`. What i first came up with is a line of code to change into the scraper directory, activate the virtual environement and start the scraper script. Since this failed, i then did the following to test (as said cronjobs run in a limited environment, so its better to write the full paths):

* * * * * /bin/echo "Successful cronjob" >> /home/scraperuser/cronjobtest.log

This runs every minute and appends “Successful cronjob” to the specified `cronjobtest.log` file. With this running i then realised i need to call the bash shell specifically. So the final crontab entry for the scraper was:

0 9 * * * /bin/bash -c 'cd /home/scraperuser/projects/best-jobscraper-in-the-world && source .venv/bin/activate && python3 src/main.py' >> /home/scraperuser/jobscraper.log 2>&1

This cronjob runs everyday at 09:00 am UTC and executes from the bash shell the command in the quotes’ and appends it to the `jobscraper.log` file.

Originally posted on michaelscheiwiller.com

I’ve been working more with servers lately, and that means getting into SSH. One thing that i found annoying was to type out full IP addresses every time I needed to connect, like `ssh root@49.31.40.21`. It’s annoying and likely for errors. Then I discovered the SSH config file. It lets you give your servers friendly names, use tab autocomplete, and connect in seconds. Here’s how to set it up, step by step.

1. Open (or Create) Your SSH Config File

On your local machine, head to your SSH directory and open — or create — the config file:

vim ~/.ssh/config

If it doesn’t exist yet, Vim will create it for you.

2. Add Your Server Details

Now, add entries for each server and user combo you want to connect to. For example, I manage a Hetzner server with two users: `root` and `scraperuser`. The latter runs cronjobs and hosts job-scraping repos for NextGenEnergyJobs.com. (Need help setting up a server? Check out my previous post on setting up a new Linux server).

Here’s what I added to my config:

Host hetzner-root
 HostName 71.13.43.01
 IdentityFile ~/.ssh/id_ed25519_hetzner
 User root

Host hetzner-scraper
 HostName 71.13.43.01
 IdentityFile ~/.ssh/id_ed25519_hetzner
 User scraperuser

• `Host`: Your custom nickname for the connection (e.g., `hetzner-root`)
• `HostName`: The server’s IP address
• `IdentityFile`: Path to the SSH private key (make sure it matches your key pair)
• `User`: The username on the server.

3. Save and Connect

Save the file (in Vim, hit `:wq` and Enter), and you are ready. Now, connecting is as simple as:

ssh hetzner-root

# or
ssh hetzner-scraper

If you type `ssh hetz` and hit Tab — your shell will autocomplete the rest.

Let me know what you think! I am very happy for every feedback!

This post was originally published on michaelscheiwiller.com.