How to Self-Host Gitea on Ubuntu 24.04 with Docker

If GitHub vanished tomorrow, would your code still be where you need it?

That question is really the whole point of running something like Gitea at home. For a lot of people, GitHub is convenient and familiar, but self-hosting gives you another level of control. You decide where your repositories live, how they are accessed, and how much of your workflow depends on someone else’s platform.

For this setup, the goal is simple: install Gitea on Ubuntu 24.04 Server, run it with Docker, enable both web access and SSH access, and then walk through a normal Git workflow so it is not just "installed" but actually usable.

Why Gitea makes sense for a homelab

Gitea is positioned as a fast, lightweight, open-source alternative to platforms like GitHub and GitLab. That lightweight part matters.

If you are running a homelab, learning Linux, or just trying to avoid overcomplicating things, Gitea fits that space really well. It is not trying to be the biggest thing in the room. It is trying to give you a practical way to host your own Git repositories without dragging in more complexity than you need.

That makes it a good option for beginners, privacy-focused users, and people who want better control over their development workflow.

What this setup covers

The flow here is centered around Ubuntu 24.04 Server with Gitea running in Docker. The video focuses on:

• Installing Gitea on Ubuntu 24.04
• Using Docker for deployment
• Making HTTP and SSH access work properly
• Fixing common beginner issues
• Testing real Git workflows like clone, commit, and push

That last part is important. A lot of tutorials stop once the web page loads. But a Git service is only useful when you can actually create a repo, connect to it, and push code successfully.

Prerequisites before you start

The setup assumes a few basic things are already in place:

• Ubuntu 24.04 Server
• A user with sudo access
• Ports 3000 and 2222 available

Those ports matter because the walkthrough uses web access for Gitea and SSH access on a non-default SSH port for Git operations.

If those ports are blocked, already in use, or forgotten during setup, things can look broken even when the container itself is running fine.

Installing Docker the easy way

The deployment in the video uses Docker, along with Docker Compose V2.

The process shown uses a Docker install script to simplify setup on Ubuntu. After that, there is a check to make sure Docker is working correctly and that Docker Compose V2 is available.

One of the early issues covered is Docker group permissions. That is a very common beginner snag. You can install Docker successfully and still hit permission errors if your user is not properly set up to use Docker without running everything the wrong way.

Gotcha to avoid: Docker permissions

This is one of the concrete mistakes that trips people up fast.

If Docker is installed but your user does not have the right group permissions, you may think Docker itself is broken when it is really just a user access issue. The walkthrough explicitly includes fixing Docker group permissions and then verifying the Docker group setup.

So if commands work inconsistently or only under certain conditions, do not skip that verification step.

Building the Gitea stack with Docker Compose

Once Docker is ready, the next step is creating a dedicated folder for Gitea and preparing the docker-compose.yml file.

The compose setup in the video includes Gitea itself, along with:

• Port mappings
• Persistent volumes

That combination is what turns this from a throwaway container into something usable. Port mappings expose the service, and volumes make sure your data is not lost every time the container changes.

The editor used in the walkthrough is Nano, which keeps things approachable if you are newer to Linux. That may seem like a small point, but it helps lower the barrier for people who are not living in Vim every day.

After the compose file is in place, the stack is started in detached mode and then checked with:

• container status checks
• live logs

That is the right mindset for container work. Do not just start a stack and assume it worked. Check status. Check logs. Confirm the service is actually healthy.

Opening the Gitea web installer

After the container comes up, the next piece is the Gitea web installer.

This is where the platform goes from "container is running" to "application is configured." The walkthrough includes going through the Gitea install wizard and getting the instance ready for use.

From there, the video moves into the application itself:

• creating the first repository
• looking over the repository interface
• exploring areas like issues, packages, wiki, actions, and settings

That broader tour matters because it shows Gitea is not just a bare repo endpoint. It gives you a full interface around the code, which is a big part of why self-hosting can still feel polished and practical.

Admin and user settings worth knowing about

The video also spends time on the admin panel and user profile settings.

