FOTOhub completes its consolidation on AWS and opens hourly CPU and GPU capacity to customers

Category: Partnership / Infrastructure / Technology

Date: August 1, 2026

Author: FOTOhub Press Team, FOTOhub.app

Tags: AWS, Amazon Web Services, cloud infrastructure, GPU, multi-region, object storage, brand AI training, agents, developer platform

Summary

FOTOhub has completed the strategic consolidation of its entire production platform on Amazon Web Services and is now a member of the AWS Startup Portfolio Tier, backed by a paid AWS Business Support agreement. The programme that began as an infrastructure migration has ended as something considerably more ambitious: the same substrate that runs FOTOhub is now a product in its own right. Through the platform console, companies, creative professionals and individual developers can rent CPU and GPU capacity by the hour, provision their own object storage in a chosen region, orchestrate durable multi step agent workflows, and, in the rollout now beginning, train brand specific AI models on their own material. FOTOhub today operates across five AWS regions on three continents, serves a catalogue of more than one hundred production AI models through a single credit balance, and exposes the whole surface through a documented REST API, official SDKs and a machine callable tool layer.

Why a single cloud was the only defensible answer

For most of its history FOTOhub ran on two clouds. That arrangement is common among fast growing AI companies and it is almost always the result of history rather than design: capacity is taken wherever it is available at the moment a workload becomes urgent. It works until the company reaches the scale at which two of everything becomes the dominant operational cost.

Two clouds meant two contracts, two billing models that could not be compared line by line, two identity and permission systems, two sets of network assumptions and two answers to the single question that every serious enterprise customer asks before signing: where exactly does our data live. None of those were catastrophic in isolation. Together they were a tax on every engineering decision and a drag on every procurement conversation.

The decision to consolidate on AWS was therefore not primarily a decision about technology quality. It was a decision about clarity. One cloud means one cost model that can be forecast, one security boundary that can be audited, one set of regional guarantees that can be written into a contract, and one platform whose managed services the engineering team can adopt deeply instead of using at the lowest common denominator of two providers.

That last point turned out to matter most. Once the platform stopped hedging across providers, it became rational to build directly on the managed layers AWS offers rather than reimplementing them. That is the difference between hosting on a cloud and being integrated with one, and it is the difference that produced the products described below.

Stage one: consolidation and the exit from the second environment

The migration was deliberately structured as a staged programme rather than a cutover, and it was never treated as a copy operation. A meaningful share of the services were rewritten rather than moved, because lifting a workload that was designed around one provider's primitives onto another provider's primitives reproduces the original compromises and inherits none of the benefits.

Work proceeded service by service, in dependency order, with the older environment kept live behind each cutover until the replacement had carried real production traffic. Media processing, generation queues, the billing core, authentication, storage and the inference tier each moved on their own schedule. The final compute node left the legacy environment in the second half of 2026, at which point the second cloud was decommissioned rather than left idle, closing both the cost and the security surface associated with a parallel estate.

The engineering conclusion from this stage is unglamorous and worth stating plainly, because it is the part most migration announcements omit: the difficulty of a cloud migration is almost never the compute. It is the identity model, the storage semantics and the accumulated assumptions about latency between components that were originally colocated.

Stage two: a multi region footprint and honest data residency

FOTOhub production workloads now run in five AWS regions across three continents, with the European Union as the default home for customer data and the primary region in Frankfurt. Ireland and Stockholm carry additional European capacity, while North American and Asian regions host latency sensitive inference and edge workloads that serve those markets directly.

This is the part of the programme with the clearest commercial consequence. Region choice is now an explicit, contractible property of a customer workload rather than an implementation detail. A European retailer processing an entire product catalogue can be told which region holds the source imagery, the derived assets and the audit trail. A studio serving the Japanese market can have its inference served from a region on the same continent as its audience instead of paying a transpacific round trip on every request.

Object storage follows the same principle. Customer buckets are provisioned in a named region, replication is a configured behaviour rather than an accident, and access logging and account level audit trails are written to dedicated log destinations from the moment a bucket exists. Content distribution runs through a global edge network in front of that storage, so a regionally pinned bucket does not become a performance penalty for a worldwide audience.

FOTOhub states one caveat openly, because the alternative is a promise that operations cannot keep. When a requested capacity class is genuinely unavailable in a customer's preferred region, the platform will surface that condition rather than silently satisfying it elsewhere, and workloads with strict residency requirements should be pinned explicitly at provisioning time.

Stage three: managed model serving as a first class layer

