* Add GitHub Actions audit job (actionlint + zizmor) to CI Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Configure dependabot for GitHub Actions, bundler, and Docker Batches all action updates into a single weekly PR. Adds cooldown periods to all ecosystems. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Add local GitHub Actions linting (actionlint + zizmor) to bin/setup and bin/ci Install actionlint, shellcheck, and zizmor in bin/setup. Run both linters as CI steps in config/ci.rb alongside existing style checks. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Pin all GitHub Actions to SHA hashes Run pinact to pin action versions to specific commit SHAs, preventing supply chain attacks from tag mutation. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Fix high severity zizmor findings - Suppress unpinned-images for redis service containers (digest pinning is nontrivial for service containers) - Move workflow-level permissions to job-level in publish-image.yml (build gets full set, manifest gets only what it needs) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Fix medium severity zizmor findings - Add persist-credentials: false to all checkout steps - Add permissions: {} at workflow level in ci.yml - Add job-level permissions (contents: read) to all CI jobs Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Fix informational template-injection findings in publish-image.yml Move steps.meta.outputs.tags from inline ${{ }} expressions to env vars in both the manifest creation and cosign signing steps. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Update brakeman to 8.0.4 bin/brakeman uses --ensure-latest which fails if not on the newest version. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Campfire
Campfire is a web-based chat application. It supports many of the features you'd expect, including:
- Multiple rooms, with access controls
- Direct messages
- File attachments with previews
- Search
- Notifications (via Web Push)
- @mentions
- API, with support for bot integrations
Deploying with Docker
Campfire's Docker image contains everything needed for a fully-functional, single-machine deployment. This includes the web app, background jobs, caching, file serving, and SSL.
To persist storage of the database and file attachments, map a volume to /rails/storage.
To configure additional features, you can set the following environment variables:
SSL_DOMAIN- enable automatic SSL via Let's Encrypt for the given domain nameDISABLE_SSL- alternatively, setDISABLE_SSLto serve over plain HTTPVAPID_PUBLIC_KEY/VAPID_PRIVATE_KEY- set these to a valid keypair to allow sending Web Push notifications. You can generate a new keypair by running/script/admin/create-vapid-keySENTRY_DSN- to enable error reporting to sentry in production, supply your DSN here
For example:
docker build -t campfire .
docker run \
--publish 80:80 --publish 443:443 \
--restart unless-stopped \
--volume campfire:/rails/storage \
--env SECRET_KEY_BASE=$YOUR_SECRET_KEY_BASE \
--env VAPID_PUBLIC_KEY=$YOUR_PUBLIC_KEY \
--env VAPID_PRIVATE_KEY=$YOUR_PRIVATE_KEY \
--env TLS_DOMAIN=chat.example.com \
campfire
Running in development
bin/setup
bin/rails server
Worth Noting
When you start Campfire for the first time, you’ll be guided through creating an admin account. The email address of this admin account will be shown on the login page so that people who forget their password know who to contact for help. (You can change this email later in the settings)
Campfire is single-tenant: any rooms designated "public" will be accessible by all users in the system. To support entirely distinct groups of customers, you would deploy multiple instances of the application.