Know what you’re getting.
Browse the catalog, compare editions and read the terms. The product, publisher and repository have recognizable identities before you commit.
PLATINUM SOFTWARE HUB
YOUR SOFTWARE, ALL TOGETHER
YOUR SOFTWARE, ALL TOGETHER
A home for the software
you use. And make.
Find your next tool, keep your apps up to date and know what you own. For developers, bring publishing, distribution and protection into the same clear workflow.
EXPLORE SOFTWARE HUB
Choose the view that fits your work.
A comfortable home for your apps.
Find something useful, make it yours and get on with using it. Software Hub brings discovery, purchases, installation, updates and ownership into one workspace, whether your tools come from Winnitude! or a repository you trust.
Your purchase has a place.
A completed purchase adds its ownership receipt or access grant to your account. Your library gives you a clear way to return to the right software and version.
Updates without the guesswork.
Acquire and update software through the same workspace. PlatinumSDK verifies the published components behind the scenes, so you can concentrate on the application instead of checking files by hand.
Keep installed and owned software together, with a clear route back to the application you need.
Less hunting. Fewer interruptions.
One library, a clearer next step
See the software you own, what is installed and which releases are available. Return to a familiar product page instead of searching old emails for an installer or guessing which download belongs to you.
A recognizable sign-in
Use PlatinumAuth to carry your identity between participating Platinum applications. Each application still asks for the authority it needs; signing in once does not quietly give every tool access to everything else.
Updates with a checked trail
The update path checks the release record, publisher authority and the contents it receives. A familiar filename or a convincing download page is not the basis for trusting an update.
A useful account of your software
Keep purchases, receipts, license terms and subscriptions organized. See which rights are lasting ownership and which depend on a seat, paid period or separately provided online service.
Repositories you can recognize
Connect to the Winnitude! Platinum master repository or a self-hosted repository you choose. Federation lets participating services recognize trusted identities while keeping each product’s licensing authority clear.
A purchase is not a permission switch.
An ordinary perpetual software purchase produces a lasting ownership record. A subscription period, publishing permission, multiplayer entitlement or managed-service seat is a separate grant. Software Hub keeps those concepts separate in both the interface and the authority model.
| What you have | What it means |
|---|---|
| Perpetual ownership | The recorded purchase remains yours. Account restrictions and unrelated service changes do not silently erase it. |
| A subscription or seat | Access follows the stated term, seat allocation and service policy. Renewal and cancellation are recorded as access changes. |
| Online capabilities | A game server, multiplayer feature or publishing service can authorize its own operations without rewriting the purchase underneath them. |
| Offline use | Authentic local release and ownership records support offline decisions where the product’s terms permit it. Features requiring a live service still need that service. |
Refunds, disputes and other commercial adjustments have their own recorded history. They are handled explicitly, rather than hidden inside an unrelated revoke-access button.
The checks happen where they help.
PlatinumSDK automatically validates the declared application inventory against its trusted release record. That includes the code and other covered components behind the interface—not just the name on the launcher. Unexpected replacements, mismatched releases and unauthenticated update sources are treated as verification problems, with a visible next step instead of silent acceptance.
The same system gives publishers a dependable release trail and gives you a clearer answer to a simple question: is this the software I meant to install? Review the publisher, repository, ownership and verification state without having to become a security specialist.
See how verification works ↗From your build to their library.
Publish, distribute, update and license your software through a connected release pipeline. Software Hub brings the commercial workspace and PlatinumSDK’s trust model together, so protection and ownership are part of the product’s foundation.
A stable identity for the product
Organize products, editions, application identities, projects, targets and builds. A release refers to a specific inventory, not whatever happens to be stored behind a mutable download link.
A complete release envelope
The PlatinumSDK publishing workflow assembles the covered application inventory: executable code, scripts, native modules, executable data, dependencies and declared assets. Content hashes, publisher authorization and the registered release record travel as one verifiable chain.
Validation built into the runtime
Standard PlatinumSDK packaging and loading integrate verification out of the box. The trusted loader checks the covered bytes before protected code or modules are admitted, and the update path verifies the replacement release through the same model.
An operational publishing desk
Follow builds, release inventory, publishing eligibility, registration, sales and licensing from focused views. Give release staff, commerce operators and developers the authority for their work without combining every role into one administrator account.
Commercial rules that remain explicit
Define perpetual products, subscriptions, seats, service capabilities and update or support rights separately. Payment outcomes produce the appropriate recorded entitlement; a browser returning to a success page is not evidence of payment.
Keep the project, its application identity and the next release connected.
More than a serial number.
Software Hub ties licensing to an authenticated identity, a defined application and its licensing authority. Signed release evidence establishes which build is involved; current grants establish which protected operations the holder may perform. Copying a file or an activation string is not a substitute for that chain.
Checks at the authority boundary
Licensing and protected online operations are authorized by the responsible service. A client-side flag, an enabled button or a caller-supplied application ID cannot grant itself rights.
Proof-bound access
Identity and grant requests are scoped to the intended issuer, audience, application and operation. Holder binding, expiry and freshness checks make copied credentials and replayed exchanges less useful than ordinary reusable unlock strings.
Tamper-evident distribution
The release envelope covers the registered component inventory. A replaced executable, script, dependency or other covered payload no longer matches the authorized release merely because the outer installer has the right name.
Separate ownership and revocable capabilities
Manage seats, timed features, publishing access and online services without repurposing those controls to erase a perpetual software purchase. Preserve a useful history of the commercial decision.
Explicit offline and service policies
Choose which operations require current authority and which may rely on authentic retained evidence. Previously verified software, a current online grant and a perpetual purchase remain distinct states.
What anti-piracy protection does—and does not—mean
The system combines trusted release admission, cryptographic evidence and server-side authorization. It reduces opportunities for substituted builds, forged grants and unauthorized service use. It does not promise unbreakable DRM or control over a machine whose operating system and trusted runtime have been compromised. Keep valuable server-side operations behind real authorization rather than relying only on a local startup check.
Use Auth. Keep your authority.
PlatinumAuth is the out-of-the-box identity integration: accounts, devices, sessions and key-based authentication are handled through a shared identity system. Software Hub retains its own product, release and licensing authority. An Auth administrator is not automatically a license operator.
You can also run a self-contained Software Hub deployment, with identity and repository services configured together under your own control. A Winnitude-hosted account service is not a requirement for operating your own repository. The SDK exposes the same application-facing identity and capability concepts through the configured deployment.
IdentityWho is making the request?
→Software HubWhat does this holder own or have permission to do?
→Your applicationUse the authorized capability at the actual operation.
Use the shared SDK integration for sign-in, identity verification, capability checks and scoped account data. Keep credentials and signing keys in their trusted providers; scripts and application views receive the handles and permitted information they need.
Explore PlatinumAuth ↗Your product. Your stack. Our licensing tools.
Use Software Hub as a licensing service, add release protection and DRM, or operate a complete software repository. The modules fit existing commercial products and internal tools as well as PlatinumSDK applications.
Licensing only
Keep your storefront, application and update system. Use the Hub for product ownership, license grants, seats, subscriptions and capability checks, with an auditable record of the commercial decisions behind them.
Licensing + DRM and verification
Add authenticated release records, component manifests, trusted validation and current capability checks. Choose where your product enforces protected operations and which offline evidence it accepts.
A complete repository
Bring catalog, acquisitions, library, builds, releases, updates, verification and licensing into one deployment. Operate privately for your organization or publish to a wider audience, with federation where you choose it.
Managed or self-hosted
Use Winnitude’s Platinum master service, a managed deployment arranged with us, or a self-hosted installation. Agree the modules, account integration and operating responsibilities around your actual business.
Bring the application you already have.
You do not need to rebuild a product on PlatinumSDK to use Software Hub. Existing native, web and game applications can integrate at the identity, licensing and verification service boundaries while keeping their own interface and technology.
Define the product.
Register its stable application identity, fixed home licensing authority and the products or capabilities you sell.
Map accounts and ownership.
Connect the accepted identity service and your commercial workflow. Bind users to verified issuer-and-subject identities and translate paid outcomes into the right ownership or grants.
Use the services you need.
Check capabilities at protected operations. Add the signed inventory, trusted loader or update integration when you want deeper verification, then expand into repository features at your own pace.
PlatinumSDK applications receive the integrated packaging and runtime validation path out of the box. For a non-Platinum application, the integration connects the chosen modules to its own build and execution boundaries. Licensing-only adoption does not require replacing the rest of its distribution system.
Discuss your existing application ↗A checked path from publisher to application.
Automatic verification is part of a normal PlatinumSDK release. The system checks the complete declared application inventory against an authenticated release record, so each covered component has a place in the chain.
- 01
Identify
The application and publisher have stable identities. The application defines its fixed home licensing authority.
- 02
Describe
A release envelope identifies the exact build, target and covered components, with content hashes and dependency information.
- 03
Authorize
The publisher and registering authority sign or authorize the appropriate release statements. Trusted keys establish who can make those claims.
- 04
Verify
The loader authenticates the release record and compares the covered payload before admitting the protected application code or module.
- 05
Use
The responsible service evaluates current grants for protected operations. Legitimate updates go through a new authenticated release record.
What is covered by “every part”?
The signed inventory covers the application components declared by the release pipeline: executable and scripted code, native extensions, executable data, dependencies and assets included in that inventory. Protection follows the package and its trusted loading path, rather than checking only a launcher and then trusting whatever it loads.
Documents created by the user and settings that legitimately change are not frozen to an installation hash. Those use their appropriate data and configuration policies. The Hub does not claim to validate every unrelated file on the operating system.
Know who you’re talking to.
Authenticate the service
The default Winnitude service is verified against its expected origin and pinned company-authorized signing identity. A fresh signed challenge binds the exchange to the intended service, audience and connection context.
Authenticate the release
Content hashes identify the bytes. Publisher signatures and trusted registration establish who authorized that exact release. A public key delivered only by an unverified endpoint is not its own proof of authenticity.
Keep authority scoped
An identity issuer, publisher, repository operator and application licensing authority have different jobs. Federation or shared sign-in does not collapse those jobs into universal administrative access.
Handle change deliberately
Key rotation, revocation and release policy are part of the trust-update path. An older signed record cannot silently overrule a current revocation or become permission for a different application.
Reject a mismatch
Unexpected components and mismatched evidence fail verification. Recovery distinguishes an authorized update, a pending configuration change and a suspicious replacement instead of automatically blessing the newest bytes.
Hashes, signatures, licenses and safety answer different questions
A SHA-256 digest identifies content. A verified signature attributes a statement to a trusted key. A release record establishes what was authorized for distribution. An ownership receipt records a purchase, and a capability grant permits a defined operation. None alone proves that software contains no bugs or malicious behavior.
The host operating system, drivers, trusted loader and key providers remain part of the security boundary. Verification is meaningful when it happens before the protected execution boundary and the checked content is the content that actually runs.
Protect settings without fighting the user.
SecurityVerified settings use signed, revisioned baselines. A legitimate change can be recorded as pending and confirmed through the configured Hub. An unexpected modification can be distinguished from that authorized work, with the relevant evidence retained.
Signed local baselines
The record binds the application, configuration identity, revision and content digest. A setting changing is not, by itself, proof of an attack.
Independent confirmation
Optional Hub confirmation provides a separate record of the accepted revision. Receipts must match the expected identity, digest and revision; an unrelated receipt does not confirm a new baseline.
Consent-based recovery
The stronger recovery option retains an accepted backup through the configured provider. Backup contents, retention and confidentiality are explicit choices; a content hash alone cannot restore a file.
Current rights still apply
Restoring settings does not revive revoked credentials, expired access or an obsolete licensing state. Recovery restores the permitted configuration while current authority remains in force.
Show the decision. Keep the boundary.
Verification, account access and optional recovery are understandable parts of the workspace. Repository and account-data access are scoped to their purpose; ordinary release verification is not a reason to upload your documents or private keys.
Online verification and optional services have explicit effective settings. Authentic retained release information supports offline decisions, while the interface distinguishes that evidence from a fresh online check. A product may still require a live service for a particular feature, and that requirement belongs in its terms.
Review your deployment’s verification and protection policies.
Your community. Your catalog. Your server.
Use the Winnitude! Software Platinum master repository, or license a self-hosted Software Hub to operate your own. Publish a focused catalog for your studio, a private organization, a community or a wider software audience.
Keep hosted deployments and their operators in one view.
Recognize the person across repositories.
Participating repositories securely verify and use one another’s user identities through configured trust relationships. A person can be recognized across services without each repository inventing an unrelated identity for every visit.
Repository AIssuer A + stable user identity
⇄Verified federationTrusted issuer · audience · holder · scope
⇄Repository BRecognizes identity; applies its own permissions
Identity is namespaced
A user is identified by its issuing service and stable subject identifier, not a matching display name or email address. Two repositories cannot impersonate one another’s users simply by choosing the same name.
Trust is configured
Repositories verify accepted issuers, keys, intended audiences and the holder of the presented credential. Joining a network does not automatically make every participant authoritative for every identity or operation.
Recognition is not a license grant
A repository may accept an external identity and still require a purchase, role or capability for its own services. Federation does not let a self-hosted issuer mint Winnitude publishing rights or another developer’s entitlements.
Account linking is deliberate
Where identities need to be linked, the relationship is explicit and verified. An email address by itself is not proof that two accounts belong to the same holder.
Share distribution. Keep authority clear.
Every application defines its fixed home licensing server. That authority is bound to its application identity and trusted release configuration. A federated repository can recognize a user or deliver a release without becoming entitled to issue licenses for that application.
| Participant | What it can establish |
|---|---|
| Trusted identity issuer | The verified identity and holder making a request, within its accepted scope. |
| Repository or distribution mirror | The catalog and release it serves, subject to the same publisher and inventory verification. |
| Application’s home licensing server | The application’s ownership and capability authority under the product’s policies. |
| The running application | Requests and uses the specific authorized operations; it cannot declare itself licensed by changing a URL. |
Changing the host that serves a download does not move the application’s licensing home. Any authorized infrastructure transition follows the application’s trust-update process, rather than accepting a replacement server chosen by an untrusted client.
Plan your repository and federation setup ↗A clearer workspace.
A connected foundation.
Responsive tools, shared services and explicit permissions, with a deployment shaped around your organization. Talk to us about publishing through Winnitude!, integrating an existing product or operating a repository of your own.
Pre-alpha and evaluation builds may differ from the full public product.