Understanding the portal

What portal.vdf.ai actually is

The portal is the gateway between you and the self-hostable VDF AI software. It does three things:

1. Authorizes your organization to access self-hosted packages.
2. Publishes the catalog of packages available to you and their current versions.
3. Mints time-limited credentials that let you pull the package container images.

Notably, the portal does not deploy software for you. It doesn’t reach into your environment, it doesn’t have a path back to your systems, and it doesn’t track what you’ve actually deployed. The deploy itself is yours to run.

The account lifecycle

Every portal account moves through a small number of states. Understanding these saves time when something looks stuck.

State	What it means	What you can do
Pending verification	You signed up but haven’t clicked the email link yet	Click the link in the verification email
Pending approval	Email verified; our team is reviewing your registration	Wait — typically under one business day
Active	Approved; you have full access to your assigned packages	Browse the catalog, generate credentials, deploy
Trial	Active, but with a time-bounded trial window	Same as Active until trial expires; contact us to extend or convert
Suspended	Access is paused (billing, terms, or admin action)	Email info@vdf.ai to resolve
Expired	Trial or subscription has ended; existing deployments still run	Renew via info@vdf.ai to restore credential generation

Your current state is shown in the portal dashboard, along with any time-bound details (trial end date, days remaining).

Trial periods

Most accounts start in a trial window. A trial doesn’t reduce capabilities — you get full credential access for every package assigned to your account. It just has an end date.

When a trial is approaching its end:

• The portal shows a banner with the days remaining.
• You’ll receive an email reminder.
• You can request an extension or convert to a production license by emailing info@vdf.ai.

Trial expiry does not affect software already deployed in your environment — those instances continue to run. What expires is your ability to generate new credentials for fresh pulls.

The credential model

When you click “Generate credentials” on a package in the portal, you get back:

• A docker login command that authenticates your local Docker / orchestrator with the package registry.
• The docker pull commands for each image in the package.
• A clear expiry timestamp for those credentials.

Why credentials are time-limited

Credentials expire automatically — typically within 12 hours of generation. That’s deliberate, and it matters for three reasons:

1. Reduced blast radius. A leaked credential is a leaked credential for hours, not forever.
2. No long-lived secrets to rotate. You never have a registry key sitting in CI for months.
3. A natural audit point. Every credential issued is logged with a clear timestamp and the user who minted it.

If credentials expire mid-deploy, generate a fresh set in the portal and continue. There’s no penalty, no rate impact for normal use.

What the credentials can do

The credentials grant read-only access to your assigned packages’ images in the package registry. They cannot:

• Push new images.
• Delete or modify existing images.
• Reach any other VDF AI registry or AWS resource.
• Be promoted to higher-privilege roles.

Even if a credential leaks before expiry, the worst outcome is that someone else pulls the same images you already have access to.

Generating new credentials

You can mint a fresh set any time. Common reasons:

• The previous set expired before you finished pulling.
• You’re starting a new deploy from a different host.
• You’ve added a new node to a Kubernetes cluster that needs to authenticate to the registry.

There’s a sensible rate limit (a couple of dozen per hour per user) to catch runaway automation. Normal operator usage never approaches it.

The package catalog

After approval, the catalog is the heart of the portal. For each package available to you, the catalog page shows:

• Name and one-line description.
• Current version available to your account. If you’re entitled to multiple channels (e.g. stable and preview), each is shown.
• System requirements in plain operator language — compute, memory, storage, network.
• The list of services that come together as that package.
• The install guide — a package-specific document covering bring-up, configuration, and first-run.

Today the catalog lists VDF AI Compliance Foundation. Additional packages will land in the catalog over the coming releases. When a new package is published and your account has access, it appears automatically — no need to re-register.

Multi-user access

Today the portal supports a single registered admin per organization. That person can:

• Manage their own account.
• Generate credentials.
• Share the resulting docker login and docker pull commands with teammates.

Because credentials are short-lived and read-only, sharing them with your platform team for the deploy window is a normal, safe pattern.

True multi-user team accounts (with per-user audit, role-based scopes, and SSO) are on the near-term roadmap. When they land, your existing organization will be migrated without disruption.

Account management

From inside the portal you can:

• Update your profile (name, job title, company size).
• Change your password.
• View your credential history (when each set was minted, by whom).
• See your trial / subscription status and renewal contact.
• Request account deletion under applicable data-protection rights.

For anything beyond self-service — trial extensions, multi-user requests, custom packages — email info@vdf.ai.

What the portal doesn’t do (by design)

It’s worth being explicit about the boundaries.

• It doesn’t deploy. No backdoor into your environment.
• It doesn’t monitor your running instances. Your observability stack is yours.
• It doesn’t bill automatically. Billing is handled outside the portal, via your normal commercial relationship.
• It doesn’t transmit telemetry from your deployments. The packages you deploy don’t phone home.

The portal is intentionally narrow: identity, authorization, and credential minting. Everything else stays in your control.

What to read next

• Infrastructure requirements — what your environment needs to host a package.
• Packages — what’s currently in the catalog.
• Operations — running and updating a deployment.
• FAQ — common questions about approval, sharing, and licensing.