connecting the dots: projectlighthouse

The big picture

There are two main ways to learn on lighthouse: reading and doing.

Structured books that teach you concepts, walk through code, and explain the "why" behind things. The philosophy behind it. Labs are the doing side—real coding environments where you build things and get your work validated automatically.

Some labs are standalone. Some are tied to specific books. Either way, the idea is the same: you don't just read about how something works, you actually build it. And you're free to break stuff too—that's how you learn.

Books

A book is a deep dive into a topic. Think of it like a textbook, except interactive and always being updated. Each book covers a single subject deeply—like Go intermediate or building your own Rust from Zero.

Books are divided into chapters, and chapters contain pages. A page is an individual lesson—a focused piece of content covering one concept, one technique, one building block. You work through pages sequentially within a chapter, and chapters build on each other.

As you read through pages, you can mark them as complete to track your progress. You can also take notes on any page—they're saved to your account so you can come back to them later.

You'll find all available books at /books.

Pages

A page is the smallest unit of content in a book. Each page teaches one thing. It might explain how goroutines work, walk through implementing a hash table, or show you how Linux namespaces provide process isolation.

Pages can contain text, code blocks, diagrams, and embedded videos. Some pages have associated exercises. The goal is always the same: after reading a page, you should understand one more thing than you did before.

Labs

Labs are where you actually write code. A lab is a structured coding exercise with a series of tasks. Each task has clear instructions, acceptance criteria, and an automated validator that checks whether your solution is correct.

You don't just submit code and hope for the best. The validators actually run your program, inspect its behavior, check outputs, and verify that things work the way they should. If your implementation is off, you'll know exactly what failed.

Tasks within a lab are sequential. You complete task 1 before moving to task 2. Each task builds on the previous one, so by the end of a lab you've built something real and complete.

Labs also have a hint system. If you're stuck, you can unlock hints that guide you without giving away the answer. Using hints is not a weakness—it's often the fastest way to learn what you're missing.

Labs are great for sharpening your skills after a few days away from code, warming up before an interview, or simply challenging yourself. They're meant to be revisited.

We're actively building more labs and books—system design, distributed systems, and beyond.

Browse available labs at /labs.

Local labs vs remote labs

There are two kinds of labs, and the distinction matters:

Local labs run on your own machine. You clone a starter repo, write code in your editor, and use a CLI tool called luxctl to validate your work. This is great for performance-sensitive exercises (like the 1 Billion Row Challenge) where you want to run on your own hardware with your own toolchain.

Remote labs run on cloud infrastructure that lighthouse provisions for you. When you start a remote lab, you get a real virtual machine with a browser-based terminal. Everything runs server-side—you don't need to install anything locally. This is useful for labs that need specific Linux features (like namespaces and cgroups for the Docker lab) that might not be available on macOS or Windows.

Book-based labs

Some labs are tied to a specific book. These book-based labs are the practice component of a book. You read about a concept in the book, then immediately apply it in the associated lab.

For example, a Go fundamentals book might have a lab where you implement a concurrent web crawler, applying the goroutines and channels you just read about. The book teaches the theory, the lab makes it stick.

Projects

Projects are larger-scale labs. While a typical lab might have 3–5 quick tasks, a project has many more steps and takes hours to complete. Projects are the "build your own X" experiences—build your own Docker, build your own Redis, build your own Git.

Projects follow the same structure as labs (sequential tasks, automated validation, hints), but they're longer, more ambitious, and result in a working implementation of something real. Completing a project means you genuinely understand how that piece of technology works under the hood.

Terminals

Terminals are browser-based SSH sessions into your remote lab environment. When you start a remote lab, lighthouse spins up a virtual machine and gives you terminal access right in your browser.

This is a real Linux environment. You have a shell, you can install packages, you can run programs, you can do anything you'd do on a regular server. The terminal connects over WebSocket, so it feels responsive even though the machine is running in the cloud.

Terminal sessions are tied to lab sessions and have time limits to keep resource usage fair. You can manage your active sessions at /terminals.

luxctl

luxctl is lighthouse's command-line tool for local labs. You install it on your machine, authenticate with your lighthouse account, and use it to fetch lab instructions and validate your solutions.

The workflow looks like this:

1. Run luxctl lab start --slug <lab-name> to fetch the lab.
2. Write your solution in your editor of choice.
3. Run luxctl run --task 1 to validate a specific task.
4. Fix what's broken, re-run, repeat until it passes.

luxctl talks to the lighthouse API to pull instructions and submit results, but validation runs entirely on your machine. Your code never leaves your computer.

XP and the leaderboard

Completing tasks earns you XP (experience points). Tasks have scoring tiers based on how efficiently you solve them—fewer attempts and less hint usage means a higher score.

The leaderboard ranks all users by total XP. It's not meant to be stressful—it's there because some people find a bit of friendly competition motivating. If that's not your thing, ignore it entirely and learn at your own pace.

How it all connects

Here's the mental model:

Books give you knowledge. Labs give you practice. Pages are the individual units of knowledge. Tasks are the individual units of practice. Terminals give you a real environment when you need one. luxctl gives you a local workflow when that's what makes sense. XP gives you a sense of progress.

That's the whole platform. Pick a book, start reading, start building.

Free vs paid content

Some books, pages, and labs are free. Others require a paid subscription. The subscriptions page shows exactly what's included at each tier. There are no hidden paywalls or surprise upsells.

Scholarship

In case you need support, maybe you are going through a tough time, or some other situation and if you think these content and material will help you break out of your current situation, please reach out. We have an Lady Elizabeth scholarship.

After work with people around the world, from different locations, I understand that the situation is not the same for everyone. The requirement for scholarship is that you'd need to share what you've done and we'd want to ask why and how would these content and lab will benefit you.

Given that is established, you'll be given access to relevant books/projects/terminals or waiver part or full payment. Let not this be a blocker for you.