With the estate consolidated, FOTOhub adopted Amazon Bedrock as a primary managed serving layer alongside its own inference tier. In the European primary region alone this makes several dozen foundation models reachable through one governed interface, with no per model provisioning work, no separate contract for each vendor and no additional key material to distribute across services.

The practical effect on the product catalogue is that model breadth is no longer gated by integration effort. FOTOhub currently maintains a catalogue of one hundred and sixty three models of which more than one hundred and ten are enabled for production use, spanning image generation, video, conversational text, three dimensional asset generation, transcription and speech synthesis. Every one of them is billed from a single credit balance regardless of which underlying provider or serving layer ultimately executes the request, which means a customer changing model does not change contract, invoice format or integration code.

Alongside the managed layer, FOTOhub continues to run its own inference on dedicated accelerated capacity for the proprietary IDA model family, where controlling the serving stack is the point rather than an overhead. Managed serving for breadth, self operated serving for the models that are ours: the consolidation is what made it affordable to do both well.

The same account also hosts the training infrastructure for FOTOhub's own audio and voice models, with dedicated training data stores and managed machine learning tooling. That capability is not theoretical or forward looking. It has already produced models that are in production today, and it is the direct technical foundation for the brand training rollout described below.

Stage four: opening the substrate to customers

The most consequential outcome of the migration is that FOTOhub no longer treats its compute layer as an internal concern. In the platform console, customers can now provision and manage their own infrastructure directly, billed by the hour, inside the same account structure, the same billing surface and the same credential model as the rest of the platform.

The rentable catalogue currently offers seventeen CPU classes and five GPU classes, ranging from small burstable instances suitable for a scheduled script to substantial multi core machines and accelerated instances sized for model inference and fine tuning. Rates are quoted per hour with no metered egress charge, capacity can be requested at interruptible pricing at roughly sixty percent below on demand rates for workloads that tolerate reclamation, and an idle instance is stopped automatically rather than quietly accruing cost until someone notices.

Provisioning, lifecycle, monitoring and teardown are handled through the console and the API, with disk sizing, operating system image and startup configuration exposed as ordinary parameters. Object storage is managed with comparable depth: fourteen dedicated administrative surfaces cover permissions and policy, access keys, lifecycle transitions between storage classes, replication, access points, event notifications, metrics, content distribution and static site delivery, backed by more than eighty storage specific API operations. Storage is priced from the underlying AWS price list rather than an invented markup schedule, and both hot and infrequent access classes are available.

This is the point at which FOTOhub's offer changes category. A customer no longer has to choose between using a creative AI platform and having real infrastructure. The generation catalogue, the workflow engine, the storage layer and the rented compute sit behind one login, one balance and one API, and the boundary between them is a design choice rather than a procurement obstacle.

Brand model training enters rollout

FOTOhub's brand system already ships and is already the mechanism by which the platform produces on brand output at scale. A brand in FOTOhub is a structured entity rather than a style note: dedicated data domains hold approved faces, logos, typography, products, materials, style presets, written guidelines and mood boards, with collaborator roles, row level access control and a database level audit trail on every change. That structure is read directly by the generation and video pipelines, which is why brand consistency currently works without any model customisation at all.

The rollout now beginning extends that from guided generation to genuine model adaptation. The training engine is built around established parameter efficient adaptation techniques across multiple modalities, with dataset sizing appropriate to real brand libraries rather than research benchmarks, interruptible training capacity with checkpoint resumption so that a long job survives reclamation, configurable retention windows and full audit logging of every job. Trained adapters are intended to be selectable in the same generation surfaces customers already use.

FOTOhub is describing this as a rollout rather than a general release, and deliberately so. The infrastructure, the schema, the training code and the accelerated capacity are in place, and the company's own audio models were trained on exactly this foundation. Customer facing brand training is being brought up in stages with early access accounts first, and FOTOhub will announce general availability when the end to end path, including dataset intake and adapter serving, has been validated with real customer libraries rather than internal ones. Announcing the capability at rollout and the availability date separately is the more useful thing to do for teams planning their own roadmaps around it.

Durable orchestration and the agent layer

The fourth pillar of the expanded offer is orchestration. FOTOhub operates a workflow engine built on durable execution rather than on best effort scripting, which is the distinction that determines whether an automation can be trusted with a production catalogue. Work is checkpointed, retried on defined policies, resumable after infrastructure interruption, invocable on a schedule and able to signal completion through authenticated webhooks.

