DEV Community: Ubayed Bin Sufian

How I Use Antigravity 2.0 to Navigate Open-Source Codebases and Make Better Technical Decisions

Ubayed Bin Sufian — Mon, 25 May 2026 07:43:09 +0000

This is a submission for the Google I/O Writing Challenge

Hook: The Tool That Changed How I Contribute to Open Source

I'll be honest — for the past two years, whenever someone asked me what AI coding tool to use, my answer was automatic: Claude Code or Codex, pick your poison. Google? Not even in the conversation.

Then Google I/O 2026 happened.

In roughly 24 hours, Google dropped over 20 tools — and one of them stopped me mid-scroll. Antigravity 2.0: a standalone desktop agent orchestration platform, free to start, built on Gemini 3.5 Flash, and designed to spin up parallel AI sub-agents the way a senior engineer delegates work to a team.

I didn't want to just read about it. I wanted to put it to work on something real. So I pointed it at a problem I run into constantly as an open-source contributor: walking into an unfamiliar codebase and trying to figure out what's already there before you touch anything.

Right now I'm using it to review WPFAevent, a WordPress plugin by FOSSASIA that integrates with the Eventyay event platform. It's a real repo — 14 open issues, 17 pull requests, PHP + JavaScript + CSS — and it gave me a good surface for testing how well Antigravity handles the kind of context-gathering work that usually eats the first hour of any contribution session.

This is the full walkthrough of how I use it, what genuinely impressed me, where I hit friction, and what every developer contributing to open source should know before they dive in.

What Is Antigravity 2.0?

Antigravity 2.0 is Google's new standalone desktop app for AI agent orchestration. Less than a year ago, Google shipped the Antigravity IDE — a full code editor with an Agent Manager baked in. It was powerful but intimidating. Antigravity 2.0 strips that away entirely. What remains is a clean chat interface that anyone can open and immediately use, backed by agents that coordinate complex work automatically.

The key word is agents — plural, parallel, autonomous.

Where a tool like Claude Code (as of this writing) requires developers to manually configure sub-agent workflows, Antigravity 2.0 is designed from the ground up around the idea that one task can, and often should, spawn multiple specialized agents working simultaneously. A code analysis agent. A research agent cross-referencing docs. A QA agent running browser tests. All at once, reporting back to you, asking for approval only when needed.

At Google I/O, the team ran Antigravity 2.0 for 12 hours straight on stage — 93 sub-agents running in parallel — and produced a working operating system. That's the scale this thing is designed to operate at.

Where it fits in Google's ecosystem: Antigravity connects directly to Google products via installable skills and plugins — Chrome DevTools, modern web guidance, and more — and the whole stack runs on Gemini 3.5 Flash, which is reportedly capable of generating code at close to 800 tokens per second. That raw speed changes how iteration feels in practice.

My Hands-On Experiment: Reviewing WPFAevent

Environment & Prerequisites

OS: Linux Mint 22.3 - Cinnamon 64-bit
Antigravity version: 2.0.6 (Manual Tarball Release)
Google account: Required for sign-in
Repo: fossasia/WPFAevent — cloned locally
Prior Antigravity IDE experience: None needed (though existing IDE users get a smooth migration path)

Step 1: Installation and Onboarding

Head to antigravity.google and grab the installer for your platform — Apple Silicon, Intel Mac, Windows (two installer options), or Linux.

# macOS: Drag to Applications, open from Spotlight
# Windows: Run the installer directly
# Linux: Build available from the site

For Linux Mint, instead of using the standard apt package manager (which still defaults to the older 1.x stable branch), you manually download the compressed package and extract it directly into the system's optional application directory.

# Extract package to system application directory
sudo tar -xzf Antigravity.tar.gz -C /opt/

Troubleshooting the Linux Desktop Shortcut

Initially, I attempted to create a standard terminal-based desktop entry using a .desktop file configuration pointing to internal package assets:

# NOTE: This automated script method did NOT work natively for pinning the icon/shortcut
cat << 'EOF' > ~/.local/share/applications/antigravity-ide.desktop
[Desktop Entry]
Name=Antigravity IDE
Comment=Antigravity IDE v2.0 - Experience liftoff
GenericName=IDE
Exec=/opt/Antigravity/antigravity %F
Icon=/opt/Antigravity/resources/app/resources/icon.png
Type=Application
Categories=Development;IDE;
Terminal=false
StartupWMClass=antigravity
EOF

update-desktop-database ~/.local/share/applications

Because the build structure handles asset routing differently (resulting in a generic gear icon or the shortcut missing from the Mint menu entirely), I verified the core application manually by calling the binary file directly from the terminal:

/opt/Antigravity/antigravity

Final Visual Icon Solution

To successfully map the IDE to the Linux Mint application menu with its real branding, I bypass text configurations entirely and configured it manually using the Cinnamon Desktop environment tools:

Download the official brand logo directly from the Antigravity Press Asset Kit.
Right-click the Linux Mint Menu button (bottom-left corner) -> Click Configure.
Navigate to the Menu tab and click Open the menu editor.
Locate the Antigravity IDE entry under your designated development categories, click it, and open Properties.
Click on the icon tile on the left side of the properties window, browse to your downloaded press asset image, and hit Save.

