← All insightsCloud economics

Running in your own cloud account: why there is no hosting markup

redfly runs inside the customer's own cloud account by preference. That means no resold compute, no lost cloud discounts, and data that never leaves your own boundary.

4 min read

Much of the software that runs alongside your database is sold with the hosting folded into the price. The vendor rents the machines, marks them up, and charges you a bundle. It is convenient, and it hides two costs: the markup itself, and the fact that your data is now sitting in somebody else's account.

redfly can be run three ways: inside your own cloud account, fully managed by redfly in redfly's cloud, or on your own servers onsite. We prefer the first, and this article is about why that choice matters to the person who signs the cloud bill.

Three ways to run it

  • In your own cloud account. redfly deploys into a subscription you already own. The memory cache, the sync service and the API run on your compute, next to your database. This is the preferred option.
  • Fully managed by redfly. We run it in our cloud and you point your application at it. Available for teams that would rather not operate any of it.
  • Onsite. The same software on your own hardware, for databases that are not in the cloud at all.

The subscription covers the software, support, improvements and the architecture review, with a minimum twelve-month term. It is not per seat and not per request. What changes between the three options is who pays for the machines, and to whom.

No resale of compute

When redfly runs in your account, we do not buy compute and sell it back to you. The cache and the services consume your cloud resources at your rates, and the charges show up on your own bill as ordinary line items. There is nothing in our price for hosting, because we are not hosting anything.

This is worth stating plainly because it changes how the saving is measured. During the architecture review we size the footprint redfly will need in your account, and the savings we quote are already net of it. The comparison is your database line before, against your database line plus the redfly footprint after, on the same bill, at the same rates.

There is no hosting markup in the price because there is no hosting in the price.

You keep your discounts

Cloud accounts of any size carry negotiated terms: committed-spend discounts, reserved capacity, enterprise agreements, credits. Every one of those was earned by your finance team, and none of them apply the moment a vendor hosts a workload for you, because the workload is now on the vendor's terms rather than yours.

Running in your own account keeps all of it. The memory cache is compute you already get at a discount. If you have committed spend to use up, redfly's footprint counts toward it. If your rates fall next year, the footprint gets cheaper with them.

Your data stays in your boundary

The second thing a hosted bundle hides is where the rows go. If a vendor runs the cache, a copy of your data lives in the vendor's account, behind the vendor's access controls, subject to the vendor's security review rather than yours.

In your own account, the rows never leave your boundary. The cache sits next to the database, inside the same network and the same identity controls your security team already manages. The sync service connects with the credentials you provide and touches only what those credentials permit. A security review of redfly becomes a review of software you run, not of a third party that holds your data.

No dependency on proprietary services

There is a quieter cost in cloud economics: the one you pay when you cannot leave. Software built on one vendor's proprietary services (the managed products that exist on that cloud and nowhere else) is cheap to adopt and expensive to move. The industry's standard advice to companies that lifted their systems into the cloud, to rebuild everything cloud-native, ends in exactly that position.

redfly does not depend on any cloud vendor's proprietary services. It runs on a database, a memory cache and ordinary compute, which every cloud provides. We prefer Azure, and SQL Server on Azure is where onboarding is fastest, but any cloud works, and so does a server room. The same deployment can move if your terms change, which is itself a negotiating position worth having.

What this means for the bill

Taken together, the shape is simple. One flat subscription for the software and the people behind it. A small footprint in your own account, at your own rates, sized in advance and already deducted from the savings we quote. No second bill from a hosting vendor, no rows outside your boundary, and no architecture that works on one cloud alone.

The database line, the largest on the bill, comes down because reads are served from memory. Everything around it stays where it was: your account, your discounts, your data, your choice of cloud.

redfly fits here as software you run rather than a service you rent hosting from: a cache kept in sync with your database, in your account, with the database still the source of truth.

Ready when you are

Stop reading. Start shipping.

Work with us as a design partner and see the difference on your own database.

redfly API + Sync Service · Licensed directly from redfly