DocsFeatures

Polyaxon connects the operational work behind AI and ML systems: workloads, runs, sandboxes, LLM gateway traffic, traces, evaluations, artifacts, prompts, models, automation, permissions, and audit history.

It keeps that work inspectable after it leaves a notebook or laptop.

One platform

Polyaxon gives teams one place to run work, collect evidence, and review what happened. A project can hold training runs, services, traces, prompts, evaluations, dashboards, artifacts, model versions, access settings, and operational metadata.

AI systems rarely fail in one layer: a bad answer might come from a prompt change, retrieval issue, model provider, tool call, stale index, weak evaluation, or deployment mismatch. Keeping these records together lets teams debug across layers without stitching context from separate tools.

Learn more in One platform and Vision.

Developer interfaces

Polyaxon is usable from the UI, CLI, SDKs, generated clients, webhooks, and the REST API. Teams can run it as a regular product for data scientists and AI engineers, or use it headlessly from internal tools and automation.

The same operations can be created, inspected, resumed, stopped, promoted, and queried from any interface. Notebooks, CI jobs, local terminals, internal dashboards, and production services share the same platform logic.

Reproducible results

Polyaxon makes your experiments reproducible, portable, and repeatable while being language and framework agnostic.

  • Powerful packaging format Polyaxonfile: A specification for packaging dependencies, inputs, outputs, artifacts, environments, and runtime of an operation to schedule on Kubernetes.
  • Extensive tracking API for source code, parameters, data, metrics, tags, and logs.
  • You can see the full experiment history at a glance, including when, who, and where.
  • Auto-document all experiments with statuses, metrics, hyperparams, source code, data, visualizations, artifacts, and resources used in each experiment.
  • Advanced insights and comparison of experiments based on results, hyperparams, versions of training data and source code.

Workspace and dashboards

The workspace gives users the daily surfaces around runs and projects: run tables, search, query filters, sorting, comparison views, logs, artifacts, lineage, metadata, dashboards, and visualizations.

Polyaxon tracks and renders common ML outputs such as metrics, charts, images, HTML, audio, video, notebooks, model files, and arbitrary artifacts. Teams can use native visualizations, TensorBoard, custom dashboards, or libraries such as Plotly, Bokeh, Altair, Vega, and Matplotlib.

See the runs dashboard and visualizations.

Workloads and runtimes

Polyaxon can run jobs, services, notebooks, TensorBoard instances, Streamlit and other internal apps, batch scoring jobs, distributed training, Ray workloads, Dask workloads, and Kubeflow operator workloads.

Jobs handle batch work such as training, data processing, evaluation, and scoring. Services handle long-running work such as notebooks, dashboards, model APIs, development environments, and sandbox sessions. Distributed and cluster runtimes cover larger training and compute jobs without changing the project record around the work.

See jobs, services, distributed workloads, and clusters.

Sandboxes

Sandboxes give engineers and agents an interactive execution surface inside Polyaxon-managed workloads. A sandbox-enabled run can expose command execution, interactive shells, file transfer, background process logs, SSH access, notebooks, and runtime debugging while keeping compute, credentials, artifacts, permissions, and auditability inside Polyaxon.

Use sandboxes to inspect a live environment, run commands against the same image and connections as the workload, iterate on code in-cluster, automate runtime actions from the CLI, or attach local tools through SSH.

Start with the sandboxes guide.

Platform automation

Polyaxon automation is a platform-level feature set for reacting to time, internal state, and external systems. It covers notifications, automated actions, event ingestion, external triggers, cron and interval schedules, and follow-up work kicked off from run, project, or organization events.

Use platform automation when work should happen because something happened: a run finished, an evaluator failed, a webhook arrived, a spend threshold was crossed, or a schedule tick fired.

See events, schedules, scheduled runs, and hooks.

Built-in flow engine

Polyaxon includes a flow engine for authoring workflows, DAGs, and multi-step ML and AI processes. It handles:

  • Queueing and routing.
  • Caching, retries, and restart behavior.
  • Concurrency and parallel execution.
  • Triggers and conditions inside workflows.
  • Dependencies across jobs, services, distributed workloads, tuning runs, Ray, Dask, and Kubeflow operator workloads.
  • Integration with projects, teams, ACL, RBAC, queues, presets, lineage, and artifacts.

The flow engine lets teams move from one-off runs to repeatable workflows without switching execution systems.

See flow engine, orchestration, and DAG automation.

Builds

Polyaxon can build containers for workloads using Dockerfiles, custom build contexts, build steps, init steps, and registry connections. Builds are normal operations, so they can use queues, resources, logs, artifacts, statuses, and permissions instead of living in a separate script.

