DEV Community

Steve Davis
Steve Davis

Posted on

I Automated DEV.to Drafts from a VPS with OpenClaw

#openclaw #automation #devops #productivity

I Automated DEV.to Drafts from a VPS with OpenClaw

Most writing workflows die in the gap between “good idea” and “I’ll write that later.” I wanted a system where I could drop a rough idea from my phone and get a polished DEV draft waiting for review. Running OpenClaw on a VPS made that possible without keeping my laptop online.

Why this matters

If you publish technical posts regularly, consistency is harder than inspiration. Ideas appear in bursts, but formatting, structuring, and posting can be slow. An always-on VPS turns that friction into an automated pipeline: capture an idea, generate a draft, and store it safely as unpublished for final human approval.

The idea in one minute

  • Build a small custom skill (devto-draft) that turns rough prompts into DEV-ready Markdown.
  • Post via the DEV API with published: false so nothing goes live by accident.
  • Return the draft URL immediately so editing and approval stay in your control.

Step-by-step

1) Create a skill for one specific outcome

General prompts produce inconsistent structure. A dedicated skill lets you enforce a predictable post shape: hook, rationale, steps, pitfalls, TL;DR, and next steps.

mkdir -p ~/.openclaw/workspace/skills/devto-draft/{templates,tools}
Enter fullscreen mode Exit fullscreen mode

Keep your SKILL.md strict about output and execution contract (write markdown to /tmp/devto_post.md, then call your uploader script).

2) Add a tiny uploader script for DEV drafts

Use a local Python script to call https://dev.to/api/articles with your API key and hard-code draft behavior.

python3 tools/devto_create_draft.py "My Title" "openclaw,automation,devops" /tmp/devto_post.md
Enter fullscreen mode Exit fullscreen mode

Inside the payload, force:

"published": false
Enter fullscreen mode Exit fullscreen mode

That one flag is the safety rail that keeps automation useful instead of risky.

3) Keep secrets and runtime stable on the VPS

Your script should read DEVTO_API_KEY from env and optionally fall back to ~/.secrets/devto.env. A VPS is ideal here because you get one stable runtime, one skill path, and one place to debug.

# ~/.secrets/devto.env
DEVTO_API_KEY=your_key_here
Enter fullscreen mode Exit fullscreen mode

Use a local venv in the skill folder so dependency changes are controlled and reproducible.

Common pitfalls

  • Pitfall: Script path mismatches between skill docs and real files

    Fix: Use absolute paths derived from the skill base directory.

  • Pitfall: Missing API key at runtime

    Fix: Check env first, then load ~/.secrets/devto.env as fallback.

  • Pitfall: Automation accidentally publishes

    Fix: Hard-code published: false in the uploader and never expose a “publish now” default.

A practical example

My day-to-day prompt can be short:

Use devto-draft: write a DEV post draft about automating DEV drafts from a VPS with OpenClaw.
Enter fullscreen mode Exit fullscreen mode

The skill handles structure and tone, writes /tmp/devto_post.md, calls the uploader, and returns JSON like:

{
  "id": 1234567,
  "url": "https://dev.to/yourname/your-slug"
}
Enter fullscreen mode Exit fullscreen mode

Now I review, tweak voice and details, then publish manually when ready.

TL;DR

  • A VPS makes OpenClaw-based writing automation always available.
  • A focused skill beats ad-hoc prompting for consistent draft quality.
  • Draft-only posting (published: false) gives you speed without losing editorial control.

Next steps

  • Add a “house style” reference file for your voice.
  • Add optional variants (short, standard, deep-dive).
  • Add a final pre-publish checklist (facts, links, code validity, claims).
  • If you run this setup, share what part saved you the most time.

Dead internet theory is real.

Top comments (1)

Some comments may only be visible to logged-in visitors. Sign in to view all comments.