Local AI · Self-Hosting · Owning Your Own Compute
Part I taught you why sovereignty matters. This part teaches you the machine — how to run your own AI and host your own software on hardware you own, so nothing you make ever passes through someone else's cloud. First we cover how to build with AI (below), then how to run your own.
Developing sophisticated, lightweight front-end layouts like the Doth Punk Command Matrix requires strategic prompt decomposition. Attempting to output hundreds of lines of complex HTML, geometric canvas arithmetic, and asynchronous loops in a single pass pushes AI models toward structural chaos or token truncation.
To consistently generate flawless results, treat your AI collaborator as a component compiler by establishing a Three-Tier Prompt Framework:
Establish strict environmental bounds. Force the model to map architectural roots, CSS variable schemes (`:root`), global document structures, and clean flex container rules before any scripts are mentioned.
Once the framework boundaries are generated, supply explicit mathematical properties to the context window to isolate calculation matrices.
Finally, prompt for structural fallbacks. Instruct the AI model to build path-recovery systems so that broken localized paths do not result in terminal interface failure.
Creating an open 3D ring array using traditional flat layout systems requires computing spatial geometry. By stacking a dynamic perspective container over an inner rotational element using transform-style: preserve-3d;, we establish a localized coordinate grid system.
The spacing depth required to prevent cards from overlapping at the center is derived directly from the number of visible panels and the card width. We use the geometric formula:
For a 240px wide card with 6 visible cards, the tangent of 30 degrees (0.577) multiplied by 2 gives 1.154. Dividing 240px by 1.154 gives approximately 207.8px minimum displacement. Pushing past this value to 360px creates an open, expansive cylinder profile suitable for stellar animations.
True platform evolution requires freshness without server weight. Instead of calling external backend servers or database networks to randomise layout components, read your customer's system date parameters directly to construct a calendar clock tracking seed:
This integer remains completely constant for a solid 24-hour cycle. Passing this number to a linear congruential generator or a high-accuracy pseudo-random function returns a deterministic decimal string. This ensures that every node across the globe scrambles cards identically at exactly the same time, giving users a unified global experience that refreshes automatically at midnight.
If you have never typed a command in your life, you are in exactly the right place. From here on, the entire skill is copy → paste → press Enter. Read these five short things once and you'll understand every single step below.
Nothing in this course can harm your computer. If a step looks scary, throws an error, or you get lost — you just close the window and start that step over. That's the worst that happens. So relax and take it slow.
A terminal is just a text window where you type instructions instead of clicking buttons. To open it:
A window with text and a blinking cursor appears. That's the terminal. Leave it open — you'll paste commands into it.
Every dark box below is a command. To run one:
A line that starts with # is just a note to you — it explains what the next line does. You don't type the # notes.
Read the last few lines of the output — the error almost always says exactly what's missing. Every module below has a Troubleshooting box for the common ones. Still stuck? Close the terminal, reopen it, redo the step. You truly cannot mess anything up.
Welcome to Module 04. Before we touch a single button, we need to get one big idea straight in your head, because everything else in this course grows out of it. That idea is sovereignty — owning your own computing instead of renting it from giant companies. Don't worry if that sounds intimidating. By the end of this module you'll understand exactly what it means, why it matters, and precisely what machine to buy or dig out of your closet. No prior knowledge needed. You genuinely cannot break anything by reading and thinking.
Let's define our two most important words in plain English.
Sovereignty just means you are in charge. A sovereign country makes its own rules on its own land. A sovereign computer user runs their own software, on their own machine, under their own control — nobody else gets to peek, change the rules, or shut you off.
Self-hosting means running the apps and services you use on a computer you own, sitting in your own home, instead of on a company's computer far away. When you use Google Photos, Gmail, or ChatGPT, your files and words live on those companies' machines. When you self-host, the equivalent tools live on your machine, on your desk or in your closet.
Here's the everyday analogy that makes it click. Using the big cloud services is like renting an apartment. It's convenient, someone else fixes the plumbing, and you can move in today — but you don't own the place, the landlord can raise the rent, they hold a key, and they can eventually evict you. Self-hosting is like owning your own home. You do a bit more of your own maintenance, but nobody can raise your rent, nobody holds a spare key, and nobody can put you out on the street.
There's a famous saying in technology that cuts right to the heart of it: "The cloud is just someone else's computer." That's not a metaphor — it's literally true. "The cloud" sounds soft and magical, but it's a warehouse full of ordinary computers owned by Amazon, Google, or Microsoft. When your data is "in the cloud," it is sitting on a hard drive that belongs to someone else, in a building you'll never see. Self-hosting simply moves that computer back into your own hands.
In security, a threat model is just a plain list of "what could go wrong and who could cause it." Let's be honest about the risks of relying entirely on Big Tech clouds. None of this is paranoia — every item below has really happened to real people.
They log everything. Most free services keep detailed records of what you do — every search, every photo, every message's time and place. That log is valuable to them and permanent by default.
They may train AI on your data. Several companies have updated their terms so that the things you type, upload, or draw can be fed into training their AI models. Your private brainstorm can quietly become part of a corporate product.
They can censor or cut you off. Accounts get suspended by automated systems all the time, often with no human to appeal to and no warning. People have lost years of email, photos of their kids, and entire businesses overnight because an algorithm flagged them by mistake. When you don't own the machine, you don't own the off switch.
They raise prices whenever they like. A service that's cheap or free today can triple its price tomorrow, and once your whole life is inside it, you're stuck paying. This has happened repeatedly with cloud storage and software subscriptions.
They have outages. When a big cloud provider goes down — and they all do, sometimes for a whole day — thousands of apps that depend on it go dark at the same time. Your own machine at home doesn't care that a data center in another state is having a bad day.
The point isn't that these companies are evil cartoon villains. The point is simple: when you rent, someone else holds the power. Sovereign compute takes that power back.
Let's be fair and put both sides on the table, because a good teacher never oversells.
What it costs you: some hardware (a computer — we'll spec exactly what) and roughly a weekend of setup time following the next few modules. That's the whole price. There's a small learning curve, but this course exists precisely to walk you through it one baby step at a time.
What you get: real privacy (your data never leaves your house), full control (nobody can suspend your account or change the rules), and no monthly fees ever. You buy the machine once. After that, running your own photo library, notes, AI assistant, or media server costs you nothing but a little electricity. Over a few years, the hardware often pays for itself compared to a stack of monthly subscriptions — and the privacy is priceless.
Before we go shopping, let's learn the four parts that matter, so the prices later make sense. Think of a computer like a kitchen.
CPU (Central Processing Unit) — the head chef. It's the main "brain" that does general work: running programs, doing math, juggling tasks. Almost any CPU from the last several years is plenty for self-hosting.
RAM (Random Access Memory) — the counter space. It's fast, temporary work space where the computer holds whatever it's actively using right now. More RAM means more can happen at once without slowdown. It's wiped clean every time you power off. We measure it in gigabytes (GB).
Disk / SSD / NVMe — the pantry and fridge. This is permanent storage where your files live even when the power is off. An old-style HDD (hard disk drive) has spinning platters and is slow. An SSD (solid-state drive) has no moving parts and is much faster. An NVMe is the fastest kind of SSD, a little stick that plugs straight into the motherboard. For any modern build, get an SSD or NVMe — the difference in feel is night and day. Measured in gigabytes (GB) or terabytes (TB; 1 TB = 1000 GB).
GPU (Graphics Processing Unit) and VRAM — this is the big one for AI, so read slowly. A GPU was originally the "art department" that drew video-game graphics. It turns out the same chip is fantastic at the math behind artificial intelligence, because it can do thousands of tiny calculations at the same time. The GPU has its own dedicated memory called VRAM (Video RAM). When you run an AI model on your own machine, the entire model has to fit inside the VRAM — think of it as the size of the workbench the AI gets to spread out on. VRAM is the single most important spec for local AI. If a model is too big for your VRAM, it either runs painfully slowly or won't run at all. This is why a card with 24 GB of VRAM is the target we keep coming back to — it's the amount that lets you run genuinely capable AI models at home. A GPU with a fast chip but small VRAM is like a brilliant chef given a workbench the size of a postage stamp.
Here's a tiny cheat-sheet you can keep in your head:
A bill of materials is just a fancy phrase for "shopping list." You don't need everything at once, so we offer three tiers. Start wherever your budget and ambitions land — you can always grow later. Prices are rough and change with the used market, but they'll orient you.
TIER 1 — The Starter (~$150). This is for pure self-hosting: running your own file storage, notes, photo library, password manager, or media organizer. It does not run big local AI, and that's fine — it does everything else beautifully. Buy a used business-grade mini-PC or an old laptop. Great picks are a used Dell OptiPlex Micro, HP EliteDesk Mini, or Lenovo ThinkCentre Tiny, or literally the old laptop in your drawer.
TIER 2 — The Serious Desktop (~$900–$1,400). This is the tier that unlocks local AI — running a chat assistant or an image generator on your own machine with nothing sent to the cloud. The heart of it is a desktop tower with an NVIDIA GPU that has 24 GB of VRAM. We say NVIDIA specifically because almost all AI software is built for NVIDIA first; it's the path of least pain for a beginner.
TIER 3 — The Fortress (~$2,500+). This is for people who want everything running 24/7, reliably, forever. It adds two ideas. First, a NAS (Network Attached Storage) — a dedicated little box whose only job is to hold lots of hard drives safely, so if one drive dies your files survive. Second, a cluster — two or more small machines working as a team, so if one goes down the others keep serving. You do not need this to start. It's the destination, not the doorway.
The secret to affordable sovereign compute is buying used. Brand-new AI hardware is wildly overpriced; the used market is where the real value hides. Here's how to do it without getting burned.
Where to buy: eBay is the safest starting point for a beginner because it has strong buyer protection — if the item is broken or never arrives, you get your money back. Local marketplaces (Facebook Marketplace, Craigslist) can be cheaper but offer no protection, so only use them if you can test the item in person before paying.
What to check before you buy: read the seller's rating (look for hundreds of reviews and 98%+ positive); make sure the listing has real photos of the actual item, not a stock image; confirm it says "tested and working"; and prefer sellers who accept returns. For a GPU specifically, ask whether it was used for gaming (fine) and avoid ones described as heavily overclocked or visibly damaged.
Why the used RTX 3090 is the sweet spot: it has the same 24 GB of VRAM as cards costing three or four times more, because VRAM — not raw speed — is the wall you hit with AI. A used 3090 gives you that crucial 24 GB for the lowest price of any option. It's a little power-hungry and a little bulky, but for running local AI at home it is, dollar for dollar, the smartest buy available. That's why this course keeps pointing you at it.
An operating system (OS) is the foundational software that runs your whole machine — Windows and macOS are the two you've probably heard of. For sovereign compute we use a third one called Linux, and specifically a beginner-friendly version of it called Ubuntu.
Two quick reassurances. First, Ubuntu is completely free — you download it, no license, no cost, ever. Second, if you remember Linux being scary and command-line-only decades ago, forget that. Modern Ubuntu has a clean, friendly, point-and-click desktop that feels a lot like Windows or a Mac. You'll spend some time in the terminal in this course, but only because it's the fastest way — never because you're forced to.
For a machine that will run quietly in a closet with no screen attached, there's also Ubuntu Server, a stripped-down version with no desktop at all — you control it from another computer. Don't worry about picking between them yet; the next module tells you exactly which to install and walks you through every click. For now, just know the answer to "which OS?" is Ubuntu, and it's free.
You now understand the mindset and know exactly what machine to get. Here's the road ahead so you can see where each piece fits:
Module 05 sets up your local AI — you'll install everything and have an AI assistant running entirely on your own hardware, with nothing sent to the cloud. Module 06 covers self-hosting — turning your machine into your own private replacements for the cloud services you use today. Module 07 makes it all reachable, so you can safely get to your sovereign services from your phone or anywhere in the world.
Take a breath — you've already done the hardest part, which is understanding why. Everything from here is just careful, well-lit steps. Grab your hardware (even just the Tier 1 old laptop to begin), and we'll see you in Module 05.
This is the big one. By the end of this module you will be typing questions to a real, intelligent AI that lives entirely on your own computer — no internet, no company reading your words, no monthly bill, no limits. Just you and a very smart program having a conversation. If that sounds like magic, it is a little. And I promise you can do it, even if today is the very first day you have ever opened a terminal.
First, let me calm one fear right now. You cannot break your computer by typing commands in this module. Everything we do here is normal, reversible, and safe. If something looks wrong, you close the window and start again. Nothing is on fire. Take a breath — we are going to go slowly, one tiny step at a time, and I will tell you exactly what you should see on your screen after every single thing you type.
One quick vocabulary word before we start: a terminal is just a plain text window where you type commands to your computer instead of clicking buttons. On a Mac it is an app called Terminal. On Windows it is called PowerShell or Command Prompt. On Linux it is Terminal too. When I say "type this and press Enter," I mean: click inside that black or white text window, type the words exactly, and hit the Enter (Return) key. That is the whole skill. You already know how to do it.
An AI model is basically a giant pile of math. Something has to do that math very fast, or the AI will answer sooo slowly you lose patience. The best thing for this job is a graphics card — also called a GPU, which stands for "Graphics Processing Unit." It was originally built to draw video games, but it turns out the exact same kind of math draws pictures and runs AI. Lucky us.
The important number on a graphics card is its VRAM — "Video RAM," the card's own private memory, measured in gigabytes (GB). The bigger this number, the bigger and smarter an AI model you can run. Think of VRAM like the size of a desk: a bigger desk lets you lay out a bigger, more detailed project. We are about to find out how big your desk is.
Open your terminal, type this command exactly, and press Enter:
That name means "NVIDIA System Management Interface" — it is a little report tool that comes with NVIDIA graphics cards. Here is what you might see:
If you see a table — a box drawn with lines, full of numbers, with words like "NVIDIA GeForce" and a column that says something like 16384MiB — congratulations, you have an NVIDIA graphics card and it works. Look for a number ending in MiB next to the word "Memory." That number divided by 1024 is roughly your VRAM in gigabytes. So 16384MiB is about 16 GB. Write that number down; you will need it in Step 3.
If you see "command not found" (or "nvidia-smi is not recognized") — do not panic. It just means you either do not have an NVIDIA card, or its drivers are not installed. This is completely fine. Plenty of people run local AI without an NVIDIA card. Move on to the Windows check below, or skip to the reassurance at the bottom of this step.
To check on Windows the easy, click-only way: press Ctrl + Shift + Esc to open Task Manager. Click the Performance tab on the left. If you see an entry named GPU (there may be GPU 0 and GPU 1), click it. In the corner it lists "Dedicated GPU memory" — that is your VRAM. If the only GPU listed is an "Intel" or "AMD Radeon Graphics" built into the processor, you have what is called integrated graphics, which have very little dedicated memory. That still works for AI — just slower.
Mac users: modern Macs (M1, M2, M3, M4 chips) do not have a separate NVIDIA card, and that is totally okay. Their memory is shared between the main computer and the graphics, and Ollama (the app we install next) is very good at using it. You do not need to run any check — just keep going.
Here is the reassuring truth: no graphics card at all still works. Your computer's main brain, the CPU ("Central Processing Unit"), can run these AI models too. It is slower — a big answer might take a minute instead of a few seconds — but it works, it is private, and it is free. Do not let a missing GPU stop you. Keep going.
Ollama is a small, free, open-source program whose entire job is to download and run AI models on your machine with almost no fuss. It is the friendly front door to local AI. Think of it like a media player, but instead of playing movies it "plays" AI brains. We install it once and never think about it again.
On a Mac or on Linux, type this single line into your terminal and press Enter:
Let me translate that so it is not scary. curl is a built-in tool that downloads things from the internet. The web address is Ollama's official installer script. The | sh part at the end means "and then run what you just downloaded." So the whole line means: "Download Ollama's official setup and run it." When you press Enter, text will scroll down the screen — messages about downloading and installing. This takes a minute or two. It may pause and ask for your password (on Linux especially); type it and press Enter — you will not see the letters appear as you type the password, and that is normal and intentional, just type it and hit Enter. When it finishes, the scrolling stops and your blinking cursor comes back, waiting for your next command. That blinking cursor returning is your signal that a command is done.
On Windows, it is even simpler — no command needed. Open your web browser, go to ollama.com, and click the big Download button. It will save a file called something like OllamaSetup.exe. Find that file in your Downloads folder, double-click it, and click "Next"/"Install" like any normal program. When it is done, Ollama runs quietly in the background — you may notice a little llama icon appear near your clock in the corner of the screen.
Now let us confirm it actually installed, on any system. Type this and press Enter:
If you see something like ollama version is 0.5.7 (the exact numbers do not matter), it worked — you now have an AI engine installed. Take a second to appreciate that. If instead you see "command not found," close your terminal completely, open a brand-new terminal window, and try ollama --version again — a fresh window is often all it needs to notice the new program. On Windows, make sure that llama icon is showing near the clock; if not, open the Start menu, type "Ollama," and click it to start it.
A model is the actual AI brain — the file full of learned knowledge that does the thinking. There are many, made by different companies and given names like qwen2.5, llama3.1, and gemma. They come in different sizes, and size is the thing you need to understand before you download one.
Model size is measured in parameters. A parameter is one tiny adjustable knob inside the AI's "brain." Modern models have billions of them, and we write that with a B for billion. So qwen2.5:7b means "the Qwen 2.5 model with 7 billion parameters." The plain-English rule: more parameters = smarter and more capable, but needs more VRAM (more desk space) and runs slower. A 7B model is quick and good for everyday chat. A 70B model is noticeably wiser but demands a serious graphics card. Bigger is not always better for you — the best model is the biggest one your computer can comfortably hold.
One more word you will see: quantization. Do not let it intimidate you. It just means the model has been cleverly compressed to take up less memory — like a high-quality zip file — with almost no loss in how smart it feels. Ollama does this for you automatically, so you get a model that fits your machine without you doing anything. You do not need to choose it; I mention it only so the word does not surprise you later.
Now, match your VRAM number from Step 1 to this table and pick exactly ONE line — the highest one your VRAM can reach:
Not sure which line is yours? When in doubt, pick the smaller model. A model that fits comfortably and runs fast is far more pleasant than a giant one that crawls or refuses to load. You can always download a bigger one later — nothing is permanent. For the rest of this module I will use qwen2.5:14b as my example; wherever you see that, swap in the one you picked.
This is the moment. One command downloads your chosen model and starts a chat with it. Type this (replacing qwen2.5:14b with your pick from the table) and press Enter:
The word run means "start using this model." Here is exactly what happens, so nothing surprises you. Because this is the first time you are using this model, Ollama has to download it first. AI models are big files — a few gigabytes — so this download takes anywhere from 5 to 30 minutes depending on your internet speed. You will see a progress bar filling up, with a percentage and a download speed, something like pulling manifest... 47% ▕████ ▏ 3.1 GB/6.6 GB. This is completely normal. Go make a coffee. You only ever wait for this once per model — after today it starts instantly.
When the download finishes, the progress bar disappears and you will see a friendly line and then this:
Those three arrows >>> are the AI's way of saying "I am ready — talk to me." This is your prompt. Click after the arrows, type a real question in plain English, and press Enter. Try this:
Watch closely. Within a second or two, words will start appearing on the screen, one after another, as if someone is typing them live. That is your AI, thinking and writing in real time, using nothing but your own computer. There is no server, no account, no internet request. This little poem was born entirely on your desk. Congratulations — you are officially running your own AI. That is a genuine milestone, and most people on Earth have never done it. Sit with that for a moment.
Ask it anything else you like — how to boil an egg, to explain a word, to help write an email. It will keep chatting for as long as you want. When you are finished and want to leave the chat, type this exactly and press Enter:
The /bye command (note the slash at the front) politely closes the AI and returns you to your normal terminal — your blinking cursor comes back, ready for ordinary commands. The AI is not deleted; it is just resting. To talk to it again anytime, you simply run ollama run qwen2.5:14b again, and this time it opens instantly because the download is already done.
You have my word that this AI runs entirely on your machine, but you do not have to take my word for it. Let us prove it with your own eyes, because seeing it makes the whole thing click.
Start a chat again with ollama run qwen2.5:14b and wait for the >>>. Now — and this is the fun part — turn off your WiFi completely. Click the WiFi icon in the corner of your screen and switch it off, or literally unplug the network cable. Fully disconnect from the internet. Then ask the AI a question, any question, and press Enter.
It answers. Just like before, exactly as fast, with no internet at all. That is your proof. The intelligence is not out there in some data center — it is right here, in the model file sitting on your hard drive. You could take this laptop to a cabin with no signal, to a plane, to the middle of the ocean, and your AI would keep working perfectly.
Why does this matter so much? Because when you use a normal online AI, every word you type travels to a company's computers, where it can be stored, read, analyzed, and used to train future systems. Your private questions, your business ideas, your health worries, your half-finished writing — all of it leaves your control. With a local AI, none of it ever leaves your computer. It is as private as a notebook in a locked drawer. That is the entire point of everything we are building. Turn your WiFi back on now — we will want it again for the next steps.
You only need a few commands to manage your AI collection. Here they are, in plain English. You type each of these at your normal terminal (not inside a >>> chat).
To see every model you have downloaded, type:
You will see a neat table listing each model's name, a size in gigabytes, and when you last touched it. This is your personal library. If you only downloaded one model, you will see one row — that is correct.
To download a new model without immediately chatting with it (handy for grabbing one to use later), type ollama pull followed by the model name. For example:
You will see the same download progress bar as before. When the cursor returns, that model is in your library, ready whenever you want it. The word "pull" is just tech-speak for "download to my machine."
To delete a model you no longer want (to free up disk space), type ollama rm ("rm" means "remove") followed by its name:
It vanishes and you get your gigabytes back. Do not worry — you can always pull it again later; deleting is not scary or permanent in any harmful way.
And switching between models is beautifully simple: there is no "switch" command to learn. You just run whichever one you want. Fancy the small fast one right now? ollama run qwen2.5:7b. Want the big brainy one for a hard question? ollama run qwen2.5:32b. Each is its own separate chat. That is all there is to it.
Here is something quietly powerful. The moment Ollama is installed, it also opens a little doorway on your own computer that other programs can knock on to talk to your AI. That doorway is called an API, which stands for "Application Programming Interface." Do not let the jargon scare you — an API is simply a way for one program to ask another program for something. It is like a drive-through window: a program pulls up, places an order ("please answer this question"), and drives away with the food (the answer).
Ollama's drive-through window has an address: localhost:11434. The word localhost is a special name that always means "this very computer, right here" — not somewhere on the internet, but the machine in front of you. The 11434 is the port number — think of it as the specific window number the AI is listening at, out of many possible windows. So localhost:11434 means "the AI service, on my own machine."
Let us prove the window is open and get your AI to answer through it — using code, so you can see how a future app or website would talk to it. Make sure Ollama is running, then type this whole thing as one command and press Enter (you can copy it in one go):
Remember curl from Step 2 — it is our little tool for sending and fetching things. This time, instead of downloading a web page, it is placing an order at your AI's drive-through window. The -d part is the order slip, written in a format called JSON (do not worry about learning it now): it names the model, the prompt (the question), and asks for the answer all at once rather than word-by-word.
After a moment, a chunk of text will appear that looks a bit messy, with curly braces and quotation marks — something like {"model":"qwen2.5:14b","response":"Hello! How are you today?", ...}. Find the part after "response": — that is your AI's answer, delivered through code. The messy wrapping around it is just the standard envelope that programs use to pass answers back and forth. This exact mechanism is how you would one day wire your local AI into a phone app, a website, or a smart-home gadget — they all knock on this same door. You just watched the future of your own private software say hello.
Typing in a terminal is powerful, but maybe you want the polished, click-friendly experience — a proper chat window in your web browser with a message history, buttons, and nice bubbles, just like the famous online AIs. There is a wonderful free tool for exactly this called Open WebUI. It gives your local Ollama a beautiful face.
One honest heads-up: Open WebUI runs inside something called Docker, which is a separate tool we cover fully in Module 06. So if you have not done Module 06 yet, bookmark this step and come back — you will need Docker installed first. It is worth it. Once Docker is ready, type this single (long) command and press Enter:
That is a mouthful, but you do not need to understand every piece. In plain terms it says: "download the Open WebUI program, run it quietly in the background, keep it running even after I restart my computer, and make it available at window number 3000." When you press Enter, text will scroll as it downloads (a one-time wait of a few minutes), then the cursor returns. That is it — it is running.
Now open your web browser (Chrome, Firefox, Safari, any of them) and in the address bar type:
Press Enter and a gorgeous chat interface loads. The first time, it asks you to create an account — this account is local, on your own computer only, not registered with anyone on the internet; it is just so the app can remember your chats. Make up an email and password, and you are in. Pick your model from the dropdown at the top, type in the message box, and chat away with the same private AI — now with a friendly face. Many people never touch the terminal again after this.
Everything so far has been about words. But your computer can also generate pictures from a text description — your own private version of tools like Midjourney or DALL·E, running with the same total privacy. The most popular tool for this is called ComfyUI, paired with an image "brain" called a FLUX model (the picture equivalent of the chat models you just learned about).
The idea is the same as before: ComfyUI is the engine, FLUX is the model it runs, and it all happens on your machine with no images ever sent to a company. You type a description — "a cozy cabin in the snow at sunset, painterly" — and a few seconds later a brand-new image appears that has never existed before, made entirely by your own hardware. This one leans harder on that graphics card and its VRAM, which is why we spent time on Step 1.
Setting up ComfyUI and FLUX has a few more moving parts than Ollama, so we give it the full, careful, nothing-assumed treatment it deserves in Part III of this course. For now, just know that it exists, that it is free, and that private local image generation is absolutely within your reach — the same reach that just let you run a local chat AI. You are more capable than you were an hour ago.
If something did not go perfectly, do not feel discouraged — every single person who does this hits at least one of these, and every one has a simple fix. Find your symptom below.
"Out of memory" or a "CUDA error" when a model loads. What it means: the model you chose is too big for your graphics card's VRAM — you tried to lay out too big a project on too small a desk. The fix: pick a smaller model from the Step 3 table. If you tried qwen2.5:14b, step down to qwen2.5:7b, or qwen2.5:3b. It will load, run faster, and still be plenty smart. There is no shame in a smaller model — it is the right choice for your hardware.
"command not found" or "not recognized" when you type ollama. What it means: your terminal has not noticed the newly installed program yet, or the install did not finish. The fix: close every terminal window completely and open a brand-new one, then try ollama --version again — a fresh window usually solves it. On Windows, check for the llama icon near your clock; if it is missing, open the Start menu, type "Ollama," and click it to launch. If it still fails, simply run the Step 2 installer once more; reinstalling on top of itself is harmless.
Answers come out very, very slowly, word by painful word. What it means: your AI is running on your CPU (the main brain) instead of a GPU, either because you have no graphics card or the model is too big to fit on it and spilled over. This is not broken — it is just working hard. The fix: for a real speed jump, use a smaller model (the 3b or 7b options); they run much faster on a CPU. If you do have an NVIDIA card but it is being ignored, see the driver fix at the bottom of this list.
"port is already in use" or "address already in use," especially on 11434 or 3000. What it means: another copy of the program is already running and has claimed that window number, so a second copy cannot open the same window. The fix: you probably do not need a second copy at all — the first one is fine, just use it. If you truly want to reset, restart your computer, which clears every window and lets things start fresh. For the Docker one on port 3000, you can also run docker restart open-webui.
The model download seems frozen or stuck partway. What it means: usually a wobbly internet connection interrupted the download. The fix: press Ctrl + C (hold Ctrl and tap C) to stop it — this is a safe, universal "cancel" that never harms anything — and then run the exact same ollama run or ollama pull command again. Ollama is smart: it picks up where it left off rather than starting over, so you do not lose the gigabytes already downloaded. If your internet is genuinely down, reconnect first, then retry.
Your NVIDIA card exists but is not being detected (nvidia-smi failed, or the AI ignores the GPU). What it means: the graphics card is physically there, but the driver — the software that lets your system talk to the card — is missing or out of date. The fix on Windows: go to nvidia.com/drivers, let it detect your card, download the latest driver, install it, and restart. The fix on Linux: your system's driver package needs installing — this varies by Linux flavor, so search "install NVIDIA driver" plus the name of your Linux (for example "install NVIDIA driver Ubuntu"). After a driver install you must restart the computer, then run nvidia-smi again — the table should now appear.
Open WebUI shows no models in its dropdown. What it means: the web interface cannot yet see your Ollama, usually because Ollama is not running or because Docker cannot reach it. The fix: make sure Ollama is running (run ollama list in a terminal — if it answers, Ollama is alive). Then refresh the browser page at http://localhost:3000. If it is still empty, run docker restart open-webui and give it a few seconds before refreshing.
And the golden rule for all of it: you cannot break anything here. Worst case, you delete a model and download it again, or you restart your computer and start the step over. There is no wrong turn you cannot walk back from. You have already done the hard, brave thing — you opened a terminal and stood up your own private artificial intelligence. Everything from here is just polish. Well done.
Right now, when you watch a movie on Netflix or store a photo on Google Photos, you are renting someone else's computer. Your data lives on a giant machine in a warehouse owned by a big company, and you pay every month for the privilege of borrowing it. Self-hosting means running that same kind of software — a movie streamer, a photo library, a notes app — on a computer you own, sitting in your own home, with your data on your own disk. Nobody can raise the price, spy on it, or switch it off. It is yours.
That probably sounds like something only a wizard could do. It is not. By the end of this module you will have a real, working service running on your own machine: Jellyfin, which is your own private Netflix — it plays your movies and shows in a web browser and on your phone. We are going to go one tiny step at a time. You have never opened a terminal? Perfect. That is exactly who this is written for. And here is the promise: you cannot break anything. Everything we do runs on a spare machine, in little sealed boxes, and if something goes wrong you can delete it and start over in thirty seconds. Nothing here can hurt your phone, your main computer, or your files.
A quick word on two terms before we start. A terminal (also called a "command line" or "shell") is just a text window where you type instructions to the computer instead of clicking buttons. A command is one of those typed instructions. When I show you a dark box, that is a command — you type it (or copy-paste it) and press the Enter key. That is the whole skill. Let's go.
You need a computer that can stay switched on. It does not need to be powerful or new. Great choices: a cheap "mini-PC" (a computer the size of a paperback book, often under $150 used), or an old laptop gathering dust in a drawer. A laptop is lovely because it has a built-in screen, keyboard, and battery. This machine will become your little "server" — a computer whose job is to run software for other devices in your home.
We are going to install Ubuntu Server on it. Ubuntu is a free, friendly version of Linux (an operating system, like Windows or macOS, but free and built for exactly this). "Server" edition means it has no fancy desktop — just the text terminal — which keeps it fast and simple. Installing it will erase everything on that machine, so make sure it is an old/spare one with nothing you want to keep.
First, on your normal everyday computer, go to ubuntu.com/download/server and download the file it offers. This file is called an ISO — think of it as a perfect digital copy of an installation CD, packed into one file. It will be around 2–3 gigabytes and take a few minutes.
Now we make a "USB installer" — a memory stick you can boot the new machine from. Get any USB stick that is 4 GB or bigger (its contents will be wiped, so use an empty one). Download a free program called balenaEtcher from etcher.balena.io. Open it, and it asks three things:
When Etcher says "Flash Complete", your USB stick is now a magic installer. Unplug it and take it to the spare machine.
Plug the USB stick into the spare machine and turn it on. You need to tell it to start from the USB rather than its own disk. Do this by tapping a key the moment you power on — usually F12, F2, Esc, or Del (the startup screen often flashes "Press F12 for boot menu"). If you see a menu, choose your USB stick. If you see X: if it boots straight into the old system instead, just turn it off and try a different key. You truly cannot break it by trying.
Ubuntu's installer now walks you through some questions. Here is what they mean in plain English — for almost all of them the default answer (just press Enter) is correct:
It installs for a few minutes, then says "Reboot Now". Pull out the USB stick and press Enter. The machine restarts into your new system and shows a plain black screen ending in something like homeserver login:. Type the username you chose, press Enter, type your password (the screen shows nothing as you type the password — that is normal and on purpose, keep typing and press Enter). You are in! You will see a $ waiting for you. That $ is the terminal, ready for commands.
First job: get all the latest security patches. Type this exactly and press Enter:
Let's decode that. apt is Ubuntu's app-installer (its "app store" for the terminal). update checks what new versions exist; upgrade -y installs them (-y means "yes, don't keep asking me"). sudo means "do this as the administrator" — it will ask for your password the first time. The && in the middle simply means "do the first thing, and if it worked, do the second thing too." You will see pages of text scroll by as it downloads updates — that is exactly right. When the $ comes back, it is done.
One more thing you need: the machine's LAN IP address. LAN means "Local Area Network" — the private network inside your home that your router creates. Every device on it (your phone, laptop, this server) gets a number, its LAN IP, like a house number on your street. Devices use it to talk to each other. Find your server's number by typing:
You will see something like 192.168.1.42. Write this number down. It is how every other gadget in your home will find your server. (If several numbers appear, the one starting 192.168 or 10. is the one you want.)
Before we install our movie service, we need Docker. Here is the problem Docker solves. Software is fussy: an app might need a specific version of some other program, which needs a specific version of something else, and getting all those pieces to agree is a nightmare that people call "dependency hell." It is like trying to cook a recipe where the ingredients keep fighting each other.
Docker fixes this with an analogy you already know: the shipping container. Before shipping containers, loading a boat meant wrestling barrels, sacks, and crates of every shape. Then someone said "put everything in identical steel boxes," and suddenly any crane at any port could handle any cargo. Docker does that for software: it packs an app plus everything it needs into one sealed box that runs the same way on any machine, launched with a single command. No dependency hell. And because each app is in its own sealed box, one can never mess up another — that is why you cannot break anything.
Install Docker by pasting this one line and pressing Enter:
That fetches Docker's official install script and runs it. You will see a lot of text scroll by for a minute or two, then the $ returns. Docker is installed. Now one small comfort tweak — by default Docker needs sudo every single time, which gets annoying. Add yourself to Docker's group so you don't have to:
usermod modifies a user, -aG docker means "add to the group called docker," and $USER is a shortcut that means "me." This change only takes effect after you log out and back in. So type exit, then log back in with your username and password. (Nothing appears to happen — that is fine.)
Let's prove Docker works. Type:
Docker will download a tiny test box and run it. You will see a friendly message that begins "Hello from Docker! This message shows that your installation appears to be working correctly." If you see that, congratulations — you have a working container engine. If instead you see "permission denied," you skipped the log-out-and-back-in; do that now and try again.
Docker only really has four words you need to know. Here they are, kept as simple as possible:
Image — the recipe, or the blueprint. It is the packaged-up app sitting on a shelf, not yet running. Jellyfin comes as an image. You download it once.
Container — the recipe actually cooking. When you "run" an image, you get a container: a live, running copy of the app. You can start it, stop it, and delete it, and the original image stays safe on the shelf so you can make another.
Volume — a folder on your real disk that the container is allowed to save things into. This matters enormously: containers are disposable, but volumes are permanent. Your movies and settings live in a volume, so even if you delete and rebuild the container, your data is untouched.
Port — a numbered "door" on your machine that lets other devices reach the app inside. Jellyfin listens on door number 8096. When your phone visits that door, it reaches Jellyfin. We simply have to leave the door open.
That's it. Image = blueprint. Container = the running app. Volume = where its data is saved. Port = the door people knock on. Keep those four in mind and the rest is easy.
We could type a long, scary docker run command by hand, but there is a much nicer way: a docker-compose file. This is a simple text file that describes what you want running, so you never have to remember the details. You write it once, then start everything with one short command.
Make a home for it. Type these two lines (press Enter after each):
mkdir makes a folder (a "directory") called jellyfin; cd means "change directory" — it walks you into that folder so we work inside it. Now create the file with a simple built-in text editor called nano:
A blank editor opens. Carefully type (or copy) exactly the following. Spacing matters in these files — use spaces, not tabs, and keep the indentation as shown:
Now let's read it line by line, because understanding it is the whole point:
services: — "here is the list of apps I want to run." Everything indented under it is one app.
jellyfin: — a nickname for this app. You pick it; it is just a label.
image: jellyfin/jellyfin:latest — which blueprint to use. This tells Docker to fetch the official Jellyfin image; :latest means the newest version.
container_name: jellyfin — the name the running container will have, so you can refer to it easily later (for example when checking its logs).
ports: - "8096:8096" — open the door. The format is always outside:inside. The left number is the door on your machine that the world knocks on; the right number is the door inside the container that the app listens on. Here they are both 8096. Remember "outside:inside" — it comes up again in troubleshooting.
volumes: - ./config:/config and - ./media:/media — the permanent folders. Again the format is outside:inside. ./config is a folder on your real disk (the dot means "right here, next to this file") that maps to /config inside the container, where Jellyfin keeps its settings. ./media maps to /media, which is where your movies and shows go. Because these point at real folders on your disk, your data is truly yours and survives anything.
restart: unless-stopped — the safety net. This tells Docker: if the app crashes, or the machine reboots after a power cut, start it back up automatically. The only time it stays off is if you deliberately stopped it.
Save the file: press Ctrl and O together (that's the letter O, for "Output"), press Enter to confirm the name, then Ctrl and X to exit back to the terminal. Now the magic word:
docker compose up reads your file and starts everything in it. The -d means "detached" — run it quietly in the background so it keeps going even after you close the terminal. You will see Docker download the Jellyfin image (a progress bar of bits and pieces) and then a line like Container jellyfin Started. That's it. Jellyfin is running.
Go to any device on your home network — your phone, your laptop — open a web browser, and type your server's LAN IP followed by :8096. Using the example from earlier that would be:
You will see the Jellyfin welcome screen. It walks you through a friendly setup: pick a language, create your own username and password for Jellyfin, and point it at your media (choose /media, the inside folder we mapped). To actually put movies in, you'd copy video files into the media folder that appeared next to your compose file. And there it is — your own private Netflix, running on your own machine.
Here is the beautiful part. Adding more software is just adding more blocks to the same file. Let's add a small extra service so you can see the pattern. Open the file again with nano docker-compose.yml and add a new block indented the same way as the first one. Your file now looks like this:
The new whoami service is a tiny, harmless app that just prints some info about itself — perfect for proving the pattern works. Notice its port line: "8200:80". The app inside listens on door 80, but we chose to expose it on door 8200 outside, because two services can't share the same outside door. Save and exit (Ctrl+O, Enter, Ctrl+X), then run the exact same command as before:
Docker is smart: it sees Jellyfin is already running and leaves it alone, and it starts only the new whoami. Visit http://YOUR-LAN-IP:8200 in a browser and you'll see it respond. That's the whole model — every new app is just another block and another run of the same command. Photo library, notes app, password manager: same pattern, forever.
Remember those volume folders? Let's see them. Make sure you are in the jellyfin folder (cd ~/jellyfin) and type:
ls means "list" — it shows what's in the current folder. You'll see docker-compose.yml, a config folder, and a media folder. Those two folders are real folders on your real disk. Everything Jellyfin knows — your account, your settings, your library — is inside config. Your videos are inside media. This is the whole payoff of self-hosting: your data is not floating in some company's cloud, it is right there, in a folder you can see, copy, and hold. Which means you can back it up and never lose it. That's next.
The golden rule of never losing data is called 3-2-1: keep 3 copies of anything you care about, on 2 different kinds of storage, with 1 copy kept offsite (somewhere else physically, in case of fire or theft). Your live folder is copy one. Let's make copy two on an external USB drive, and think of an offsite location for copy three (a friend's house, a second drive you keep at work, or an encrypted cloud folder).
The tool for copying folders safely is rsync. It is clever: it only copies what has changed since last time, so backups after the first are fast. Plug in an external drive (say it appears at /mnt/backup) and run:
Decoding it: rsync is the copier; -a means "archive" (keep everything exactly as it is); -v means "verbose" (show me what you're doing); --delete keeps the backup a perfect mirror by removing files from the backup that you deleted from the original. The first path is from (your live data), the second is to (the backup drive). You'll see a list of files scroll past as they copy.
Doing that by hand every night is a chore you'll forget, so let's have the machine do it automatically with a cron job — a built-in scheduler that runs commands on a timer. Type:
If it asks which editor, choose nano (usually option 1). At the bottom of the file that opens, add this single line:
Those five symbols at the front are the schedule: minute, hour, day-of-month, month, day-of-week. 0 3 * * * means "at minute 0 of hour 3, every day" — i.e. 3 a.m. nightly. The stars mean "every." Save and exit (Ctrl+O, Enter, Ctrl+X). Now your data quietly backs itself up every night while you sleep. Every so often, copy the backup drive's contents somewhere offsite, and you've completed 3-2-1.
Software gets improvements and security fixes. Updating your services is two short commands. From inside the folder with your compose file, run:
docker compose pull downloads the newest version of each image in your file; then (thanks to &&, "and if that worked") docker compose up -d gently swaps each running container for the fresh version. Your volumes are untouched, so nothing you care about is lost — just the app gets newer. Old, replaced images pile up over time and waste disk space, so clean them out now and then with:
That deletes only unused leftover images (-f means "don't ask me to confirm"). It never touches anything that's running. Do this whole update routine once a month and you're in great shape.
Three little commands tell you everything about how your services are doing. First, see what's running:
ps means "processes" — it lists every running container with its name, its status, and its ports. You should see jellyfin with a status of Up. If something you expected isn't there, it isn't running. To see why a service is misbehaving, read its logs (the diary an app writes about what it's doing):
Swap jellyfin for whichever container name you're curious about. You'll see the app's recent messages; error messages usually say in plain-ish English what went wrong. Finally, to stop everything cleanly (for example before moving the machine) and start it again:
down stops and removes the containers (but not your volumes — your data is safe), and up -d brings them all back. This stop-and-start is the classic "turn it off and on again," and it fixes a surprising number of hiccups.
"permission denied" when you run a docker command. This almost always means you skipped the group step or the log-out. Run sudo usermod -aG docker $USER again, then fully log out (exit) and log back in. Test with docker ps. That fixes it every time.
"port is already allocated" or "address already in use" when starting. Two apps are trying to use the same outside door. Remember outside:inside — just change the left (outside) number in your compose file to a free one. For example change "8096:8096" to "8097:8096", save, and run docker compose up -d again. Then visit the new number (:8097) in your browser. The inside number stays the same because the app inside doesn't move.
A container keeps restarting over and over. In docker ps you'll see its status flickering or saying "Restarting." The container is trying to start, failing, and (thanks to your restart policy) trying again. Read its diary to find out why: docker logs jellyfin. The last few lines usually name the problem — often a typo in the compose file or a folder it can't access. Fix that, then docker compose up -d.
You can't reach the service from your phone or laptop. First, double-check the address: it must be your server's LAN IP (run hostname -I on the server to confirm it hasn't changed) followed by the correct outside port, like http://192.168.1.42:8096. Make sure the other device is on the same home Wi-Fi — a phone on mobile data can't see your LAN. If it's still unreachable, a firewall on the server may be blocking the door; open it with sudo ufw allow 8096 (swap in your port). Then reload the page.
And that is genuinely all of it. You installed an operating system, learned Docker, ran a real service, made it scale, backed it up automatically, and learned to keep it healthy and fix it. You are now self-hosting — running your own software, on your own machine, with your own data. Everything from here — photos, notes, passwords, a whole home cloud — is the exact same pattern you just learned: add a block, run docker compose up -d, and it's yours.
Take a breath — you've done the hard part. Your service is running on your machine at home. But right now it only works when you're sitting in your own house, on your own WiFi. The moment you walk out the door, your phone can't reach it anymore. In this module we fix that: by the end, you'll be able to open a web address on your phone from anywhere on Earth — a coffee shop, another country, a moving car — and see your own AI or software, running on your own machine at home, encrypted and private. And we're going to do it the safe way, the way that does not turn your home into a target. Let's go slowly. You don't need to understand networking to follow this. I'll explain every word.
Before we do anything, let me give you four little words so nothing feels like magic. You do not need to memorize these — just read them once.
A network (or "LAN", which stands for Local Area Network) is just all the devices in your home talking to each other through your router — your laptop, your phone, your printer, your TV. Think of it like the rooms inside your house.
An IP address is the "phone number" of a device on a network. There are two kinds. A local IP (like 192.168.1.50) is your device's number inside your house only — useless from outside, like a room number that only means something once you're already in the building. A public IP is the single number your whole home shows to the outside internet — like your house's street address. Anyone on the internet can, in principle, see that public address.
A port is a numbered door on a machine. One computer can run many programs at once, so each program listens at its own numbered door. Your Jellyfin media server might listen at door 8096; an AI chat app might listen at door 3000. That's what localhost:8096 means — "door 8096 on this very machine."
A router is the box from your internet company that sits between your home and the internet. It's the front gate. By default, that gate is closed to the outside world — nobody out there can reach into your house. That closed gate is a good thing, and we are going to keep it closed.
If you search the internet for "how to access my server from outside," a lot of old advice will tell you to log into your router and turn on something called port forwarding — punching a hole in that front gate so the outside internet can reach a door on your machine. Please don't do this. Let me tell you plainly why.
The moment you open a port on your router, your home is no longer private. Your public IP address — your house's street address — is now exposed, and within minutes automated programs called bots (which endlessly scan the entire internet looking for open doors) will find yours and start rattling the handle. They will try thousands of passwords. They will look for known weaknesses in whatever software you exposed. This isn't paranoia; it is the constant background weather of the internet. People have had home cameras, servers, and networks broken into this exact way. Opening a port trades your safety for convenience, and it's a bad trade.
So we're going to get the exact same result — reaching your app from anywhere — without opening a single door on your router. Here's the trick.
Here is the beautiful idea. Instead of poking a hole in your gate so the internet can call in, we have your server quietly call out — like you making a phone call. Your machine dials a company called Cloudflare and holds that line open. When someone visits your web address, Cloudflare passes their request back down that phone line your server already opened. The request rides in on a connection you made, so there are no incoming holes, and your home's real IP address is never revealed — visitors only ever see Cloudflare.
This is called a Cloudflare Tunnel, and the software that makes the call is named cloudflared. It is genuinely free. It gives you a real, proper https:// web address (the padlock kind — automatically encrypted so nobody in between can read the traffic). It's the same approach professionals use.
One thing you need first: a domain name — a web address you own, like yourname.com. You can buy one for around ten dollars a year, and it must be set up on Cloudflare. When you add a domain to Cloudflare (free account), Cloudflare gives you two "nameserver" addresses; you paste those into wherever you bought the domain. That step tells the internet "Cloudflare is in charge of this name now." It can take a little while to take effect, and Cloudflare's dashboard walks you through it. Once your domain shows as Active in your Cloudflare dashboard, come back here.
Now we install the tunnel software on the machine running your service. These commands are for Debian or Ubuntu-style Linux (the most common kind). Type them one line at a time, pressing Enter after each. It's normal to be asked for your password when a line starts with sudo — that word just means "do this as the administrator."
What you'll see: some lines of text scrolling by as it downloads and installs. When it finishes and gives you back your normal prompt with no big red errors, it worked. To double-check, type cloudflared --version and you should see a version number printed back.
Now log in and connect cloudflared to your Cloudflare account:
What you'll see: the terminal prints a long web link and says it's waiting. Your web browser should pop open automatically (if it doesn't, copy that link into a browser yourself). In the browser, log into Cloudflare and click your domain to authorize it. Once you do, the terminal will say something like You have successfully logged in and mention a certificate was saved. You can close the browser tab. That's it — your machine and Cloudflare now trust each other.
Let's create one named tunnel. We'll call it home, but the name is just for you — call it whatever you like.
What you'll see: a message that a tunnel was created, and a long string called a Tunnel ID — it looks like 6ff42ae2-765d-4adf-8112-31c55c1551ef. It also saves a small credentials file (a .json file) whose name is that Tunnel ID. Copy that Tunnel ID somewhere safe now — a sticky note, a password manager — because we're about to use it. Don't worry if you lose it; you can always list your tunnels again with cloudflared tunnel list.
Now we tell the tunnel which web addresses point to which doors on your machine. We do that in a small text file called config.yml. The nice part: one single tunnel can serve as many apps as you want — you just add a line for each. Create the file at ~/.cloudflared/config.yml (the ~ means your home folder) using any text editor. Here is a complete example serving two apps:
Let me walk you through every line so none of it is a mystery:
tunnel: home — the name of the tunnel we just created.
credentials-file: — the full path to that little .json file from Step 5. Replace YOUR-USERNAME with your actual Linux username, and replace <TUNNEL-ID>.json with your real Tunnel ID followed by .json — for example 6ff42ae2-765d-4adf-8112-31c55c1551ef.json. This file is how the tunnel proves it's really yours.
ingress: — this word means "incoming traffic rules." Everything under it is a list, read top to bottom, of "if someone visits this address, send them to that local door."
The first rule says: visits to jellyfin.yourdomain.com go to http://localhost:8096 — door 8096 on this machine, where Jellyfin lives. The second says visits to ai.yourdomain.com go to door 3000, your AI app. You'd swap in your own real domain and your own real port numbers.
The last line, - service: http_status:404, is a required catch-all. It means "anything I didn't list above, politely answer 'not found.'" Cloudflare requires this catch-all to be present — leave it as the final line, always. A small formatting note: this is a YAML file, so the indentation matters. Use spaces, not tabs, and keep the alignment exactly as shown.
The config file knows where to send traffic, but the internet doesn't yet know these web addresses exist. We create them (this is called a DNS record — basically registering the name) with one command per app:
What you'll see: a short confirmation for each, saying the record was added. If it ever says the record already exists, that's fine — it's already done.
Now, the final step: make the tunnel run automatically all the time, even after you reboot, without you keeping the terminal open. This installs it as a background service:
What you'll see: a couple of short lines confirming the service was installed and started. That's it. Your tunnel is now live, permanently. Open a browser and go to https://jellyfin.yourdomain.com — you should see your app, with a padlock in the address bar. You just reached your home machine over the internet, encrypted, with your router still fully closed. Take a moment. That's a real accomplishment.
Reaching your app from anywhere is powerful — which means we need to be a little careful about who else can reach it. Two easy layers:
App-level PINs and passwords. Most good apps have their own login or PIN. Turn it on. Never, ever expose an admin panel that has no login at all — if it lets anyone who finds the URL change settings or see your data, it needs a password before it goes on a tunnel. Treat "no login" as "not ready for the internet."
Cloudflare Access. For anything private, Cloudflare offers a free feature called Access that puts a login wall in front of your app, at Cloudflare's edge — before a visitor ever reaches your home at all. You can set it so only your email address (verified by a one-time code) or a passkey can get through; everyone else is stopped cold. In the Cloudflare dashboard, look under Zero Trust → Access → Applications, add your hostname, and create a rule allowing only your email. This is the single best thing you can do for a private app. Use it.
Here's a common trap: you test the URL on your phone while standing in your kitchen, it works, and you assume you're done — but your phone was on your home WiFi, so it never actually left the house. To truly prove the tunnel works from the outside world, do this: on your phone, turn WiFi OFF so it uses cellular/mobile data instead. Now open https://jellyfin.yourdomain.com. If it loads, congratulations — that request genuinely traveled across the internet and back down your tunnel. It works from anywhere. Turn WiFi back on when you're done.
If you only ever want to reach your stuff from your own devices — your phone, your laptop — and never share a public web address at all, there's an even simpler option worth knowing about called Tailscale. It creates a tiny private network (a "mesh VPN") linking just your own gadgets together, as if they were all on the same home WiFi no matter where they physically are. No domain name needed, nothing public. Cloudflare Tunnel is the right choice when you want a real public https:// address; Tailscale is the right choice for private, personal-only access. Many people happily use both.
"tunnel credentials not found" or a credentials error. This almost always means the credentials-file: path in your config.yml is wrong. Double-check the username, and make sure the Tunnel ID in the filename exactly matches your real one, ending in .json. Run ls ~/.cloudflared/ to see the actual file that's sitting there and copy its name precisely.
"502 Bad Gateway" in your browser. The tunnel is working, but it couldn't reach your local app. That means either the app isn't running right now, or you pointed at the wrong door number. Confirm the app is up, and check that the port in your config (like 8096) matches the port the app actually uses.
The address won't load / DNS not resolving. Fresh web addresses sometimes take a few minutes to spread across the internet. Wait five or ten minutes and try again. Also make sure you ran the route dns command for that exact hostname.
Cloudflare says your domain isn't available. Your domain must be fully set up on Cloudflare first — showing as Active in the dashboard, with its nameservers pointed at Cloudflare (Step 3). If it isn't active yet, tunnels for it won't work. Finish that move first, then come back.
Stop and look at what you've built. You are running your own software — maybe your own AI — on your own hardware, in your own home. You can reach it from anywhere on the planet, over an encrypted connection, with a real web address, and you did it without opening a single hole in your home network. No rented cloud. No company owning your data. No exposed front door. That is genuine digital sovereignty, and most people never get there. You own the Machine.
That's the end of the building. In Part III — The Ledger of Creativity — we turn the page from running the Machine to creating with it: making things, and truly owning what you make. You've earned it. Onward.