A cloud native platform offering comprehensive control and automation of all HPC tasks via CLI and a user-friendly GUI for designing, editing, and executing HPC jobs. Human-readable, portable workflow files that execute anywhere. Streamlined R&D for HPC & AI Research.
CIQ Fuzzball is a container-first performance intensive computing platform that accelerates innovation by reducing the burdens of workflow development, infrastructure provisioning and management of clustered jobs, even across hybrid environments.
Fuzzball modernizes traditional HPC with an API-first, container-optimized architecture. Operating on Kubernetes, it provides all the security, performance, stability, and convenience found in modern software and infrastructure.
Fuzzball takes an engineer and researcher-first approach and provides intuitive tools to build and deploy without expertise in infrastructure and lowers the barrier for all performance intensive computing. Fuzzball not only abstracts the infrastructure layer but also automates the orchestration of complex workflows, driving greater efficiency and collaboration. Plug it into your existing orchestration and automation, build your own SDKs, or simply point-and-click.
You define compute resource pools and the Fuzzball control plane analyzes the data, compute and storage requirements to automate the provisioning and orchestration of the right resources. Fuzzball makes it simple to embed and run applications with Workflow templates that can be built and designed for any workflow or application.
Fuzzball will deploy and optimize placement of your workflows across disparate clusters that reside in multiple regions or even across on-premise and cloud providers. This optimizes your environment based on data, compute and storage requirements and gives you the flexibility to develop in the cloud and deploy on premise or develop locally and deploy to the cloud for scale. And it comes with integrations for the tools you already use and templates so anyone can enjoy it, including Jupyter, Matlab, OpenRadioss, PyTorch, R Studio, TensorFlow, and it works with your CI/CD pipelines including Jenkins, GitLab, and GitHub Actions.
If you are planning on using CIQ Fuzzball, we strongly encourage you to review the Fuzzball documentation attached to this listing prior to purchase, and contact CIQ if you have any questions before clicking deploy.
Highlights
A user-friendly GUI for designing, editing, and executing HPC jobs. Comprehensive control and automation of all HPC tasks via CLI. Human-readable, portable workflow files that execute anywhere
Automated data ingress and egress with full compliance logs. Native integration with GPU, both on-prem and cloud storage, and your favorite applications and CI/CD pipelines.
Extensive is support included for installation and configuration, bug and security fixes, platform updates and upgrades, troubleshooting and diagnostics, integration, best practices, and general Fuzzball support for usage. See Support information for details.
AWS Marketplace now accepts line of credit payments through the PNC Vendor Finance program. This program is available to select AWS customers in the US, excluding NV, NC, ND, TN, & VT.
Fuzzball bills by usage, charging you per minute across three separate dimensions. Fuzzball Orchestrate covers the control plane that schedules and manages your workflows. The two Substrate Node dimensions cover the compute that runs your jobs: a standard node and a GPU-enabled node. You pay for each node type by the minute it runs, so GPU workloads bill separately from standard compute. Total cost scales with how long you run Orchestrate plus the number and runtime of the nodes you use. Standard and GPU nodes are priced independently, letting you match compute to each job.
Top-of-mind questions for buyers
What counts as one Substrate Node for billing, and how does the GPU node differ?
A Substrate Node is a compute node that runs your workflow jobs. The standard node handles general compute, while the GPU node adds graphics-processing hardware for training and inference tasks. Each node bills per minute it runs. You choose which node type each job requires, so GPU compute meters separately from standard compute.
Am I charged when a node sits idle or a job finishes?
All three dimensions bill per minute of runtime. Charges accrue while Orchestrate is active and while each Substrate Node runs. When a node stops, its per-minute charge stops. GPU nodes bill only for the minutes they run, so ending a job halts that node's charges.
How do the three dimensions combine on my bill?
The three dimensions bill independently and appear together. Fuzzball Orchestrate meters the control plane that schedules workflows. Standard and GPU Substrate Nodes meter the compute running your jobs. Your total adds Orchestrate runtime plus the runtime of every node used. Node minutes usually drive most of the cost for compute-heavy or GPU workloads.
ciq.com
Helpful?
Vendor refund policy
CIQ does not offer refunds at this time.
How can we make this page better?
Tell us how we can improve this page, or report an issue with this product.
Give us feedbackReport a problem with this product or seller
Legal
Vendor terms and conditions
Upon subscribing to this product, you must acknowledge and agree to the terms and conditions outlined in the vendor's End User License Agreement (EULA).
Content disclaimer
Vendors are responsible for their product descriptions and other product content. AWS does not warrant that vendors' product descriptions or other product content are accurate, complete, reliable, current, or error-free.
Helm charts are Kubernetes YAML manifests combined into a single package that can be installed on Kubernetes clusters. The containerized application is deployed on a cluster by running a single Helm install command to install the seller-provided Helm chart.
Version release notes
Fuzzball v4.3.0 release notes
Fuzzball v4.3.0 is a feature release.
Headline features:
The workflow catalog provides a new set of AI catalog entries: there's a vLLM
entry, eleven pre-configured entries for specific self-hosted models, a gateway
for providing access to multiple models simultaneously, a RAG document service,
and two coding-agents. Models are provided as auto-scaled service pools, so they
can scale up and down to meet demand.
v4.3.0 rolls up v4.2.1, v4.2.2, and v4.2.3, so these notes are complete for
anyone upgrading directly from v4.2.0; items marked (also in vX.Y.Z) already
shipped on those patches.
Important
Upgrade notes.
Catalog repository URIs are now restricted to HTTPS and publicly routable
hosts by default. Other repositories will stop syncing and must be re-added
over HTTPS. Operator-managed deployments can relax this with
spec.fuzzball.workflowCatalog.restrictions.allowPrivateAddresses, and
tighten it with allowedHosts, maxCloneBytes and cloneTimeout.
Catalog entry IDs change on the first sync after upgrade. The ID is now
derived from the catalog source as well as the entry's id frontmatter. Saved
links and scripts referring to catalog entries by UUID must be updated.
Ingress routes on the kong and nginx classes now require TLS and
redirect plaintext callers with a 308. Other classes are unchanged.
A leftover pending-restore marker now fails the deployment instead of
being silently ignored, which previously skipped the required pre-upgrade
database dump. Delete the pending-pg-restore ConfigMap to clear one.
New Features
Turn-Key AI Model Serving
Serving a large language model no longer requires writing a Fuzzfile or
configuring vLLM from scratch. New workflow catalog entries start a model on
cluster GPUs and hand back one stable base URL speaking the OpenAI API, so any
OpenAI-compatible client can use it.
vLLM entry. Serves a model from an autoscaled pool of vLLM replicas on
NVIDIA or AMD GPUs. The model is downloaded once at workflow start and served
offline from the workflow's volume, and a replica runs on one node or spans
several with tensor or expert parallelism. By default an in-workflow LiteLLM
proxy holds the endpoint, load-balances across ready replicas, and drives
scale-up from its own metrics.
Eleven model presets. Individual catalog entries each configure the vLLM
entry template with GPU count, context size, and serving arguments validated
for each model. GPT-OSS 20B and 120B, Ministral 3 8B and 14B, Qwen3-Coder 30B
and Next 80B, Nemotron 3 Nano and Super, Mistral Medium 3.5, Llama 4 Scout,
and Gemma 4 31B are included in this release.
LiteLLM Model Gateway. As an alternative to the in-workflow proxy, a
single LiteLLM instance started from the workflow catalog can serve several
models from one endpoint, so a client agent reaches all of them from a single
configuration. It discovers pools through the Fuzzball endpoints API,
registering the per-replica endpoints a pool publishes when its own proxy is
turned off, and a request for a pool scaled to zero wakes it and succeeds on
retry.
Document retrieval. The rag entry runs a retrieval service built on
haiku.rag. It ingests PDF, DOCX, PPTX, HTML and plain text, indexes them for
hybrid vector and full-text search in an embedded LanceDB on the workflow's
volume, and exposes retrieval as MCP tools on a workflow endpoint. Embeddings
are served by a customer-provided OpenAI-compatible endpoint.
Coding agents. OpenCode and hermes-agent run a coding agent in the
cluster against a discovered, Fuzzball-hosted model or an OpenAI-compatible
API outside the cluster.
Endpoints for Autoscaled Service Pools
Workflow service endpoints now work against an autoscaled pool, not just
single-instance services. A pool's endpoint keeps one stable URL for the life of
the workflow and forwards each request to a replica ready at that moment, so
callers never need to know how many replicas exist.
Pool endpoints. An ordinary endpoint on a service declaring
autoscaler.replicas becomes a pool endpoint. It must use type: subdomain
and reference a named port. Scaling up adds replicas to the rotation as they
pass readiness, and scaling down removes one when its drain period begins,
after in-flight requests finish.
Waking a pool idle at zero. A pool at replicas.min: 0 keeps its endpoint
while idle. A request arriving then gets 503 with Retry-After: 120 and
starts one replica; retry after the cold start and it is served. The request
must be authenticated, so a scope: public endpoint never wakes its pool, and
a burst starts one replica rather than one per request. Each wake shows up in
fuzzball workflow events.
Per-replica endpoints. Setting per-replica: true gives every live
replica its own endpoint alongside the pool's, for callers doing their own
load balancing. fuzzball workflow endpoints list adds a REPLICA column and
poolEndpointId is available with -o json or -o yaml.
Annotations. Any endpoint may declare key-value pair annotations to
assist a client in discovering endpoints.
Multi-node replicas. A service may combine multinode with
autoscaler.replicas, so each replica is a gang-scheduled group of ranks
serving from rank 0. replicas.min and replicas.max count groups, and pool
capacity is total rank slots divided by group size.
Deleting, Pruning and Retaining Workflows
fuzzball workflow delete WORKFLOW permanently removes a single finished,
failed, or canceled workflow and fuzzball workflow prune --older-than DURATION
removes them in bulk, with --limit and --dry-run. Who may delete is set per
role in the central config's workflow.delete section, which takes
clusterAdmin, organizationOwner, groupOwner, and workflowOwner booleans.
All four default to false, so deletion is off until a cluster administrator
enables a role, and a caller may delete a workflow when any enabled role applies
to them. prune fails fast with a clear message when deletion is disabled
rather than reporting every candidate as skipped. On a federate deployment the
federate cluster and the orchestrate cluster owning the workflow each apply
their own setting.
Operators can also age workflows out on a schedule with a workflow.retention
block (spec.fuzzball.workflow.retention on the CRD), which takes enabled,
maxAge, interval, and batchSize parameters.
Deletion is permanent and takes the workflow's stages, events, metrics,
placements, cost and egress records, volume attachments, and service endpoints
with it. It refuses while published volumes or live service DNS records remain,
and a finished workflow with no recorded end time is never prunable. Both
commands are audited and replicate to federate clusters, while the scheduled
sweep has no caller identity to audit as, so its service log is the record of
what it removed. A delete against a Federate cluster is forwarded to the owning
Orchestrate cluster. prune must run against the owning cluster directly.
Node-Local Volumes
A storage provisioner whose base path is per-node storage rather than the same
shared filesystem on every node declares local: true. Every volume on such a
provisioner exists on exactly one holding node and Fuzzball places every
stage that uses the volume there.
Persistent volumes. Local provisioners now accept create and access
policies, and now support persistent volumes. The holding node is recorded
when the volume is created, and fuzzball volume create --node targets a
particular node when creating the volume.
Ephemeral volumes. An ephemeral volume on a local
provisioner is created once rather than once per consuming node, allowing
additional stages to access the volume later in the workflow.
Single-node only. A local volume exists on one node, so a shape needing
more than one is refused at submission. Multinode stages, concurrent task
arrays, and autoscaled services that scale above a single node may not mount a
local volume.
Concurrent volumes. A stage mounting more than one local volume
places them on a single node, and an ephemeral local volume mounted alongside
a persistent local volume is created on the persistent volume's holding node.
Capacity-aware placement. Placement skips nodes without room for the
requested size, and targeting a node that lacks space fails naming the node
and its free space rather than reporting a bare capacity error. Sized
ephemeral volumes on a local provisioner setting costPerGbHour are now
billed, having previously been created on a path that recorded no usage.
Scanning. fuzzball volume provisioner scan scans one node, selectable
with --node and records the holding node of every volume it finds.
Compute Policy Management from the CLI and Web UI
Organization compute policy grants shipped in v4.2.0 as an API with enforcement,
but with no way to manage them short of calling the API. v4.3.0 adds CLI and web
UI interfaces for managing access to node provisioners via the "compute policy."
Policies can be set at organization and group level.
Compute policy enforcement is still opt-in via computePolicy.enforce, which
defaults to false.
Changing a Submitted Workflow's Priority
fuzzball workflow update WORKFLOW --priority N changes a queued workflow's
priority in place. The value is re-stamped onto every unfinished stage, the
scheduler applies it on its next pass, and each stage records a
priority_updated entry in the activity log.
Enhancements and Changes
Node Health
AMD GPU health collection. ECC errors and overheating on AMD cards now
feed the node reliability score, cordon, drain, and fault eviction alongside
NVIDIA faults.
Substrate nodes are no longer degraded for IO errors on disks backing no
mounted filesystem or swap.
Workflow Definitions and Scheduling
Multi-node jobs fail as a group. Every rank now reports its own exit, so a
rank that is killed, runs out of memory, or crashes fails the whole job, and
the error names the rank, its node, and the exit status.
Defaults-level resource flags inherit correctly. exclusive,
cpu.threads, and memory.by-core set under defaults now apply to jobs and
services declaring any other resource field.
Multinode services run with host networking and publish resolvable replica
SRV records, fixing the startup bind failure and service discovery.
FB_GROUP_ID is now injected into job and service containers.
Volumes
New volumes default to mode 0750 instead of 0755, so they are no longer
world-readable or world-traversable without an explicit --permissions
definition.
Workflow Catalog
Template reuse. A catalog entry can point at another entry's template with
a template field in its metadata.md frontmatter instead of carrying its
own template.yaml. References resolve within a repository and one level
deep.
Workflow catalog search can now find entries by tag.
In-Workflow API Access
Expanded access for the workflow token, including the ability to read job
logs, resolve cluster names, browse and render the workflow catalog, list and
create volumes, use the object cache, and explain scheduling through fuzzball workflow why and queue show --mine.
Workflow containers receive a read-only bind mount of the node trust
store, so the token works on clusters terminating TLS with a private CA.
(also in v4.2.3)
Deployment and Infrastructure
Docker Compose subdomain endpoints. Workflow service endpoint URLs now
resolve on a Compose deployment, with a default base domain
<host-ip>.nip.io. The stack can serve a host-only wildcard zone from the
stack with --wildcard-dns, and --setup-dns configures the local host to
use the stack's resolver.
Azure. New --substrate-image-base-id and --substrate-image-nvidia-id
adopt an already-registered gallery image.
GCP. cluster gcp deploy|update pulls images and Helm charts using
the v-prefixed tags the source registry publishes.
AWS. Adds the p5.4xlarge and p6-b300.48xlarge instance types.
AWS SaaS deployments can give Federate its own DNS zone with
--federate-root and --federate-root-hosted-zone-id.
Diagnostics and Observability
Fuzzball debug CLI. fuzzball debug is now available to assist with
cluster troubleshooting. debug dump includes collectors for metrics,
JetStream, CRDs, ingress, certificates, storage, database health, and node
health, plus a --namespace flag for including additional underlying
namespaces.
Lease-grant failures are bounded and explained. Failure to secure a
resource lease is reported in the workflow's activity log and explained by
fuzzball workflow why.
fuzzball report charges and report charge-summary now correctly renders
--output yaml.
Web UI
Streamlined sign-in experience. The page opens on identity-provider
sign-in, looks up the organizations an address can use as you finish typing
it, and remembers your last-used organization, listing it first and marked
"Recent". When the lookup finds nothing it says so and offers a local sign-in
button; otherwise local sign-in stays available as a de-emphasized link. A
local sign-in that fails for an address registered with an identity provider
now offers a button back to the provider form.
Volume permissions. The volume creation form has a Permissions control for
the POSIX mode, and the detail panel shows an existing volume's mode.
Fuzzfile tab. A workflow's detail page shows the submitted workflow
definition as read-only YAML, alongside the Events tab.
Cluster kind. The clusters list shows each cluster's kind.
Volume connections in the workflow editor. The graph draws a connection
between a volume and the jobs and services that mount it.
Workflow search matches email, ID, cluster ID, parent workflow ID, and
error text as well as name.
Secrets. The image URI field filters secret suggestions to those matching
the registry's domain, and the secrets table has a Private column showing
whether an organization secret is private or shared.
Services can select a node provisioner in the service form; the field is
renamed from Node pool to Node provisioner.
Cancelled workflows no longer display with error styling, and the workflow
events and logs panels no longer show an unwanted horizontal scrollbar.
Fixes
Security
Fixed unsafe SQL construction on the catalog, usage-stats, and billing
endpoints by hardening how those queries are built.
Fixed an issue where a catalog repository URI could make the server issue
requests on the caller's behalf (server-side request forgery). Repository URIs
are now restricted to HTTPS and publicly routable hosts by default.
Fixed an issue where object cache TTL configuration could reach across
organizations. fuzzball org set-object-ttl and get-object-ttl now
correctly restrict to the organization scope.
Fixed an issue where the password change workflow could be bypassed. Setting a
password during signup now requires the correct short-lived signup token.
Fixed an open redirect on sign-in, where a login returnUrl containing a
backslash could send users to an external site or pack in additional request
parameters. The return target is now validated before the redirect.
Fixed an issue where the endpoint proxy forwarded Fuzzball credentials to
service endpoints. They are now stripped from the forwarded request.
Fixed an issue where public ingress routes on the kong and nginx classes
accepted plaintext traffic. TLS is now required on those classes.
Deployment
Azure
Fixed several issues in cluster azure update: it attempted a PostgreSQL
downgrade when --postgres-version was omitted, cleared configured substrate
image IDs when --substrate-image-base was omitted, and dropped the kubelet
gallery Reader grant, which made provisioning fail with
LinkedAuthorizationFailed. Also fixed fresh deployments, where the first
context login failed with ForbiddenByRbac and azure_files volume creation
failed with AuthorizationPermissionMismatch.
Operator
Fixed an issue where a Degraded Orchestrate or Federate stayed Degraded after
a failed configuration check or deployment. It now retries automatically.
Fixed an issue where the operator never re-ran a pending database restore,
leaving a stale marker that silently skipped the required pre-upgrade
database dump on later version upgrades.
Fixed an issue where a federate database restore might erroneously consume an
orchestrate cluster's dump, because both used the same pg-migrate dump path.
The operator's dump path is now qualified per cluster.
Fixed an operator panic when the ingress proxy type is NodePort without
both an http and a tls node port. The CRD now rejects that combination.
Compose
Fixed an issue where Nginx held onto a resolved upstream address, so a service
recreated by docker compose up kept receiving traffic at its old address.
Nginx now re-resolves its upstreams.
Fixed an issue where a missing Keycloak realm or UI client silently broke Web
UI login. Now such issues generate an error at startup.
Fixed an issue where a Compose deployment advertised its default storage
provisioner to nodes that cannot reach the shared Docker volume. The
provisioner is now scoped to the compose-managed nodes on new deployments; an
upgraded deployment keeps its original unsegmented provisioner, which has to
be retired by hand.
Google
Fixed an issue where cluster gcp update dropped --substrate-image-project.
The flag is now honored.
Amazon
Fixed an issue where the ECS task runner's launch request exceeded the
container-overrides size limit, causing stack updates on parameter-heavy
deployments to be rejected. The runner now keeps the request under the limit
(also in v4.2.2).
Fixed an issue where parallel checkpointing of targeted EKS control-plane
steps could persist a corrupt Pulumi snapshot. Those steps are now serialized
(also in v4.2.1).
Scheduler and Provisioner
Fixed several issues that left jobs queued indefinitely: whole-node-exclusive
jobs were placed onto nodes that already had other work, wedging the workflow
in READY forever; the scheduler could pick a provisioner definition holding
fewer nodes than the job needed, leaving it queued with no error; and
workflows could remain Pending after the scheduler had already finished their
allocations. Undersized definitions are no longer selected, and fuzzball workflow why now reports INSUFFICIENT_RESOURCES naming the definition and
both node counts.
Fixed an issue where workflow why misreported a capacity-blocked service
replica as a dependency wait. A replica the autoscaler is holding back, or one
whose pool shrank beneath it, now reports SERVICE_POOL_AT_CAPACITY naming
the provisioner definition and how many replicas the pool can hold.
Fixed three scheduler leadership issues: a leader that hit a JetStream timeout
during a leader start following the first election kept leadership with node
health tracking off, and now steps down so the start is retried on
re-election; a demoted replica kept its service event consumer and took
service health results from the new leader, and now releases it; and a crash
during leader-election churn left the scheduler unavailable until the pod
restarted.
Fixed several cases where nodes and instances leaked. Cloud VMs left behind by
a failed create or an interrupted provisioner are now recorded and deleted on
all four backends; Azure instance deletion no longer reports success without
deleting anything when a node reported a hostname that was not its VM name;
and a node registration whose address has been reused by a different node is
now purged, so the scheduler stops counting the departed node's capacity as
free.
Fixed an issue where fuzzball workflow start --priority rejected a positive
value from an organization owner. It now accepts one, matching update.
Fixed an issue where FB_JOB_IMAGE carried a uri: prefix.
Fixed an issue where cyclic dependsOn workflow graphs were accepted at
submission and left unschedulable. They are now refused at submission.
Services, Autoscaling and Endpoints
Fixed an issue where autoscaler scale-up released replicas before their image
and other dependency stages had completed, causing failed replicas and pool
flapping, and where a service with no dependents was stopped before its
container finished starting.
Fixed an issue where stopping or canceling a workflow running an autoscaled
pool left the pool's autoscaler, SRV, and per-replica DNS records in place.
Endpoint rows are now removed when the owning workflow ends even if its
service never ran teardown, and getting an endpoint or minting an endpoint
token for an ended workflow now fails with FAILED_PRECONDITION.
Fixed an issue where endpoints created or deleted during a page walk produced
duplicated and skipped rows.
Fixed an issue where ingress re-executed endpoint requests running past 60
seconds and buffered streamed responses, and where the embedded endpoint
servers used by Compose and single-binary deployments cut responses, streams,
and uploads off after 15 seconds.
Web UI, Authentication and Federate
Fixed an issue where volume ownership defaulted to root on LDAP-federated
deployments. UID now resolves from the caller's JWT claims before the
database, and GID from the selected account before the claim.
(also in v4.2.3)
Fixed three Web UI defects: the storage provisioner form rejected every local
provisioner by always sending create and access policies, the workflow editor
crashed while an environment variable was being added in the YAML view, and
saving a template with an empty YAML body reported nothing rather than the
validation error.
Fixed an issue where an image build stage's Web UI panel had no Logs tab, so
the post script's output was unreachable there although the CLI could already
read it with fuzzball workflow log. The panel now carries one.
Fixed an issue where the nodes list did not show its cluster column.
Fixed an issue where the workflow editor dropped volumes, jobs, and services
whose YAML map entry had an empty body.
Fixed an issue where deleted federate organizations could not be recreated.
Also fixed a missing default volume provisioner per registered cluster,
fan-out errors for federated local users that did not name what failed, and
cluster administrators being unable to leave an assumed session without
re-authenticating.
Workflow Catalog
Fixed an issue where listing a large catalog over REST failed because the
OpenAPI gateway's gRPC receive limit was smaller than the one used by the CLI
and backend services. The limits now match.
Fixed an issue where a malformed values.yaml aborted the whole catalog sync
run. Sync now skips the offending entry and continues.
Fixed filtering the workflow catalog by tag.
Fixed an unhandled exception when starting a workflow from a catalog template
ID that does not exist.
Application-specific assistance to run workloads on Fuzzball and professional services to create and manage workflows are available from CIQ at an additional cost. Contact us for details.
AWS Support is a one-on-one, fast-response support channel that is staffed 24x7x365 with experienced and technical support engineers. The service helps customers of all sizes and technical abilities to successfully utilize the products and features provided by Amazon Web Services.
Provides accurate visibility into Slack’s Enterprise Grid and Plus level customers – its primary revenue generators. The monthly data feed details customer names, totals, acquisitions, churn and migrations/upgrades associated with these highest contributing revenue levels.
FloQast, an Accounting Transformation Platform created by accountants for accountants, enables organizations to automate a variety of accounting operations. Trusted by more than 3,000+ global accounting teams, including Twilio, Los Angeles Lakers, Okta, and Snowflake, FloQast enhances the way accounting teams work, enabling customers to automate close management, account reconciliations, accounting operations, and compliance activities. With FloQast, teams can utilize the latest advancements in AI technology to manage aspects of the close, reduce their compliance burden, stay audit-ready, and improve accuracy, visibility, and collaboration overall. FloQast is consistently rated #1 across all user review sites. Learn more at FloQast.com.
Provides accurate visibility into Slack’s Enterprise Grid and Plus level customers – its primary revenue generators. The monthly data feed details customer names, totals, acquisitions, churn and migrations/upgrades associated with these highest contributing revenue levels.
Gameball is a gamification-first loyalty and engagement platform that embeds points, tiers, missions, and referrals directly into your existing app, website, and POS through API and SDKs. Enterprise retail, banking, fintech, F&B, and marketplace teams use it to run loyalty as owned infrastructure across every channel, with no separate app for customers to download. Trusted by 3,000+ brands across 70+ countries.
Be the first to review this product. We've partnered with PeerSpot to gather customer feedback. You can share your experience by writing or recording a review, or scheduling a call with a PeerSpot analyst.