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:
- Log into DigitalOcean
- Select image, size, and region
- Configure firewall rules manually
- Set up DNS records manually
- 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:
| Component | What it does |
|---|---|
| Workspace | Connected to DigitalOcean using an API token |
| App | Created from the "Preview Environments (GitHub + DigitalOcean)" template |
| Canvas | The visual workflow editor where you drag and connect components |
| Trigger | Listens for droplet.create events |
| Actions | Create Droplet → Create DNS Record → Send Slack notification |
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:
- Drag
Create Dropletonto the canvas - Drag
Create DNS Recordnext to it - Click and drag an arrow to connect the two nodes
- 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.
Top comments (7)
Never heard of SuperPlane, but doesn't Digital Ocean itself offer or recommend a deployment tool for their platform? Sounds like a very big and surprising "hole" in their product/service catalog ...
P.S. hm the answer is "probably not", or "only when using App Platform" (which is Digital Ocean's "PaaS") - for 'bare metal' they don't really have a recommended standard tool it seems, looks like they steer you toward using Docker or Kubernetes ... SuperPlane sounds like a good call then!
Great question Leob You're right - DigitalOcean does offer tools like App Platform and Terraform integration for deployment. But this wasn't really about deployment it was about building an internal workflow for provisioning infrastructure with approvals, audit logs, and visibility across the team.
DigitalOcean is great for the infrastructure layer. SuperPlane sits on top and acts as a control plane adding governance, approval steps, and a visual canvas to connect everything. I used it to turn manual tasks (create droplet → DNS → notify) into a governed workflow that non-engineers can also understand and trigger.
Think of it as adding an orchestration layer with built-in guardrails, rather than replacing what DigitalOcean already does well. Hope that helps clarify!
Sounds very powerful! Definitely goes beyond what DO itself offers, I would say (AppPlatform is their PaaS, so it's only easy if you opt into that - and Terraform is powerful, but complex ...)
This is really impressive I love how you've simplified the DigitalOcean infrastructure automation with Superplane The step-by-step breakdown makes it very approachable. Quick question: How does Superplane handle rollbacks if something goes wrong during deployment? Would love to know more about the error-handling side.
Thanks for the kind words really appreciate it That's a great question about rollbacks. SuperPlane keeps a full execution history for every run so if a step fails you can see exactly where it broke (input, output, error message). For rollbacks you can manually trigger a workflow with the same configuration or adjust specific parameters and rerun. Right now I use the execution logs to track and revert changes.
SuperPlane also has built-in approval steps for destructive actions (like deleting droplets), which adds an extra layer of safety before anything goes wrong.
Hope that helps! Let me know if you have more questions.
Hey!! Harsh hope you are doing well!!
This is a great example of moving infrastructure management from manual operations to repeatable automation.
What stood out to me is how SuperPlane acts as an orchestration layer on top of DigitalOcean, allowing infrastructure tasks to be triggered through workflows instead of relying on ad-hoc scripts or dashboard clicks. The ability to automate actions like Droplet creation, DNS management, snapshots, and deployments can significantly reduce operational overhead while improving consistency.
I’m curious: after implementing this workflow, what was the biggest improvement you noticed—faster deployments, fewer configuration mistakes, or simply saving time on routine infrastructure tasks?
Hey! Thanks so much really glad you found it useful.
You hit the nail on the head. The biggest improvement for me has been peace of mind, honestly. Before this, there was always that lingering doubt: "Did I update the DNS record?" or "Did I document this correctly?"
After implementing this workflow, the biggest tangible win has been consistency. Every droplet is provisioned exactly the same way - no typos, no missed steps, no "oops I forgot to set the region." The time savings are great, but knowing that every deployment is identical and auditable is what actually makes it production-ready for me.
Also, being able to hand this off to non-engineers (via Slack triggers) without worrying about them accidentally misconfiguring something has been a game changer.
Appreciate you reading and asking such a thoughtful question!