Run GitHub Actions across a whole organization — safely, in bulk, and live.

Features · How it works · Getting started · Configuration · Security · Development · Architecture

---

EasyActions is a web dashboard for GitHub Actions. You pick a GitHub organization and see every repository with its branches and workflows, plus the live status of each one. You can start workflow_dispatch runs on many repositories at once, then watch them finish, all from one screen.

EasyActions is the product name. Pipliner is the codename: you will still see it in the code, the cookies, the /health answer and the logs.

Features

• Sign in with GitHub, stay signed in. It uses a GitHub App with a PKCE flow. You stay signed in for up to 30 days (configurable): your GitHub tokens are kept encrypted on the server and renewed automatically. The browser never sees them.
• Daily code. Once a day, each browser asks for the 6-digit code of an authenticator app (Google Authenticator, Authy, 2FAS, 1Password…), set up with a QR code at your first sign-in. Ten one-time recovery codes cover a lost phone.
• Your account. See every browser where you are signed in, sign the others out, make new recovery codes, change your authenticator app, download your data or delete it. Sign-ins and security actions are kept in a history.
• Settings in the website, for admins. Enter the GitHub connection (addresses, GitHub App client ID and secret) on a setup page the first time, then change it and the limits without editing files. Manage users: roles, authenticator reset, sign-out, deletion. Read the security history. Sensitive changes ask for a current 6-digit code.
• Statistics dashboard. Each organization opens on its dashboard: people who committed on any branch, successful and failed runs, success rate, average duration and branches, compared with the previous period; runs over time, rankings by repository, top failing workflows and recent failures. 7, 30 or 90 days. Every chart has a table view, and the page names anything it could not read.
• Sidebar, organization already chosen. The navigation sits on the left (a drawer on a phone): your organization with its dashboard and repositories, the admin pages, and your account card with its sign-out button. The organization you opened last in this browser is selected for you (otherwise the first of your list); switch to another from the card at the top. While anything loads, the EasyActions gear turns.
• Organization overview. See every repository the app can access. Search and filter them by visibility, language and archived state, and sort them. The filters are saved in the address, so you can share a link to a filtered view.
• Branches and workflows per repository. Branches are listed in this order: the default branch, then active branches, then stale ones. Each workflow shows the status of its latest run on the branch you chose.
• Bulk runs. Select repositories and workflows, look over the full list of targets in a confirmation dialog, and start them all with one request.
• Guard for production branches. If any target is on a repository's default branch, the Run button stays locked until you type the organization's name.
• Live tracking. Started runs are checked with an adaptive polling interval. If their state can't be confirmed, they show "Status unknown" and a link to GitHub. The app never guesses a result.
• Desktop window. bun run desktop opens EasyActions in its own window. You can also install it from Brave, Chrome or Edge.
• GitHub Enterprise Server and GHE.com are supported through two settings.

How it works

One Bun process serves both the web app and its API from the same origin.

