This approach introduces more operational complexity than a single VM setup, but it is the most robust option if you expect growth, higher execution volume, or need production-grade reliability.

Why EKS + Postgres?

Before diving into setup, it’s important to understand the architectural choices.

Why Kubernetes (EKS)?

• Horizontal scalability as the workload grows
• Declarative infrastructure with versioned manifests
• Better fault tolerance and restart guarantees
• Easier future expansion (workers, queues, HA setups)

Why Postgres instead of SQLite?

SQLite works for small, single-node setups, but breaks down quickly in real deployments.

Postgres gives you:

• Concurrent access safety
• Better performance under load
• Durability across pod restarts
• A clear path to scaling n8n horizontally

Persistent storage becomes non-negotiable once you move beyond experimentation.

Prerequisites

You’ll need the following tools installed and configured:

• AWS account with sufficient permissions
• AWS CLI (configured with credentials)
• eksctl
• kubectl
• Git

You should already be comfortable with:

• Kubernetes concepts (pods, services, volumes)
• Containerized applications
• Basic AWS networking

Creating the EKS Cluster

Use eksctl to provision a Kubernetes cluster:

eksctl create cluster --name n8n --region <your-aws-region>

Cluster creation takes several minutes. Once complete, kubectl will automatically be configured to use this cluster context.

Cloning the n8n Kubernetes Manifests

n8n provides a reference repository containing Kubernetes manifests for production setups.

git clone https://github.com/n8n-io/n8n-hosting.git
cd n8n-hosting/kubernetes

This directory contains manifests for:

• Namespace creation
• Postgres deployment and service
• n8n deployment and service
• Persistent volume claims
• Secrets

Configuring Postgres with Persistent Storage

Why Persistent Volumes Matter

Kubernetes pods are ephemeral by design. Without persistent volumes:

• A Postgres pod restart wipes your database
• n8n loses workflows, credentials, and execution history

To prevent this, Postgres must be backed by an AWS EBS volume.

Storage Class

The default AWS gp3 Storage class is a solid choice for Postgres workloads.

In postgres-claim0-persistentvolumeclaim.yaml:

spec:
  storageClassName: gp3
  accessModes:
    - ReadWriteOnce

This ensures:

• Data survives pod restarts
• Storage is attached to exactly one node at a time (required by EBS)

Postgres Environment Variables

Postgres requires credentials and database configuration passed as environment variables.

The postgres-secret.yaml file contains placeholders. You must replace these with your hosted Postgres credentials:

• POSTGRES_USER – root/admin user
• POSTGRES_PASSWORD
• POSTGRES_DB
• POSTGRES_NON_ROOT_USER
• POSTGRES_NON_ROOT_PASSWORD

Why Two Users?

• The root user is used for initialization and administration
• The non-root user is what n8n uses at runtime

This follows best practices:

• Reduced blast radius if credentials leak
• Lower risk of accidental schema or system damage

The postgres-deployment.yaml manifest injects these values into the container securely.

Configuring n8n Persistent Storage

File Storage Volume

While n8n can technically run without persistent storage, doing so is risky.

Persistent storage is required to:

• Preserve uploaded files
• Store the encryption key file generated on startup
• Avoid credential invalidation after restarts

The n8n-claim0-persistentvolumeclaim.yaml creates this volume, which is mounted in n8n-deployment.yaml:

volumes:
  - name: n8n-claim0
    persistentVolumeClaim:
      claimName: n8n-claim0

This ensures n8n behaves like a stateful application rather than a disposable container.

Resource Configuration

Kubernetes allows you to define resource requests and limits per pod.

From n8n-deployment.yaml:

resources:
  requests:
    memory: "250Mi"
  limits:
    memory: "500Mi"

This configuration:

• Guarantees a minimum memory allocation
• Prevents runaway memory usage
• Leaves CPU scheduling to Kubernetes

Reference: n8n Cloud Resource Profiles

• Start: ~320MB RAM
• Pro (10k executions): ~640MB RAM
• Pro (50k executions): ~1280MB RAM

Adjust these values based on your workload and node size.

Environment Variables for n8n

n8n behavior is largely controlled through environment variables.

Create an n8n-secret.yaml file and define:

• Database connection details
• Encryption key
• Base URL
• Execution mode
• Security-related flags

Refer to the official n8n environment variable documentation for a full list.

Deploying to the Cluster

Apply all manifests:

kubectl apply -f .

If you see a namespace error, apply it explicitly:

kubectl apply -f namespace.yaml
kubectl apply -f .

This creates:

• The n8n namespace
• Postgres deployment + service
• n8n deployment + service
• Persistent volumes and secrets

Exposing n8n via Load Balancer