A screenshot of the Linux Mint Menu Editor properties dialog box showing the Antigravity desktop entry, with the custom branded press-asset icon selected and successfully mapped.

Open the app, sign in with your Google account, and you'll land in a short onboarding flow.

During onboarding, you hit the "Build with Google" page. This is where you install skills and plugins — essentially integrations that give your agents context about specific tools.

I installed:

Modern Web Guidance — helps the agent reason about web development patterns and best practices
Chrome DevTools — gives the agent the ability to interact with and inspect the browser

If you're migrating from the Antigravity IDE, keep the "Keep Antigravity IDE" checkbox selected — your old setup carries over cleanly.

Step 2: Creating a Project

Antigravity 2.0 is project-centric. A project is simply a folder on your local machine that the AI reads from and writes to directly.

Click the + icon next to Projects
→ New Project
→ Select your cloned repo folder
→ All agent context and output is scoped to this folder

I pointed it at my local clone of WPFAevent. From this point forward, every question I ask is answered with reference to the actual source files in that directory — not generic knowledge about WordPress plugins, but this specific codebase.

Step 3: Orienting to the Codebase

Before jumping to any specific issue, I sent an orientation prompt to get a high-level map of the project:

"Give me an overview of this codebase. What does it do, how is it structured, and what are the main entry points I should know about?"

Antigravity compares the actual plugin structure (includes/cpt/, includes/cache/) with the outdated README and correctly uses the live codebase as the source of truth.

This is where the first surprise hit. The project's README.md outlined a file structure containing API shortcodes like class-event-api.php and class-event-speakers.php. But the agent read through the directory, ignored the outdated documentation, and mapped the actual codebase structure:

wpfaevent.php — Core plugin bootstrap file, registering CLI commands and calling run_wpfaevent().
includes/class-wpfaevent.php — The main orchestrator that registers Custom Post Types, taxonomies, metadata, and admin/public hooks.
includes/cpt/ — Declares custom post types wpfa_event and wpfa_speaker.
includes/meta/ & includes/taxonomies/ — Defines fields like start/end dates, locations, speaker bio details, and categories.
includes/cache/class-wpfaevent-cache.php — Implements transient-like caching for page lookups (specifically the Code of Conduct page ID).
public/templates/ — Contains custom WordPress page templates (page-speakers.php, page-schedule.php, page-past-events.php) which are dynamically loaded by class-wpfaevent-landing.php on activation. What would have taken me 15 minutes of head-scratching over why files mentioned in the README didn't exist took the agent 15 seconds to clarify. It immediately pointed out: "The codebase is currently a robust skeleton relying on Custom Post Types and page templates rather than active external API endpoints."

Step 4: Digging Into GitHub Issues

Here's where the workflow gets genuinely useful. I opened the WPFAevent issues list alongside Antigravity and started feeding it specific issues to reason about.

Issue: Caching behavior on API failure

Walk me through how class-event-api.php handles caching.
What transient keys does it use, and what happens when the API call fails?
Is there a risk that a failed response gets cached and served to users?

The agent read the file, traced the transient logic, and identified exactly where an error condition could result in stale or empty data being cached — something I would have had to trace manually through several function calls to find.

Issue: Adding a new shortcode

Which files would I need to touch to add a new shortcode
for displaying event sponsors? Walk me through the pattern
used by the existing shortcodes so I follow the same conventions.

Rather than guessing at the pattern, I got a step-by-step breakdown: create a new class in includes/, register it in class-event-loader.php, add a display template in public/partials/, and enqueue any new assets correctly. The agent even flagged that I'd need to update the translation template in languages/ if I added new user-facing strings.

Issue: Schedule endpoint and multi-day events

There's an open issue about the schedule endpoint not handling
multi-day events correctly. Based on the current implementation in
class-event-schedule.php, what's the most likely cause, and what
would a fix look like?

The agent read the schedule class, identified that the current grouping logic assumed a single date field per session without accounting for sessions spanning midnight, and suggested where the grouping function would need to be extended. I came out of this with a concrete hypothesis to test — before writing a single line.

Step 5: Inline Comments on Artifacts

One feature that surprised me was how naturally Antigravity handles iterative refinement. When the agent produces an analysis artifact — say, a breakdown of what changes are needed for a fix — I can leave comments directly on that artifact, the same way you'd annotate a Google Doc.

I used this to push back on one of its suggestions:

[Comment on artifact]: "This approach modifies the API response parsing — but can we keep the change isolated to the display layer instead? I don't want to touch class-event-api.php for this."

The agent re-read the constraint, updated its recommendation, and produced a revised approach scoped entirely to the template file. No need to rephrase the whole context in a new message.

Step 6: Parallel Agents for Broader Analysis

When I had several open issues I wanted to evaluate at once, I used parallel conversations with work trees — Antigravity's mechanism for running multiple agent threads against separate copies of the codebase simultaneously.

Work Tree = a new folder containing a copy of the project, so agents can explore different issues or approaches in parallel without interfering with each other.

I kicked off three parallel threads:

Thread 1 — Dependency audit:

Check composer.json and the includes/ directory.
Are there any outdated dependencies or missing requirements
relative to the WordPress 5.8+ target stated in the README?
→ New Work Tree

Thread 2 — i18n coverage:

Review the codebase for any user-facing strings that are
not wrapped in __() or _e(). List them by file.
→ New Work Tree