Browser ── same origin ──▶ Bun + Hono
                            ├─ /health, /auth/*, /api/*  → server/  (GitHub adapters: OAuth, repos, Actions)
                            └─ any other path            → app/     (TiniJS + Lit web app)

Every design choice, the full list of routes, and the behaviour on each kind of failure are described in docs/ARCHITECTURE.md; what is stored and how it is protected, in docs/SECURITY.md.

Getting started

Prerequisites

• Bun 1.3.11
• A GitHub organization where you can install a GitHub App
• Optional: a Chromium-based browser (Brave, Chromium, Chrome, Edge) for the desktop window

1. Create a GitHub App

On GitHub, go to Settings › Developer settings › GitHub Apps › New GitHub App (or do the same in your organization's settings), then set:

Create the app. Note its Client ID, generate a client secret, and install the app on your organization.

2. Configure

bun install --frozen-lockfile
cp .env.example .env
openssl rand -base64 32
openssl rand -base64 32

Open .env and replace every <TO_PROVIDE>:

• SESSION_SECRET: the first output of the openssl command
• DATA_ENCRYPTION_KEY: the second output (a different value; keep it safe — losing it signs everybody out)

.env is git-ignored. Never commit it. The GitHub App's client ID and secret never go in it: you type them on the website (step 4).

Then create the database (run it again after every upgrade, with the server stopped):

bun run db:migrate

3. Run

Development mode, with hot reload, on http://127.0.0.1:8094:

bun run dev

Production mode (stop the dev server first, because both use the same port):

bun run build
bun run start

Desktop window. This reuses a running server, or builds and starts one in the background:

bun run desktop

4. Connect your GitHub App

The first time, the server starts in setup mode: open http://127.0.0.1:8094 and it shows the setup page. In the repository folder, get a one-time setup code (it works for 30 minutes):

bun run settings:setup-code

On the setup page, type that code, the GitHub address (the API address fills itself in), your app's Client ID and client secret, then Test connection and Save and finish. The secret is stored encrypted in the database and never shown again.

5. Become the first admin

Sign in with GitHub (and set up your authenticator app), then run this in the repository folder, with your GitHub login instead of your-github-login:

bun run users:promote your-github-login

Reload the page: an Administration section (Settings, Users, History) appears in the sidebar. Other admins can then be made from the Users page.

Configuration

Configuration has two places:

• .env, for the server and security. Every variable in the table below is required. If one is missing, still set to <TO_PROVIDE>, or invalid, the server does not start and lists the names of the problem variables (never their values). .env.example documents each one.
• The website, for the website settings (GitHub connection and limits, second table). They are stored in the database: the GitHub connection is entered once on the setup page, then admins change everything on the Settings page. Limits start at the defaults below.

Website settings (setup page, then Settings page):

Changing the GitHub address or client ID signs everybody out. If a wrong value locks everybody out, run bun run settings:setup-code --reset: it clears the connection (signing everybody out), puts the server back in setup mode and prints a new setup code.

Security

• Sessions in a local database. The cookie holds only a random id; the session and its GitHub tokens live in the SQLite file, the tokens encrypted (AES-256-GCM). Signing out closes the session and revokes the token; the Account page signs out other browsers, exports or deletes your data. Details: docs/SECURITY.md.
• Admins are checked by the server. Every admin route answers 403 to other users. Changing the GitHub connection, a role, someone's authenticator app or deleting someone needs a current 6-digit code, and the history records who did it.
• Setup needs the server. Until a GitHub connection is saved, only the setup page answers, and only with a one-time code printed by bun run settings:setup-code on the server. Once set up, the setup page is closed for good (--reset reopens it, from the server only).
• CSRF protection. Every POST must carry the app's exact Origin, and cookies are SameSite=Lax.
• Strict headers. Every response sets a CSP and frame-ancestors 'none', so the "Run" button cannot be embedded in another site (clickjacking).
• No duplicate deploys. A dispatch is never retried. If a dispatch times out or GitHub answers with a server error, the result is reported as "unknown" and you are asked to check GitHub. A retry could start the same deployment twice.
• Privacy-safe logs. Logs are JSON lines built from a fixed list of allowed fields. They never contain tokens, request bodies, headers or personal data.

Warning: a workflow_dispatch run usually deploys something. Test with a sandbox repository that has a no-op workflow, never with production workflows.

Development

Check gate. All of these must pass before a change is considered done:

bun install --frozen-lockfile && bun run typecheck && bun test && bun run build && bun audit --audit-level=high

Project conventions:

• Every dependency is pinned to an exact version.
• app/ never imports from server/.
• Every error body has the shape { detail: { code, message } }.
• Logs go only through server/config/logger.ts.
• Components use shadow DOM and only MASKAI semantic classes.

The tests check the design rules. The full rules are in docs/ARCHITECTURE.md.

Roadmap

The planned milestones (M0–M8) are delivered. How the dashboard counts is described in docs/DASHBOARD.md.

Brand

The logos, app icons and favicons are in EasyActions-Logo-Pack-v2/. Its README covers colours, typeface, sizes and clear-space rules.

License

EasyActions is released under the Apache License 2.0 (SPDX-License-Identifier: Apache-2.0). The full text is in LICENSE, and every package ships a copy. You may use, modify and redistribute it, including commercially, as long as you keep the copyright and licence notices and state the changes you made to any file you redistribute.

The licence covers the code only. The EasyActions name and the logos, app icons and favicons in EasyActions-Logo-Pack-v2/ are not granted with it: a fork may use the code, not the brand.