WebinOne and AWS: what runs where, and whose account it runs in

WebinOne is an AWS-native digital experience platform built by Upgrade Parade Corp, formerly Treepl CMS, delivered white-label by agencies and systems integrators. For most readers "AWS-native" is a hosting detail two levels below anything they care about. For a firm whose own product is AWS delivery, it is either common ground or a claim to test, and the entire difference is in the specifics.

So this page is the specifics: what the platform runs on, whose account it runs in, what a dedicated deployment is actually made of, what your client can see, and what your practice stops doing if you deliver on it. Where a fact is ours rather than independently verifiable, it is labelled as ours.

Whose AWS account does WebinOne run in?

Ours, today. Production sites run in the platform's own AWS account, operated by the platform team, and that is the arrangement every partner is delivering on right now.

That is stated as a fact rather than a policy, because the follow-up has a real answer. A different arrangement is available by agreement: a custom licensing and setup quote, priced deal by deal. What it is not is a switch, and it is not a shipped capability you can plan a bid around from reading this page. If your practice needs the platform running inside an account you hold, raise it in the first commercial conversation and get it quoted — treat it as a deal term, because that is what it is. An integrator can work with a clear boundary. What nobody can work with is an evasive one, which is why the default is written here in one sentence instead of being left to inference.

Where does the responsibility boundary fall between the platform team and your practice?

Higher up than you are probably used to. The platform team operates the AWS account, the compute, the platform runtime, patching, backups and monitoring; your practice operates everything from the content model upward — the front end, integrations, custom services alongside the platform, and the client relationship.

You already know the shared responsibility model, so the only useful thing to add is where our line sits inside it. We are not handing you infrastructure to run, we are handing you a running platform, and that is a smaller surface than a managed-service engagement and a larger one than a SaaS subscription. Two places are worth testing early rather than late. The first is the API surface: it is extended when a delivery needs something it does not yet cover, and that happens regularly, but as scoped and quoted project work on our schedule rather than as something your engineers unblock themselves. The second is tooling — whatever your practice standardises on for monitoring, deployment or infrastructure-as-code cannot be pointed at an account you do not hold. Neither is a surprise if you know it in week one. Both are expensive to find in week nine.

Where can a client's data sit?

On AWS, across six AWS regions, with data residency options for compliance requirements. Which location a specific client's site runs in, and what residency options apply to it, is confirmed in the technical assessment.

If a client's requirement falls outside the current footprint, an additional AWS region can be stood up on request. The platform team's own account of the effort is hours of provisioning work rather than a procurement cycle, and that is our figure rather than an audited one, so ask for it against your specific case. What it tells you reliably is the shape of the answer: "can you run this client in region X" is a scoping question here, not a roadmap question, and that is a direct consequence of the footprint being built on AWS rather than on our own metal.

What can you and your client actually see?

Live AWS charts, pulled from AWS and rendered inside the site's own admin panel — visible to your client, not only to you. On a dedicated deployment the site owner can watch server load in real time during a campaign and see how the capacity they are paying for is being consumed.

This leads the inventory rather than trailing it, because it is precisely what an integrator reselling infrastructure needs: a client who can see their own load does not need you to defend the invoice, and the same charts are the input for sizing the next campaign rather than guessing at it. Full load visibility for planning the next configuration is stated as one of the purposes of the feature on our own dedicated servers page. Automated site monitoring, storage backup, a CDN and load testing before go-live are included on every dedicated package alongside it.

What does a dedicated deployment actually consist of?

A dedicated base server running the site 24/7, sized in cores and RAM, with a dedicated IP, and optionally a dedicated RDS instance instead of shared database capacity. Extra bandwidth and extra storage are discrete line items, and the option is available to Partners and Partner Agencies only.

Above one server it becomes a load-balancing pair, or a web farm of three or more servers running synchronised copies of the same site, with admin and content management continuing to operate normally against it. One element there is a prerequisite rather than a feature, and it is the single item on this page an AWS reader is most likely to guess wrong: load balancing across a two-or-more-server configuration runs through a Cloudflare integration, and we require the partner to hold the Cloudflare account. Cloudflare is recommended for any high-traffic site and required at two servers and above. If you were about to assume an AWS load balancer, correct that assumption before you architect around it — and note what it means operationally, that the account, the billing and an administrator for that layer are yours.

Two more boundaries are better had before a technical assessment than after it. A dedicated deployment is scoped to one site; running more than one site on it is treated as a custom setup and priced as one. And RDS is the only AWS managed service we name publicly as part of the stack, which is a deliberate limit on this page rather than an accident — where you need a specific service inventory for an architecture or security review, ask for it in the assessment instead of inferring it, including from here.

How is capacity handled for a known traffic peak?

Extra servers are scheduled from a calendar inside the site admin and billed by the hour, by whoever holds the site — you, or your client directly. The mechanism is built for known peaks: a broadcast slot, a launch, a seasonal spike.

The pattern our own page documents is a modestly sized base server running around the clock, with a larger extra server enabled for a few hours around an advertising slot and disabling itself automatically afterwards. What earns this a section in an architecture piece is that it is self-service and reversible: when the ad time moves, the site owner changes the schedule in the admin panel, with no ticket to us and no deployment. If your practice currently builds burst capacity per client, that requirement is already met at the platform layer, and the hours nobody bills for it are the ones you were spending on it.

How fast is provisioning, and what does it require from you?

Within one business day, with no sales or technical interview to get started. What it requires from you is a partner or partner agency account and a chosen configuration.

The reason to state it is what it implies about the cost of evaluating us. You can put a real workload on a dedicated deployment inside a week, on one real client, without a procurement process — and a real workload is the only thing that settles the questions on this page. It also gives you something to hold us to: if provisioning your first deployment takes materially longer than that, it is a deviation from what we publish, and worth saying so.

Where does this fit against an integrator's existing AWS practice?

For a firm whose product is operating infrastructure, a platform that operates the infrastructure for them is a trade, not a gift. You stop running the stack: no instance to size after the first configuration, no patching rota, no on-call for the platform layer, no account of your own in the path — and if managed hosting is a billed line on your client contracts, that line goes away.

What is left is everything else, and for most firms it is the larger half. You keep the client contract and your own pricing under the partner programme, the build, the content model, the integrations, the custom services that talk to the platform over its API, and the ongoing account. The margin moves out of operations and into delivery. Whether that trade is a good one depends on something we cannot tell you: what share of your revenue the operations contract is, and whether it is the thing you compete on. If it is, this platform costs you a revenue line and a differentiator, and that case is set out in full, unhedged, on our page about where WebinOne is the wrong choice. If your operations work is overhead you carry in order to win the build, the trade runs the other way.

What this page does not answer

Certification posture and contractual terms, deliberately. Which formal certifications the platform does and does not hold is stated plainly in our article on what an integrator needs from a platform before migrating a client off a legacy DXP, and commitments about uptime, notice periods and data ownership belong in a contract and a security review rather than in an architecture description.

One measurement, since it is usually asked here: availability across the last twelve months was 99.99%. That is a historical figure quoted as a fact, not a service commitment, and the commercial terms are their own document and their own conversation. The rest of the platform briefing — what it is, who builds it, what it replaces, who already runs on it — is in the systems integrator briefing, and named deployments an architect can open and inspect are collected on the enterprise page. The fastest route to answers specific to your own estate is a technical assessment against one real client rather than a demo.