Skip to content
Brand Logo

Rig Community
  1. Home
  2. Feature ideas

Feature ideas

5 Topics 8 Posts

What should Rig do next. Search first. We reply on top ideas each month.

This category can be followed from the open social web via the handle feature-ideas@community.userig.app

  • RigR

    Suggest a feature

    Pinned
    1
    0 Votes
    1 Posts
    27 Views
    RigR
    Suggest a feature This category is for what Rig should do next. How to write a good idea Search first — duplicate ideas get merged. One idea per topic. Describe the job to be done (what you’re trying to accomplish), not just a UI sketch. Optional: how you work around it today. What happens next We read everything. Each month Rig replies on the top ideas with a short yes / later / no-and-why. Private account requests → help.userig.app. — Rig
  • RigR

    probe

    2
    0 Votes
    2 Posts
    12 Views
    RigR
    Ignore — accidental probe while wiring Feature ideas push. Safe to delete.
  • RigR

    DDEV / Magento first-class recipes

    ddev magento docker recipes
    2
    1 Votes
    2 Posts
    6 Views
    RigR
    Canonical write-up (opening post may have mangled markdown from an earlier push): Ask: First-class DDEV (and Magento) integration — detect .ddev/, map ddev start / ddev stop / HTTPS URLs, and ship Magento scaffolds/recipes. Today: DDEV isn’t a first-class integration (no Magento/DDEV-specific recipes). If DDEV exposes the site on localhost ports and you point Rig at the project folder, you get the outer control plane (start/stop the compose/DDEV command you configure, logs from that process, MCP against that project). Honest limit: For Magento-in-DDEV day-to-day, DDEV + Magento MCP stay the primary tools; Rig is optional glue, not a replacement — until this ships. Sketch: Detect .ddev/ on add-project / setup assist Preferred scripts: ddev start / stop / describe URLs Magento scaffold / recipe beside existing Laravel / WordPress paths Docs: when Rig helps vs when DDEV + store MCP should lead Source: Prospect feedback (Magento 2 / angeo module-aeo-audit), 2026-09-03. Tracked in docs/feature-ideas-todo-2.md.
  • RigR

    Container-interior process visibility (Docker / DDEV)

    docker ddev containers
    2
    1 Votes
    2 Posts
    6 Views
    RigR
    Canonical write-up (opening post may have mangled markdown from an earlier push): Ask: Give Rig optional visibility into processes inside containers — not only host processes and published ports. Today: Rig is host-oriented. It can run Compose / DDEV as an outer process and see published localhost ports. It does not give deep visibility of processes inside containers the way docker top / DDEV’s own tooling does. Why: Magento + DDEV (and other Docker-first) users need per-service status, interior PIDs/ports, and container logs without replacing Docker/DDEV as the runtime. Sketch: Optional container-aware board for Compose / DDEV projects Per-service status + logs via Docker CLI MCP: surface container services under get_status / get_logs without a raw shell Source: Prospect feedback (Magento 2 / DDEV), 2026-09-03. Tracked in docs/feature-ideas-todo-2.md.
  • R

    Proactive port conflict scan

    1
    0 Votes
    1 Posts
    18 Views
    R
    Right now Rig only tells you who owns a port reactively, when a start fails on bind. Add a read-only scan that shows what's already listening on common dev ports (and on the ports your added projects declare) before you hit start, so conflicts are visible upfront instead of discovered by a failed boot. Not full system auto-discovery — just extending the existing "who owns this port" lookup to run proactively across a range rather than waiting for EADDRINUSE.