Neruba quickstart
Neruba Billing Engine includes a real getting-started path: bring up the stack, confirm readiness, and move into implementation with fewer unknowns.
Start the app and required services with a clear local path.
Run migrations and prepare demo-safe state.
Hit the core flow so the stack proves itself quickly.
Check health, balances, and billing behavior before deeper work.
Bring the stack up, prove readiness, then move on
Use quickstart for the shortest technical path into a trustworthy environment. Bring the app up, confirm readiness, and only then jump to examples, implementation, or operations based on the next blocker.
- You need the first working environment instead of a conceptual walkthrough.
- A team wants to choose between Docker and a local runtime without reading the full docs shelf first.
- You need the specific checks that turn a demo bring-up into a rollout-ready starting point.
- 1Choose Docker when speed matters and you want the fastest shared demo path.
- 2Use the local runtime when your team needs host-level database or runtime control.
- 3Run readiness, docs exposure, webhook, and migration checks before treating the setup as trustworthy.
Go from fresh clone to a verified billing loop
Bring up the stack, validate configuration, exercise the first ingest path, and confirm health and readiness before you branch into deeper setup.
Start the local stack
Run migrations and base setup
Exercise core flows
Validate health and outputs
A faster path from fresh clone to first working billing loop
Choose the runtime path, pick MySQL/MariaDB, confirm readiness, and move from demo success to production-minded validation with less guesswork.
Start the local stack
Run migrations and base setup
Exercise core flows
Validate health and outputs
Start with Docker when speed matters
Run the demo stack locally with seeded data so engineering, product, and finance can inspect the full billing flow before deeper rollout work starts.
Use MySQL/MariaDB
Choose the MySQL-compatible database your environment already trusts. The shipped app is aligned to a MySQL/MariaDB path for implementation and deployment.
Validate with readiness checks first
Use health and readiness endpoints, env validation, and migration runners before you treat a local bring-up as trustworthy.
Fastest implementation start
Install dependencies, run the first-run checks, start the Docker demo, and wait for the stack to reach readiness before opening docs and sample endpoints.
Local path without Docker
Use the local scripts when your team needs a database running on the host machine or wants tighter control over the runtime during implementation.
Production-minded validation
Before go-live, verify env secrets, docs exposure, webhook signing, migration discipline, retention, and support workflows rather than stopping at a successful demo.
- Create local env files from the safe templates
- Pick MySQL/MariaDB for the implementation stack
- Run the demo or local start path and wait for readiness
- Open API examples once the demo is ready and verify the main request flows
- Open docs and OpenAPI only in the environments where you intend to expose them
- Seed data or test event flows before comparing billing outputs
- Capture migration, deployment, or edge-case questions for rollout planning
The checklist that matters after the demo is up
A working demo is only the start. Strong billing rollouts also verify secret handling, docs exposure, webhook integrity, migration discipline, and support readiness before any cutover decision is made.
Set strong secrets, keep browser auth decisions explicit, and use least-privilege credentials for databases and operator access.
Disable Swagger and OpenAPI in production unless required, protect them when enabled, and preserve raw-body verification for Stripe webhooks.
Run migrations on deploy, keep the migration history committed, and treat release checks and support reports as part of the rollout plan.
Want the quickstart mapped to your rollout?
Plan your rollout when you want the bring-up path, deployment posture, migration plan, and edge cases mapped to your actual project instead of a generic demo stack.