The node library available to that engine currently spans one hundred and sixty node types across fifteen categories, with several dozen prebuilt templates covering common creative and commerce operations. Roughly two thirds of the node types carry no incremental generation cost, because they perform control flow, transformation and data handling rather than inference. A representative workload looks like this: watch a product feed, generate a packshot set and a short form video per new item, apply the brand entity, write the outputs to a customer owned bucket in a named region, and call back a store backend when the batch completes, with every step individually retryable.

FOTOhub is characterising the engine and the node library as production capability, and the breadth of third party account connections as phased. Connector availability is being enabled progressively rather than declared complete, and the company would rather list a connector on the day a customer can authenticate against it than on the day the node exists in the library.

What the expanded offer means for each audience

For companies, the proposition is that catalogue scale creative production and the infrastructure it runs on can now come from one supplier, under one agreement, with a stated region for every artefact and an audit trail that exists by default rather than on request. Procurement complexity, not model quality, is the usual blocker on this class of project, and consolidation is what removes it.

For creative professionals and studios, the value is elasticity without operational overhead. A campaign that needs accelerated capacity for four days does not require an infrastructure hire, a separate cloud account or a monthly commitment. It requires an hourly instance that stops when the campaign does, next to the model catalogue and brand system that the studio already uses daily.

For individual developers, FOTOhub is deliberately positioning itself as a platform to build on rather than a tool to use. The surface is two hundred and sixty seven documented REST endpoints across the platform's modules, official Python and TypeScript SDKs published to public registries, a command line client, and a machine callable tool layer exposing thirty platform operations so that an AI assistant can drive the platform directly. Every one of those paths bills from the same balance and authenticates with the same key material as the console, and the free tier is entitled to provision from the same infrastructure catalogue as everyone else.

The relationship with AWS

FOTOhub participates in the AWS Startup Portfolio Tier and holds a paid AWS Business Support agreement. The support agreement is the less glamorous half of that sentence and the more important one operationally: it means defined response times and access to AWS engineers during an incident, on a platform where customers process entire product catalogues and cannot be told to wait for a forum reply. A company at this stage of growth should not have a single person support function standing between a customer's production deadline and a cloud provider.

Membership of the Portfolio Tier reflects a technical relationship rather than a purely commercial one, and the specific commercial terms of the arrangement are not disclosed. What is disclosable, and what matters to customers evaluating FOTOhub, is the architectural consequence: the platform is built on the provider's managed services rather than merely hosted on its servers, and the roadmap is now planned against one provider's capability curve instead of the intersection of two.

"Consolidating on AWS was framed internally as a cost and clarity project. It finished as a product strategy. Once the whole platform sat on one substrate that we understood end to end, there was no longer a good reason to keep that substrate to ourselves. Our customers get the same compute, the same storage and the same regional guarantees we run on, billed by the hour, next to the models and the brand system they already use." FOTOhub Press Team

Reliability, governance and what FOTOhub is not claiming

The platform maintains automated model health tracking that disables an upstream model that begins failing rather than passing errors to customers, per operation usage and cost accounting, account level audit trails, row level access control on customer data, and a public status surface with body level assertions on its checks rather than simple reachability pings.

FOTOhub also wants to be precise about the boundaries of this announcement, because infrastructure announcements are where overstatement is most costly. The company is not announcing a formal security certification, and does not claim one. It is not claiming that every third party connector in the workflow library is connectable today. It is not claiming general availability of customer brand model training, which is entering staged rollout. And it is not publishing specific hardware model names or per instance capacity commitments in a press release, because those change on a shorter cycle than a press release lives and the console catalogue is the authoritative answer at any given moment.

What comes next

Three lines of work follow directly from this programme. The first is depth in the rented infrastructure layer, extending the catalogue and the automation around it so that provisioning a workload for a creative pipeline requires no more infrastructure knowledge than choosing a model does. The second is completing the brand training path to general availability, with dataset intake and trained adapter serving finished end to end. The third is widening authenticated connector coverage in the orchestration layer, announced connector by connector as each becomes usable.

The through line is the same one that motivated the migration. FOTOhub is building a platform where creative generation, the brand knowledge that makes generation usable commercially, the automation that makes it repeatable and the infrastructure it all runs on are one system with one bill, in a region the customer chose. Consolidating on AWS was the precondition for that. Opening it to customers is the point.

About FOTOhub. FOTOhub is a creative AI platform combining a multi provider model catalogue across image, video, audio, text and three dimensional generation with a brand system, a durable workflow engine, object storage and hourly infrastructure, exposed through a documented API, official SDKs and a machine callable tool layer.

Press contact. FOTOhub Press Team, FOTOhub.app

Technical detail: API documentation · model catalogue · infrastructure console · brand and training