How I Automated DigitalOcean Infrastructure with SuperPlane

Our infrastructure "documentation" was a Google Sheet. Anyone on the team could edit it. Nobody always did.

Every new droplet meant the same five manual steps: log in, pick image and size, configure firewall rules, set up DNS, update the spreadsheet. 30 minutes if nothing went wrong. No record of who did it. No approval process. No way to trace a misconfigured droplet back to a decision or a person.

The obvious fix was a script. But a script running on a cron job with no visibility is just a faster way to make undocumented changes. You still don't know what ran, when, or why something broke.

What I actually needed was audit logs, approvals, and notifications - without stitching together three separate tools to get them.

That's what SuperPlane gave me.

The Problem

Every time I needed to provision a new droplet, the process looked the same:

1. Log into DigitalOcean
2. Select image, size, and region
3. Configure firewall rules manually
4. Set up DNS records manually
5. Document everything in a spreadsheet - hoping I didn't forget anything

No audit trail. No approval process. No visibility into who made which change or when.

If something went wrong, there was no way to trace it back. If a team member provisioned resources without approval, there was no record. This wasn't just inefficient - it was risky.

The spreadsheet was becoming the most important piece of infrastructure, and it was just a Google Sheet that anyone could edit.

The Workflow I Built

I built a simple automation workflow using SuperPlane. The setup started with creating an owner account and connecting my DigitalOcean workspace.

SuperPlane's initial setup screen - straightforward owner account creation before configuring your first workspace.

Once the workspace was set up, I created a new app using the built-in app catalog. SuperPlane offers starter templates for common workflows, including a pre-built Preview Environments (GitHub + DigitalOcean) integration.

The New App screen. Two options immediately relevant: Preview Environments with GitHub + DigitalOcean, and GitHub + AWS. I chose the DigitalOcean path.

The workflow I built has four steps:

Step 1 - Trigger
Activates when a new droplet needs to be provisioned. Listens for a droplet event so the automation starts automatically - no manual kick-off required.

Step 2 - Create Droplet
Provisions a droplet with predefined specifications: specific image, size, and region. No one on the team has to remember the correct settings.

Step 3 - Configure DNS
Creates DNS records automatically once the droplet is ready. This used to be the step most likely to be forgotten.

Step 4 - Notify
Sends a Slack notification when everything is complete. The whole team knows the environment is ready without anyone having to check.

When a team member requests a new environment, the workflow triggers automatically. The droplet gets created. DNS configures itself. Everyone gets notified. No manual steps, no delays, no "did someone set up DNS?" in Slack at 11 PM.

What Gets Triggered & How the Demo App Works

The workflow starts when a droplet event is triggered. This happens when someone requests a new environment - either through a chat command, a form submission, or directly from SuperPlane's UI. The trigger listens for droplet.create events and kicks off the automation automatically.

Here's the demo app architecture:

When the trigger fires, it captures request details (droplet name, region, size) and passes them through the canvas. Each component receives the output from the previous one automatically - no manual wiring required.

The Visual Workflow Canvas

SuperPlane gives you a visual canvas to build infrastructure workflows - no YAML files, no scripting, just drag and connect.

The canvas editor. Left panel: the AI Agent (already greeting you and setting up) plus Console, Memory, and Files tabs. Center: the visual canvas where you drag and connect components. Top right: Publish button when the workflow is ready.

When you click on the New Component node, a sidebar opens with every available DigitalOcean action:

The full DigitalOcean component library - Create Droplet, Create GPU Droplet, Create Knowledge Base, Create Load Balancer, Create Snapshot, Delete actions, DNS records, and more. Every DigitalOcean operation available as a drag-and-drop component.

How the flow comes together:

1. Drag Create Droplet onto the canvas
2. Drag Create DNS Record next to it
3. Click and drag an arrow to connect the two nodes
4. Configure each component - select region, size, droplet name

The canvas automatically passes data between components. When Create Droplet runs, its output droplet ID, IP address - flows directly into Create DNS Record. No manual wiring of variables.

Where observability lives:

• The Console tab shows execution logs for every run
• The Agent panel helps debug failures in plain language
• Click any component to inspect its input, output, and status
• Every workflow run is recorded with timestamps and who triggered it

This is what makes SuperPlane different from a script or a Makefile. You see everything on one screen. The execution history is right there. No digging through log files, no guessing why something failed.

Why SuperPlane Made It Actually Work

Before this, I tried two other approaches.

First was a Bash script on a cron job. It worked until it didn't - and when it broke, there was no way to know what had run, what hadn't, or why.

Second was Terraform with a Slack webhook bolted on. Better, but I still had no approval step and the audit trail was just Git blame on a state file.

The thing both approaches were missing wasn't automation. It was control.

SuperPlane is open-source, so I could read exactly what it was doing. That mattered. What kept me using it was four things I couldn't easily get elsewhere without stitching tools together:

Logs that are actually useful. Every run is recorded with a timestamp and who triggered it. When something breaks, I click the run, see the exact step that failed, and read the input and output for that component. No digging through CloudWatch or grepping log files.

Approvals built into the workflow. Destructive operations like deleting a droplet require a human to confirm before anything executes. This isn't a policy document someone has to remember - it's enforced at the workflow level.

Budget guardrails. The workflow won't provision outside predefined limits. The constraint isn't in a README - it's in the system.

Human-in-the-loop for AI actions. Agents can propose workflow changes but nothing executes without a person reviewing it first. This is the part that I think is actually new. Not AI automation. Governed AI automation.

A cron job does the task. SuperPlane does the task and gives you a paper trail you can actually trust in production.

The Bigger Takeaway

Small automations are useful. Governed automations are valuable.

The difference is oversight - knowing what ran, when, why, and who approved it. Platform teams can now build custom operational workflows without stitching together five different tools to get audit logs, approvals, and notifications working together.

What used to take me 30 minutes of manual work - logging in, configuring, documenting, notifying - now happens automatically. The infrastructure workflow that required constant babysitting runs itself.

More importantly: I can trust it. That's the part that matters.

Get Started

SuperPlane is open-source. Run the demo in 2 minutes:

docker run --rm -p 3000:3000 -v spdata:/app/data -ti \
  ghcr.io/superplanehq/superplane-demo:stable

Then open http://localhost:3000 in your browser.

👉 GitHub: github.com/superplanehq/superplane

Have you automated your infrastructure workflows? What tools are you using? What's the part that still requires manual steps you wish didn't?

Drop a comment - I read every one.