Self-Host on a Free Oracle Cloud Server with Greffon

Oracle Cloud will give you a server and not charge you for it. Not a 12-month trial that turns into a bill, but an Always Free tier: an ARM machine with real cores and real memory, running for as long as you keep it. For anyone who would rather own their apps than rent them, that is a good place to start.

This is a walkthrough of turning that free Oracle box into a greffer, a server you own and run your own apps on, and grafting your first greffon onto it. It is honest about the parts that are smooth and the parts that still ask something of you. We would rather you know the sharp edges before you hit them.

Why Oracle's Always Free tier is a good greffer

A greffer is just a machine you control with Docker on it. Oracle's Always Free ARM instance qualifies on every count: enough compute to run a blog, an analytics tool, a password vault, or a VPN, at no rent. Compared to paying monthly for a small VPS, it is a sensible first greffer for self-hosting, and you keep the data on a box that is yours.

The hardware is not the hard part. The work is in the steps between instance created and app reachable over HTTPS. Here they are, in order.

Step 1: Create the instance, then open the door

Create an Always Free ARM instance (the A1.Flex shape) with an Oracle Linux image. That part is a few clicks.

The first sharp edge comes right after. A fresh Oracle subnet often has no route to the internet, so even when the firewall rule allows SSH, your connection just times out. Allowing a port is not the same as having a road to it. In the Oracle console, attach an internet gateway and add a 0.0.0.0/0 route to the subnet route table, then confirm the security list allows the ports you need. After that, SSH connects.

Step 2: Install Docker, and make it survive a reboot

A greffer runs on Docker, so install Docker on Oracle Linux. Rather than rewrite steps that already exist, follow the oracle-base guide to installing Docker on Oracle Linux. The short version: add the Docker CE repository, install the docker-ce packages, then start the service. The steps work as written on the ARM instance.

Two things that guide will not nag you about, and both bite people. First, load the netfilter kernel modules that Docker networking and several greffons rely on, and pin them so a reboot does not drop them. Second, enable Docker on boot.

# load the netfilter modules Docker and iptables-based greffons need
sudo modprobe ip_tables iptable_nat iptable_filter

# pin them so a reboot does not undo this
printf 'ip_tables\niptable_nat\niptable_filter\n' | sudo tee /etc/modules-load.d/iptables.conf

# make sure Docker comes back after a reboot
sudo systemctl enable docker

Skip the last line and the first reboot stops every container with nothing bringing them back. A self-hosted setup that does not survive a reboot is a demo, not a home for your apps.

Step 3: Turn the box into a greffer

With Docker running, you install the greffer worker and register it with the Greffon control plane, which is where you graft, start, and stop apps. The exact commands live in the getting started guide and we keep them current there rather than letting them drift in a blog post. At a high level: run the greffer, register it, accept it from the control plane, and it is ready to host greffons.

From here, the experience changes. You stop hand-writing compose files and firewall rules for each app and start picking from a catalog.

Step 4: Graft your first greffon

Pick an app from the catalog, a blog, an analytics tool, a password vault, and graft it onto your greffer. Greffon handles certificates and wires the reverse proxy, so the app comes up reachable over HTTPS without you assembling that plumbing by hand. Starting and stopping it later is one action, not a remembered sequence of commands.

This is the part that earns its keep: the routing and TLS layer that is the same correct answer on every server, handled once so you do not solve it per app.

The sharp edges we will not hide

Self-hosting is worth it, and it is not free of work. Three honest notes:

• Always-on matters for always-on apps. A free Oracle instance stays on, which is the right shape for a blog or a vault. If you ever run a greffer on a laptop that closes at night, expect downtime for anything meant to be always available.
• Reaching it from outside needs networking. To get to your greffer from beyond its own network, you still deal with port forwarding, dynamic DNS, or a tunnel. Plan for that step.
• Some greffons need a kernel assist on the host. A few apps lean on host kernel features that the greffer does not set up for you yet. A WireGuard greffon, for example, needs the host iptables modules (ip_tables, iptable_nat) loaded, or its interface will not come up and the dashboard returns a 500. That is exactly why Step 2 loads those modules as part of base setup.

None of these are reasons not to self-host. They are the reasons to know what you are signing up for.

Keep the box, keep the data

Oracle Always Free is a genuinely good deal, and you should take it. The honest version of the pitch is this: the free part is the server, the work is the setup, and Greffon takes the repeatable middle (TLS, routing, the catalog, one place to manage your greffons) off your plate while leaving the node and the data yours.

If you want to try it, start with turning your machine into a greffer, and read what a greffer actually is if the word is new to you. Your server, your apps, your call.

FAQ