Self-hosting as a designer: from Plex to Docker to open-source AI

I run my own servers. Not because a blog post told me it would make me a better design leader—but because I wanted to understand what happens after my designs leave Figma. Self-hosting as a designer started as curiosity: a Plex media server on a spare machine, then a VPS for a portfolio, then Docker containers for real products, and eventually running open-source AI models for design workflows. Each step taught me something about infrastructure constraints that no documentation, tutorial, or secondhand explanation could replace. The knowledge is visceral. When you’ve watched a process crash at 2am and debugged it yourself, you understand why engineering teams make the decisions they do. That understanding—constraint literacy, not sysadmin certification—is what changes how you collaborate, scope features, and earn credibility in technical conversations.

Why designers should care about what runs behind the screen

Infrastructure constraints are design constraints. This is obvious to engineers and invisible to most designers, and that gap costs both sides.

When you’ve set up a server and watched it struggle under load, you understand why engineers push back on features that require heavy real-time data. When you’ve managed a database and seen how query complexity affects response time, you understand why “just add a filter” isn’t a free feature. These aren’t things you can fully grasp from a product requirements document—they become real when you’ve dealt with them yourself.

Deployment complexity affects product decisions in ways that don’t surface in design reviews. Understanding that “adding a new service” means provisioning infrastructure, setting up monitoring, managing secrets, and handling deployment coordination—not just writing code—changes how you think about scope. A design feature that technically works but requires a new backend service has a real cost that affects sprint planning, release timing, and team capacity.

Security and privacy constraints are structural, not bureaucratic. When you’ve configured firewall rules, managed environment secrets, and set up SSL certificates, you stop seeing engineering caution around data handling as obstruction. Design decisions that treat sensitive data carelessly create infrastructure-level problems that are expensive to fix.

The goal here isn’t to become a sysadmin. It’s to develop what I think of as constraint literacy: enough hands-on experience that you can participate in infrastructure conversations as someone who understands the tradeoffs, not just someone who advocates for design requirements. That literacy compounds—it changes how you scope work, how you communicate with engineering, and how seriously your assessments are taken in product planning. For how this connects to broader engineering collaboration, embedding in engineering teams as a design director covers the day-to-day patterns this knowledge supports.

How a Plex server taught me more than any tutorial

My entry point into self-hosting wasn’t a VPS or a deployment pipeline. It was a Plex media server on an old machine in my apartment.

Setting up Plex sounds simple—install the software, point it at a folder of media files, open a browser. But the moment you want it to actually work reliably, you encounter the same concepts that underpin production infrastructure: networking (port forwarding, local vs. external access), storage (drive formats, RAID considerations, what happens when a disk fills up), and process management (the server needs to start on boot, stay running, and recover from crashes). You learn that a service is not just software—it’s software that needs to stay alive on hardware that has opinions.

The homelab is the lowest-stakes environment to learn these things. Nothing breaks except your own movie night. But the mental models transfer directly: the difference between a process and a service, what ports and firewalls actually do, why persistent storage matters, how networking works at the level below “it just connects.” Once you’ve kept something alive on a network for a few months—handled an OS update that broke a dependency, expanded storage when it ran out, configured remote access so it works outside your local network—the next step feels natural rather than intimidating.

From VPS to Docker — what building for Peridio and Avocado OS taught me

The jump from a home server to a VPS is smaller than it looks. SSH into a remote machine, install a web server, configure a domain and SSL—each step is well-documented and individually manageable. The real shift in my understanding came with Docker.

Docker containers solved a problem I’d been running into repeatedly: the “works on my machine” gap between development and production environments. When I started containerizing services for Peridio and Avocado OS, the value became concrete. A Dockerfile defines every dependency, every configuration, every environment variable. The container that runs on my laptop is the same container that runs in staging and production. Immutable. Replicable. Consistent across systems.

This matters more than it sounds. Before Docker, deploying meant hoping that the production server had the right versions of the right dependencies configured the right way. With Docker, the deployment artifact is the environment itself. Docker Compose extends this further—defining multi-service applications (a web server, a database, a background worker) as a single configuration file that spins up identically everywhere.

