# Hosting cost estimation improvement suggestions **URL:** \ **Category:** Documentation\ **Created:** [February 26, 2025, 6:39pm UTC](https://forum.communityhealthtoolkit.org/t/hosting-cost-estimation-improvement-suggestions/4694 "2025-02-26T18:39:39Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![elijah](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/elijah/32/95_2.png) [@elijah](https://forum.communityhealthtoolkit.org/u/elijah)\ **Post date:** [February 26, 2025, 6:39pm UTC](https://forum.communityhealthtoolkit.org/t/hosting-cost-estimation-improvement-suggestions/4694/1 "2025-02-26T18:39:40Z")
Hello community! CHT documentation has a very useful guide for [estimating deployment resourcing needs and hosting costs](https://docs.communityhealthtoolkit.org/hosting/costs/). In addition to this, a [total cost of ownership squad](https://forum.communityhealthtoolkit.org/t/hosting-total-cost-of-ownership-squad/4568) has been established to optimize disk space utilization. The question of how much would it cost to run CHT comes up fairly regularly and the hosting cost estimation documentation could be improved by being structured as a calculator over time because project context likely changes as discoveries are made and new goals set. What I’m seeing could be most helpful would be a dynamic page where the input would be initial user count and expected growth rate. Resources required over time for optimal operation would be forecast & displayed on a 2 axis graph together with associated costing for major cloud service providers. The user can experiment with different deployment scenarios for more realistic planning. Please share thoughts on how total cost of ownership documentation can be enhanced. ---
**Author:** ![jkuester](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/jkuester/32/806_2.png) [@jkuester](https://forum.communityhealthtoolkit.org/u/jkuester)\ **Post date:** [February 27, 2025, 8:48pm UTC](https://forum.communityhealthtoolkit.org/t/hosting-cost-estimation-improvement-suggestions/4694/2 "2025-02-27T20:48:58Z")
I like this line of thinking! Hosting costs will always be something of a moving target as costs and the demands of the system will not remain constant. This probably just makes it even more essential that folks have a way to calculate estimated costs with the greatest possible accuracy. One idea that I think would be an incremental improvement over the current docs page you have linked would be just a template Google Sheet that could operationalize the calculations from the docs. The idea would be that anyone could make a copy of the sheet and plug in the estimated numbers for their deployment. Then the sheet could show not only the current cost estimates, but could also be sophisticated enough to allow extrapolating to future costs based on some parameters… ---
**Author:** ![mrjones](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/mrjones/32/681_2.png) [@mrjones](https://forum.communityhealthtoolkit.org/u/mrjones)\ **Post date:** [February 27, 2025, 9:53pm UTC](https://forum.communityhealthtoolkit.org/t/hosting-cost-estimation-improvement-suggestions/4694/3 "2025-02-27T21:53:45Z")
Yes - seconding Josh’s interest in the topic - thanks for raising it Elijah! And for sure it can be a moving target. A big challenge that we’ve faced when trying to offer dynamic calculators is not only [what’s included and what’s not](https://docs.communityhealthtoolkit.org/hosting/costs/#whats-included-in-the-per-user-cost), but even the costs differences between a bare-metal installation and a cloud installation. To that end, maybe you can help us out here with some practical use cases? For example, would it be helpful to have a more detailed/interactive calculator based on current [Amazon Elastic Kubernetes Service](https://aws.amazon.com/eks/) (AWS EKS) and [Amazon Elastic Compute Cloud](https://aws.amazon.com/ec2/) (AWS EC2) pricing? While helpful for planing an AWS cloud deployment, this likely would not be applicable to a bare-metal installs which would require hundreds and likely tens of thousands of dollars ($USD) of hardware capitol purchased upfront. “Upfront Purchase of Hardware” is very much [excluded](https://docs.communityhealthtoolkit.org/hosting/costs/#excluded) today! A more simple solution might be the “[T-Shirt sizes](https://asana.com/resources/t-shirt-sizing)” approach, where we add two more “medium” and “large” pricing tables to the existing “small” size [already published](https://docs.communityhealthtoolkit.org/hosting/costs/#monthly-costs). Maybe this is more impactful in the immediate term? cheers! ---
**Author:** ![jkuester](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/jkuester/32/806_2.png) [@jkuester](https://forum.communityhealthtoolkit.org/u/jkuester)\ **Post date:** [December 20, 2025, 4:27pm UTC](https://forum.communityhealthtoolkit.org/t/hosting-cost-estimation-improvement-suggestions/4694/4 "2025-12-20T16:27:19Z")
@elijah I would appreciate any feedback you have on this Docs PR I am cooking up: > > > \# Description > > This is a little present for @mrjones-plip when he returns from… the holidays! :christmas\_tree: > > \image > > It is a first draft of an interactive Hosting Cost estimation tool (\[forum thread\](https://forum.communityhealthtoolkit.org/t/hosting-cost-estimation-improvement-suggestions/4694)). > > It turns out it is pretty easy to add interactive HTML to your Hugo site via a custom shortcode. And, the modern CSS functionality provide very nice layout and visualization so I did not have to resort to any dependencies. > > I am pretty happy with the features/layout/functionality of the whole thing, but the \_tuning\_ of it could use more eyes. > > One simplification that I have started with (but which could be easily refactored) is that I have only factored in the costs \[of 5 example EC2 instances\](https://github.com/medic/cht-docs/pull/2101/changes#diff-3c24e5eaba03526c09365be6c7c4c9e967f2fbd8e08ff59da4a1f69302fc597fR3) and I try to pick one of those based on load (users \* workflows). This approach has obvious limitations, but it was simple enough to let me get started with real world numbers. Definitely open to suggestions on the best way to improve this. > > The other things that need more tuning are the various constant value that are used in down-stream computations: > > \`\`\`js > DISK\_COST\_PER\_GB: 1, > CONTACTS\_PER\_PLACE: 5, > WORKFLOW\_YEARLY\_DOCS\_PER\_CONTACT: 12, > DOCS\_PER\_GB: 12000, > \`\`\` > > \`DISK\_COST\_PER\_GB\` is a rounded-up estimate from EBS. \`CONTACTS\_PER\_PLACE\` is roughly the "household size", but it gets used to estimate how many ancestor contacts are in the hierarchy tree (given the user input of the population size). Currently the logic assumes a completely even distribution and density of contacts throughout the tree. \`WORKFLOW\_YEARLY\_DOCS\_PER\_CONTACT\` is by far the most hand-wavy. Basically I need some way to connect how many workflows are being supported by the instance with an estimate of how many reports will be generated per year. So, in this case \`12\` means that I think we will have an average of 1 report created per month per workflow per contact. This may be way off. \`DOCS\_PER\_GB\` is a rough estimate that I made based on Watchdog data from a large production instance. > > Most of this code was written (or heavily influenced) by Claude, but I have carefully reviewed and edited it for maximum maintainability. > > \# License > > The software is provided under AGPL-3.0. Contributions to this project are accepted under the same license. Like I note in the PR description, the parameters/algorithms need more tuning so any thoughts you have there are most welcome as well as ideas on any key metrics that I may have missed. 👍 ---
**Author:** ![Prajwol](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/prajwol/32/1328_2.png) [@Prajwol](https://forum.communityhealthtoolkit.org/u/Prajwol)\ **Post date:** [December 30, 2025, 10:54am UTC](https://forum.communityhealthtoolkit.org/t/hosting-cost-estimation-improvement-suggestions/4694/5 "2025-12-30T10:54:56Z")
@jkuester First, thank you, this is a much requested and valuable feature! The idea of having a dynamic hosting cost calculator for CHT deployments would be extremely helpful. I’m curious: when building the hosting cost estimation or total cost of ownership guidance, **are actual production metrics** [from Watchdog](https://watchdog.app.medicmobile.org/d/3J_78b6Zz/cht-api-server?var-interval=10m&orgId=1&from=now-3h&to=now&timezone=utc&var-cht_instance=panchthar-ne.app.medicmobile.org&refresh=5s) **such as CPU, RAM, and disk usage, taken into account**? Or is the guidance based purely on model assumptions and projected user/device counts? It would be great to know whether live operational data is being leveraged to make these forecasts more accurate, and if not, whether integrating it is being considered ---
**Author:** ![jkuester](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/jkuester/32/806_2.png) [@jkuester](https://forum.communityhealthtoolkit.org/u/jkuester)\ **Post date:** [January 5, 2026, 3:24pm UTC](https://forum.communityhealthtoolkit.org/t/hosting-cost-estimation-improvement-suggestions/4694/6 "2026-01-05T15:24:35Z")
I think the short answer is, yes. Even this first iteration of the calculator is based on data collected from production instances. _However_, it is important to note that the current algorithm is _extremely primitive_ (mostly for the sake of starting simple and then layering on complexity as necessary). For example, the server costs are being scoped to 1 out of 5 different EC2 instance configurations. The actual production costs for that EC2 instance are included, but there are many other EC2 configurations that _could_ be used instead. I think it should be pretty feasible to get accurate numbers for things like hosting cost per CPU/RAM/Disk as well as for things like docs-per-GB of disk space. However, precision is going to be harder for things like projecting the doc growth rate. Currently I am approximating a number based on the number of workflows implemented and the number of contacts in the instance. But perhaps there is a better way? So, yeah, the main goal here is to leverage the data we have about productions instances into the most accurate estimation of the TCO for instances with various properties. But, some level of abstraction, approximation is always going to be required. My hope is that we can continue to evaluate and refine the algorithm and “test” it against known production instances to gain confidence in the accuracy of the estimation. ---
**Author:** ![mrjones](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/mrjones/32/681_2.png) [@mrjones](https://forum.communityhealthtoolkit.org/u/mrjones)\ **Post date:** [January 8, 2026, 1:30am UTC](https://forum.communityhealthtoolkit.org/t/hosting-cost-estimation-improvement-suggestions/4694/7 "2026-01-08T01:30:14Z")
@jkuester - I just spent a [BUNCH](https://github.com/medic/cht-docs/pull/2101#pullrequestreview-3637350446) of time playing with this and it’s just amazing - thank you! To try and increase the community awareness and spread my excitement, I made a short video clip of how it’s working in you first generation. While the numbers may not be correct, I hope seeing it live in action will solicit more questions and discussion! ---
**Author:** ![scott\_213](https://communityhealthtoolkit.b-cdn.net/letter_avatar_proxy/v4/letter/s/c6cbf5/32.png) [@scott\_213](https://forum.communityhealthtoolkit.org/u/scott_213)\ **Post date:** [January 19, 2026, 10:30am UTC](https://forum.communityhealthtoolkit.org/t/hosting-cost-estimation-improvement-suggestions/4694/8 "2026-01-19T10:30:34Z")
Scope creep is the challenging aspect, not the math. The best course of action for estimating hosting costs is to map actual production metrics (cpu, RAM, and disk) to a limited, subjective range of AWS EC2 sizes. The calculator becomes useless once you attempt to cover every potential configuration. Although document growth will always be ambiguous, it is acceptable to tie it to contacts and workflows as a starting point. Simply state that it is an estimate and not a guarantee. I would completely exclude bare-metal from the dynamic calculator. distinct economics and audiences. A dynamic AWS calculator combined with a basic t-shirt sizing chart for bare metal is much more understandable and useful. ---
**Author:** ![mrjones](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/mrjones/32/681_2.png) [@mrjones](https://forum.communityhealthtoolkit.org/u/mrjones)\ **Post date:** [May 21, 2026, 10:00pm UTC](https://forum.communityhealthtoolkit.org/t/hosting-cost-estimation-improvement-suggestions/4694/9 "2026-05-21T22:00:08Z")
Circling back to this thread - we’ve launched this tool and [published a short video](https://forum.communityhealthtoolkit.org/t/launch-of-interactive-cht-hosting-cost-calculator/5618) about it!