iGaming platform source code.
Not access to a platform. A copy of the code, and it is yours.
This page sets out what a source-code purchase of Callisto covers: what is delivered, what your team may do with it afterwards, what remains your responsibility, and how the code can be reviewed before any commitment is made.
Everything needed to build it without us.
What matters in a source-code delivery is not its volume but its completeness: whether your team can build, deploy and modify the platform without assistance from the vendor.
A complete copy, shared libraries included
Every service, together with the cross-service libraries beneath them — messaging contracts, data access, logging, authentication — delivered as source rather than as compiled packages from a feed we host. Your build therefore carries no dependency on infrastructure we control.
Each service builds on its own
Every service carries its Dockerfile, its database migrations, its unit and integration tests and its own README. A single service can be taken and run independently, which is how the completeness of the documentation is verified.
Deployed through your own CI/CD
GitHub Actions workflows and Docker Compose files ship with the code. Point them at your registry and your servers — nothing routes through infrastructure we control, and there is no build step only we can run.
From then on the history is yours
The copy goes into your own Git, and from that point the commit log belongs to your team: your branches, your reviews, your releases. Callisto’s own repository stays with us, because Callisto is a product that keeps being developed — which is also how improvements reach you while you keep support, as changes you choose to take rather than a version you are moved onto.
The whole running platform.
Roughly what a buyer sees on the first technical walk-through. The exact set is written into your agreement, because scope is what you are actually paying for and it should not live on a marketing page.
Player-facing
- Casino web front end
- Player wallet and cashier
- Registration, login and KYC flows
- Agent portal
Operations
- Callisto Operator OS (backoffice UI)
- Player, customer and skin management
- Payment review and manual entries
- Statements, invoices and billing
- Support desk
- Reporting and dashboards
Core services
- Player, wallet, payment, transaction
- Customer, currency, user and roles
- Game, game provider, casino provider
- Progressive jackpots
- Agent, agent wallet, affiliate
- Bonus and bonus engine
Compliance and risk
- Responsible gaming service
- KYC and document review
- Configurable risk rules and alerts
- Compliance review cases
- Audit trails
Engagement
- Communication hub (in-app, email, push)
- Marketing campaigns, segments and web analytics
- Telegram Mini App per skin
- Site Builder and Content Studio
- Outbound webhooks
Engineering support
- Database migrations per service
- Unit and integration test suites
- CI/CD workflows
- Provider and payment simulators for testing
The simulators warrant particular mention: they allow deposits, bets and payouts to be tested end to end before any provider contract is signed — typically months before such testing would otherwise be possible.
Read it, change it, run it.
The three questions technical buyers raise most often, answered in advance of the first meeting.
Modify anything, without asking
Every rule that touches money is readable and editable by your team. There is no feature request to file and no release schedule to wait for.
Run as many brands as you like
The skin model is built for it: one backend, many brands, each with its own domain, theme, currencies, payment methods and responsible-gaming defaults. The architecture imposes no per-brand fee.
Keep running if we part ways
You hold the source, the containers and the documentation. Support and updates are a service you can stop buying; they are not a licence check that stops the platform. This is the principal difference from a white-label contract, and we recommend having it confirmed in writing — with us or with any other vendor.
The limits are in the agreement
Owning the source is not the same as holding the right to resell the platform as a competing product. What is granted and what is reserved is set out in the contract, in plain terms, before signature.
What is not included.
Each item below is required to operate and is not part of the delivery — from us or from any other platform vendor. We set them out here so they are accounted for during planning rather than encountered during implementation.
The gaming licence
You hold the licence for every market you operate in. We provide the controls, gates and audit trails a regulator asks about; we do not provide, sponsor or share a licence, and no software vendor can.
Game content
The platform is an aggregation layer with provider integrations — the games themselves are licensed from the studios that make them, under your own commercial terms with them.
Payment provider contracts
Providers plug in behind a common interface, but the merchant account, the underwriting and the rolling reserve are between you and the provider. This is usually the longest item on a launch timeline.
Hosting and operations
Self-hosted means yours to run: servers, backups, monitoring and the staff who respond to incidents. We can help set it up, and it is still your infrastructure afterwards.
Legal and regulatory advice
Which controls your market requires is a question for your compliance counsel. What we can tell you is precisely how each control is implemented, because you can read it.
We recommend requesting the equivalent list from any vendor you are comparing.
Verify the code before you buy it.
Source code can be examined in full before any commitment is made. We treat that as a normal part of the evaluation rather than a concession; the sequence below is what we propose.
- 1
Technical demo of the running platform
A working system rather than slides: the backoffice, the casino front end and a deposit processed end to end.
- 2
A code review session with your engineers
We take your technical team through the architecture and open the files they ask to see — the wallet under concurrency, the payment callbacks, the responsible-gaming enforcement. We suggest concentrating on these three, as they carry the most operational risk.
- 3
Your own due diligence on the parts that matter
Test coverage, migration history, handling of secrets, authentication between services, and behaviour when a provider callback arrives twice. We provide evidence for each of these on request.
- 4
Scope and terms in writing
Which repositories, which rights, what support looks like afterwards and what happens if you stop. Agreed before signature, not discovered after.
Moving off a revenue-share deal.
The most common reason operators approach us. The platform is rarely the difficult part — the data and the contracts are.
The commercial calculation
A revenue share grows with volume indefinitely. Owning the software converts an open-ended percentage into a fixed cost plus your own engineering — less favourable at low volume, and materially better above a certain point. We recommend establishing your own break-even before evaluating quotes.
Your players and their balances
Player accounts, balances, transaction history and KYC status can be migrated; how cleanly depends on what your current provider will export. This is worth establishing early, as it affects the timeline more than the technical work does.
Providers have to be re-contracted
Game and payment integrations sit in your name once you leave. Some providers move easily, some renegotiate. This is contract work running in parallel with the technical migration, and it usually sets the launch date.
You can run both for a while
Nothing forces a single cut-over. Operators commonly launch a new brand on the owned platform first, learn on it, and migrate the existing one once the operation is proven.
Source-code questions.
These are the questions that come up once the code itself is under discussion, rather than the general ones answered on the home page.
Real delivery. Escrow means a third party holds the code and releases it if the vendor fails — you get nothing until something goes wrong, and you have never seen what you would receive. Here the copy is delivered at the start of the engagement: on your infrastructure, in your Git, available to your engineers immediately. If your legal team wants escrow terms on top for their own reasons, that is a contract discussion rather than a technical obstacle.
Yes, and that is the design rather than a concession. Support, fixes and new modules are a service you can stop buying. Nothing phones home, no licence key expires, and no build step runs on our infrastructure — so there is no lever to pull if you leave.
It is a full platform: 35+ services, and no individual holds all of it in their head, ours included. What makes it maintainable is that the services are small, consistent and independently deployable — the same architecture and the same layout in each, so an engineer who learns one understands the shape of the rest. A team of several engineers can carry it; a single engineer cannot, and we would rather say so before the question becomes practical.
Callisto is a product, not a bespoke build, so the same code can go to more than one buyer — nothing in how it is sold reserves it for one. Every deployment runs on its own infrastructure with its own data, and no deployment can see another. Exclusivity in a market is a commercial question rather than a technical one; if it matters to you, raise it before signing rather than assuming either answer.
It is the platform we operate, not a reference implementation built for sale. This has implications in both directions: real load and real payment providers on one side, and areas under active development that are visible in the code on the other. The review session covers whatever you ask to see.
It depends on scope — individual modules, the full platform, or the platform with our engineers working alongside your team — so a single figure on a web page would be misleading for most readers. One call is enough to scope it, and if Callisto is not the right fit we will say so.
Bring your engineers.
The fastest way to judge a source-code platform is to have your technical team read it with ours in the room. Tell us what you run today and what you are trying to change.
We reply within a day, usually the same one.