Working on Avocado OS in particular drove this home. The system needed to be reproducible across hardware targets—not just “it runs” but “it runs identically, every time, on every device.” Dockerizing that workflow forced me to think about infrastructure the way embedded engineers think about firmware: every dependency is explicit, every environment variable is declared, and there’s no room for “it probably has Node 18 installed.” That discipline changed how I approach every project now, even simple ones. If I can’t describe the full environment in a Dockerfile or a Compose file, I haven’t finished the setup.

For how this infrastructure thinking connects to the broader design system architecture work at Peridio, building reusable design infrastructure at an IoT consultancy covers the design token and component system side of the same product.

Why GoDaddy-era hosting can’t keep up with modern design-engineering workflows

Once you’ve containerized your projects and set up CI/CD pipelines, you hit a wall: the hosting platforms most people start with were not built for how modern teams ship software.

Traditional shared hosting—GoDaddy, cPanel-based providers, conventional FTP-upload hosts—was designed for a different era. Upload files to a directory, maybe configure a database through phpMyAdmin, done. That model worked when websites were static pages updated weekly. It breaks when your workflow demands continuous deployment on every push, cache optimization at the edge, staging environments that mirror production, elasticity that scales for launches and contracts after, and tight integration with GitHub Actions and CI/CD pipelines.

I hit this wall personally. The speed, cache behavior, and deployment constraints of legacy platforms were actively blocking the workflow I’d built. Deploys that should have been automatic required manual FTP transfers. Cache invalidation was unpredictable. There was no concept of a staging environment—you deployed to production and hoped. Scaling meant calling a support line and upgrading to a more expensive plan.

The shift to platforms built for modern deployment—Vercel, Netlify, Cloudflare Pages, Railway, Fly.io—wasn’t just a convenience upgrade. It was a workflow transformation. Each platform solves a specific part of the puzzle: Vercel and Netlify handle static and serverless deployments with automatic preview URLs for every pull request. Cloudflare Pages pairs with their edge network for cache optimization that actually works predictably. Railway and Fly.io handle containerized applications with straightforward scaling. Every one of them integrates natively with GitHub, so the CI/CD pipeline patterns that automate your builds also automate your deployments.

Staging environments in particular became a design tool, not just an engineering artifact. Being able to share a real preview URL with stakeholders—instead of screenshots, Loom videos, or “check the Figma prototype”—changes the feedback loop fundamentally. The stakeholder sees the real product, with real data, with real performance characteristics. Design review happens in the medium the user will actually experience.

Serverless configuration added another dimension. Not every feature needs a full server running 24/7. An image optimization function, a form handler, a scheduled report generator—these can run as serverless functions that only consume resources when invoked. Understanding this changes how you scope features: “this needs a server” and “this needs a function” are different infrastructure costs, and knowing the difference makes your feature proposals more precise.

How do you run open-source AI models on your own infrastructure?

The most recent layer in my self-hosting journey connects infrastructure knowledge directly to AI-powered design workflows. Running open-source AI models—rather than relying exclusively on API calls to OpenAI or Anthropic—opens up a different set of capabilities and tradeoffs that designers should understand.

Platforms like Fireworks AI make it practical to deploy open-source models (Llama, Mistral, Mixtral, and others) with production-grade reliability. The advantage isn’t just cost—though cost matters when you’re running models at volume for design automation. It’s control: you choose the model, you control the latency characteristics, you can fine-tune for specific tasks, and you understand exactly what happens to the data you send.

For designers exploring AI workflows, Ollama is the most accessible starting point. Install it locally, pull a model, and you have a local LLM running on your machine. No API key, no usage costs, no data leaving your computer. It’s the Plex of AI inference: a low-stakes environment to learn how models work, what inference speed feels like at different parameter counts, and what the resource tradeoffs actually are. A 7B-parameter model runs on a laptop; a 70B model needs serious hardware or a cloud deployment. Understanding that spectrum—and where different use cases land on it—informs how you design features that depend on AI.

