The Monthly Bill for Running Your Own Stack

The monthly bill for a self-hosted automation stack contains seven recurring lines: chain access, compute, storage, monitoring and alerting, secrets handling, a staging copy, and labour. Six of them arrive as invoices. The seventh is your own time, is usually the largest, and never appears on a statement. This page is the blank sheet for all seven.

There are no prices here on purpose. Plan names and rates change faster than any page can track, and a figure copied from somebody else describes their request pattern rather than yours. What is durable is the structure: which unit each line is charged in, and which of your behaviours drives the quantity.

The floor of a quiet month

Start with the number that matters most and gets calculated least: what the stack costs in a month where nothing happened. No trades, no incidents, no changes, nobody logging in. That figure is the floor, and it is the number any hosted alternative has to beat before capability is even discussed.

The floor is high in a way that surprises people, because most of the bill is availability rather than usage. A host charges for existing, an endpoint plan charges for the allowance whether or not you consume it, monitoring charges for watching, and the staging copy charges for being ready. Only a minority of a small stack scales with activity at all.

The blank cost sheet

Copy this table and fill the last column from your own invoices. Where a line is genuinely shared with another system, enter the marginal cost of adding this workload rather than the whole charge, and note in the row that it is a share.

Chain access, and how it is charged

Chain access is the line most likely to be mispriced at the start, because development traffic looks nothing like production traffic. A developer testing by hand makes a handful of requests. An unattended process polling for state, submitting, confirming and retrying makes a continuous stream, and the stream is spikiest exactly when activity is highest.

Providers meter on some combination of monthly allowance, per-request or per-credit charges above it, and a rate limit expressed per second. The two numbers behave differently: the allowance governs your invoice and the rate limit governs whether the system works. A plan that comfortably covers your monthly total can still throttle you during the busy ten minutes that mattered, which reads as a strategy failure rather than as a billing one.

Estimating your quantity means estimating a request pattern rather than a request count. Count the calls in one complete cycle of what your process does, multiply by cycles per hour, and then multiply again by every wallet or venue you intend to run in parallel. The public Solana documentation is the reference for which methods your flow actually needs, and the count is usually higher than the intuition.

Compute that has to stay up

Something must run continuously, and continuous is the expensive word. A process that runs for ten minutes a day still needs a host that exists for the other twenty-three hours and fifty minutes, unless you have deliberately built it to be started and stopped, which is itself engineering work with a cost.

Count processes rather than machines. A worker, a scheduler, somewhere to keep state, and a staging copy is four things even if they share one host, and they will not share one host for long once any of them needs to be restarted independently. Each addition is individually defensible and collectively becomes a bill.

Location is a cost lever with an operational tail. Placing compute closer to the infrastructure it talks to is a real technique, and it is also a commitment to a specific provider and region that becomes awkward to reverse. Treat it as an optimisation to make once you have measured a problem, not as a starting configuration.

Storage, retention and the log bill

Log costs behave counter-intuitively. They are trivial while the system is quiet and grow fastest during exactly the periods when the logs are most valuable, because a busy hour produces both the most data and the most questions. Anyone who has reduced verbosity to control a bill has discovered this in the wrong order.

Retention is the lever you actually control. Decide how far back you need to be able to answer a question, and be honest that the answer is usually weeks rather than months for operational debugging, while the small subset you need for records is much smaller and can be stored differently. Splitting the two is the single most effective way to keep this line flat.

Monitoring, alerting and paging

Monitoring is charged in series, hosts or seats depending on the vendor, and it is the line teams most often skip at the start and add after the first outage they discovered by accident. Adding it later is more expensive than including it, because the instrumentation has to be retrofitted into code that was written without it.

Alerting has a separate charge and a separate failure mode. Notifications that arrive somewhere nobody watches are a cost with no benefit, and the path from a failure to a human has to be tested deliberately, occasionally, forever. That test is labour rather than invoice, and it belongs in the hours column.

Secrets, staging and the small subscriptions

Credentials have to live somewhere with access control, and the somewhere is either a service with a charge or a homemade arrangement with an ownership cost. Both are real; only one of them appears on the bill, which is why the homemade option keeps winning comparisons it should not win.

Staging is the line most often deleted to save money and most often regretted. Its whole purpose is to make a change survivable, and its cost should be measured against one bad deployment against live funds rather than against its monthly charge. Keep it small, keep it real, and keep it in use.

