Operations Architect
1 Week
n8n, Docker, PostgreSQL, Grafana, etc.
Infrastructure Deployment
The client had outgrown the economics and limitations of their managed automation platform.
As workflow volume increased, vendor-imposed task limits began restricting what their automations could do, while licensing costs continued to rise alongside usage. The business faced a decision: upgrade to a significantly more expensive cloud tier or take ownership of its automation infrastructure entirely.
After reviewing workflow volume, operational requirements, and long-term growth plans, I recommended a self-hosted deployment.
The primary benefit was not cost savings, although moving to a private Oracle Cloud Infrastructure environment would reduce automation software and infrastructure costs by more than 99%. The more important advantage was control. A self-hosted environment removes vendor-imposed execution limits, gives the business full ownership of its data, and provides complete visibility into the infrastructure supporting mission-critical workflows.
For a client whose automations processed sensitive operational data, infrastructure ownership was not simply a financial decision. It was a governance and compliance decision.
Before deploying any infrastructure, I assessed workflow volume, execution patterns, data retention requirements, monitoring expectations, and future scalability needs.
This audit produced the architecture blueprint and informed every major infrastructure decision, including server sizing, database selection, monitoring strategy, and security controls.
By defining the architecture before deployment began, the environment was built around operational requirements rather than retrofitted after launch.
The platform was deployed on Ubuntu 22.04 running on an Oracle Cloud Infrastructure instance.
n8n was deployed using Docker, creating a clear separation between the application layer and the host operating system. This approach simplified maintenance, improved portability, and reduced the risk of configuration drift over time.
Future application updates could be completed by replacing container images rather than modifying server-level configurations.
Rather than relying on n8n’s default SQLite database, I configured a dedicated PostgreSQL instance for workflow execution and operational data.
While SQLite is suitable for smaller deployments, it can become a performance bottleneck as workflow volume increases. Implementing PostgreSQL during setup required minimal additional effort while eliminating the need for a complex production database migration later.
This decision ensured the platform was prepared for growth from day one.
Cloudflare was configured to manage DNS and secure external access to the platform using strict SSL policies, ensuring all traffic remained encrypted.
To provide visibility into system health, I implemented Grafana monitoring connected directly to server metrics. The dashboard allowed the client to monitor CPU utilization, memory consumption, uptime, and infrastructure performance without requiring direct server access.
The monitoring layer was designed to support operational independence after handoff rather than relying on technical intervention for routine health checks.
The simplest deployment path would have been to use SQLite because it requires less configuration and works adequately for small installations.
I intentionally replaced it with PostgreSQL during setup because the client’s workflow volume made long-term execution data management an important consideration. Implementing the right database architecture early eliminated the risk, cost, and downtime associated with a future production migration.
Installing n8n directly on the host server would have reduced deployment time.
I chose Docker because it isolates the application from the underlying operating system and simplifies future upgrades. This decision reduced operational complexity and made it easier for the client to manage the platform after project handoff.
Monitoring systems are often configured for technical administrators rather than business operators.
I designed the Grafana environment so the client could view infrastructure health without needing SSH access or server-level expertise. CPU usage, memory consumption, uptime, and system performance were available through a simple dashboard that supported self-service monitoring after deployment.
The most important architectural decision was moving away from a platform constrained by licensing tiers and execution limits.
By adopting a self-hosted model, the client gained complete ownership of their automation environment, sensitive business data, and operational roadmap. Future workflow growth would no longer be dictated by vendor pricing structures or platform restrictions.
The deployment achieved 99.9% uptime from go-live while reducing automation software and infrastructure costs by more than 99% compared to the client’s previous platform.
Vendor-imposed execution limits were eliminated entirely, allowing the business to increase workflow complexity and automation volume without introducing new licensing constraints.
All sensitive credentials, operational data, and workflow activity remained inside the client’s private cloud environment, satisfying compliance requirements from the first day of operation.
The Grafana monitoring layer provided ongoing visibility into system health, while Docker-based deployment simplified maintenance and future upgrades.
Beyond the immediate cost savings, the project established a scalable automation foundation capable of supporting future workflow growth without requiring significant architectural changes. The client gained full ownership of their automation infrastructure while maintaining visibility, security, and operational control.
Uptime Achieved
Operational Cost Saved
Data Sovereignty
Task Execution Capacity
That is exactly where I do my best work. Tell me what is frustrating you operationally, even if you cannot name it precisely yet. I will ask the right questions and tell you what I would fix first.