The n8n-service.yaml exposes n8n on port 5678 using a Kubernetes LoadBalancer.

To find the public endpoint:

1. Open the EKS cluster in the AWS console
2. Go to Resources → Services
3. Select the n8n service
4. Copy the Load balancer URL

Point your DNS subdomain to this address.

Important: HTTP vs HTTPS

The example manifests expose HTTP only.

AWS may show an HTTPS URL for the load balancer, but this will fail unless TLS is explicitly configured.

For now:

• Access n8n using http://your-subdomain:5678
• Add TLS later using an Ingress + cert-manager if needed

Cleaning Up

To delete all Kubernetes resources created by this setup:

kubectl delete -f .

To fully remove the cluster:

eksctl delete cluster --name n8n

Final Thoughts

Running n8n on EKS with Postgres is not the simplest way to get started, but it is the most future-proof.

You gain:

• Durable workflow storage
• Safe restarts and upgrades
• Horizontal scalability
• Clear separation between application and data

If you’re serious about running n8n in production, persistent Postgres storage is not optional — it’s foundational.

At Renben Technologies, we help businesses design and deploy AI-first workflows that go beyond simple automation. By combining tools like n8n with scalable cloud architectures and custom AI integrations, we turn fragmented processes into reliable, production-ready systems that deliver real business impact.

Self-Hosting n8n on AWS with EKS and Postgres was originally published in Renben Technologies on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’ll walk you through how to get the smaller of the two models, GPT-OSS 20B, up and running using Ollama, one of the easiest tools out there for local LLM inference.

What Is GPT-OSS?

OpenAI’s newly released models are:

• GPT-OSS 20B: A 20 billion parameter model built for reasoning and designed to run on everyday hardware
• GPT-OSS 120B: A larger, much more powerful version that requires serious GPU power to run locally

For most people, GPT-OSS 20B is the sweet spot. It’s fast, surprisingly capable, and works on devices with just 16 GB of RAM.

Why Use Ollama?

If you’re new to local models, Ollama is the tool that makes everything feel seamless. It takes care of the annoying stuff like model downloads, tokenization, GPU optimization, and serving the model. You can be chatting with a 20B parameter model in under 10 minutes.

Ollama works on macOS, Windows, and Linux. It supports both command-line interaction and integrations with apps like LM Studio. No Python environments. No Docker. Just a clean, native setup experience.

System Requirements

To run GPT-OSS 20B with Ollama, here’s what you’ll need:

• A machine with at least 16 GB of RAM
• Around 13 GB of free disk space
• macOS (M1/M2/M3), Windows, or a modern Linux distro

You don’t need a GPU, though it’ll help with speed. You also don’t need a cloud account or any API keys. It’s all local.

Note: The larger GPT-OSS 120B model is not practical for most users to run locally unless you have access to an 80 GB GPU.

Installing Ollama

To get started, install Ollama. On macOS or Linux, you can run this in the terminal:

curl -fsSL https://ollama.com/install.sh | sh

Or, if you’re on a Mac and prefer Homebrew:

brew install ollama

Windows users can download the installer from ollama.com/download.

Once installed, check everything’s working by running:

ollama --version

Learn more about running Ollama on Windows or Mac.

Running GPT-OSS 20B

Let’s pull and run the model.

Start by downloading it:

ollama pull gpt-oss:20b

This will grab the 12.8 GB model and set everything up behind the scenes.

Once it’s done, you can start chatting

ollama run gpt-oss:20b

That’s it. You’re now running an OpenAI reasoning model on your own machine.

Final Thoughts

Running a 20B model locally opens up so many possibilities. You don’t need an API key or a cloud subscription. You don’t need to worry about rate limits or privacy. And you don’t have to rely on someone else’s infrastructure.

This is a huge step for:

• Developers who want to prototype fast
• Researchers testing model behavior
• Anyone who wants full control over their AI workflows
• People working in sensitive or air-gapped environments

It’s also just really fun to play with.

Like the article? A ‘clap’ goes a long way!

Happy exploring with Ollama!

Key Benefits:

• Ultra-Fast Access: Sub-10ms response times globally
• Global Distribution: Automatic replication across Vercel’s edge network
• Secure by Default: Built-in authentication
• Real-time Updates: Changes propagate within seconds

Common Use Cases:

• Feature Flags
• API Keys & Secrets
• Application Settings
• Content Management
• A/B Testing
• Routing Rules

Getting Started

1. Installation

pip install vercelpy

2. Setup

Get your Edge Config connection string from the Vercel Dashboard and set it in your environment:

EDGE_CONFIG=https://edge-config.vercel.com/edcg_id?token=your_token

3. Getting Started with vercelpy

The vercelpy library makes working with Edge Config incredibly straightforward. Here’s one simple example for each core function:

import vercelpy.edge_config as edge

# Get a single value
api_key = edge.get("stripe_api_key")

# Check if a key exists
has_feature = edge.has("new_feature")

# Get multiple values at once
config = edge.get_all(["app_name", "timeout", "debug_mode"])

# Get configuration digest (for caching)
digest = edge.digest()

# Create a custom client (optional)
client = edge.create_client("https://edge-config.vercel.com/edcg_id?token=your_token")

4. Error Handling

from vercelpy.edge_config.errors import EdgeConfigError

try:
  value = edge.get("api_key")
except Exception as e:
  if str(e) == EdgeConfigError.UNAUTHORIZED:
    print("Authentication failed")
  elif str(e) == EdgeConfigError.EDGE_CONFIG_NOT_FOUND:
    print("Edge Config not found")
  else:
    print(f"Unexpected error: {e}")

Best Practices:

1. Use consistent key naming:

feature_new_ui = edge.get("feature_new_ui")
api_stripe_key = edge.get("api_stripe_key")
setting_timeout = edge.get("setting_timeout")

2. Batch your requests:

# ✅ Good: Single batch request
config = edge.get_all(["api_key", "timeout", "retry_count"])

# ❌ Bad: Multiple individual requests
api_key = edge.get("api_key")
timeout = edge.get("timeout")
retry_count = edge.get("retry_count")

3. Implement fallbacks:

def get_safe_config(key: str, default=None):
  try:
    return edge.get(key)
  except Exception:
    return default

max_retries = get_safe_config("max_retries", 3)

Ready to get started? Install vercelpy today and experience the power of edge-based configuration management!

pip install vercelpy

🔗 Like this guide?

• Clap for this story!
• Find me on Medium, GitHub, or LinkedIn

Uploading large files efficiently is crucial in modern web applications. Vercel Blob Storage supports multipart uploads, allowing you to handle files up to 5 TB by splitting them into smaller parts. This article demonstrates how to implement multipart uploads to Vercel Blob Storage using Python.

❓What Are Multipart Uploads?

Multipart uploads divide a large file into smaller parts, uploading each part separately. This approach offers several advantages:

• Resilience: If a part fails to upload, only that part needs to be retried, not the entire file.
• Efficiency: Parallel uploads of parts can speed up the overall upload process.
• Scalability: Supports uploading huge files without overwhelming memory resources.

Vercel’s Blob Storage API supports multipart uploads by setting multipart: True the upload process.

Prerequisites

Before implementing multipart uploads, ensure you have the following:

• Python 3.10 or higher: Required for compatibility with the vercel_blob library.
• Vercel Blob Storage Token: Obtain your BLOB_READ_WRITE_TOKEN from your Vercel project dashboard.
• vercel_blob Library: A Python wrapper for the Vercel Blob Storage API. Install it using pip:

pip3 install vercel_blob

Implementing Multipart Uploads in Python

The vercel_blob library simplifies interactions with Vercel Blob Storage. Here's how to perform a multipart upload:

import vercel_blob
import os

# Set your Vercel Blob Storage token
os.environ['BLOB_READ_WRITE_TOKEN'] = 'your_token_here'

# Define the file to upload
file_path = 'large_file.mp4'
file_name = os.path.basename(file_path)

# Open the file in binary mode
with open(file_path, 'rb') as f:
    # Upload the file with multipart enabled
    response = vercel_blob.put(
        file_name,
        f.read(),
        multipart=True,

    )

print("Upload successful!")
print(f"Blob URL: {response['url']}")

Explanation of Parameters:

• file_name: The name of the file to be stored in Vercel Blob Storage.
• f.read(): Reads the entire file content into memory.
• multipart=True: Enables multipart upload

This script reads the file in binary mode and uploads it to Vercel Blob Storage using multipart upload. The response contains the URL of the uploaded blob.

📚 Additional Resources

• vercel_blob GitHub Repository: SuryaSekhar14/vercel_blob
• Medium Article on Using Vercel Blob with Python: How to use Vercel Blob Storage with Python

By leveraging multipart uploads, you can efficiently handle large file uploads to Vercel Blob Storage in your Python applications. Ensure proper error handling and consider memory management strategies for optimal performance.

Feel free to contribute to ‘vercel_blob’, and if there are any issues, please open an Issue on GitHub. Also maybe, Buy me a Coffee?

“Which AI model should I actually be using?”

“Which AI model is best for Coding?”

You’re not alone — and you’re right to ask. Between OpenAI, Anthropic, Google, Meta, and Mistral all launching model after model, it’s starting to feel like you’re drafting code with a swarm of co-pilots, not one. Each one claims to be fast, smart, or cheap — but only some are helpful for your project.

