Search for a command to run...
Learn how to configure PostgreSQL and Redis on Kubernetes for n8n workflow automation. Includes security best practices and persistence configuration.
I am a student studying in Mumbai University, learning DevOps, looking for opportunities to learn more things by gaining experience at prestigious institutions
No comments yet. Be the first to comment.
A comprehensive guide to deploying n8n workflow automation platform on AKS using first principles and production-grade best practices.
Master n8n's queue mode and worker scaling on Kubernetes. Learn how to configure distributed workflow processing for high-volume automation needs.
A Dev Journey Through Hackathons, Childhood Games, and Pokémon Cards
A Deep Dive into CI/CD, Workflow Architecture, and Secure Automation for Modern Software Development
A comprehensive guide to creating a robust, scalable CI/CD pipeline for a multi-tier Java application using AWS, Kubernetes, Terraform &GitHub Actions
A technical deep dive into how we built a cloud-native system that transforms handwritten prescriptions into structured medication information
A First Principles Approach to Decoding Server Activity and Transforming Data into Actionable Intelligence
This is Part 3 of the "Building a Production-Ready n8n Workflow Automation Platform on Azure Kubernetes Service" series. View the complete series here.
A robust data layer is critical for any production workflow system. In our n8n deployment, the data layer consists of two primary components:
Let's implement each of these components with production-grade configurations.
n8n stores various types of data that require a reliable, ACID-compliant database:
PostgreSQL is an excellent choice for n8n because it offers:
For our production deployment, we implemented several security best practices:
First, we created a Kubernetes Secret to store database credentials:
apiVersion: v1
kind: Secret
metadata:
name: postgres-secret
namespace: n8n
type: Opaque
data:
POSTGRES_USER: cG9zdGdyZXM= # "postgres" base64 encoded
POSTGRES_PASSWORD: cFstNUpxdHM9UyVGYzMrTEY= # base64 encoded password
POSTGRES_DB: bjhu # "n8n" base64 encoded
Note: For security, always generate strong random passwords for production deployments.
We applied this secret:
kubectl apply -f postgres-secret.yaml
To create a dedicated n8n user in PostgreSQL, we created a ConfigMap with an initialization script:
apiVersion: v1
kind: ConfigMap
metadata:
name: postgres-init-script
namespace: n8n
data:
init-db.sh: |
#!/bin/bash
set -e
psql -v ON_ERROR_STOP=1 --username "$POSTGRES_USER" --dbname "$POSTGRES_DB" <<-EOSQL
CREATE USER n8n WITH PASSWORD 'secure-password-here';
GRANT ALL PRIVILEGES ON DATABASE n8n TO n8n;
ALTER USER n8n WITH SUPERUSER;
EOSQL
This script is executed when PostgreSQL starts, creating an n8n user with appropriate privileges.
Now we can create the PostgreSQL deployment:
apiVersion: apps/v1
kind: Deployment
metadata:
name: postgres
namespace: n8n
spec:
replicas: 1
selector:
matchLabels:
app: postgres
template:
metadata:
labels:
app: postgres
spec:
containers:
- name: postgres
image: postgres:13
ports:
- containerPort: 5432
env:
- name: POSTGRES_USER
valueFrom:
secretKeyRef:
name: postgres-secret
key: POSTGRES_USER
- name: POSTGRES_PASSWORD
valueFrom:
secretKeyRef:
name: postgres-secret
key: POSTGRES_PASSWORD
- name: POSTGRES_DB
valueFrom:
secretKeyRef:
name: postgres-secret
key: POSTGRES_DB
volumeMounts:
- name: postgres-data
mountPath: /var/lib/postgresql/data
- name: init-script
mountPath: /docker-entrypoint-initdb.d
resources:
requests:
memory: "512Mi"
cpu: "500m"
limits:
memory: "1Gi"
cpu: "1000m"
volumes:
- name: postgres-data
persistentVolumeClaim:
claimName: postgres-data-claim
- name: init-script
configMap:
name: postgres-init-script
Key aspects of this configuration:
To make PostgreSQL accessible to other pods in the cluster, we created a Kubernetes Service:
apiVersion: v1
kind: Service
metadata:
name: postgres-service
namespace: n8n
spec:
selector:
app: postgres
ports:
- port: 5432
targetPort: 5432
type: ClusterIP
This service provides a stable endpoint (postgres-service) for other components to connect to PostgreSQL.
Redis serves as the queue manager for n8n's distributed workflow execution. It:
We deployed Redis with the following configuration:
apiVersion: apps/v1
kind: Deployment
metadata:
name: redis
namespace: n8n
spec:
replicas: 1
selector:
matchLabels:
app: redis
template:
metadata:
labels:
app: redis
spec:
containers:
- name: redis
image: redis:6-alpine
ports:
- containerPort: 6379
resources:
requests:
memory: "256Mi"
cpu: "200m"
limits:
memory: "512Mi"
cpu: "500m"
volumeMounts:
- name: redis-data
mountPath: /data
volumes:
- name: redis-data
emptyDir: {}
For our use case, we chose a simple Redis deployment without persistence, as the queue data can be regenerated if lost. For more critical deployments, you could add a PersistentVolumeClaim similar to PostgreSQL.
We created a Redis service to make it accessible to n8n components:
apiVersion: v1
kind: Service
metadata:
name: redis-service
namespace: n8n
spec:
selector:
app: redis
ports:
- port: 6379
targetPort: 6379
type: ClusterIP
Our complete data layer architecture can be visualized as:
This architecture provides:
After deploying PostgreSQL and Redis, we verified their status:
kubectl get pods -n n8n
Successful output looks like:
NAME READY STATUS RESTARTS AGE
postgres-xxxxxxxxx-xxxxx 1/1 Running 0 2m
redis-xxxxxxxxx-xxxxx 1/1 Running 0 1m
We also verified the services:
kubectl get services -n n8n
With output:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
postgres-service ClusterIP 10.0.xxx.xxx <none> 5432/TCP 2m
redis-service ClusterIP 10.0.xxx.xxx <none> 6379/TCP 1m
Now that our data layer is properly set up, we can proceed to deploying the n8n application layer in the next section.
With our data layer successfully deployed, we have reliable PostgreSQL storage for our workflow definitions and execution history, plus Redis for efficient queue management. These components form the persistence backbone of our n8n deployment.
In the next article, we'll deploy the n8n application itself, including the main service and worker nodes for distributed processing. [Continue to Part 4: Application Layer]
Have you implemented PostgreSQL or Redis in Kubernetes before? What database optimization techniques have worked best for your workflow automation systems? Share your insights in the comments!