Thread 3 (main thread) — PR review:

There are 17 open pull requests. Based on the current codebase,
which open issues do you think represent the highest-impact
and lowest-risk changes for a new contributor to start with?

All three running simultaneously. While I reviewed the PR analysis coming back on the main thread, the dependency audit and i18n coverage checks were still running. The i18n thread came back with a list of specific files and line numbers — exactly the kind of output that's tedious to produce manually but trivial to act on.

Step 7: Scheduled Tasks for Ongoing Contribution

The final feature I explored was Scheduled Tasks — brand new to Antigravity 2.0.

Scheduled tasks let you run any prompt on a recurring schedule, with the app running silently in the background even when all windows are closed. A menu bar icon shows how many agents are active.

For ongoing open-source contribution, this opens up a genuinely useful workflow. I set up a task called "WPFAevent Issue Digest":

Name: WPFAevent Issue Digest
Schedule: Every Monday, 8:00 AM

Prompt:
Review the current state of the WPFAevent codebase in this project folder.
Check if there are any new patterns or inconsistencies introduced since last week.
Summarize which open issues now have enough context in the codebase to act on,
and flag anything that looks like it might conflict with work already in progress.

Every Monday morning, a brief lands in the app summarising where things stand — without me having to re-orient from scratch each time I come back to the project. For anyone juggling multiple open-source repos alongside their main work, this kind of ambient awareness is genuinely valuable.

The same pattern applies beyond open source: PR status checks, dependency monitoring, documentation drift alerts — any recurring check you'd otherwise do manually.

What Worked Well

Speed changes the cost of asking questions. Gemini 3.5 Flash at close to 800 tokens/second means there's no friction to firing off a quick question about a file you're not sure about. The low latency makes exploratory questioning feel natural rather than effortful.

Parallel agents change the math on codebase analysis. Running a dependency audit, an i18n coverage check, and a PR review simultaneously — each scoped to its own work tree — compressed what would have been a multi-hour orientation into a single focused session.

Inline artifact comments are intuitive. Instead of rephrasing context in a new message, I could annotate the agent's analysis directly, redirect its approach, and get an updated response — exactly like commenting on a Google Doc. This interaction model clicked immediately.

Voice input is underrated. For longer, more nuanced questions about a codebase, speaking is faster and more natural than typing. The agent handled complex multi-part prompts accurately.

Command approval flow builds trust. Knowing exactly what terminal commands the agent wants to run — and having the ability to approve, reject, or whitelist them — means you never feel like you've lost control of your machine.

Self-testing via /browser is a big deal. For issues that involve frontend behavior, being able to ask the agent to verify its own proposed fix in a real browser — and watch it catch its own mistakes — is meaningfully more reliable than code review alone.

Free model access is exceptional value. Gemini 3.5 Flash, Claude Sonnet, Claude Opus, and GPT models are all accessible from the model picker in the free tier. Limited usage, but the breadth is remarkable for zero cost.

What Was Challenging

Model switching restrictions are a regression. In the original Antigravity IDE, you could mix and match — Claude for one task, Codex for another, choosing the best model for the specific job. That flexibility is currently gone. You work with what Google gives you out of the box. For developers who've built workflows around model-specific strengths, this is a real limitation worth acknowledging upfront.

Early rate limits were brutal — though largely fixed. In the first few days post-launch, users were hitting weekly caps after just a couple of work sessions. The backlash was significant. Google responded by tripling rate limits across paid plans, resetting quotas, and then tripling again. Paid users now have roughly 9x the original launch runway. If you tried it early and walked away frustrated, it's worth revisiting. Free tier limits remain tighter.

Browser setup requires a manual step. Connecting the /browser agent to Chrome requires enabling Remote Debugging in Chrome — it's a two-click process, but it's not automatic. First-timers will need to follow the setup prompt before browser testing works.

Sub-agent oversight can feel like a second job at scale. When you have 5–10 sub-agents running simultaneously, monitoring the overview panel and approving occasional blocked actions requires attention. The UI handles this reasonably well, but it's worth being mentally prepared for — this isn't a "fire and forget" tool for complex tasks.

Key Takeaways

Antigravity 2.0 is genuinely designed for agents, not retrofitted for them. The parallel sub-agent architecture, work trees, and /browser command make this feel purpose-built in a way that competing tools don't.
Codebase orientation is a first-class use case. Dropping a repo into a project and asking targeted questions about architecture, issue context, and implementation gaps is one of the most practical things you can do with the tool — and one of the least talked about.
Scheduled tasks turn it into an autonomous employee. The ability to set recurring prompts that run in the background — even with the window closed — opens a class of use cases most AI coding tools don't address.
The free tier is a genuine on-ramp. There's enough free usage to complete a real contribution session, evaluate the tool properly, and decide whether a paid plan makes sense. You don't need a credit card to form a real opinion.
Speed changes behavior. When a tool responds this fast, you ask questions you'd have otherwise skipped. You explore tangents. You pressure-test assumptions before committing to an approach. The raw throughput of Gemini 3.5 Flash has real downstream effects on how you think through a problem.

Who should try it:

Open-source contributors who need to understand existing codebases before diving into issues
Developers onboarding onto new projects at work who want to compress the orientation phase
Developers who want faster iteration cycles on complex multi-part features
Developers running background research, audit, or monitoring workflows
Anyone who has been waiting for a free, capable alternative to Claude Code or Codex