The connection to self-hosting knowledge is direct. Running a local model is running a service—it needs memory allocation, it responds to HTTP requests, it has performance characteristics that depend on hardware. Running a model on Fireworks AI is managing a cloud deployment—you configure the instance, set the concurrency, monitor the costs. The same infrastructure intuition that started with a Plex server applies here: what does it cost, what are the constraints, and how do those constraints shape what you can build?

For design teams specifically, understanding model hosting means understanding why certain AI features are expensive (large context windows, real-time inference, multi-modal input), why latency varies (local vs. cloud vs. edge), and when it makes sense to build with open-source models versus commercial APIs. This is constraint literacy applied to the fastest-moving part of the design toolchain.

The tools that make self-hosting approachable in 2026

The infrastructure tooling landscape has gotten dramatically more approachable. You don’t need deep Linux expertise to run a productive self-hosted stack.

VPS providers: DigitalOcean, Hetzner, Vultr, Linode. Hetzner offers the best price-to-performance; DigitalOcean has the best documentation for beginners.

Web servers: nginx for static sites and reverse proxy. Caddy as an alternative that handles SSL automatically with cleaner configuration syntax.

Containers: Docker Desktop for local development. Docker Compose for multi-service applications. Coolify as a self-hosted Heroku alternative that manages containers and deployments through a UI.

Modern deployment platforms: Vercel and Netlify for static and serverless deployments with automatic preview URLs. Cloudflare Pages for edge-optimized hosting. Railway and Fly.io for containerized applications with straightforward scaling.

Serverless: Cloudflare Workers for edge functions. Vercel Functions for API routes alongside your frontend. AWS Lambda when you need the full ecosystem.

CI/CD: GitHub Actions for automated builds and deployments. Kamal for container-based deployments with zero-downtime.

Databases: SQLite for small projects. PostgreSQL for anything that scales. Managed providers (Neon, Supabase) for the database layer without operational overhead.

AI model hosting: Ollama for local inference and experimentation. Fireworks AI for production-grade open-source model deployment. vLLM for self-hosted high-throughput inference.

Monitoring: UptimeRobot for uptime checks. Grafana + Prometheus for full observability. Betterstack Logtail for log management.

What should designers realistically aim for?

Not everyone needs to manage their own infrastructure in production. The goal isn’t to become a sysadmin—it’s to develop enough context that you’re a more informed participant in decisions that involve infrastructure tradeoffs.

The realistic target for a design director who wants infrastructure fluency:

• Can deploy and maintain a personal project on a VPS or a modern deployment platform
• Understands SSH, web server configuration, SSL, and DNS at a conceptual level
• Has containerized at least one project with Docker—understands images, containers, and Compose files
• Has set up a CI/CD pipeline at least once, even for a personal project
• Can read server logs and understand what a failed deployment looks like
• Knows the difference between traditional hosting and modern deployment platforms—and why the distinction matters for team velocity
• Can articulate what it costs to host an AI model and what tradeoffs different hosting options create
• Can have a meaningful conversation about infrastructure tradeoffs in a product planning meeting

This level of knowledge takes a few weekends of hands-on work to develop. Start with a Plex server or a VPS—something low-stakes with personal utility. The return on that investment—in engineering credibility, in design decision quality, in independence—compounds over the career.

Key Takeaways

• Self-hosting as a designer builds constraint literacy—visceral understanding of infrastructure limits that changes how you scope features, communicate with engineering, and participate in technical decisions
• A Plex server or home server is the lowest-stakes entry point: the same concepts (networking, storage, process management, service uptime) that underpin production infrastructure, with nothing at risk except your own media library
• Docker and containerization are the key unlock for professional infrastructure work—immutable, replicable environments that behave identically across development, staging, and production, as I experienced firsthand building for Peridio and Avocado OS
• Legacy hosting (GoDaddy, cPanel, FTP) can’t support modern design-engineering workflows—continuous deployment, staging previews, edge caching, and serverless functions require platforms built for how teams actually ship software now
• Running open-source AI models (locally via Ollama or in production via Fireworks AI) extends infrastructure literacy into the fastest-moving part of the design toolchain—understanding model hosting costs and constraints shapes smarter AI feature decisions
• The realistic goal isn’t sysadmin competence—it’s enough hands-on experience to be a credible, informed participant in infrastructure conversations