Then there is the tail: a domain, certificates where they are not free, an error tracker, a status page, a scheduler, a repository plan, a seat somebody added for a contractor two months ago. Individually negligible, collectively a line item, and nobody owns cancelling them. Auditing this tail quarterly is the cheapest saving available on the whole sheet.

On-chain fees are a separate sheet

Network fees do not belong in the recurring bill, because they scale with activity while the rest of the sheet arrives regardless. Keep them separate so the infrastructure floor stays comparable across months. They are still worth understanding, because the arithmetic is deterministic and often mis-modelled.

Solana charges a base fee per signature, currently 5,000 lamports, and an optional priority fee equal to the compute unit price multiplied by the compute unit limit. The price is quoted in micro-lamports per compute unit, so a limit of 200,000 units at a price of 20,000 micro-lamports is 4,000,000,000 micro-lamports, which is 4,000 lamports, giving 9,000 lamports in total for a single-signature transaction. That is 0.000009 SOL, and the figures here are illustrative inputs rather than a recommendation about what to set.

Separately, creating a token account that does not yet exist requires a rent-exempt deposit, which at current rent parameters is roughly 0.00204 SOL for a standard token account and is recoverable if the account is later closed. Fees are not recoverable; deposits are. Anyone modelling campaign cost should treat those two categories differently, and the account model behind the distinction is described in the Solana program documentation.

The labour line

The labour line is the difference between a sheet that informs a decision and a sheet that flatters one. Everything in the ownership matrix consumes hours: capacity checks, patching, upgrades, alert tuning, incident response and the records. If those hours are entered as zero, the sheet has already decided in favour of building before any comparison happens.

Use a rate you would defend out loud, apply it consistently to both sides of the comparison, and track actual hours for two or three months to replace the estimate. If you would like the sheet to be conservative, use a lower rate rather than fewer hours, because the hours are observable and the rate is a judgement.

A quiet month and a busy month

This is illustrative arithmetic with placeholder inputs. Substitute your own before drawing any conclusion; the purpose is to show the shape of the gap between the two months rather than to suggest any amount.

Carry both totals into any build-versus-buy comparison, not an average of them. The quiet total tells you the floor you are committed to; the busy total tells you what a real campaign month costs. Comparing a hosted charge against the quiet total alone is the mirror image of the mistake this whole page is about, and knowing what a volume bot costs on the rented side is what makes the comparison symmetrical.

Filling the sheet in one sitting

An hour is enough for a first pass. Precision arrives on the second pass, once a real invoice exists to check the guesses against.

1. Export the last three invoices from every provider. Including the ones inherited from an earlier project, because unowned charges are the most persistent kind.
2. Map each charge to a line on the sheet. Anything that does not map is either a line you forgot or a subscription nobody needs; both are useful findings.
3. Mark shared items and enter only the marginal cost. Note the basis of the share in the row so the next person can check it.
4. Pick a quiet month and a busy month. Fill the sheet twice using actual figures from each, rather than averaging.
5. Add the labour line at a written rate. Use tracked hours if you have them and an honest estimate if you do not, marked as an estimate.
6. Total both columns and date the sheet. An undated cost sheet gets reused long after it stopped being true.

Where the bill jumps rather than grows

Recurring costs are usually modelled as smooth and are usually stepped. The steps are predictable enough to plan for, which is the main reason to know where they are before you hit them rather than after.

The common ones: crossing an endpoint allowance into overage or the next tier, adding a fallback provider because the primary became a single point of failure, splitting one host into several because restarts started interfering with each other, extending log retention after an incident you could not reconstruct, and adding a second person to the paging rotation. Each is a step change rather than an increment.

What falls off the bill when you rent

The honest version of this section says what does not fall off as well. Renting removes the infrastructure lines and most of the labour attached to them: endpoint capacity, hosts, log storage, metrics, the staging copy, dependency upgrades and overnight operation. That is the majority of the sheet above.

What remains is a residual attention cost that is real and should be entered rather than zeroed: watching what the tool is doing, checking results against expectations, and handling the parts you still fund. Anyone moving from a self-built stack to Solana volume automation that somebody else operates should keep a line for that residual, because pricing it at zero is the same error in the opposite direction and produces the same unreliable verdict.

Questions this sheet gets asked