See builds.

Components and integrations

Components package reusable logic with typed inputs and outputs. They can be used directly, composed into DAGs, attached as hooks, scheduled, shared across teams, or versioned in a public or private hub.

Integrations connect workloads to artifact stores, Git repositories, container registries, notification systems, secrets, service accounts, and external systems through connections, webhooks, API calls, and components.

See component hub and integrations.

Built-in optimization engine

Polyaxon includes an optimization engine for parameter search and tuning. It supports grid search, random search, Bayesian optimization, Hyperband, Hyperopt-backed search, iterative tuning loops, and parallel sweeps.

Optimization runs use the same scheduler as other workloads: queues, routing, resources, concurrency limits, caching, early stopping, lineage, artifacts, and metrics, so search jobs are governed like any other platform work.

See the optimization engine's search algorithms, hyperparameter tuning, and matrix mapping.

AI gateway for LLMs

Polyaxon's AI gateway gives applications and agents a managed path for LLM calls. It supports two modes: a normalized provider interface for provider-agnostic streaming, and a passthrough proxy for native SDKs such as OpenAI-compatible and Anthropic clients.

The gateway centralizes provider credentials, key rotation, cooldowns after provider errors, model listing, request IDs, usage tracking, and organization policy. Applications can call a Polyaxon endpoint instead of carrying provider keys directly, while traces, evaluations, cost, latency, prompts, and model usage stay connected to the same project record.

This also gives platform teams a place to add model aliases, provider routing, fallbacks, rate limits, and guardrails without rewriting every application.

Tracing and observability

Polyaxon supports two related observability problems.

Application tracing records what happens inside LLM applications and agents: requests, sessions, observations, prompts, completions, tool calls, retrieval steps, token usage, latency, cost, metadata, and errors. This gives application teams enough context to debug behavior, compare versions, and connect traces to evaluation results. Gateway-mediated LLM calls can feed the same usage and request context instead of living as separate provider logs.

Platform observability covers the health of the Polyaxon deployment itself: gateway, scheduler, workers, agents, logs, health checks, infrastructure metrics, and error tracking integrations.

See application tracing and platform observability.

Evaluation and alerts

Polyaxon evaluations help teams test LLM applications and agents with datasets, human review, model-based scoring, custom metrics, and live evaluators over production traces.

Evaluations run before release and continue after it: teams can watch for regressions, expensive traces, latency problems, failed scores, and usage changes. Polyaxon also supports operational alerts such as spend thresholds, and events can trigger follow-up operations when internal or external conditions are met.

See evaluations and events.

Tracking and reproducibility

The tracking API records parameters, metrics, code versions, artifacts, logs, resources, metadata, tags, statuses, exceptions, lineage, and run history. Polyaxonfiles define the runtime shape of work: dependencies, inputs, outputs, artifacts, environments, connections, build steps, init steps, and the operation to schedule.

This gives ML teams a reproducible record of how an experiment, job, service, pipeline, or evaluation ran. It also gives reviewers the evidence they need to compare runs, inspect outputs, and understand what changed.

See tracking, runs dashboard, and visualizations.

Registries and versioning

Polyaxon provides registries for models, artifacts, components, and prompts. Teams can version release objects, attach metadata, manage labels, preserve lineage, and connect registry entries to the runs, traces, and evaluations that justify them.

Versioning answers what is live, what changed, who changed it, and what evidence supported the change.

See registry, model registry, artifact versioning, and prompt management.

Scheduling and scale

Polyaxon schedules jobs, services, distributed workloads, notebooks, dashboards, DAGs, matrix runs, and sandbox sessions on Kubernetes. Queues, concurrency limits, priorities, presets, resource requests, GPU settings, node placement, manual approvals, routing rules, caching, retries, backfills, restarts, and termination policies control execution.

Platform teams can scale the gateway, scheduler, compiler, workers, and backing services while keeping agents close to the clusters where workloads run. Agents can route work across namespaces, clusters, and resource pools without forcing users to handle Kubernetes details in every operation.

See scheduling, queues, concurrency, and replication.

Governance

Polyaxon attaches governance to the same projects, workloads, traces, prompts, models, artifacts, and evaluations teams already use. Organizations can manage members, teams, projects, service accounts, connections, presets, RBAC, audit logs, data retention, billing, and access policies.

Access control, audit history, and policy stay attached to the runs, traces, prompts, and models they apply to, so it stays clear who can run jobs, use credentials, view traces, change prompts, promote models, or inspect audit history.

See administration, RBAC, audit logs, and data retention.