On the admin side, there is a tour of areas like:

• users
• repositories
• maintenance
• stats

On the user side, there is a look at settings such as:

• two-factor authentication
• SSH keys
• themes

That split is useful because self-hosting often means you are wearing multiple hats. You are both the platform admin and the user of the platform. Knowing where those controls live makes the system easier to manage as it grows.

Testing Gitea with a real repository

After setup, the next step is proving it works.

The workflow shown starts with cloning a repository over HTTP as a quick test. That is a nice simple first step because it confirms the service is reachable and the repository exists.

Then the walkthrough moves to SSH, which is the recommended path for ongoing Git use.

Setting up SSH access the right way

SSH setup is one of the most important parts of the whole process.

The steps covered include:

• generating an ed25519 SSH key
• starting ssh-agent
• adding the key with ssh-add
• adding the public key to Gitea under SSH/GPG keys
• testing the SSH connection to Gitea on port 2222

This matters because SSH is usually the better long-term experience for self-hosted Git. Once it is working, cloning and pushing feel much cleaner.

Gotcha to avoid: forgetting the custom SSH port

This setup uses port 2222 for SSH access to Gitea, not the default SSH port people often assume.

That means your SSH test and your Git SSH access need to line up with that port choice. If you try to connect like it is a default SSH setup, you can waste time troubleshooting the wrong problem.

When SSH does not work, double-check the port before assuming your keys are bad.

Cloning over SSH and making your first push

Once the SSH key is in place and the connection test succeeds, the walkthrough clones the repository over SSH.

From there, it runs through the basic Git workflow:

• create or update a README
• git add
• git commit
• git push

This is the part I like seeing in practical tutorials because it confirms the whole chain works end to end. Web UI, repository access, authentication, local Git config, and remote push all need to line up.

Fixing the classic Git identity error

One of the beginner issues covered is the Author identity unknown message.

If you have ever installed Git on a new machine and then tried to commit right away, you have probably seen this. Git needs your user name and email configured before it can create commits properly.

That is one of those small setup details that can stop momentum fast if you are new to Git or building out a fresh Linux box.

Mistake to avoid: assuming Git is ready with zero config

Even after Gitea is installed and SSH is working, local Git still needs its own identity configuration. If you hit Author identity unknown, that is not a Gitea failure. It is a local Git configuration issue.

The video addresses that directly, and it is a good reminder that self-hosting Git still depends on basic Git setup on the client side.

Best practices called out in the walkthrough

Toward the end, the video touches on some practical best practices, including:

• SQLite vs Postgres
• backups
• ports
• upgrades

The important thing here is not to overstate it. The walkthrough raises these as real-world considerations when you start self-hosting Git seriously.

Backups especially deserve attention. If the whole point of self-hosting is control, then protecting the data is part of the job. Running your own Git service is not just about getting the app online. It is also about making sure your repositories are safe and recoverable.

Who this approach is really for

This setup makes a lot of sense if you fit into one of these groups:

• you are learning Linux and want a project with real utility
• you run a homelab and want your own internal code hosting
• you care about privacy and control
• you want something lighter than a more heavyweight platform

That does not mean you have to abandon GitHub or GitLab entirely. For a lot of people, Gitea is about having options. It is your own Git service, on your own hardware, under your own control.

And honestly, there is something valuable about understanding the full workflow yourself. Not just using Git as a website feature, but actually knowing how the hosting side works.

Final thoughts

Running Gitea on Ubuntu 24.04 with Docker is a strong entry point into self-hosted development infrastructure. You get a lightweight Git platform, a clean web interface, SSH-based workflows, and enough flexibility to make it useful in a real homelab or personal dev setup.

The biggest wins in this walkthrough are not just the install itself. It is the fact that it also covers the common pain points. Docker permissions, SSH key setup, custom port awareness, and Git identity configuration are exactly the kinds of issues that can make a beginner quit early if nobody calls them out.

Get those pieces right, and self-hosted Git starts to feel a lot less intimidating.

Keep learning, keep building, and I’ll catch you in the next one.