Final Verdict

Would I recommend it? Yes, with awareness of the current limitations.

Is it production-ready? For codebase analysis, contribution workflows, and sophisticated side projects — absolutely. For mission-critical production pipelines where model flexibility and guaranteed uptime matter more than cost, the rate limits and model restrictions are worth factoring in. Google has shown it responds fast to user feedback, so this calculus may shift.

What excites me most? Not any single feature — it's the direction. Antigravity 2.0 is a bet that the future of software development is orchestration: you describe intent, agents coordinate execution, and you stay in the loop as a reviewer and decision-maker rather than a line-by-line author. That model of working is going to win. The question is which platform it wins on.

After this session, Google has a serious claim to that platform.

Check it out at antigravity.google.

Tooling note

In the spirit of transparency, here’s how I used AI while creating this post:

Antigravity 2.0.6 — used directly for codebase review and issue analysis on the WPFAevent repository.
Claude Sonnet 4.6 — used to help structure and refine the written draft of this article.
GPT-5.5 — used to generate the cover image concept and visuals.

All hands-on testing, observations, and conclusions in this post are based on my own experience using Antigravity during this review workflow.

References

Build Your Own Lab: Virtualization for DevOps Beginners

Ubayed Bin Sufian — Sun, 10 May 2026 02:04:52 +0000

What We'll cover?

Setting up your lab (laptop vs cloud)
Virtual Box
- Deploying VMs

Setting Up a Lab on Your Laptop

There are two main options for practicing DevOps: set up a lab on your local machine, or spin up cloud VMs on AWS, Azure, or GCP.

We will focus on the home lab — using a laptop or desktop you already own. It gives you full control, costs nothing extra, and you can use virtualization software like VirtualBox to create and manage virtual machines right on your hardware.

What Is a Home Lab, and What Can You Do in It?

Imagine your laptop is a studio apartment. Now imagine you're trying to run a full restaurant kitchen, a woodworking shop, and a recording studio — all in that same apartment. Things are going to get messy.

That's what happens when you install every DevOps tool directly on your machine: Git, Jenkins, Docker, Kubernetes, Ansible, Python, Java, Node.js, Apache, Nginx, MySQL, MongoDB, AWS CLI, Ubuntu, CentOS... they all start stepping on each other. Different versions conflict. Something breaks. You don't know what you did. You're afraid to change anything.

Virtual machines are the solution. Think of each VM as a separate apartment in the same building. Same physical hardware underneath, but completely isolated from each other. If one apartment burns down (a VM breaks), the others are fine. You just rebuild that one.

With VMs you can:

Run different OS versions (Ubuntu, CentOS, Red Hat) side by side
Isolate tools and projects so they never interfere
Snapshot a working state and roll back if something goes wrong
Delete and recreate freely — no fear

Virtualization software

Virtualization software (also called a hypervisor) sits between your physical hardware and your virtual machines, letting multiple operating systems run on the same machine simultaneously.

There are two types:

Type 1 — Bare-metal Hypervisor: This runs directly on the hardware, with no host OS underneath. Think of it as the hypervisor being the operating system. Examples: VMware ESXi, Microsoft Hyper-V, Xen. These are used in enterprise environments where you need high performance and dozens (or hundreds) of VMs. They're powerful, but expensive and complex.

Type 2 — Hosted Hypervisor: This runs on top of your regular OS (host) — like any other application you install. Examples: Oracle VirtualBox, VMware Workstation, Parallels Desktop. These are perfect for home labs and development environments. Easier to set up, free or cheap, and more than capable for learning. However, they may have performance overhead due to running on top of a host operating system.

Reference: https://www.facebook.com/photo/?fbid=122115084969253388&set=gm.1847442505941341&idorvanity=192962784722663

We will be using Type 2 hypervisor, specifically Oracle VirtualBox, for our home lab environment.

Here's a quick comparison if you're choosing between the two popular options:

Feature	Oracle VirtualBox	VMware Workstation
Cost	Free and open-source	Paid (free trial available)
Platform Support	Windows, macOS, Linux	Windows, Linux
Performance	Good for most use cases	Better for resource-intensive tasks
User Interface	Simple and intuitive	More advanced features
Snapshot & Cloning	Yes	Yes
Resource Management	Good	Advanced

Installing VirtualBox on Linux Mint 22.3 (Zena)

For Windows and macOS installation, refer to the YouTube video in the Reference section below.

I use Linux Mint, so I'll walk through that. You can check your OS details with:

cat /etc/os-release

Linux Mint 22.3 is based on Ubuntu 24.04 LTS (noble), so we use the noble VirtualBox repository.

Step 1 — Add the Oracle VirtualBox repository key:

wget -O- https://www.virtualbox.org/download/oracle_vbox_2016.asc | \
sudo gpg --yes --output /usr/share/keyrings/oracle-virtualbox-2016.gpg --dearmor

Step 2 — Add the repository:

echo "deb [arch=amd64 signed-by=/usr/share/keyrings/oracle-virtualbox-2016.gpg] https://download.virtualbox.org/virtualbox/debian noble contrib" | \
sudo tee /etc/apt/sources.list.d/virtualbox.list

