Project: a reusable AI OS blueprint you can deploy for any project

One build, many clients. Picture this. You built an AI assistant for a dental clinic. It answers customer messages, books appointments and logs new leads in a database, and it took you two weeks. Now a small online bakery wants exactly the same thing. Do you start from zero again? Most people do, and that's where the profit disappears. In this final project of the module, you'll turn everything you've built into a reusable blueprint. It's one folder you copy, fill in and deploy, so client number two takes an afternoon instead of two weeks.

What you will learn. Here's the plan for this lesson. First, you'll package the whole stack from this module into one folder. That stack is the proxy with SSL, n8n, the database with memory and documents, and the AI model. Second, you'll learn the most important design rule of any blueprint: keep the parts that never change apart from the few details that change for every client. Third, you'll walk through a real deployment for a new client, from an empty server to working workflows. By the end, you'll have something you can sell again and again.

The blueprint at a glance. Let's look at the whole system before we package it. There are four services on one server. That server is a VPS, a virtual private server, which simply means a computer you rent in the cloud by the month. Caddy is the front door: it handles the domain and the SSL certificate, the padlock in the browser. n8n runs your workflows. Postgres stores conversations and business data, and with the pgvector add-on it also stores your documents for RAG, which means the agent looks things up in your own files before it answers. Ollama runs the AI model on the server itself. A small model needs about 8 gigabytes of memory, so on a smaller server you can call a model API instead. When a customer writes in, the message passes through Caddy to n8n, which reads the history, asks the model and sends the answer back. Every client gets the same four boxes.

One folder per client. The blueprint is just a folder, and a folder is easy to copy. Inside it there are four things. The compose file describes the four services, and it's identical for every client. The Caddyfile is a tiny file for Caddy. It reads the domain from the settings and sends every visitor on to n8n. The settings file, called dot env, holds everything that's specific to one client. The workflows folder holds your exported n8n workflows as JSON files, which are plain text files describing each workflow. For a new client, you make a fresh folder on their server and copy those four things in. That's the whole setup step, and it takes less than a minute.

The compose file never changes. Here's a trimmed version of the compose file. Docker Compose reads it and starts all four services together with one command. Notice what's missing: there's no domain name, no password and no client name anywhere in it. The services that need settings read them from the same dot env file, and Caddy also gets the Caddyfile from the folder. That's the trick. Because the compose file holds nothing personal, you can copy it to fifty servers without editing a single line. The moment you type a client's password into this file, it stops being a blueprint and becomes a one-off build again.

The settings file changes per client. Now the part that does change. This small Python script writes a fresh settings file for one client. It sets the client name and their domain, then creates a strong random database password and a random encryption key for n8n. The database lines tell n8n to use Postgres and give it that same password. Random here means generated by the computer so nobody can guess it, like a new key cut for every front door. Run it once per client and you never reuse a password between clients again. Paste the output into the dot env file, and the client's identity is done.

Workflows as templates. Your workflows follow the same rule. Over this course, you've built a set of workflows for small businesses: answering customer messages, booking appointments, qualifying leads, sending invoices and a weekly sales report. Export each one from n8n as a JSON file and keep it in the workflows folder. Inside the workflows, don't type the business name or the email address into the nodes. Read them from settings or from a small table in the database instead. Then a new client is just a menu: a salon might take messages and bookings, while a consultant takes leads and invoices.

Worked example: Lotus Yoga. Let's deploy it for a real client, a small yoga studio called Lotus Yoga. Start with the owner's phone. Customers message the studio about class times and prices, and the answer workflow replies using the studio's own timetable and price list, loaded into the knowledge base. Next, the server. It's a VPS with 8 gigabytes of memory, enough for a small local model, running the four services from the blueprint. It has the settings file we generated a moment ago and only three workflows imported: messages, bookings and the sales report. Finally, the report. Every Monday morning, the owner gets a summary of bookings and income. Total setup time: about two hours.

The deployment checklist. Let's slow down and put the whole deployment in order, because the order matters. Rent the server. Turn on the firewall, the guard that blocks every door into the server you don't need. Leave open only the web ports and SSH, the secure remote login you use to control the server from your own computer. Then set up DNS, which means pointing the client's domain name at the server's address. Copy the blueprint folder and fill in the settings file. Run docker compose up, and Caddy reads the domain from the Caddyfile and fetches the SSL certificate on its own. Then, before you hand anything over, switch on the nightly backup and the uptime check from the previous lesson. Write this list down and follow it the same way every time.

Common mistake: one server for everyone. Here's the trap that catches many beginners. To save money, they put every client on one server with one shared database. It works for a while. Then the clinic's patient messages sit next to the bakery's orders, one bad workflow fills the disk and every client goes offline at once, and a single leaked password exposes all of them. Clients also can't leave with their data cleanly. The fix is simple: give each client their own copy of the blueprint, ideally on their own server. A server costs a few dollars a month, and trust is worth far more.

Recap. Let's wrap up. Your AI operating system now fits in one folder: a compose file and a Caddyfile that never change, a settings file that holds each client's details, and a library of workflow templates. Everything personal lives in the settings, so the rest can be copied freely. And every deployment follows the same checklist, with one separate copy per client so that their data and their uptime stay their own. That's the difference between a project you build once and a product you can sell many times.

Exercise: deploy it twice. Now it's your turn. Gather everything from this module into one blueprint folder: the compose file, the Caddyfile, a settings example and at least two exported workflows. Then deploy it for two imaginary clients, say a hair salon and an online plant shop, each with its own settings file. Use cheap servers or two folders on one test machine, just for practice. Time the second deployment and write down every step you took. If the second one is clearly faster than the first, your blueprint works. And with that, you've finished the module.