Railway's paid plan cards, captured from its official pricing page on November 4, 2026. This teardown models Hobby only; the other plans are shown for context.
Railway's published resource rates, captured on November 4, 2026. This example uses only service memory, CPU and egress; volumes and object storage are excluded.
This example covers the standard, unwaived Hobby plan in USD for one workspace and a full monthly billing cycle. It excludes volumes, backups, object storage, sandboxes, VMs, agents, other plans, trial or promotional credits, taxes, plan changes and negotiated terms. Assume those excluded resources incur no charges. The event names and properties below are illustrative Flexprice inputs, not Railway API fields.
Pricing profile
These labels describe only the unwaived Hobby service CPU, RAM and egress offering modeled here, not Railway’s entire product catalog or sales process.Railway Hobby service pricing
The official pricing page publishes the following service rates. Use the displayed per-second rates directly rather than deriving them from rounded monthly estimates.
Railway’s billing guide explains that the subscription is billed in advance and resource overage in arrears. Unused included usage resets each billing cycle and does not roll over. For total resource cost
U in one full cycle:
How Railway’s pricing maps to Flexprice
A currency allowance shared across resources is not three independent free-unit entitlements. Do not give each meter $5 of free usage, apply a separate minimum to every resource, or combine this grant with an additional minimum-spend commitment. The recurring charge and usage-only credits together implement the minimum.
Design takeaways
These are modeling implications of the published terms, not claims about Railway’s business intent.- Apply the allowance after combining resource costs. Railway’s included usage applies against total resource usage. In Flexprice, one shared currency grant preserves that relationship when the CPU-to-RAM mix changes; three separate resource allowances would change the total discount.
- Keep time-based consumption separate from data transfer. The service rate table prices CPU and RAM per second, but egress per GB. Separate SUM meters retain those units without treating outbound traffic as a function of uptime or rounding compute into hourly packages.
- Treat included usage as cycle-scoped funding, not permanent balance. Railway’s billing guide says unused included usage does not roll over. A recurring grant with billing-cycle expiry models that reset; a one-time, nonexpiring wallet top-up would not reproduce later cycles.
Set up the resource meters
Create three metered features with Event Namerailway_service_usage, Aggregation SUM and usage reset BILLING_PERIOD. Apply the filter resource_scope = hobby_services to every meter. Use one Flexprice customer for the workspace so usage from all its modeled services shares one credit pool.
Normalize nonoverlapping measurement intervals before ingestion. For each interval, multiply average memory in GB by elapsed seconds, and average CPU in vCPU by elapsed seconds. For varying consumption, integrate the measurements rather than multiplying a single instantaneous sample by the whole month. A count of requests or service uptime alone is not CPU consumption. Include idle memory and CPU consumption, not just request-serving activity.
Send outbound GB for that interval, not a cumulative network counter. Preserve the source’s GB convention when normalizing; do not silently substitute another byte-to-GB conversion. Keep numeric precision through aggregation and pricing. No whole-hour or whole-GB package rounding is configured in this model.
Railway exposes a GraphQL public API, but this guide does not provide an automatic telemetry export. Your collector must normalize actual resource measurements into the fields above. It must not assume a dashboard or API quantity already uses these units.
Leave
reporting_unit unset for this setup. If you later display GB-hours or vCPU-hours, use a conversion_rate of 3600: displayed quantity is raw seconds-based quantity divided by 3600. This changes reporting only; keep the per-second prices unchanged.
Configure the plan and included usage
1
Create the plan and four charges
Create a plan named Railway Hobby Services. Add a monthly USD fixed charge for
5.00, billed in advance. Link the three metered features and add a monthly usage charge for each at the decimal rates above, billed in arrears.For API configuration, each price uses billing_period: "MONTHLY", billing_period_count: 1, billing_model: "FLAT_FEE", price_unit_type: "FIAT", entity_type: "PLAN" and the plan’s entity_id. Use type: "FIXED" with invoice_cadence: "ADVANCE" for the subscription charge. Use type: "USAGE", invoice_cadence: "ARREAR" and the corresponding feature’s meter_id for each resource price. Amounts are decimal strings and currency is "usd". Publish the plan before attaching the credit grant.2
Restrict the credit wallet to usage
Use a dedicated example customer with a USD prepaid wallet, a credit conversion rate of See wallet credits and wallet payment restrictions for how credits offset eligible charges. Disable auto top-up for this example. Do not load another $5 manually on top of the recurring grant.
1 and no other balance or subscriptions. Confirm that the wallet receiving the grant allows only usage charges. An unrestricted wallet could spend the included credit on the fixed fee and remove the minimum.Update that wallet through PUT /v1/wallets/{id} with:3
Create one recurring grant on the plan
Use The grant is shared across the three resource charges. Do not create one grant per feature or use nonexpiring credits. It offsets up to $5 of eligible usage; it is not a refund of the fixed subscription charge.
POST /v1/creditgrants with the actual plan ID in place of plan_example:4
Subscribe the customer and verify the lifecycle
Subscribe the example customer to the plan in USD with monthly anniversary billing and
billing_period_count: 1. Confirm the initial $5 fixed charge, the monthly grant application and the receiving wallet’s usage-only restriction before ingesting events.At renewal, verify that the expiring cycle’s usage receives only that cycle’s included credit, unused credit does not carry over, and one new $5 grant becomes available for the next cycle. Check both below-minimum and above-minimum usage before using the configuration for production billing. The model does not implement Railway’s resource provisioning limits or access controls.Send usage and check the arithmetic
The following normalized event represents a hypothetical 1,000-second interval with average RAM consumption of 1 GB, average CPU consumption of 0.5 vCPU and 0.02 GB of outbound data:
Use decimal arithmetic to reproduce the calculation without binary floating-point drift:
Pricing sources
Pricing checked on 2026-11-04.- Railway pricing: Hobby’s $5 minimum, included monthly usage and the service RAM, CPU and egress rates used here. Sandbox and VM rates are separate and excluded.
- Railway plans: monthly subscription terms, shared included usage, reset behavior and examples below and above the minimum.
- Understanding your Railway bill: advance subscription billing, arrears overage and application of included usage.
- Railway public API: GraphQL access and authentication reference for building your own collector; it is not an event schema for this guide.
- Railway’s core concepts: application services and deployments supporting the profile’s developer-tools classification.