Step 3 — Install VirtualBox:

sudo apt-get update
sudo apt-get install virtualbox-7.1

Step 4 — Verify the installation:

virtualbox --help

For the latest version and other Linux distributions, check the official site: https://www.virtualbox.org/wiki/Linux_Downloads

Setting Up Your First VM in VirtualBox

Open VirtualBox from your applications menu.
Click New to create a virtual machine.
Follow the prompts — choose your OS, allocate memory (at least 2GB recommended for Linux, though 1GB works for lightweight setups), and set up a virtual hard disk.

You have two options here: install the OS manually via an ISO (like inserting a CD), or use a pre-configured VM image that already has the OS installed. I prefer the second approach — it saves time. You can find pre-built images at osboxes.org.
Download the .7z file from osboxes.org, extract it, and you'll get a .vmdk file — that's the virtual hard disk.
When the wizard asks for a hard disk, select "Use an existing virtual hard disk file" and point it to the .vmdk file you extracted.
Before starting the VM, right-click it → Settings → Network → set the adapter to Bridged Adapter. This allows the VM to connect to the same network as your host machine and enable the VM to have its own IP address and access the internet.
Once the virtual machine is created, start in Normal Start.
Log in with the default credentials from osboxes.org (username: osboxes, password: osboxes.org).

Connecting to Your VM

Now your VM is running. But how do you actually talk to it?

Think of VMs like tenants in a building. Just because they share the same physical building (your laptop) doesn't mean they can walk into each other's apartments freely. They need proper addresses and open doors.

Three Ways to Start a VM

Normal Start — Opens a console window with the VM's UI. Closing the window shuts down the VM. Good for initial setup.
Headless Start — VM runs in the background with no window. You access it only via SSH or remote desktop. This is the DevOps way.
Detachable Start — Like Normal Start, but closing the console window doesn't shut down the VM. It keeps running in the background.

SSH Into a Linux VM

For Linux guest VMs, SSH is your main tool. For Windows guests, you'd use Remote Desktop (RDP).

The VM needs:

An IP address assigned
SSH service running Use the console window to do your initial configuration first — get the IP set, start SSH. After that, you can switch to your host terminal for everything else.

Even the vms are within our laptop (host) think of them as separate machines connected to the same network so whatever you need for one system to connect to another system you would need these vms configured with ip addresses and the relevant services must be configured and running on. On windows, the remote desktop service needs to be running and on linux the ssh service needs to be running so make sure ssh server is installed and is in a running state in the vm (guest system). If configured you can ssh into the vm from the host system using the terminal on the host and the ip address of the remote vm.

# Check SSH status on the VM
service sshd status

# Start SSH if it's not running
service sshd start

To SSH in from your host machine:

ssh username@ip_address

If you can't connect, check these first:

Does the VM have an IP address?
Are you using the correct IP?
Is the SSH service running on the VM?

Networking: Bridged vs NAT

This is where a lot of beginners get confused. Let's use an analogy.

Bridged Adapter is like giving your VM its own room in the house with its own doorbell. It gets a real IP address on your network. Anyone on your local network can reach it. SSH is straightforward:

ssh username@vm_ip_address

NAT (Network Address Translation) is like the VM living in a back room with no direct doorbell — it can call out (access the internet), but nobody outside can call in directly. If you have multiple NAT VMs, they're also isolated from each other (they all get the same internal IP and can't see each other).

To SSH into a NAT VM, you need port forwarding — you tell VirtualBox: "whenever someone knocks on my host machine's port 2222, forward that knock to port 22 on the VM."

Set it up in VirtualBox:
Settings → Network → Advanced → Port Forwarding → Add Rule

Name	Protocol	Host Port	Guest Port
ssh	TCP	2222	22