This post is your no-fluff breakdown of how to pick the best AI model for the job — whether you’re prototyping fast, refactoring a legacy mess, or debugging with one hand and crying with the other.

Developer Personas

Let’s match AI models to who you are and what kind of work you do.

🛠️ The Prototyper

You’re building fast, breaking things faster.

• Prioritize speed and cost
• Okay with rough edges if it runs

Models to try:

• o3-mini: Super fast
• LLaMA 3 8B: Local and competent
• DeepSeek Coder 6.7B: Fast and clean

🧠 The Debugger

You’re hunting logic bugs and deciphering stack traces.

Models to try:

• GPT 4.5: Top-tier reasoning
• Claude 3.7: Long-context window, great Chain-of-Thought, explains well
• DeepSeek Code V2: Solid logic clarity

📚 The Documentarian

Explaining code is your jam.

Models to try:

• Claude 3.5: Structured & Clear
• Mistral Medium: Straightforward, no-fluff output
• DeepSeek Chat: Simplifies well

🏡 The Architect

You plan systems, not just functions.

Models to try:

• Claude 3.7: Handles the ‘big picture’ well
• GPT-4.5: From function to framework, it knows it all
• LLaMA3 70B: Open Source, Smart, Fast, Precise

🎨 The Designer-Dev

Visual inputs, layout debugging, front-end meets logic.

Models to try:

• GPT-4o: Elite multimodal performance
• Gemini Flash: Elite multi-modal performance
• Command R+: Good with data + UI

🔄 Model Matchmaking: Compute vs Capability

Here’s how top models compare when you weigh speed, reasoning depth, and cost:

• o3-mini
  💨 Blazing fast
  🧠 Basic reasoning
  💵 Ultra cheap
  🔧 Great for fast code sketches
• DeepSeek Coder 6.7B
  ⚡ Fast and sharp
  🧠 Solid reasoning
  💵 Budget-friendly
  🔧 Ideal for lightweight coding tasks
• Claude 3.5 Sonnet
  ⚡ Fast enough
  🧠 Balanced reasoning
  💸 Mid-tier cost
  📄 Excellent for documentation and mid-complexity tasks
• GPT-4o
  ⚡ Very fast
  🧠 Deep, multimodal understanding
  💸 Moderate cost
  💡 Best all-rounder
• Claude 3.7 Sonnet
  🐢 Slower
  🧠🧠🧠🧠 Reasoning powerhouse
  💸💸💸 Premium
  🧠 Suited for large, complex codebases
• GPT-4.5
  ⚡ Decent speed
  🧠🧠🧠🧠🧠 Top-tier logic
  💰 High cost
  🔍 For deep logic, planning, and architecture
• LLaMA 3 70B
  ⚡ Fast (local)
  🧠🧠🧠🧠 Strong reasoning
  💸 Reasonable cost
  🛠️ Ideal for self-hosting and power users
• DeepSeek Coder V2
  ⚡ Fast
  🧠🧠🧠🧠 Great depth
  💵 Affordable
  🧠 Great GPT-4 alternative for heavy lifting
• Gemini 1.5 Flash
  ⚡ Fast
  🧠 Moderate reasoning
  💸 Budget tier
  🎨 Great for visual tasks and frontend work
• Command R+
  🐢 Medium speed
  🧠 Good with data and UI
  💸 Reasonable
  📊 Perfect for UI and data-heavy workflows

🧹 The Decision Matrix (Cheat Sheet)

Here’s your cheat sheet, plain and fast:

• Need speed?
  Use o3-mini, DeepSeek 6.7B, or Mistral 7B.
• On a tight budget?
  Go with LLaMA 3 8B, DeepSeek, or Mistral.
• Writing lots of code?
  Reach for GPT-4.5, Claude 3.7, or DeepSeek V2.
• Working with visuals or front-end?
  Choose GPT-4o, Gemini Flash, or Command R+.
• Multi-file or big projects?
  Use Claude 3.7, GPT-4.5, or LLaMA 70B.
• Writing documentation?
  Pick Claude 3.5, DeepSeek Chat, or Mistral.
• Working offline / local?
  Try LLaMA 3, DeepSeek, or Mistral.

🏁 Final Notes

• Switch models based on your task. Don’t just default to GPT.
• DeepSeek is underrated. Try it. You might stop paying for other models.
• Claude = clean code. Especially if you like readable output.
• LLaMA 3 is the open-source MVP. Great for local or private setups.

You’re not picking one forever. You’re picking the right blade in the toolbox.

🧠 Smart devs use the right tool at the right time.

🔗 Like this guide?

• Clap for this story!
• Find me on Medium, GitHub, or LinkedIn