* Add saas:usage_report rake task and extract Subscription.paid scope Add a rake task to generate a CSV usage report with per-account data: Queenbee ID, sign up date, paid date, card count, storage used, and last active date. Extract the paid subscriptions query from Admin::StatsController into an Account::Subscription.paid scope so both the controller and the new rake task can share it. * Add comped and account name columns to usage report * Update saas/lib/tasks/fizzy/usage_report.rake Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> * Preload storage_total to avoid N+1 in usage report * Batch last_active_at queries to avoid per-account aggregates * Add tests for Account::Subscription.paid scope * Update saas/app/models/account/subscription.rb Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> * Aggregate paid dates in SQL instead of loading all subscriptions * Fix paid scope to derive plan keys from Plan.all instead of PLANS hash * Move paid dates and comped lookups into per-batch queries * Materialize batch IDs to avoid cross-database subquery SaasRecord models live on a separate database (fizzy_saas) that doesn't have the accounts table. Using batch.select(:id) generated a subquery that ran on the saas database, causing a table-not-found error. Using pluck(:id) materializes the IDs into an array instead. --------- Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
This is a Rails engine that 37signals bundles with Fizzy to offer the hosted version at https://fizzy.do.
Development
To make Fizzy run in SaaS mode, run this in the terminal:
bin/rails saas:enable
To go back to open source mode:
bin/rails saas:disable
Then you can do Fizzy development as usual.
How to update Fizzy
After making changes to this gem, you need to update Fizzy to pick up the changes:
BUNDLE_GEMFILE=Gemfile.saas bundle update --conservative fizzy-saas
Working with Stripe
The first time, you need to:
- Install Stripe CLI: https://stripe.com/docs/stripe-cli
- Run
stripe loginand authorize the environment37signals Development
Then, for working on the Stripe integration locally, you need to run this script to start the tunneling and set the environment variables:
eval "$(BUNDLE_GEMFILE=Gemfile.saas bundle exec stripe-dev)"
bin/dev # You need to start the dev server in the same terminal session
This will ask for your 1password authorization to read and set the environment variables that Stripe needs.
Stripe environments
Working with Push Notifications
To test native push notifications (APNs and FCM) locally, start the dev server with the --push flag:
bin/dev --push
This will ask for your 1Password authorization to fetch the push credentials. Note that this loads the production APNs and FCM credentials into your environment.
Environments
Fizzy is deployed with Kamal. You'll need to have the 1Password CLI set up in order to access the secrets that are used when deploying. Provided you have that, it should be as simple as bin/kamal deploy to the correct environment.
Handbook
See the Fizzy handbook for runbooks and more.
Production
This environment uses a FlashBlade bucket for blob storage.
Beta
Beta is primarily intended for testing product features. It uses the same production database and Active Storage configuration.
There are 4 beta environments:
- https://beta1.fizzy-beta.com
- https://beta2.fizzy-beta.com
- https://beta3.fizzy-beta.com
- https://beta4.fizzy-beta.com
Deploy with: bin/kamal deploy -d beta1 (or -d beta2, -d beta3, -d beta4)
Staging
Staging is primarily intended for testing infrastructure changes. It uses production-like but separate database and Active Storage configurations.
License
fizzy-saas is released under the O'Saasy License.