(We use port 2222 on the host because port 22 is already used by the host's own SSH service.)

Then SSH in using:

ssh username@127.0.0.1 -p 2222

This is part of my DevOps Prerequisite series:

DevOps Prerequisite #1: Linux Basics You Actually Need
Build Your Own Lab: Virtualization for DevOps Beginners (this post)
Why Vagrant Still Matters (and When It Doesn’t) (next)
Networking for DevOps: The Only Concepts You Need
YAML Explained for Future DevOps Engineers

Disclaimer: I have used GH copilot for writing the topics, Gemini Nano Banana for image generation, ChatGPT for the html snippet & other concepts and Claude for fine tuning the entire blog.

Reference:
💡 Want a visual walkthrough?
This video does a great job explaining the basics covered here. Use it as a supplement—not a replacement:

Linux Services Made Simple: Create, Control, and Remove Your First systemd Service

Ubayed Bin Sufian — Tue, 05 May 2026 18:45:21 +0000

Linux as a service (The simplest Way to Understand It)

A service is just a program that runs in the background
systemctl is the tool to control it
systemd is the system that manages services

Simple analogy

Think of a service like a car 🚗:

You can start it
You can stop it
You can check if it’s running

The systemd is like the engine that keeps the car running smoothly behind the scenes.

What you'll learn

By the end of this, you’ll be able to:

Create your own service
Start / stop it using systemctl
Enable / disable it at boot
Delete it cleanly (no leftover mess)

Step 1: Create a simple script

Create a file:

sudo nano ~/my_simple_service.sh

Paste this content:

#!/bin/bash

while true
do
  echo "Hello! Service is running..."
  sleep 5
done

Save and exit.

Ctrl + O --> Enter
Ctrl + X

Make it executable:

chmod +x ~/my_simple_service.sh

Step 2: Create a systemd service

Now we tell systemd how to run our script.

sudo nano /etc/systemd/system/my-simple.service

Paste this:

[Unit]
Description=My Simple Demo Service

[Service]
ExecStart=/home/$USER/my-simple-service.sh
Restart=always

[Install]
WantedBy=multi-user.target

👉 Replace /home/your-username with your actual username
(Don’t use $USER here — systemd won’t expand it properly)

Step 3: Reload systemd and start the service

sudo systemctl daemon-reload
sudo systemctl start my-simple.service

Step 4: Check status

sudo systemctl status my-simple.service

You should see the service running.

Step 5: Stop the service

sudo systemctl stop my-simple.service

Step 6: Enable / Disable (auto-start on boot)

Enable:

sudo systemctl enable my-simple.service

Disable:

sudo systemctl disable my-simple.service

Step 7: View logs (while service is running)

sudo journalctl -u my-simple.service -f

-f - follow (like tail -f)

You should see:

"Hello! Service is running..."

…repeating every 5 seconds.

Stop the service: sudo systemctl stop my-simple.service

View logs again: sudo journalctl -u my-simple.service

You will only see past logs (no new updates).

Step 8: Clean up (Delete everything properly)

[CAUTION: PLEASE BE CAREFUL WHEN DELETING THE SERVICE FILES SO WE DO NOT DELETE ANY SYSTEM FILES]

sudo systemctl stop my-simple.service
sudo systemctl disable my-simple.service
sudo rm /etc/systemd/system/my-simple.service
sudo systemctl daemon-reload
sudo rm ~/my_simple_service.sh

Now your system is back to a clean state—no leftover services, no hidden issues.

You just created and managed your first Linux service from scratch 🎉

This is a small step—but it’s exactly how real-world services (like web servers and databases) are managed in production.

Flow Diagram

Disclaimer: I have used GH copilot for writing the topics, Gemini Nano Banana for image generation and ChatGPT for the flow diagram and other concepts.

DevOps Prerequisite: Linux Basics You Actually Need

Ubayed Bin Sufian — Fri, 01 May 2026 01:24:51 +0000

Most DevOps roadmaps look like a never-ending checklist—tools, technologies, and concepts thrown at you all at once.

If you're from a non-IT background or just starting out, it is easy to feel stuck thinking: “Where do I even begin?”

I’ve been there.

That’s why I’m starting this DevOps Prerequisite series to break things down into simple, practical steps that actually matter.

In this first part, we will focus on the one skill that quietly powers almost everything in DevOps: Linux and Vi editor.

Not everything, just the Linux basics you actually need to get started and build confidence.

Basic Linux Commands

According to the Stack Overflow Developer Survey 2024, Linux is the most commonly used operating system among developers, and it's also one of the most loved. Most of the industry tools and platforms are built on Linux, making it essential for DevOps professionals to have a good understanding of Linux commands and operations.

Shell Types

Bourne Shell (sh): The original Unix shell, which is still widely used for scripting.
C Shell (csh/tcsh): Known for its C-like syntax, often used in interactive use.
Z Shell (zsh): An extended version of the Bourne Shell with many improvements, popular among developers for its features and customization options.
Bourne Again Shell (bash): The most widely used shell, which is an enhanced version of the Bourne Shell, offering features like command history and job control.

echo $SHELL - This command will display the current shell being used.

Basic Commands

echo <message>: Prints the message to the terminal. Also used to display the value of environment variables. In scripts and configuration files, it can be used to print information or debug messages.
ls: Lists files and directories.
cd: Change directory.
pwd: Print working directory.
mkdir: Create a new directory.
cd new_dir; mkdir sub_dir; pwd: Multiple commands in one line. ; is used to separate commands, allowing you to execute them sequentially.

Directory Management

To create a dir hierarchy asia/bangladesh/dhaka:
- mkdir asia
- mkdir asia/bangladesh
- mkdir asia/bangladesh/dhaka

[To create the dir hierarchy in one line]

mkdir -p asia/bangladesh/dhaka (using -p flag to create parent directories if they don't exist)
rm -r asia: Remove a directory and its contents recursively.
cp -r my_dir /tmp/my_dir_copy: Copy a directory and its contents recursively.

File Management

touch file1.txt: Create an empty file or update the timestamp of an existing file.
cat > file2.txt: After running this command, the prompt will appear and you can type the content. Hit the Enter key for a new line and press Ctrl + D to save and exit.
cat file2.txt: Display the content of the file.
cp file2.txt dir: Copy a file to a new location.
mv dir/file2.txt dir/sub_dir: Move or rename a file. To rename a file, you can use the same command with the new name in the same directory, e.g., mv file.txt new_file.txt.
rm my_dir.txt: Remove a file.

User Management

whoami: Display the current user.
id: Display user ID and group information.
su username: Switch to another user account. You will be prompted to enter the password for the specified user. Same machine, different user.
ssh username@hostname: Connect to a remote server using SSH. You will be prompted to enter the password for the specified user on the remote server. Different machine, login remotely.
Every linux system has a super user called the root user. The root user has full administrative privileges and can perform any action on the system. In production or enterprise environments, acces to root user is often restricted for security reasons, and users are given specific permissions to perform their tasks.
If a normal user needs to perform administrative tasks, they can use the sudo command to execute commands with elevated privileges such as installing software, modifying system configurations, or managing user accounts. The root user can grant them sudo privileges by adding their username into the /etc/sudoers file or by adding them to a group that has sudo privileges (e.g., the "sudo" group on Debian-based systems). Now, the user can run commands with sudo to perform administrative tasks without needing to log in as the root user. The user needs to enter their own password to confirm the action, and the system will log the command for auditing purposes.

Download files

curl -O https://www.digitalocean.com/robots.txt: Download a file from the specified URL and save it with the custom name. Without the -o flag, the content will be displayed in the terminal instead of being saved to a file. curl; "Client URL".
wget https://example.com/file.txt -O file.txt: Download a file from the specified URL and save it with a custom name. wget; "World Wide Web get".

Check OS version

ls /etc/*release*: This command lists the contents of the /etc directory that match the pattern release, which typically includes files that contain information about the operating system version and distribution. The output may vary depending on the Linux distribution being used, but it often includes files like os-release, lsb-release, or redhat-release that provide details about the OS version, name, and other relevant information.
cat /etc/*release*: This command displays the contents of the files in the /etc directory that match the pattern release. These files usually contain information about the operating system version and distribution. By running this command, you can see details such as the OS name, version number, and other relevant information about the Linux distribution you are using.

Package Managers

Package managers are tools that automate the process of installing, updating, configuring, and removing software packages on a computer. They help manage dependencies and ensure that the correct versions of software are installed. Different Linux distributions use different package managers. For example:

Debian-based distributions (like Ubuntu) use apt (Advanced Package Tool).
Red Hat-based distributions (like CentOS, Fedora) use yum or dnf.
Arch Linux uses pacman.

apt (Advanced Package Tool)

apt is a package manager used in Debian-based Linux distributions that provides a high-level interface for managing software packages. It automatically resolves dependencies and allows you to easily install, update, and remove software packages. For example:

apt install package_name: Install a package along with its dependencies.
apt remove package_name: Remove a package.
apt update: Update the package index to get the latest information about available packages.
apt upgrade: Upgrade all installed packages to their latest versions.

Red Hat Package Manager (RPM)

A software is bundled into a package file with the .rpm extension. The rpm command is used to manage these packages, allowing you to install, update, remove, and query software on your system. For example:

rpm -i package.rpm: Install a package.
rpm -e package_name: Remove a package.
rpm -q package_name: Query if a package is installed.

It does not resolve dependencies automatically, so you may need to manually install any required packages before installing the main package. For example, if you try to install ansible using rpm -i ansible.rpm and it has dependencies like python3 and python3-pip, you would need to install those dependencies first before installing ansible.

yum (Yellowdog Updater, Modified)

yum is a high level package manager used in Red Hat-based Linux distributions that uses RPM under the hood. It automatically resolves dependencies and allows you to easily install, update, and remove software packages. It searches software repositories that act as warehouses containing rpm packages. For example:

yum install package_name: Install a package along with its dependencies.
yum remove package_name: Remove a package.
yum update package_name: Update a package to the latest version.

How does yum find where a particular is located? It looks into the repository configuration files located in /etc/yum.repos.d/ directory. These files contain information about the repositories, including their URLs and the packages they contain. When you run a yum command, it checks these repositories for the requested package and its dependencies, and then downloads and installs them as needed. At times, the default set of repos may not have the software you need or may not have the latest version. So you need to configure additional repositories so yum can find those packages. Instructions to configure additional repositories are usually provided on the software vendor's website.

yum repolist: List all configured repositories and their status (enabled/disabled).
ls /etc/yum.repos.d/: List the repository configuration files in the yum.repos.d directory. Each file corresponds to a repository and contains information about its name, base URL, and other settings. By checking these files, you can see which repositories are configured on your system and where yum will look for packages when you run installation or update commands.
cat /etc/yum.repos.d/<repo_file>.repo: Display the contents of a specific repository configuration file. This file contains details about the repository, such as its name, base URL, and whether it is enabled or disabled. By examining this file, you can understand where yum will look for packages when you run installation or update commands, and you can also modify the repository settings if needed.
yum list <package_name>: Check if a specific package is available in the configured repositories.
yum --showduplicates list <package_name>: Check for all available versions of a specific package in the configured repositories. This command will show you all the versions of the package that are available for installation, allowing you to choose which version you want to install or update to.

Services

Services are background processes that run on a server to provide specific functionality, such as web hosting, database management, or file sharing.

Once software that runs in the background (e.g., web servers, databases) is installed, it needs to keep running reliably even after a reboot. Services ensure that these programs start automatically and in the correct order. For example, a database service should start before a web server that depends on it. Most background software is configured as a service during installation.

service <service_name> start : Start a service. (old command, still works in some distros)
systemctl start <service_name> : Start a service. (new command, used in most modern distros)
systemctl stop <service_name> : Stop a service.
systemctl status <service_name> : Check the status of a service (whether it's running or not).
systemctl enable <service_name> : Enable a service to start automatically at boot time.
systemctl disable <service_name>: Disable a service from starting automatically at boot time.

How to configure a software/program as a service?

Most modern Linux distributions use systemd to manage services. Each service is defined using a unit file, which is a configuration file (with a .service extension) typically located in /etc/systemd/system/.

Steps to configure a software as a systemd service:

Create a unit file for the service. For example, if you want to create a service for a web application called "myapp", you would create a file named myapp.service in the /etc/systemd/system/ directory.
To add additional metadata about the service, such as a description or dependencies, you can include a [Unit] section in the unit file.
Define a section caled [Service] in the unit file, where you specify the command to start the service and directive named ExecStart to specify the command that will be executed to start the service. If the application has other dependencies, commands or scripts to run before or after starting the main application, you can specify them using directives like ExecStartPre or ExecStartPost. If the app needs to be restarted if it crashes, you can use the Restart directive.
To configure the service to start automatically at boot time, define a section called [Install] in the unit file. In this section, you can specify the target that the service should be associated with using the WantedBy directive. For example, if you want the service to start when the system reaches the multi-user target (which is a common target for services), you would add the following lines to the unit file.
After defining the [Install] section, you can enable the service to start at boot time using the systemctl command: sudo systemctl enable myapp.service
Save the unit file and reload the systemd manager configuration to recognize the new service: sudo systemctl daemon-reload
Start the service using the systemctl command: sudo systemctl start myapp.service
Stop the service using the systemctl command: sudo systemctl stop myapp.service
Check the status of the service: sudo systemctl status myapp.service

Unit file contents:

[Unit]
Description=My Web Application Service

[Service]
ExecStart=/usr/bin/python3 /path/to/myapp.py
ExecStartPre=/usr/bin/echo "Starting myapp service..."
ExecStartPost=/usr/bin/echo "myapp service started successfully!"
Restart=always

[Install]
WantedBy=multi-user.target

I have written an example blog on configuring a linux service:

Ubayed Bin Sufian

Linux Services Made Simple: Create, Control, and Remove Your First systemd Service

#linux #devops #systemdesign #beginners

Comments

2 min read

Vi Editor

vi is a powerful text editor that is commonly used in Linux environments. In devops and cloud environments, you will often need to edit configuration files, write scripts, or manage code directly on the server. Knowing how to use vi allows you to efficiently make changes to files without needing a graphical interface, which is especially important when working on remote servers via SSH. vi editor comes by default in most Linux distributions. Types of vi editors:

vi: The original version of the editor.
vim (Vi IMproved): An enhanced version of vi with additional features and improvements. It is widely used and often the default vi editor in many Linux distributions.
nvim (Neovim): A modern fork of vim that aims to improve performance and add new features while maintaining compatibility with vim. It is gaining popularity among developers for its extensibility and improved user experience.
nano: A simpler text editor that is easier for beginners to use. It provides a more user-friendly interface compared to vi and vim, making it a good choice for those who are new to command-line text editing.

Basic vi Commands

Vi editor has two main modes: command mode and insert mode. When you open a file in vi, you start in command mode, where you can navigate through the file and execute commands. To edit the file, you need to switch to insert mode. Here are some basic commands to get started with vi editor:

vi filename: Open a file in vi editor. This will open the specified file in command mode.
i: Switch to insert mode to start editing the file. In insert mode, you can type and make changes to the file. To return to command mode from insert mode, press the Esc key.
Use the arrow keys to navigate through the file in command mode. You can also use h, j, k, and l keys for left, down, up, and right navigation respectively.
x: Delete the character under the cursor in command mode.
dd: Delete the entire line where the cursor is located in command mode.
yy: Copy the entire line where the cursor is located in command mode.
p: Paste the copied line below the current line in command mode.
Ctrl + u: Scroll up half a page in command mode.
Ctrl + d: Scroll down half a page in command mode.
:: Enter command-line mode in vi editor. In this mode, you can execute various commands to save, quit, or perform other actions on the file.
:w: Save the changes made to the file in command-line mode.
:q: Quit the vi editor in command-line mode. If you have unsaved changes, it will prompt you to save before quitting.
:wq: Save the changes and quit the vi editor in command-line mode.
/search_term: Search for a specific term in the file in command mode. This will highlight the occurrences of the search term in the file. You can navigate through the search results using n (next) and N (previous) commands in command mode.

This wasn’t about memorizing commands, it was about getting comfortable with the environment where DevOps actually happens.

If you understand these Linux basics, you’ve already taken a solid first step that many beginners skip.

In the next part of this series, we’ll move from commands to hands-on practice, you’ll learn how to build your own lab using VirtualBox, so you can experiment, break things, and learn by doing.

Because DevOps isn’t learned by reading, it’s learned by doing.

This is part of my DevOps Prerequisite series:

DevOps Prerequisite #1: Linux Basics You Actually Need (this post)
Build Your Own Lab: Virtualization for DevOps Beginners (next)
Why Vagrant Still Matters (and When It Doesn’t)
Networking for DevOps: The Only Concepts You Need
YAML Explained for Future DevOps Engineers

Disclaimer: I have used GH copilot for writing the topics, Gemini Nano Banana for image generation and ChatGPT for the html snippet and other concepts.

Reference:
💡 Want a visual walkthrough?
This video does a great job explaining the basics covered here. Use it as a supplement—not a replacement: