🔄 Request: More Frequent `dev` Branch Updates + Release Channel Switcher

Open
  • Is something wrong?
#433 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
typescript
Domain
cli, release

Research direction

Start by tracing how openship update currently pulls a build and restarts the service, and how the installer uses OPENSHIP_REF. Then assess how channel selection should affect the tracked ref, build/image, and restart flow, while preserving data and configuration. Done means users can switch between main and dev, see the current channel, and retain their data and config.

Written by the indexing model from the issue text.

Description

Summary

Two related requests around the dev branch — more frequent updates so it's usable for active testing, and a built-in way to switch between channels without manual reinstall.

Problem

main currently has a significant backlog of open bug reports that haven't been addressed in a release yet. For self-hosters, this means running a build with known bugs and no reliable way to test fixes without manually switching branches.

Some of the currently open issues (including several reported from our end):

  • #429 – Unrecognized hostnames return raw TLS/OpenResty errors instead of a friendly "Service Not Found" page
  • #428 – Cannot create project — POST /api/projects/ensure returns 400 Bad Request
  • #427 – Terminal session counter not reset after browser disconnect — ghost sessions block new shells indefinitely
  • #411 – Login with username only (without @domain) not supported on single-domain setup
  • #410 – Rollback action permanently disabled — status string mismatch ("ready" vs "success")
  • #408 – Docker health check shows Unhealthy on external server added via SSH despite Docker running normally
  • #396 – Overview page shows 0 requests / no traffic data on some projects (silent AbortError)
  • #392 – smtp_tls_security_level set to "encrypt" breaks inbound mail delivery via Amavis
  • #391 – Relay SMTP settings not applied to webmail container + logout redirects to 404
  • #390 – Latest version broke the CLI
  • #389 – App expects a package manager field to deploy a docker-compose file
  • #384 – Windows compatibility: ESM loader fails with absolute Windows paths

The dev branch exists but receives infrequent pushes, making it impractical as a testing channel. Switching between main and dev also requires manually editing OPENSHIP_REF and re-running the installer with no easy way to revert.

Request 1: More Frequent Pushes to dev

Could the maintainers consider:

  1. Merging fix PRs into dev first before they land on main, so testers can verify them early
  2. A rough push cadence on dev (e.g. at least once a week, or whenever a batch of fixes is ready)
  3. Optional: a brief note when dev is updated so testers know what changed
Request 2: Release Channel Switcher

Add a built-in way to switch between main (stable) and dev (bleeding-edge) without a manual reinstall:

# Switch to dev channel
openship channel set dev

# Switch back to stable
openship channel set main

# Show current channel
openship channel

This would update the tracked ref, pull the correct build/image, and restart the service — similar to how openship update works today.

Stretch goal: A small toggle in the dashboard settings showing the current channel (🟢 Stable / 🟡 Dev), similar to what Coolify, Gitea, and Portainer already do.

Acceptance criteria:

  • User can switch main ↔ dev with a single CLI command or UI action
  • Current channel is clearly visible in CLI output or dashboard
  • Data and config are preserved across channel switches
Why This Matters

With 50+ open bug reports and a growing list of unmerged fix PRs, self-hosters have no practical way to run a build that includes those fixes without manually tracking each PR or branch. An active dev channel + switcher would:

  • Let testers verify fixes before they hit main
  • Reduce duplicate bug reports from users hitting already-fixed issues
  • Give contributors faster feedback loops

Happy to help test or contribute a PR. 🙏

Dominant language
TypeScript
Stars
14.5k
Forks
1.3k
Avg merge
15h 13m
Merged PRs (30d)
309

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from oblien/openship

All issues in oblien/openship

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.