# JFrog Fly Documentation > JFrog Fly is an agentic package management platform that enables you to manage, share, and release artifacts directly from your coding agent. It provides seamless integration with AI-powered IDEs, GitHub Actions, and supports all major package managers including npm, pip, Maven, Gradle, Docker, NuGet, and Go. ## Table of Contents - [Docker](https://docs.fly.jfrog.com/package-managers/docker/): Push, pull, and deploy Docker images through Fly Registry. Supports Docker CLI, Buildx, and Podman. - [Fly App](https://docs.fly.jfrog.com/where-to-use-fly/fly-app/): Publish, find releases, and deploy from your coding agent. The Fly App is your local bridge to Fly. - [Get Started](https://docs.fly.jfrog.com/getting-started/): Install Fly, configure your CI, and ship your first release in 5 minutes. - [Git Repositories](https://docs.fly.jfrog.com/fly-platform/git-repositories/): Every commit, PR, and artifact linked automatically once your GitHub repositories are connected. - [Artifacts](https://docs.fly.jfrog.com/fly-platform/artifacts/): Browse, search, and trace every package and image your team produces across all package managers. - [Coding Agent](https://docs.fly.jfrog.com/where-to-use-fly/coding-agent/): Release, deploy, and track from your coding agent in natural language. Decisions captured automatically as you work. - [Deploy Your First Release](https://docs.fly.jfrog.com/getting-started/deploy-your-first-release/): Create a runtime environment, connect your cluster, and deploy your first release. - [From Planning to Production](https://docs.fly.jfrog.com/from-planning-to-production/): The lifecycle of shipping with Fly: plan, release, deploy, distribute, track. Each stage connects to the next, so the why and what stay together. - [Helm](https://docs.fly.jfrog.com/package-managers/helm/): Your Helm charts stored, versioned, and distributed through one registry using the OCI standard. - [Fly Web](https://docs.fly.jfrog.com/where-to-use-fly/fly-web/): Your team's central hub for releases, environments, artifacts, and chat. At fly.jfrog.ai. - [npm](https://docs.fly.jfrog.com/package-managers/npm/): Your private npm packages and public dependencies from npmjs.org, all managed through one registry. - [Releases](https://docs.fly.jfrog.com/fly-platform/releases/): Find, track, and deploy any release by what it contains. Every release connects code, artifacts, and environments. - [Where to Use Fly](https://docs.fly.jfrog.com/where-to-use-fly/): Wherever you work, Fly is with you -- coding agent, CI, terminal, Slack, browser. Use whichever interfaces boost your productivity: one, all, or a mix. - [CI](https://docs.fly.jfrog.com/where-to-use-fly/ci/): Connect your GitHub Actions workflows to Fly once, and every push automatically creates a searchable release with full traceability. - [Concepts](https://docs.fly.jfrog.com/fly-platform/): How Fly connects your code, packages, releases, and deployments into a single traceable chain. - [PyPI](https://docs.fly.jfrog.com/package-managers/pypi/): Your private Python packages and public dependencies from PyPI, all managed through one registry. - [Runtime Environments](https://docs.fly.jfrog.com/fly-platform/runtime-environments/): Track what's running across all your environments. Know what's deployed, when it shipped, and which release produced it. - [Decision Records](https://docs.fly.jfrog.com/fly-platform/decision-records/): Capture the choices behind what your team builds. Your coding agent uses them as context, and every release shows the decisions made to ship it. - [Go](https://docs.fly.jfrog.com/package-managers/go/): Publish Go modules to your team's registry and pull dependencies from proxy.golang.org, all cached and managed through Fly. - [Package Managers](https://docs.fly.jfrog.com/package-managers/): Reference documentation for configuring package types (Docker, Helm, npm, PyPI, .NET, Go, Maven, Gradle, Generic) with JFrog Fly Registry. - [Terminal](https://docs.fly.jfrog.com/where-to-use-fly/terminal/): Publish and install from your terminal. npm publish, docker push, pip install, and mvn deploy all route through your Fly Registry. - [.NET](https://docs.fly.jfrog.com/package-managers/dotnet/): Your private NuGet packages and public dependencies from nuget.org, all managed through one registry. - [FAQ](https://docs.fly.jfrog.com/faq/): Frequently Asked Questions about JFrog Fly: setup, package management, workflows, deployment, and access control. - [Slack](https://docs.fly.jfrog.com/where-to-use-fly/slack/): Get Fly notifications in Slack. Releases, deployments, and your custom watches arrive where your team already works. - [Workflows](https://docs.fly.jfrog.com/fly-platform/workflows/): Every push automatically creates a searchable release with full traceability, no tokens or secrets needed. - [Maven](https://docs.fly.jfrog.com/package-managers/maven/): Your private Maven artifacts and public dependencies from Maven Central, all managed through one registry. - [Tokens](https://docs.fly.jfrog.com/fly-platform/tokens/): Give Kubernetes clusters, CI tools, and external systems secure access to your Fly Registry. - [Gradle](https://docs.fly.jfrog.com/package-managers/gradle/): Your private Gradle artifacts and public dependencies from Maven Central, all managed through one registry. - [Notifications](https://docs.fly.jfrog.com/fly-platform/notifications/): Describe what you care about in plain language, and Fly notifies you in Slack when it happens. - [Generic](https://docs.fly.jfrog.com/package-managers/generic/): Upload, download, and distribute any file through Fly Registry, organized by package name and version. - [Team Management](https://docs.fly.jfrog.com/fly-platform/team-management/): Manage your team's access to Fly. Add members, assign roles, and control permissions. - [Distribution](https://docs.fly.jfrog.com/fly-platform/distribution/): Share artifact versions with your customers so they download or pull them directly, track every download, and revoke access anytime. - [Search](https://docs.fly.jfrog.com/search/) --- # Docker URL: https://docs.fly.jfrog.com/package-managers/docker/ Markdown: https://docs.fly.jfrog.com/package-managers/docker/index.md > Push, pull, and deploy Docker images through Fly Registry. Supports Docker CLI, Buildx, and Podman. --- ## Overview Push, pull, and deploy Docker images through Fly Registry. Your images are stored securely, linked to releases, and tracked all the way to your runtime environments. JFrog Fly supports OCI (Open Container Initiative) native images, ensuring compatibility across container tools like Docker, Docker Buildx, and Podman. --- ## Supported Clients JFrog Fly supports container images built with: - **Docker CLI** (`docker build`, `docker push`, `docker pull`) - The standard Docker command-line interface for building and managing container images - **Docker Buildx** (`docker buildx build --push`) - Docker's extended build capabilities with BuildKit, supporting multi-platform images (e.g., amd64 and arm64), improved caching, and advanced build features - **Podman** (`podman build`, `podman push`, `podman pull`) - Daemonless container engine, fully compatible with Docker images All tools push and pull images using the same registry format, so images built with any tool are fully compatible. --- ## Upload / Push Image ### With Fly App Activate Docker in your Fly App to automatically authenticate, then push your image: ```bash docker push .jfrog.io/docker/my-image:latest ``` ### Manual Configuration **1. Generate an access token** in Fly Token Management **2. Login to Docker:** ```bash docker login .jfrog.io -u -p ``` **3. Push your image:** ```bash docker push .jfrog.io/docker/my-image:latest ``` --- ## Download / Pull Image ### With Fly App Activate Docker in your Fly App to automatically authenticate, then pull your image: ```bash docker pull .jfrog.io/docker/my-image:latest ``` ### Manual Configuration **1. Generate an access token** in Fly Token Management **2. Login to Docker:** ```bash docker login .jfrog.io -u -p ``` **3. Pull your image:** ```bash docker pull .jfrog.io/docker/my-image:latest ``` ### From Public Registry Activate Docker in your Fly App (or login manually as shown above), then pull from public registries. When you pull an image that isn't in your Fly Registry, JFrog Fly automatically fetches it from DockerHub and caches it for future use. ```bash docker pull .jfrog.io/docker/nginx:latest ``` --- ## Push/Pull Images with CI To push and pull Docker images with CI, update your GitHub Actions workflow to include the Fly action. Simply ask your coding agent: **"Configure my workflows with Fly"** and Fly MCP will configure your GitHub Actions workflow yml file, as follows: **1. Add permissions** (top level, after `on:`): ```yaml permissions: contents: read id-token: write ``` **2. Add Fly Action** (after package manager setup steps like `actions/setup-node`, before artifact operations like `npm install`, `docker push`): ```yaml - uses: jfrog/fly-action@v1 # Setup Fly package managers ``` **3. Use the `FLY_REGISTRY_SUBDOMAIN` environment variable** (exported by the Fly action, e.g., `acmecorp.jfrog.io`) in your image path: `${{ env.FLY_REGISTRY_SUBDOMAIN }}/docker/my-app:tag` ### GitHub Action Example ```yaml name: Build and Push Docker Image on: push: branches: [main] permissions: contents: read id-token: write jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - uses: jfrog/fly-action@v1 # Setup Fly package managers - run: docker build -t ${{ env.FLY_REGISTRY_SUBDOMAIN }}/docker/my-app:${{ github.sha }} . # Base images pulled from Fly registry - run: docker push ${{ env.FLY_REGISTRY_SUBDOMAIN }}/docker/my-app:${{ github.sha }} # Push to Fly registry ``` --- ## Deployment to Runtime To deploy your Docker image to your runtime environment, you need a Fly image secret. If you don't have one: - **Option A:** Ask your coding agent to deploy the image, and Fly MCP will add the token in a secure way - **Option B:** Generate a new token in Fly Token Management and add it to your Kubernetes cluster or other container orchestration platform ### Pull Docker Secret to K8s Here's an example of how to create an image pull secret with your Fly credentials: ```bash kubectl create secret docker-registry \ --docker-server=.jfrog.io/docker \ --docker-username= \ --docker-password= \ --namespace= ``` > [!NOTE] > Replace `` with any name you choose (e.g., `fly-registry-secret`). Use `` and `` from Fly Token Management. Use the Fly Registry image path in your deployment: `.jfrog.io/docker/:` **Example:** `acmecorp.jfrog.io/docker/payment-service:v2.3.1` --- ## Distribution Docker images support public distribution -- make a specific image version pullable by anyone without authentication. Once you distribute an image, your customers pull it directly with `docker pull`, no `docker login` required. To manage and track your distributions, see [Distribution →](../../fly-platform/distribution/). ### Distribute with CI Add the distribute step after you push your image: ```yaml - uses: jfrog/fly-action@v1 # Setup Fly - uses: jfrog/fly-action/distribute@v1 # Distribute publicly with: name: myorg/my-image version: '1.0.0' type: docker ``` | Input | Required | Description | |-------|----------|-------------| | `name` | Yes | Image name to distribute | | `version` | Yes | Image tag to distribute | | `type` | Yes | Set to `docker` | ### Public Pull Command Once an image version is distributed, anyone can pull it -- no `docker login`: ``` docker pull .jfrog.io/docker-public/: ``` | Parameter | Description | Example | |-----------|-------------|---------| | `` | Your Fly organization subdomain | `acme` | | `docker-public` | The public Docker registry path (fixed) | `docker-public` | | `` | The Docker image name | `myorg/my-image` | | `` | The distributed image tag | `1.0.0`, `latest` | **Example:** ```bash docker pull acme.jfrog.io/docker-public/myorg/my-image:1.0.0 ``` The public endpoint is pull-only -- pushes are rejected. --- *Back to [Package Managers →](../)* --- # Fly App URL: https://docs.fly.jfrog.com/where-to-use-fly/fly-app/ Markdown: https://docs.fly.jfrog.com/where-to-use-fly/fly-app/index.md > Publish, find releases, and deploy from your coding agent. The Fly App is your local bridge to Fly. --- ## Overview Publish packages, find releases, and deploy to production without leaving your coding agent. Install the Fly App, sign in, and you're ready. It detects your coding agent and your package managers and wires them up to Fly. Authentication, registry configuration, and credential routing run in the background. Talk to your coding agent. Install it first. The other local interfaces depend on it. --- ## What you can do With the Fly App installed, your coding agent, terminal, and package managers can all talk to Fly: - **Publish and find packages.** Your `npm publish`, `docker push`, and `pip install` commands route through Fly as usual. Search later by content: *"Find the release where I fixed the login bug."* - **Ship and track from your coding agent.** Ask your agent to release, deploy, and check what's running. *"Deploy the login fix to staging."* *"Is it live in production?"* - **Agent context management.** Conversations with your coding agent become [Decision Records](../../fly-platform/decision-records/) linked to the releases they shape. The *why* ships with the *what*. --- ## Setup 1. **Download the Fly App.** Click to download at [fly.jfrog.ai/home](https://fly.jfrog.ai/home), or run from your terminal: **macOS** ```bash curl -fsSL https://fly.jfrog.ai/download/desktop | bash ``` **Windows** ```powershell powershell -c "irm https://fly.jfrog.ai/download/desktop | iex" ``` 2. **Sign up or sign in.** 3. **Walk through the onboarding.** The Fly App connects your coding agent, detects your package managers, and shows you the Fly App menu. --- ## The Fly App menu Click the Fly App icon in your menu bar (macOS) or system tray (Windows) to open the menu. From here you can see what's connected, toggle anything on or off, and check your account. ### Coding agents The Fly App scans for supported coding agents on your machine: Cursor, VS Code (Copilot), Claude Code, and OpenCode. Each one shows up in the menu with a toggle. Toggle on the agent you use. The Fly App wires up Fly MCP and Fly skills behind the scenes, registers the config in the right place, and your agent picks up Fly's tools automatically. No manual MCP setup. Talk to your agent. Working across coding agents? Toggle on more than one. Pick your default from your profile. ### Package managers The Fly App scans for the package managers you have installed: npm, pip, Docker, Helm, Go, Maven, and others. Each one shows up in the menu with a toggle. Toggle on the package managers you want to use with Fly. The Fly App reconfigures each one to route through your Fly Registry. Your everyday commands keep working as before: `npm publish` uploads to Fly, `pip install` pulls from Fly, `go get` resolves through Fly. No `.npmrc` edits, no manual login. For Docker and Helm, include the Fly Registry path in your command. Authentication is handled in the background: - `docker push .jfrog.io/docker/my-image:tag` - `helm push my-chart.tgz oci://.jfrog.io/helmoci` Toggle a package manager off any time to skip Fly for that one. Your other tools stay routed. See [Package Managers →](../../package-managers/) for per-tool details. ### Profile Open the Profile to see your identity in Fly: your username, your team, and your Fly Registry subdomain. From here you can also switch your default coding agent, or check whether the Fly App is up to date. ### Settings Click the gear icon in the tray header to open Settings. From here you can control Fly App behavior: - **Capture decision records** -- Toggle whether Fly captures [Decision Records](../../fly-platform/decision-records/) from your coding agent conversations. Enabled by default. Turning this off stops new collection while keeping existing records available as agent context. --- ## Troubleshooting **Package manager not detected?** The Fly App scans standard installation paths. If your tool is in a non-standard location, configure it manually using the Fly Client CLI bundled with the app: `fly setup `. **Coding agent not recognizing Fly?** Make sure the coding agent connection is toggled on in the Fly App menu. If it is on but still not working, toggle it off and back on, then restart your coding agent. If the issue persists, restart the Fly App. Check that the Fly MCP config file exists for your agent: | Coding agent | Config file | |--------------|-------------| | **Cursor** | `.cursor/mcp.json` | | **VS Code (Copilot)** | `Code/User/mcp.json` | | **Claude Code** | `.claude.json` | | **OpenCode** | `opencode.json` | **Can't find the Fly App?** On macOS, look in the menu bar (no Dock icon). On Windows, check the system tray overflow area. **Need to log out?** Open your user profile from the Fly App menu, then click log out. **Grabbing logs for support?** Open your user profile from the Fly App menu and click **Open Logs**. You can also enable **Debug Logging** there for more detailed traces. **Need to sign in again?** Restart the Fly App to re-trigger the sign-in flow. --- ## Next steps - [Coding agent →](../coding-agent/) - The interface where you'll work day to day - [From Planning to Production →](../../from-planning-to-production/) - The lifecycle, end to end - [Where to Use Fly →](../) - All the interfaces --- # Get Started URL: https://docs.fly.jfrog.com/getting-started/ Markdown: https://docs.fly.jfrog.com/getting-started/index.md > Install Fly, configure your CI, and ship your first release in 5 minutes. --- ## Overview Get productive with Fly in 5 minutes. Install the app, connect your repos, and ship your first release. --- ## Get up and running in 5 minutes 1. **Download Fly App** — Install on your machine. 2. **Sign up and create your team** — Your registry lives at `.jfrog.io`. 3. **Start working with Fly** — Ask your coding agent to wire CI in one prompt. 4. **Generate your first release** — Every push creates a tracked release. --- ## 1. Download Fly App The Fly App connects your coding agent, your package managers, and your registry. Install it once on your machine. Download from [jfrog.com/fly](https://jfrog.com/fly/), or run from your terminal: **macOS** ```bash curl -fsSL https://fly.jfrog.ai/download/desktop | bash ``` **Windows** ```powershell powershell -c "irm https://fly.jfrog.ai/download/desktop | iex" ``` Grant the permissions when prompted. The app detects your package managers (npm, pip, Docker, Helm, Maven, Gradle, Go, NuGet) and connects your coding agent (Cursor, Copilot, Claude Code, OpenCode) automatically. --- ## 2. Sign up and create your team Sign up to Fly and pick a team name. This becomes your private Fly Registry at `.jfrog.io`, where all your releases, packages, and images live. The first user becomes the team **Admin** with full permissions. --- ## 3. Start working with Fly Ask your coding agent: *"Start working with Fly"* Your agent asks for access to your GitHub, scans your `.github/workflows/*.yml` files, and opens a pull request that wires your workflows to Fly: - **OIDC permissions** — your workflows authenticate to Fly without any tokens or secrets. - **The Fly action step** — your package managers (npm, Docker, Maven, Helm, etc.) automatically route through your Fly Registry. - **Docker and Helm paths** — image and chart commands include the Fly Registry path inline. The action exports `FLY_REGISTRY_SUBDOMAIN` so you can reference it in your `docker push` and `helm push` commands. Here's what a minimal npm workflow looks like after the PR: ```yaml permissions: # Required for Fly OIDC authentication contents: read id-token: write jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - uses: actions/setup-node@v6 with: node-version: '24' - uses: jfrog/fly-action@v1 # Setup Fly package managers - run: npm install # From Fly Registry - run: npm publish # To Fly Registry ``` And here's what a minimal Docker workflow looks like after the PR: ```yaml permissions: # Required for Fly OIDC authentication contents: read id-token: write jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - uses: jfrog/fly-action@v1 # Setup Fly package managers - run: docker build -t ${{ env.FLY_REGISTRY_SUBDOMAIN }}/docker/my-app:${{ github.sha }} . # Base images pulled from Fly Registry - run: docker push ${{ env.FLY_REGISTRY_SUBDOMAIN }}/docker/my-app:${{ github.sha }} # Push to Fly Registry ``` See [CI](../where-to-use-fly/ci/) for full examples (Go modules, Helm, generic artifacts, distribution). --- ## 4. Generate your first release Review and merge the configuration PR. Every push from then on creates a Fly release linked to the commit, PR, author, and an AI-generated summary. No secrets to manage. Every release is searchable by content. Ask your coding agent anything: - *"Show me my latest release"* - *"Find the release that fixed the login bug"* - *"What's in the release from yesterday?"* You can also browse all your releases at [fly.jfrog.ai](https://fly.jfrog.ai). --- ## Next steps - [Deploy Your First Release →](deploy-your-first-release/) - Deploy your first release in 10–15 minutes - [Where to Use Fly →](../where-to-use-fly/) - The interfaces in depth - [From Planning to Production →](../from-planning-to-production/) - The full lifecycle --- # Git Repositories URL: https://docs.fly.jfrog.com/fly-platform/git-repositories/ Markdown: https://docs.fly.jfrog.com/fly-platform/git-repositories/index.md > Every commit, PR, and artifact linked automatically once your GitHub repositories are connected. --- ## Overview Every commit, PR, and artifact linked automatically once your GitHub repositories are connected. Repositories are the starting point for everything in Fly. By connecting your GitHub repositories, you give Fly the context it needs to link artifacts to code, generate meaningful release summaries, and provide full traceability from commit to deployment. When you connect a GitHub organization, Fly gains visibility into your repositories, watches their workflows, and tracks the artifacts and releases they produce. The connection is established through the GitHub App integration, which you can set up from your coding agent by asking *"Start working with Fly"* or directly from Fly Web. --- ## How It Works ### Connection Model Fly connects to your GitHub organization via a GitHub App. Once installed, you choose which repositories Fly can access. Fly automatically syncs when you add or remove repositories. ### Configuration Status Each repository has one of two statuses: **Configured** -- At least one workflow is set up with the Fly action. Artifacts are being tracked, releases are being created, and full traceability is active. **Not Configured** -- The repository is connected to Fly but no workflows are configured yet. Fly can see it, but it's not producing artifacts or releases. ### What Fly Tracks Per Repository - Artifacts produced by workflows and local uploads - Releases from configured workflow runs - Workflow files and their configuration status - Links to GitHub source --- ## From Your Coding Agent The fastest way to connect repositories and configure workflows is through your coding agent. Fly handles the GitHub authorization, scans your workflows, and opens PRs with the required changes. ### Connect Your Organization *"Start working with Fly"* Fly walks you through GitHub authorization, connects your repositories, scans your workflows, and opens a PR with CI configuration. ### Configure Workflows *"Configure my workflows with Fly"* Fly scans your `.github/workflows/*.yml` files and opens a pull request with the required changes. [Learn more →](../../where-to-use-fly/ci/) ### Manage Repositories To add or remove GitHub organizations or repositories after initial setup, use the **Manage Org & Repositories** button in Fly Web, which redirects to GitHub to manage permissions. --- ## In Fly Web Fly Web gives your team a visual overview of all connected repositories, their configuration status, and quick access to each repository's artifacts, releases, and workflows. ### Repository List Navigate to **Git Repositories** to see all connected repositories from your selected GitHub organization. | Column | Description | |--------|-------------| | **Repository Name** | Full repository name (org/repo) | | **Status** | Configured or Not Configured | | **Last Activity** | Most recent artifact or release | | **Artifacts** | Number of artifacts and package types | ### Repository Details Click any repository to access: - **Artifacts** -- Packages and images associated with this repository - **Releases** -- Complete history of CI/CD runs with AI-generated summaries - **Workflows** -- GitHub Actions workflow files and their configuration status ### Actions - **Configure Workflows** -- Appears for unconfigured repositories. Opens the coding agent flow or manual configuration - **View on GitHub** -- Opens the repository on GitHub - **Manage Org & Repositories** -- Redirects to GitHub to manage which repositories Fly can access --- ## Next Steps - [Artifacts →](../artifacts/) - Packages and images stored in Fly - [Releases →](../releases/) - AI-generated release summaries - [Workflows →](../workflows/) - CI/CD configuration - [CI →](../../where-to-use-fly/ci/) - Configure your CI --- # Artifacts URL: https://docs.fly.jfrog.com/fly-platform/artifacts/ Markdown: https://docs.fly.jfrog.com/fly-platform/artifacts/index.md > Browse, search, and trace every package and image your team produces across all package managers. --- ## Overview Browse, search, and trace every package and image your team produces. An artifact is any package, library, or container image that your team builds or depends on: npm packages, Docker images, Helm charts, Python wheels, Maven JARs, Go modules, and more. In Fly, artifacts are the building blocks of your releases. Every artifact your team publishes ends up in Fly Registry, where it's stored securely, linked back to the code that produced it, and available to your entire team. Fly also caches public dependencies so your builds are faster and more reliable. - **Uploaded Artifacts** -- Packages you or your team have published (from CI/CD or local development) - **Public Dependencies** -- Packages from public registries (npm, PyPI, Maven Central, DockerHub, etc.) that have been cached in Fly All artifacts are stored in your private Fly Registry at `.jfrog.io`. --- ## How It Works ### Lifecycle **Upload** -- Artifacts are published in two ways: 1. **CI Workflows** -- GitHub Actions workflows automatically upload artifacts when the Fly action is configured. [Learn more →](../../where-to-use-fly/ci/) 2. **Local Development** -- Upload from your workstation using standard package manager commands. The Fly App handles authentication automatically. [Learn more →](../../where-to-use-fly/terminal/) **Storage** -- All artifacts are stored in your Fly Registry with secure, encrypted storage. **Download** -- Artifacts can be downloaded by team members, CI/CD workflows (via OIDC), and external systems (via tokens). **Public Dependencies** are automatically cached when first requested from public registries. ### Artifact Identity Each artifact has: - **Name** -- The package name - **Type** -- Package manager type (npm, docker, helm, oci, pip, etc.) - **Version** -- Version identifier - **Git Repository** -- The repository that produced it (if available) Artifacts with the same name are grouped together, with the latest version shown by default. ### Docker and OCI Co-Tags When the same Docker or OCI image has multiple tags (like `latest` and `v1.2.3` pointing to the same digest), Fly shows it as a single entry with all tags listed together -- not as duplicate rows. You see one row per unique image. --- ## From Your Coding Agent Your coding agent can publish, find, and manage artifacts using natural language. The Fly App handles authentication and registry routing in the background -- no manual configuration needed. ### Publish Artifacts *"Publish this npm package to Fly"* *"Push this Docker image"* Your coding agent handles authentication and routing. [Learn more →](../../where-to-use-fly/terminal/) ### Find Artifacts *"Find my latest artifact"* *"Show me all npm packages uploaded this week"* Fly searches across your artifacts to find what you need. --- ## In Fly Web Fly Web lets you browse all artifacts across your registry, drill into version history, and manage artifacts visually. You can view artifacts across your entire team or scoped to a specific Git repository. ### Artifact Views **All Artifacts Tab** -- Every artifact in your Fly Registry, including those without Git repository association. **Git Repository View** -- Navigate to a specific repository to see its associated artifacts. ### List View | Column | Description | |--------|-------------| | **Name** | Artifact package name | | **Type** | Package manager type | | **Latest Version** | Most recent version number | | **Last Updated** | When the latest version was uploaded | | **Git Repository** | Repository that produced the artifact | Click any artifact to see its detail view with specific version details and complete version history. ### Actions - **Download** -- Use standard package manager commands or ask your coding agent - **Manage Distribution** -- Make a version public and manage it - **Delete Versions** -- Admins can select and permanently delete artifact versions from the detail page. > [!WARNING] > Deleting a Docker or OCI version also removes every co-tag that shares the same manifest digest. If `latest` and `v1.2.3` point to the same digest, deleting one removes both. --- ## Next Steps - [Git Repositories →](../git-repositories/) - Repositories that produce artifacts - [Releases →](../releases/) - Releases that produce artifacts - [Package Managers →](../../package-managers/) - Registry configuration for each package manager - [Terminal →](../../where-to-use-fly/terminal/) - Build, install, and publish packages on your machine - [Distribution →](../distribution/) - Track downloads and manage your distributions --- # Coding Agent URL: https://docs.fly.jfrog.com/where-to-use-fly/coding-agent/ Markdown: https://docs.fly.jfrog.com/where-to-use-fly/coding-agent/index.md > Release, deploy, and track from your coding agent in natural language. Decisions captured automatically as you work. --- ## Overview Release, deploy, and track without leaving your coding agent. No dashboard, no commands to memorize, no context switch. --- ## What you can do Your coding agent knows your Fly registry: every release, every environment, every team decision. Anything you can do in Fly, it can do too. - **Develop with Agent context.** Your agent has every past team decision at hand. As you work, the relevant ones surface. Your own conversations join automatically as [Decision Records](../../fly-platform/decision-records/) on the release they shape. - **Release.** Ship a new version with full traceability. If your repo or CI isn't set up for Fly yet, your agent will handle it for you. - **Runtime Deploy & Track.** Deploy releases to any environment, and see what's running. *"Deploy the login fix to staging."* *"Is the login fix live in production?"* - **Distribute.** Ship artifacts to customers, partners, or the public. *"Distribute the new SDK to our partner channel."* Or have your agent set up your CI to distribute automatically on each release. - **Upload and download artifacts locally.** Move binaries, installers, or one-off files. *"Upload my docker image to Fly."* *"Get the artifact from yesterday's release."* - **Find anything by content.** Search releases, deployments, and what's running across your environments semantically. *"Find the release where I fixed the login bug."* *"What's running in production right now?"* - **Manage notifications.** Add, edit, or remove watches directly from your coding agent. *"Watch for security fixes that reach prod."* --- > [!NOTE] > Works with **Cursor**, **VS Code (Copilot)**, **Claude Code**, and **OpenCode**. Requires the [Fly App](../fly-app/) installed with the agent toggle active. ## How it works When the Fly App connects your agent, it adds Fly's MCP tools (direct actions on Fly) and Fly skills (guided flows like deploying to k8s or configuring CI workflows). That means you can ask your agent anything you'd do in Fly: - *"Is the login fix in production?"* - *"Distribute this version to our partners."* - *"Notify me when David deploys to production."* --- ## Next steps - [From Planning to Production →](../../from-planning-to-production/) - Ship a package, end to end - [Deploy Your First Release →](../../getting-started/deploy-your-first-release/) - The full deploy and track flow - [Where to Use Fly →](../) - The other interfaces --- # Deploy Your First Release URL: https://docs.fly.jfrog.com/getting-started/deploy-your-first-release/ Markdown: https://docs.fly.jfrog.com/getting-started/deploy-your-first-release/index.md > Create a runtime environment, connect your cluster, and deploy your first release. --- ## Overview Know what's running across your environments. Connect a runtime to Fly once, and every image pull becomes a tracked deployment automatically. No more checking dashboards or running kubectl to see what's live. Ask your coding agent and you'll see what's deployed where, when, and by whom. --- ## Deploy and track 1. **Create a runtime environment** — Your release target in Fly (staging, production, etc.). 2. **Connect your namespace** — Your cluster pulls from your Fly Registry. 3. **Deploy your release** — Your release lands in the environment. 4. **Track what's running** — You know what's live, everywhere. --- ## 1. Create a runtime environment Ask your coding agent: *"Create a staging environment"* Your agent creates the environment in Fly. (You can also create one from Fly Web.) --- ## 2. Connect your namespace Ask your coding agent: *"Set up my K8s to work with Fly"* Fly generates a token, associates it with your environment, and gives you the commands to apply. You can also generate tokens from Fly Web. Create the image pull secret: ```bash kubectl create secret docker-registry fly-registry-secret \ --docker-server=.jfrog.io/docker \ --docker-username= \ --docker-password= \ --namespace= ``` Reference it in your deployment: ```yaml spec: template: spec: imagePullSecrets: - name: fly-registry-secret containers: - name: my-app image: .jfrog.io/docker/: ``` Once connected, Fly tracks every image pull automatically. --- ## 3. Deploy your release Deploy as you always have. Your existing workflow keeps working (kubectl apply, GitOps, ArgoCD, Helm, and so on). Just point your image references at your Fly Registry: `.jfrog.io/docker/:`. Or ask your coding agent: *"Deploy the latest release to staging"* Fly finds the release, and your agent updates your Kubernetes deployment. Once the new image is pulled, Fly tracks it as a deployment event. --- ## 4. Track what's running Once your environment is connected, every deployment is tracked automatically. Ask your coding agent anything: - *"What's running in production?"* - *"Is the login fix live in staging?"* - *"Compare staging and production"* You'll see exactly what's deployed where, when it landed, and who shipped it. --- ## Next steps - [From Planning to Production →](../../from-planning-to-production/) - The full lifecycle story - [Runtime Environments →](../../fly-platform/runtime-environments/) - The environment model - [Where to Use Fly →](../../where-to-use-fly/) - The interfaces in depth --- # From Planning to Production URL: https://docs.fly.jfrog.com/from-planning-to-production/ Markdown: https://docs.fly.jfrog.com/from-planning-to-production/index.md > The lifecycle of shipping with Fly: plan, release, deploy, distribute, track. Each stage connects to the next, so the why and what stay together. --- ## Overview Your team and your agents always have the full story of your product development lifecycle. Fly captures decisions, releases, deployments, and distributions as you work. {{< mermaid >}} flowchart LR A[Plan & Develop] --> B[Release] B --> C[Deploy to Runtime] B --> D[Distribute] {{< /mermaid >}} --- ## Plan and Develop — capture context as you work As your team plans and develops with coding agents, Fly turns the decisions you make into shared context for every coding agent on your team. Your product builds up a layer of accumulated knowledge: the trade-offs, the approaches, the reasoning behind your choices. Every agent on your team draws from it. From the next coding session forward, every agent on your team has the new context. Whether they're working on auth, payments, or anything else, they draw from the decisions your team just made. This context lives in Decision Records, attached to the releases they shaped. ### How decisions become Decision Records Fly captures your coding conversations in the background. When a release is created, Fly reviews the conversations that led up to it and identifies the substantive decisions: trade-offs weighed, approaches debated, choices made. Each becomes a Decision Record attached to the release. They emerge from the work you were already doing. See [Decision Records →](../fly-platform/decision-records/) for the entity model. --- ## Release — every push tells a story Every push that produces an artifact creates a Fly release. The release captures everything about what shipped, in a form your team and your agents can query later. ### What a release contains, and why - **The artifact** — the package, image, or binary you produced - **Source links** (PRs, commits, author) — so the release traces back to its code origins - **AI-generated summary** — a plain-language description that enables semantic search later - **Decision Records** — links to the planning conversations that shaped this release - **Workflow run** — the CI run or terminal command that produced it, for full provenance Each piece does a lifecycle job. Source links anchor the release to its code. The summary makes it searchable. Decision Records carry the *why*. The workflow run is the audit trail. ### How releases are triggered Once `jfrog/fly-action@v1` is in your workflow, every push that produces an artifact creates a release. Most production releases run through CI. ### Search by content, not by version The releases you accumulate become a searchable history. Prompt your coding agent or browse in Fly Web. Ask in plain language: - *"Find the release where I fixed the login bug."* - *"What's the latest release with auth changes?"* - *"Show me all releases from payment-service this week."* Fly matches semantically against PR titles, commit messages, the AI summary, and linked Decision Records. You don't need to remember version numbers. See [Releases →](../fly-platform/releases/) for the entity model, status states, and management operations. --- ## Deploy to Runtime — know what's running When a release lands in a runtime environment, Fly captures it as a deployment event. You stop guessing what's running and start asking. ### What's a deployment event, and why it matters A deployment event is created when a release lands in a connected runtime environment. The event captures: - **The image** — exactly which tag was pulled - **The environment** — which runtime (staging, production, etc.) - **The release** — links back to the Fly release that produced the image - **When** — timestamp of the pull - **Who** — the user or system that triggered the deploy Each event ties a running container back to the release record, and through the release to the PRs, commits, and decisions behind it. ### How deployments are tracked Tracking is automatic once your runtime environment is connected. You don't instrument your CD or add steps. The mechanism: image pulls from your Fly Registry leave a server-side trace, and Fly correlates each pull to a release. This means your existing CD keeps working: kubectl apply, GitOps, ArgoCD, Helm. Whatever pulls an image gets tracked. ### Multi-environment patterns Connect each runtime environment to Fly (e.g. `staging`, `production`, `eu-prod`). Each gets its own deployment history. For any release, you see: - Which environments it has reached - When it landed in each one - Who deployed it - What was previously running there Ask *"is the auth fix live in production?"* or *"show me deployments to staging in the last 24 hours."* See [Runtime Environments →](../fly-platform/runtime-environments/) for the environment model and connection setup. --- ## Distribute — reach your customers Distribute a release to make it publicly accessible outside your team. Fly keeps a full audit trail of who distributed what, when. ### What's in the audit trail, and why For every distribution event, Fly captures: - **Who** distributed it — the user or system that triggered the distribution - **What** — the release and artifact distributed - **When** — timestamp - **Public access state** — whether the version is currently public The audit trail lets compliance, security, and product teams answer *who got what, and when*. Public access can be revoked; the revocation is in the audit trail too. ### How to distribute **In your CI.** Add a distribute step after your build step. Every successful push distributes the release automatically. See [CI →](../where-to-use-fly/ci/) for a full workflow example. **Via your coding agent.** Ask *"Distribute this version publicly."* **In Fly Web.** Open a release, select the artifact you want to distribute, and click **Distribute**. See [Distribution →](../fly-platform/distribution/) for distribution targets, public URL configuration, and management. --- ## Next steps - [Get Started →](../getting-started/) - Install Fly and ship your first release - [Where to Use Fly →](../where-to-use-fly/) - The interfaces in depth - [Concepts →](../fly-platform/) - The entity models --- # Helm URL: https://docs.fly.jfrog.com/package-managers/helm/ Markdown: https://docs.fly.jfrog.com/package-managers/helm/index.md > Your Helm charts stored, versioned, and distributed through one registry using the OCI standard. --- ## Overview Your Helm charts stored, versioned, and distributed through one registry using the OCI standard. JFrog Fly supports Helm charts via OCI (Open Container Initiative) registry, ensuring compatibility with Helm 3.8+ and modern chart workflows. --- ## Supported Clients JFrog Fly supports Helm charts with: - **Helm CLI** (`helm push`, `helm pull`, `helm install`) - The standard Helm command-line tool (Helm 3.8+) --- ## Upload / Push Chart ### With Fly App Activate Helm in your Fly App to automatically authenticate, then push your chart: ```bash helm push my-chart-1.0.0.tgz oci://.jfrog.io/helmoci ``` ### Manual Configuration **1. Generate an access token** in Fly Token Management **2. Login to the Helm OCI registry:** ```bash helm registry login .jfrog.io -u -p ``` **3. Package your chart** (if not already packaged): ```bash helm package my-chart/ ``` **4. Push your chart:** ```bash helm push my-chart-1.0.0.tgz oci://.jfrog.io/helmoci ``` --- ## Download / Pull Chart ### With Fly App Activate Helm in your Fly App to automatically authenticate, then pull your chart: ```bash helm pull oci://.jfrog.io/helmoci/my-chart --version 1.0.0 ``` ### Manual Configuration **1. Generate an access token** in Fly Token Management **2. Login to the Helm OCI registry:** ```bash helm registry login .jfrog.io -u -p ``` **3. Pull your chart:** ```bash helm pull oci://.jfrog.io/helmoci/my-chart --version 1.0.0 ``` ### Install Directly You can install a chart directly from Fly Registry without pulling first: ```bash helm install my-release oci://.jfrog.io/helmoci/my-chart --version 1.0.0 ``` --- ## Push/Pull Charts with CI To push and pull Helm charts with CI, update your GitHub Actions workflow to include the Fly action. Simply ask your coding agent: **"Configure my workflows with Fly"** and Fly MCP will configure your GitHub Actions workflow yml file, as follows: **1. Add permissions** (top level, after `on:`): ```yaml permissions: contents: read id-token: write ``` **2. Add Fly Action** (after setup steps, before artifact operations): ```yaml - uses: jfrog/fly-action@v1 # Setup Fly package managers ``` **3. Push your chart using your Fly registry path:** `oci://${{ env.FLY_REGISTRY_SUBDOMAIN }}/helmoci` ### GitHub Action Example ```yaml name: Package and Push Helm Chart on: push: branches: [main] permissions: contents: read id-token: write jobs: helm: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - uses: jfrog/fly-action@v1 # Setup Fly package managers - run: helm package my-chart/ - run: helm push my-chart-1.0.0.tgz oci://${{ env.FLY_REGISTRY_SUBDOMAIN }}/helmoci # Push to Fly registry ``` --- *Back to [Package Managers →](../)* --- # Fly Web URL: https://docs.fly.jfrog.com/where-to-use-fly/fly-web/ Markdown: https://docs.fly.jfrog.com/where-to-use-fly/fly-web/index.md > Your team's central hub for releases, environments, artifacts, and chat. At fly.jfrog.ai. --- ## Overview Browse releases, compare environments, and manage your team. All at [fly.jfrog.ai](https://fly.jfrog.ai). Fly Web is your team's web hub. See everything that happens with your team and product: releases, environments, artifacts, repositories, members, tokens. Fly Chat is built into every page. --- ## What you can do Manage your team and your product from one web interface. - **Track releases.** Follow every release from creation to deployment. See what changed, what PRs landed, what artifacts shipped, and where it's running. - **Manage your runtime environments.** Connect new environments, configure them, and compare them live. See every deployment that landed in each one. - **Distribute releases.** Ship artifacts to customers, partners, or the public. - **Manage your Git repositories.** Connect your GitHub repos to Fly so releases and artifacts trace back to source. - **Manage your team.** Invite members, assign roles, create and revoke tokens. See [Team Management](../../fly-platform/team-management/) for roles and permissions. --- ## Fly Chat Fly Chat lets you ask questions or perform any action you'd do in Fly Web, directly from the chat. - *"Show me the latest release from payment-service."* - *"Find the release where I fixed the login bug."* - *"What's running in production?"* - *"Is the authentication fix live in staging?"* - *"Compare staging vs production."* ### Thread history Every conversation in Fly Chat is saved. Open the **History** panel to browse past threads, resume where you left off, or delete threads you no longer need. Start a new thread anytime to switch context. ### Auto-navigation Fly Chat doesn't just answer, it takes you there. When auto-navigation is on, Fly opens the relevant page after answering. Toggle it on or off from the chat footer. ### Follow-up suggestions After each reply, Fly suggests follow-up prompts based on the conversation. Click any suggestion to keep going. --- ## Next steps - [Releases →](../../fly-platform/releases/) - The release model, end to end - [Runtime Environments →](../../fly-platform/runtime-environments/) - Connect a cluster, see deployments - [Distribute →](../../from-planning-to-production/) - Ship artifacts to customers and partners - [Where to Use Fly →](../) - The other interfaces --- # npm URL: https://docs.fly.jfrog.com/package-managers/npm/ Markdown: https://docs.fly.jfrog.com/package-managers/npm/index.md > Your private npm packages and public dependencies from npmjs.org, all managed through one registry. --- ## Overview Your private npm packages and public dependencies from npmjs.org, all managed through one registry. --- ## Supported Clients JFrog Fly supports npm packages built with: - **npm CLI** (`npm publish`, `npm install`) - The standard Node.js package manager included with Node.js - **pnpm** (`pnpm publish`, `pnpm install`) - Fast, disk-space-efficient package manager --- ## Upload / Publish Package ### With Fly App Activate npm in your Fly App to configure your `.npmrc` globally with Fly, then publish as usual: ```bash npm publish ``` **Using pnpm:** ```bash pnpm publish ``` ### Manual Configuration **1. Generate an access token** in Fly Token Management **2. Configure npm** in your project or home directory. Create or edit `.npmrc`: ```ini registry=https://.jfrog.io/artifactory/api/npm/npm/ //.jfrog.io/artifactory/api/npm/npm/:_authToken= ``` **3. Publish:** ```bash npm publish ``` **Using pnpm:** ```bash pnpm publish ``` > [!IMPORTANT] > You cannot publish a package version that already exists. Increment the version in your `package.json` before publishing again. --- ## Download / Install Package ### With Fly App Activate npm in your Fly App to configure your `.npmrc` globally with Fly, then install as usual: ```bash npm install ``` **Using pnpm:** ```bash pnpm install ``` ### Manual Configuration **1. Generate an access token** in Fly Token Management **2. Configure npm** in your project or home directory. Create or edit `.npmrc`: ```ini registry=https://.jfrog.io/artifactory/api/npm/npm/ //.jfrog.io/artifactory/api/npm/npm/:_authToken= ``` **3. Install:** ```bash npm install ``` **Using pnpm:** ```bash pnpm install ``` ### From Public Registry When you install a package that isn't in your Fly Registry, JFrog Fly automatically fetches it from npmjs.org and caches it for future use. ```bash npm install express ``` **Using pnpm:** ```bash pnpm install express ``` --- ## Publish/Install Packages with CI To publish and install npm packages with CI, update your GitHub Actions workflow to include the Fly action. Simply ask your coding agent: **"Configure my workflows with Fly"** and Fly MCP will configure your GitHub Actions workflow yml file, as follows: **1. Add permissions** (top level, after `on:`): ```yaml permissions: contents: read id-token: write ``` **2. Add Fly Action** (after `actions/setup-node`, before npm commands): ```yaml - uses: jfrog/fly-action@v1 # Setup Fly package managers ``` ### GitHub Action Example ```yaml name: Build and Publish npm Package on: push: branches: [main] permissions: contents: read id-token: write jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - uses: actions/setup-node@v6 with: node-version: '24' - uses: jfrog/fly-action@v1 # Setup Fly package managers - run: npm install # Dependencies from Fly registry - run: npm run build - run: npm publish # Publish to Fly registry ``` --- *Back to [Package Managers →](../)* --- # Releases URL: https://docs.fly.jfrog.com/fly-platform/releases/ Markdown: https://docs.fly.jfrog.com/fly-platform/releases/index.md > Find, track, and deploy any release by what it contains. Every release connects code, artifacts, and environments. --- ## Overview Find, track, and deploy any release by what it contains, not by version numbers. A release represents a complete snapshot of what was built and shipped in a single CI run. Unlike traditional version numbers or GitHub releases, a Fly release connects everything: the code changes (PRs and commits), the artifacts produced (packages and images), who triggered it, and where it's currently running. This means you can find any release by *what it contains* -- "the release where I fixed the login bug" -- rather than memorizing version numbers or run IDs. Every release gets an AI-generated summary and the decisions behind the changes -- what shipped, and why. Releases are automatically created every time a configured workflow pushes an artifact to Fly Registry. --- ## How It Works ### What's in a Release | Component | Description | |-----------|-------------| | **Release Title** | A short, descriptive name with an icon signaling the type of change (e.g., "CVE-2026-1234 Base Image Fix"). Auto-generated by Fly. Editable. | | **Release Description** | A one-line summary shown as a hover preview. Auto-generated. Editable. | | **Release Summary** | A full structured breakdown: overview, changes, and notes about breaking changes or migration steps. | | **Run Number** | The workflow run number (e.g., `#141`). | | **Triggered By** | The GitHub user who ran the workflow. | | **Artifacts** | All packages and images produced, with types and versions. | | **Commits** | All commits included, with links to GitHub. | | **Pull Requests** | PRs merged in this release, with links to GitHub. | | **Decision Records** | The choices your team made during the work that produced this release. Auto-captured from your developer-agent conversations. | | **Workflow** | The GitHub Actions workflow that produced this release, with a link to the run. | | **Generation Time** | When the release was created. | | **Environment Badges** | Environments this release is currently running in. | ### How Releases Are Generated A release is automatically created when: 1. A GitHub Actions workflow runs 2. The workflow has the Fly action configured 3. The workflow successfully uploads at least one artifact to Fly Registry ### Semantic Search Releases are searchable using natural language. Fly searches through titles, descriptions, summaries, commits, PRs, and metadata. Edited titles and descriptions are included in search results. --- ## From Your Coding Agent Your coding agent can find, explore, and deploy releases using natural language. Fly uses semantic search to match your intent -- you don't need to remember version numbers or run IDs. ### Find Releases *"Find the release where I fixed the login bug"* *"Show me Jon's last deployment"* *"Releases from last week with API changes"* *"Show releases running in staging"* You can scope searches by environment name, author, date range, or any combination. Add "Fly release" to your query to help focus the search. ### Deploy Releases *"Deploy the login fix to staging"* *"Deploy payment-service v2.3.1 to production"* Fly uses semantic release data to find what you mean and handles the deployment. [Learn more →](../runtime-environments/) --- ## In Fly Web Fly Web provides a rich release explorer with filtering, sorting, semantic search, and inline editing. Browse releases per repository, filter by workflow or author, and drill into any release for full details. ### Release List Navigate to **Git Repositories** → select a repository → **Releases** tab. Each release shows: | Field | Description | |-------|-------------| | **Release Title** | Name with icon and run number | | **Release Description** | Hover preview of what changed | | **Triggered By** | GitHub user avatar and username | | **Generation Time** | Relative time (e.g., "2 hours ago") | | **Environment Badges** | Which environments are running this release | | **Status** | Indicator if the release was incomplete | ### Workflow Selector If a repository has multiple configured workflows, a selector at the top lets you focus on one workflow or view all together. The URL updates for bookmarking. ### Fly Chat Search and track releases from anywhere in Fly Web using natural language. Type your question and Fly surfaces matching releases. Example: *"Find the release where I fixed the login bug"* ### Filtering and Search | Filter | Description | |--------|-------------| | **Workflow** | Releases from a specific workflow or all | | **Release Author** | Filter by who triggered the release | | **Running on Environment** | Releases deployed to a specific environment | | **Date Range** | Last 24 hours, 7 days, or 14 days | ### Editing Click on a release's **Title** or **Description** to edit. Changes are saved immediately and reflected in semantic search. ### Distribution Distribute a release's artifacts publicly so customers can download them with a shareable URL. Select a release, open the actions menu, and select **Manage Distribution** to toggle distribution on. [Learn more about distribution →](../distribution/) --- ## From Slack Use `/fly` in Slack to search and track releases with natural language -- the same queries that work in Fly Chat. Example: *"What's running in production?"* --- ## Next Steps - [Runtime Environments →](../runtime-environments/) - Deploy releases and track what's running - [Decision Records →](../decision-records/) - The decisions behind every release - [Distribution →](../distribution/) - Distribute artifacts to your customers - [Workflows →](../workflows/) - CI/CD configuration that generates releases - [CI →](../../where-to-use-fly/ci/) - The automation story --- # Where to Use Fly URL: https://docs.fly.jfrog.com/where-to-use-fly/ Markdown: https://docs.fly.jfrog.com/where-to-use-fly/index.md > Wherever you work, Fly is with you -- coding agent, CI, terminal, Slack, browser. Use whichever interfaces boost your productivity: one, all, or a mix. --- ## Overview Wherever you work, Fly is with you. It's in your coding agent, your CI, your terminal, Slack, and your browser. Use whichever interfaces boost your productivity: one, all, or a mix. --- ## Interfaces - **[Fly App](fly-app/)** — The bridge between your local tools and Fly. Installs once, runs in your menu bar (macOS) or system tray (Windows). Detects your package managers and coding agents and handles authentication automatically. Install it first; the others depend on it. - **[Coding agent](coding-agent/)** — Where you develop and ship. Fly integrates with your IDE through Fly MCP and skills. Ask anything: *"release a new version"*, *"show me the release that fixed authentication"*, *"what's running in production?"* - **[Fly Web](fly-web/)** — Your team's central hub at fly.jfrog.ai. Browse releases, compare environments, view artifacts, manage repositories and team access. Fly Chat is built into every page. - **[CI](ci/)** — Where your release pipeline runs. Configure your workflows once with your coding agent. Every push that produces an artifact becomes a tracked release, automatically. - **[Terminal](terminal/)** — For direct artifact work. Upload or download from your shell: `npm publish`, `docker push`, `helm upload`. They all land in your Fly Registry; the Fly App handles auth in the background. - **[Slack](slack/)** — Where notifications arrive. Get pinged when security fixes hit prod, deploys fail, or something you watched happens. You can also ask Fly quick questions in any channel. --- ## Next steps - [From Planning to Production](../from-planning-to-production/) - The lifecycle, end to end - [Get Started](../getting-started/) - Install and ship your first release --- # CI URL: https://docs.fly.jfrog.com/where-to-use-fly/ci/ Markdown: https://docs.fly.jfrog.com/where-to-use-fly/ci/index.md > Connect your GitHub Actions workflows to Fly once, and every push automatically creates a searchable release with full traceability. --- ## Overview Connect your GitHub Actions workflows to Fly once, and every push automatically publishes your artifacts and creates a release with full traceability. Once your CI is connected, every push to your repository automatically: - **Publishes artifacts** to your team's Fly Registry (npm packages, Docker images, Helm charts, etc.) - **Creates a release** with full traceability from commit to artifact - **Links everything together**: commits, pull requests, artifacts, and releases — all connected - **Finds releases by content**, not just version numbers. Ask your coding agent *"what release contains this fix?"* and get an answer Connect once, and it works for every push going forward. --- ## Connect your CI Connect once. Every workflow run that produces an artifact automatically creates a release in Fly. 1. **Prompt your coding agent:** *"Start working with Fly"* Make sure the Fly App is running and your coding agent is connected. 2. **Review and merge the PR.** Fly scans your `.github/workflows/*.yml` files and opens a PR that includes: - **OIDC Permissions** ```yaml permissions: contents: read id-token: write ``` - **Fly Action** ```yaml - uses: jfrog/fly-action@v1 # Setup Fly package managers ``` - **Docker and Helm paths** — if your workflow uses Docker or Helm, Fly includes the registry path as `FLY_REGISTRY_SUBDOMAIN` so you can reference it in your `docker push`, `docker pull`, `helm push`, and `helm pull` commands. **Example — Docker workflow** ```yaml permissions: # Required for Fly OIDC authentication contents: read id-token: write jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - uses: jfrog/fly-action@v1 # Setup Fly package managers - run: docker build -t ${{ env.FLY_REGISTRY_SUBDOMAIN }}/docker/my-app:${{ github.sha }} . - run: docker push ${{ env.FLY_REGISTRY_SUBDOMAIN }}/docker/my-app:${{ github.sha }} ``` > [!NOTE] > **Prefer to edit the YAML yourself?** Add the OIDC permissions block and the Fly action step to your `.github/workflows/*.yml` files directly. Place the **permissions block** at the top level (after `on:` and before `jobs:`), and the **Fly action step** inside your job (before artifact operations like `npm publish` or `docker push`). --- ## Skip specific package managers from CI By default, the Fly action configures every supported package manager on the runner. To skip specific ones, use the `ignore` input: ```yaml - uses: jfrog/fly-action@v1 with: ignore: docker,pip ``` --- ## Upload & download generic artifacts Upload and download files that aren't standard packages (binaries, archives, test results) to and from Fly. After the Fly action step in your workflow, add the upload or download action with a package name, version, and the files to include. **Upload:** ```yaml - uses: jfrog/fly-action/upload@v1 with: name: my-app version: '1.0.0' files: | dist/app.zip dist/app.tar.gz ``` **Download:** ```yaml - uses: jfrog/fly-action/download@v1 with: name: my-app version: '1.0.0' files: | app.zip output-dir: ./downloads ``` --- ## Distribute with CI Make your generic artifact versions available for your customers to download. ```yaml - uses: jfrog/fly-action/distribute@v1 # Distribute publicly with: name: my-app version: '1.0.0' type: generic ``` To distribute multiple artifacts, add a separate step for each one. See [Distribution →](../../fly-platform/distribution/) for full details on download URLs, managing distributions, and tracking downloads. --- ## Publish Go modules with CI Publish your Go modules to Fly Registry so your team can depend on them privately. Add the `go-publish` sub-action to your workflow and every tagged release is published automatically. ```yaml - uses: jfrog/fly-action/go-publish@v1 # Publish Go module ``` Version is auto-detected from git tags, or you can set it explicitly. See [Go →](../../package-managers/go/) for full details. --- ## Full examples ### npm package workflow ```yaml name: Build and Publish npm Package on: push: branches: [main] permissions: # Required for Fly OIDC authentication contents: read id-token: write jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - uses: actions/setup-node@v6 with: node-version: '24' - uses: jfrog/fly-action@v1 # Setup Fly package managers - run: npm install # Dependencies from Fly Registry - run: npm run build - run: npm publish # Publish to Fly Registry ``` ### Docker image workflow ```yaml name: Build and Push Docker Image on: push: branches: [main] permissions: # Required for Fly OIDC authentication contents: read id-token: write jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - uses: jfrog/fly-action@v1 # Setup Fly package managers - run: docker build -t ${{ env.FLY_REGISTRY_SUBDOMAIN }}/docker/my-app:${{ github.sha }} . # Base images pulled from Fly Registry - run: docker push ${{ env.FLY_REGISTRY_SUBDOMAIN }}/docker/my-app:${{ github.sha }} # Push to Fly Registry ``` ### Go module workflow ```yaml name: Publish Go Module on: push: tags: ['v*'] permissions: # Required for Fly OIDC authentication contents: read id-token: write jobs: publish: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 with: fetch-tags: true # Fetch tags for version detection - uses: actions/setup-go@v6 with: go-version: '1.26' - uses: jfrog/fly-action@v1 # Setup Fly package managers - uses: jfrog/fly-action/go-publish@v1 # Publish Go module ``` ### Generic artifacts workflow ```yaml name: Build and Upload Release Artifacts on: push: branches: [main] permissions: # Required for Fly OIDC authentication contents: read id-token: write jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - uses: jfrog/fly-action@v1 # Setup Fly package managers - run: make build # Build your project - uses: jfrog/fly-action/upload@v1 # Upload artifacts to Fly with: name: my-app version: '1.0.0' files: | dist/app.zip dist/app.tar.gz ``` --- ## Next steps - [Coding Agent →](../coding-agent/) - The interface most teams use to configure CI - [Package Managers →](../../package-managers/) - Per-tool reference and details - [Releases →](../../fly-platform/releases/) - The release model and lifecycle - [Where to Use Fly →](../) - The other interfaces --- # Concepts URL: https://docs.fly.jfrog.com/fly-platform/ Markdown: https://docs.fly.jfrog.com/fly-platform/index.md > How Fly connects your code, packages, releases, and deployments into a single traceable chain. --- ## Overview See how Fly connects your code, packages, releases, and deployments into a single traceable chain. These are the core entities Fly manages. Each can be accessed from multiple interfaces: your coding agent, Fly Web, or Slack. - **[Git Repositories](git-repositories/)** -- Your connected GitHub repositories. Fly watches them for workflows, tracks artifacts, and generates releases. - **[Artifacts](artifacts/)** -- Every package and image your team publishes or caches. Stored in your private Fly Registry. - **[Releases](releases/)** -- Semantic records of workflow runs. What changed, who shipped it, what was produced, where it's running. - **[Runtime Environments](runtime-environments/)** -- Deployment targets connected to your K8s namespaces for full runtime visibility. - **[Decision Records](decision-records/)** -- Your team's decisions, captured from developer-agent conversations and carried into every release and future session. - **[Workflows](workflows/)** -- Your GitHub Actions workflow files and their Fly configuration status. - **[Distribution](distribution/)** -- Track downloads and manage your public distributions. - **[Tokens](tokens/)** -- Credentials for connecting environments, configuring package managers, and integrating external systems. - **[Notifications](notifications/)** -- Natural-language watches that notify you in Slack when events happen. - **[Team Management](team-management/)** -- User roles, permissions, and access control. --- ## Next Steps - [Getting Started →](../getting-started/) - Set up your account and ship your first release - [From Planning to Production →](../from-planning-to-production/) - The lifecycle, end to end - [Fly Web →](../where-to-use-fly/fly-web/) - Your team's web interface --- # PyPI URL: https://docs.fly.jfrog.com/package-managers/pypi/ Markdown: https://docs.fly.jfrog.com/package-managers/pypi/index.md > Your private Python packages and public dependencies from PyPI, all managed through one registry. --- ## Overview Your private Python packages and public dependencies from PyPI, all managed through one registry. --- ## Supported Clients JFrog Fly supports Python packages with: - **Twine** (`twine upload`) - The official tool for publishing packages to PyPI - **pip** (`pip install`) - The standard package installer for Python - **Pipenv** (`pipenv install`) - Package installer with virtual environment management - **Poetry** (`poetry publish`, `poetry install`) - Dependency management and packaging tool - **UV** (`uv publish`, `uv pip install`) - Fast Python package manager and resolver --- ## Upload / Publish Package ### With Fly App Activate your Python tools in the Fly App. Fly detects your installed tools and configures them automatically. Once activated, publish your package: #### Twine ```bash twine upload dist/* ``` #### Poetry ```bash poetry publish ``` #### UV ```bash uv publish dist/* ``` ### Manual Configuration **1. Generate an access token** in Fly Token Management #### Twine **2.** Create `~/.pypirc`: ```ini [distutils] index-servers = pypi [pypi] repository = https://.jfrog.io/artifactory/api/pypi/pypi username = password = ``` > [!TIP] > Using `pypi` as the section name makes it the default repository for Twine, so you don't need to specify `-r` when uploading. **3.** Upload: ```bash twine upload dist/* ``` #### Poetry **2.** Configure the repository: ```bash poetry config repositories.pypi https://.jfrog.io/artifactory/api/pypi/pypi poetry config http-basic.pypi ``` **3.** Publish: ```bash poetry publish -r pypi ``` #### UV **2.** Add Fly as an index in your `uv.toml` or `pyproject.toml`: ```toml # uv.toml [[index]] name = "jfrog-pypi" url = "https://.jfrog.io/artifactory/api/pypi/pypi/simple" default = true publish-url = "https://.jfrog.io/artifactory/api/pypi/pypi" ``` **3.** Sign in: ```bash uv auth login .jfrog.io --username --password ``` **4.** Publish: ```bash uv publish dist/* ``` > [!IMPORTANT] > You cannot publish a package version that already exists. Increment the version before publishing again. --- ## Download / Install Package ### With Fly App Activate your Python tools in the Fly App. Fly detects your installed tools and configures them automatically. Once activated, install packages as usual: #### pip ```bash pip install ``` #### Pipenv ```bash pipenv install ``` #### Poetry ```bash poetry add ``` #### UV ```bash uv pip install ``` ### Manual Configuration **1. Generate an access token** in Fly Token Management #### pip / Pipenv **2.** Create `~/.config/pip/pip.conf` (Linux/macOS) or `%APPDATA%\pip\pip.ini` (Windows): ```ini [global] index-url = https://:@.jfrog.io/artifactory/api/pypi/pypi/simple ``` **3.** Install: ```bash pip install ``` Pipenv uses the same pip configuration, so `pipenv install ` works automatically. #### Poetry **2.** Add Fly as a source in your `pyproject.toml`: ```toml [[tool.poetry.source]] name = "fly" url = "https://.jfrog.io/artifactory/api/pypi/pypi/simple" priority = "primary" ``` **3.** Configure authentication: ```bash poetry config http-basic.fly ``` **4.** Install: ```bash poetry add ``` #### UV **2.** Add Fly as an index in your `uv.toml` or `pyproject.toml`: ```toml # uv.toml [[index]] name = "jfrog-pypi" url = "https://.jfrog.io/artifactory/api/pypi/pypi/simple" default = true ``` **3.** Sign in: ```bash uv auth login .jfrog.io --username --password ``` **4.** Install: ```bash uv pip install ``` ### From Public Registry When you install a package that isn't in your Fly Registry, JFrog Fly automatically fetches it from PyPI and caches it for future use. Just install as usual -- for example, `pip install requests`, `pipenv install requests`, `poetry add requests`, or `uv pip install requests`. --- ## Publish/Install Packages with CI To publish and install Python packages with CI, update your GitHub Actions workflow to include the Fly action. Simply ask your coding agent: **"Configure my workflows with Fly"** and Fly MCP will configure your GitHub Actions workflow yml file, as follows: **1. Add permissions** (top level, after `on:`): ```yaml permissions: contents: read id-token: write ``` **2. Add Fly Action** (after `actions/setup-python`, before pip/twine commands): ```yaml - uses: jfrog/fly-action@v1 # Setup Fly package managers ``` ### GitHub Action Example ```yaml name: Build and Publish Python Package on: push: branches: [main] permissions: contents: read id-token: write jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - uses: actions/setup-python@v6 with: python-version: '3.13' - uses: jfrog/fly-action@v1 # Setup Fly package managers - run: pip install build twine # Dependencies from Fly registry - run: python -m build - run: twine upload dist/* # Publish to Fly registry ``` --- *Back to [Package Managers →](../)* --- # Runtime Environments URL: https://docs.fly.jfrog.com/fly-platform/runtime-environments/ Markdown: https://docs.fly.jfrog.com/fly-platform/runtime-environments/index.md > Track what's running across all your environments. Know what's deployed, when it shipped, and which release produced it. --- ## Overview Know what's running across all your environments and verify that your fixes are live. A runtime environment represents a deployment target: `production`, `staging`, `dev`, or any named environment your team uses. Without environments, you have no visibility into what's actually running. You ship a release, but you can't answer: *"Is the login fix live in production?"* or *"What changed in staging this week?"* By creating an environment in Fly and connecting it to your Kubernetes namespace, you close that gap. Fly tracks every deployment, so you always know what's running, when it shipped, and which release produced it. You can compare environments, verify fixes, and investigate issues -- all from your coding agent or Fly Chat. --- ## How It Works ### Connection Model Environments connect to Fly through **environment-scoped tokens**. When you generate a token for an environment and apply it as a Kubernetes image pull secret, every pull using that token becomes a deployment event for the environment -- Fly groups them into a chronological deployment timeline. This gives you: - See what's deployed and when, across every environment - Query runtime state from your coding agent or Fly Chat - Know whether your environment is up to date with the latest release ### Environment Lifecycle 1. **Create** -- Give it a name (lowercase letters, numbers, hyphens), optional description, and a color to visually distinguish it in Fly Web 2. **Connect** -- Generate a token, apply the pull secret to your K8s namespace 3. **Track** -- Fly turns image pulls into deployments, links each one to its releases, and shows the full timeline 4. **Query** -- Ask what's running, compare environments, verify fixes ### Apply the Image Pull Secret ```bash kubectl create secret docker-registry fly-registry-secret \ --docker-server=.jfrog.io/docker \ --docker-username= \ --docker-password= \ --namespace= ``` Reference it in your deployment spec: ```yaml spec: template: spec: imagePullSecrets: - name: fly-registry-secret containers: - name: my-app image: .jfrog.io/docker/: ``` --- ## From Your Coding Agent Your coding agent is the fastest way to create environments, connect them to Kubernetes, deploy releases, and query what's running -- all with natural language prompts. ### Create an Environment *"Create a new environment called prod-us-east"* *"Create a staging environment"* ### Connect Your Environment *"Set up my K8s to work with Fly"* *"Generate a deployment token for production"* Fly generates the token, associates it with your environment, and gives you the kubectl command to apply. ### Deploy Releases *"Deploy the login fix to staging"* *"Deploy payment-service v2.3.1 to production"* *"Find the release where I fixed the auth bug and deploy it"* Fly uses semantic release data to find the right release and image, identifies the environment, handles credentials, and tracks the deployment. ### Track Your Runtime *"What's running in production?"* -- Shows the active image, which release produced it, features and fixes included, and deployment history. *"Is the fix for the login timeout issue deployed to production?"* -- Searches releases to confirm if the fix exists in your environment. *"Is staging up to date?"* -- Compares live state against the latest release. Shows missing releases if there's a gap. *"Compare staging vs production"* -- Side-by-side comparison of releases, PRs, fixes, and version gaps. --- ## In Fly Web See all your environments in one dashboard. Review deployment history, manage tokens, and drill into any environment for a full profile. ### Environment Dashboard Navigate to **Environments** to see all your environments. For each environment: - **Environment name, color, and description** -- The color appears as a visual badge to help distinguish environments at a glance (e.g., red for production, green for staging) - **Latest deployment** -- The most recent deployment, the releases it shipped, and when it landed. Locally pulled images appear as **"Pulled Locally"**, and rollback deployments are marked with a **Rollback** badge. ### Environment Deep Dive Click any environment to see: **Deployments** -- See everything that's shipped to this environment, in order. Each deployment shows all the releases that landed since the previous deployment and a short summary of what changed. Rollbacks appear here too, showing how many releases were reverted. Click any deployment to see the full set of releases it included, or jump to a specific release. **Token Tracking** -- Active tokens, names, and last usage timestamps. ### Actions - **Create Environment** -- Click **Create Environment**, provide name, color, and description - **Generate Token** -- From the environment profile, generate tokens for connecting - **Revoke Token** -- Revoke any token from the environment profile - **Update** -- Change name, color, or description (doesn't affect tokens or history) - **Delete** -- Available from the environment profile, requires confirmation. > [!WARNING] > Deleting an environment revokes all associated tokens and stops tracking. This cannot be undone. --- ## Next Steps - [Tokens →](../tokens/) - Token types, scoping, and management - [Releases →](../releases/) - Releases that get deployed to environments - [Deploy Your First Release →](../../getting-started/deploy-your-first-release/) - The end-to-end deployment journey --- # Decision Records URL: https://docs.fly.jfrog.com/fly-platform/decision-records/ Markdown: https://docs.fly.jfrog.com/fly-platform/decision-records/index.md > Capture the choices behind what your team builds. Your coding agent uses them as context, and every release shows the decisions made to ship it. --- ## Overview Build with your team's decisions in every coding-agent session, and see what shipped and why on every release. A Decision Record is a statement of what your team has decided to build, and why -- automatically captured from your developer-agent conversations and recorded when you release. Without them, intent evaporates: a developer says *"use Postgres, not Redis"* in chat, the agent applies it, the conversation closes, and the next session starts from zero. With Decision Records, that intent compounds. --- ## How Decision Records Are Used ### Agent context for better development Decisions the team has already made show up in every future agent session for the same repository. Your agent reasons inside them on every prompt -- it knows you picked Postgres, it knows your error envelope convention, it knows what's been decided and doesn't relitigate. You ship faster and your team stays aligned -- your agent always has the full context of what your team has decided. ### Release tracking Every release page in Fly Web shows the Decision Records added, updated, or removed in that release -- alongside the commits, PRs, and artifacts. Each record carries who made the decision and when, so a release now answers *what shipped*, *why*, and *who decided it*. The release summary also references the decisions when they shaped what was built. ### Review decisions from your coding agent Ask your agent what the team has decided, and it lists the active decisions for the repository: *"Show me the decision records for this repo"* *"What has the team decided about error handling?"* You see exactly what's steering every session -- handy before you start a feature, or when you suspect the agent is following something that's gone stale. --- ## Manage Decision Records Fly manages your team's decisions as you work -- capturing them from your conversations and keeping them current. And when a decision no longer fits, you can remove it yourself by simply asking your coding agent. ### Automatically, as you work Decision Records are captured from your developer-agent conversations as you work -- the [Fly App →](../../where-to-use-fly/fly-app/) records them in the background. When a release is finalized, Fly reviews the conversations that led to it and produces the Decision Records for that release. Each Decision Record on a release reflects one of three lifecycle events: - **Created** -- the team commits to a new direction (*"every HTTP error uses the shared envelope"*). - **Updated** -- the team changes its mind (*"actually, route this through the queue, not inline"*). - **Removed** -- the topic no longer applies and the decision is retired. ### Remove decisions on demand When a decision no longer applies, you can simply remove it by asking your coding agent: *"Remove the decision record about using Redis for caching"* *"Delete the decision about the old API envelope format"* Not sure which one? List them first with *"Show me the decision records for this repo"*. By removing a decision record, you and your team will no longer have it as context for your agent in future sessions. ### Pause collection To stop capturing new Decision Records, open the Fly App settings (gear icon in the tray header) and toggle off **Capture decision records**. While collection is paused: - No new decisions are captured from your coding agent conversations. - Existing Decision Records stay available as agent context and on releases. - Sync continues: records from your team still arrive normally. Toggle it back on whenever you're ready to resume. Collection is enabled by default. --- ## Next Steps - [Releases →](../releases/) - Decision Records appear on every release page - [Runtime Environments →](../runtime-environments/) - See what's deployed where --- # Go URL: https://docs.fly.jfrog.com/package-managers/go/ Markdown: https://docs.fly.jfrog.com/package-managers/go/index.md > Publish Go modules to your team's registry and pull dependencies from proxy.golang.org, all cached and managed through Fly. --- ## Overview Publish Go modules to your team's registry and pull dependencies from proxy.golang.org, all cached and managed through Fly. Go modules is the dependency management system for Go projects. JFrog Fly proxies Go modules from [proxy.golang.org](https://proxy.golang.org) (the official Go module mirror) and hosts your team's private modules. By configuring Fly, all your dependencies are cached and managed through Fly, providing faster downloads, unified dependency management, and a private registry for your own modules. --- ## Supported Clients JFrog Fly supports Go modules with: - **Go CLI** (`go get`, `go mod download`) - The standard Go toolchain for managing dependencies --- ## Download Module ### With Fly App Activate Go in your Fly App to configure your `GOPROXY` to use Fly. All modules from proxy.golang.org will be cached and managed through Fly: ```bash go get ``` Or download all dependencies: ```bash go mod download ``` ### Manual Configuration **1. Generate an access token** in Fly Token Management **2. Configure GOPROXY** to route through Fly: ```bash go env -w GOPROXY=https://:@.jfrog.io/artifactory/api/go/go,direct ``` > [!TIP] > The `,direct` fallback ensures that if a module is not found in Fly, Go will attempt to fetch it directly from the source. This is the recommended configuration. **3. Download module:** ```bash go get ``` All modules will be fetched from proxy.golang.org through Fly and cached for future use. --- ## Download Modules with CI To download Go modules with CI, update your GitHub Actions workflow to include the Fly action. Simply ask your coding agent: **"Configure my workflows with Fly"** and Fly MCP will configure your GitHub Actions workflow yml file, as follows: **1. Add permissions** (top level, after `on:`): ```yaml permissions: contents: read id-token: write ``` **2. Add Fly Action** (after `actions/setup-go`, before go commands): ```yaml - uses: jfrog/fly-action@v1 # Setup Fly package managers ``` ### GitHub Action Example ```yaml name: Build Go Application on: push: branches: [main] permissions: contents: read id-token: write jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - uses: actions/setup-go@v6 with: go-version: '1.26' - uses: jfrog/fly-action@v1 # Setup Fly package managers - run: go mod download # Modules from Fly registry - run: go build -v ./... - run: go test -v ./... ``` --- ## Publish Module with CI To publish Go modules from CI, add the `jfrog/fly-action/go-publish` step to your GitHub Actions workflow. **1. Add permissions** (top level, after `on:`): ```yaml permissions: contents: read id-token: write ``` **2. Add Fly Action and publish step** (in your job's `steps:`): ```yaml - uses: jfrog/fly-action@v1 # Setup Fly package managers - uses: jfrog/fly-action/go-publish@v1 # Publish Go module ``` The action auto-detects the module path from `go.mod` and the version from git tags. To override: ```yaml - uses: jfrog/fly-action/go-publish@v1 # Publish Go module with: path: ./path/to/module version: v1.2.0 ``` | Input | Required | Description | |-------|----------|-------------| | `path` | No | Path to the Go module directory (defaults to repo root) | | `version` | No | Explicit module version (auto-detected from git tags if omitted) | ### GitHub Action Example ```yaml name: Publish Go Module on: push: tags: ['v*'] permissions: contents: read id-token: write jobs: publish: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 with: fetch-depth: 0 - uses: actions/setup-go@v6 with: go-version: '1.26' - uses: jfrog/fly-action@v1 # Setup Fly package managers - uses: jfrog/fly-action/go-publish@v1 # Publish Go module ``` > [!TIP] > Use `fetch-depth: 0` in `actions/checkout` so the action can read git tags for automatic version detection. --- *Back to [Package Managers →](../)* --- # Package Managers URL: https://docs.fly.jfrog.com/package-managers/ Markdown: https://docs.fly.jfrog.com/package-managers/index.md > Reference documentation for configuring package types (Docker, Helm, npm, PyPI, .NET, Go, Maven, Gradle, Generic) with JFrog Fly Registry. --- ## Overview Upload, download, and manage all your packages through Fly. All your dependencies are cached and managed through Fly, providing faster downloads and unified dependency management. **Three ways to upload and download artifacts with Fly:** - **Locally with your Fly App** - Toggle your package manager to active, and you're ready to go. No tokens, no configuration files. - **Release with CI** - Add the Fly action to your GitHub Actions workflow. Your CI automatically uploads and downloads from Fly. - **Authentication with Tokens** - Generate a token and configure your package manager. For Kubernetes, external systems, or environments without the Fly App. --- ## Supported Package Managers | **Package Type** | **Supported Clients** | **JFrog Fly Registry** | |------------------|----------------------|------------------------| | **[Docker](docker/)** | Docker, Docker Buildx, Podman | `.jfrog.io/docker` | | **[Helm](helm/)** | Helm CLI | `.jfrog.io/helmoci` | | **[npm](npm/)** | npm, pnpm | `.jfrog.io/artifactory/api/npm/npm` | | **[PyPI](pypi/)** | pip, Pipenv, Poetry, Twine, UV | `.jfrog.io/artifactory/api/pypi/pypi/simple` | | **[Go](go/)** | Go | `.jfrog.io/artifactory/api/go/go` | | **[.NET](dotnet/)** | dotnet CLI, NuGet CLI | `.jfrog.io/artifactory/api/nuget/nuget` | | **[Maven](maven/)** | Maven | `.jfrog.io/artifactory/maven` | | **[Gradle](gradle/)** | Gradle | `.jfrog.io/artifactory/maven` | | **[Generic](generic/)** | Fly Client, cURL | `.jfrog.io/artifactory/api/generic` | --- ## Public Registry Proxying JFrog Fly proxies public registries, providing: - **Speed** - Cached public dependencies download faster - **Reliability** - Available even if public registry is down (for cached dependencies) - **Unified Access** - Single registry for both your private packages and public dependencies When you request a package, JFrog Fly checks your private artifacts first, then fetches from the public registry if needed and caches it for future use. ### Proxied Public Registries | **Package Type** | **Supported Clients** | **Public Registry** | |------------------|----------------------|---------------------| | **Docker** | Docker, Docker Buildx, Podman | https://registry-1.docker.io (DockerHub) | | **Helm** | Helm CLI | https://registry-1.docker.io (DockerHub) | | **npm** | npm, pnpm | https://registry.npmjs.org | | **PyPI** | pip, Pipenv, Poetry, Twine, UV | https://files.pythonhosted.org (PyPI) | | **Go** | Go | https://proxy.golang.org | | **.NET** | dotnet CLI, NuGet CLI | https://www.nuget.org | | **Maven** | Maven | https://repo1.maven.org/maven2 (Maven Central) | | **Gradle** | Gradle | https://repo1.maven.org/maven2 (Maven Central) | --- ## Next Steps - [Artifacts →](../fly-platform/artifacts/) - Browse and manage all your packages in Fly - [From Planning to Production →](../from-planning-to-production/) - The lifecycle, end to end - [Tokens →](../fly-platform/tokens/) - Manual authentication for external systems --- # Terminal URL: https://docs.fly.jfrog.com/where-to-use-fly/terminal/ Markdown: https://docs.fly.jfrog.com/where-to-use-fly/terminal/index.md > Publish and install from your terminal. npm publish, docker push, pip install, and mvn deploy all route through your Fly Registry. --- ## Overview Use your terminal commands as-is. Your `npm publish`, `docker push`, `pip install`, and `mvn deploy` all go to your Fly Registry, with no changes to your existing workflow. From your terminal you can: - **Publish private packages** to your team's Fly Registry at `.jfrog.io`. - **Install public dependencies** (npm, PyPI, Maven Central, Docker Hub, etc.) proxied and cached through Fly. - **Use a token** where Fly App isn't available. No new tools, no special syntax. With Fly App active, your existing commands just work. --- ## Upload & download from terminal | Package Manager | Upload | Download | |---|---|---| | **npm** | `npm publish` | `npm install` | | **pip (PyPI)** | `twine upload dist/*` | `pip install` | | **Maven (Java)** | `mvn deploy` | `mvn install` | | **Gradle (Java)** | `./gradlew publish` | `./gradlew build` | | **Go** | N/A (via Git) | `go get` | | **NuGet** | `dotnet nuget push` | `dotnet restore` | For **Docker** and **Helm**, include your Fly Registry path in the image or chart reference. **Docker:** ```bash docker push .jfrog.io/docker/my-image:latest docker pull .jfrog.io/docker/my-image:latest ``` **Helm:** ```bash helm push my-chart-1.0.0.tgz oci://.jfrog.io/helmoci helm pull oci://.jfrog.io/helmoci/my-chart --version 1.0.0 ``` > [!NOTE] > Requires the [Fly App](../fly-app/) active, with the package manager you want to use toggled on in the Fly App menu. --- ## Upload & download with a token In environments without Fly App (Kubernetes pods, external CI runners, remote build environments), generate an access token in Fly Web and configure your package manager manually using your registry path. | Package Manager | Registry Path | |---|---| | **Docker** | `.jfrog.io/docker` | | **Helm** | `.jfrog.io/helmoci` | | **npm** | `.jfrog.io/artifactory/api/npm/npm/` | | **pip (PyPI)** | `.jfrog.io/artifactory/api/pypi/pypi/simple` | | **Maven** | `.jfrog.io/artifactory/maven` | | **Go** | `.jfrog.io/artifactory/api/go/go` | | **NuGet** | `.jfrog.io/artifactory/api/nuget/nuget` | See [Package Managers →](../../package-managers/) for detailed per-tool configuration steps. --- ## Next steps - [Fly App →](../fly-app/) - Install and connect Fly App locally - [Package Managers →](../../package-managers/) - Per-tool setup and reference - [Where to Use Fly →](../) - The other interfaces --- # .NET URL: https://docs.fly.jfrog.com/package-managers/dotnet/ Markdown: https://docs.fly.jfrog.com/package-managers/dotnet/index.md > Your private NuGet packages and public dependencies from nuget.org, all managed through one registry. --- ## Overview Your private NuGet packages and public dependencies from nuget.org, all managed through one registry. --- ## Supported Clients JFrog Fly supports .NET packages with: - **dotnet CLI** (`dotnet nuget push`, `dotnet restore`) - The modern .NET command-line interface - **NuGet CLI** (`nuget push`, `nuget restore`) - The standalone NuGet command-line tool --- ## Upload / Push Package ### With Fly App Activate .NET in your Fly App to configure .NET globally with Fly. The Fly App sets the Fly registry as the default push source, so you can push without specifying `--source`: **Using dotnet CLI:** ```bash dotnet nuget push .nupkg ``` **Using NuGet CLI:** ```bash nuget push .nupkg ``` ### Manual Configuration **1. Generate an access token** in Fly Token Management **2. Configure .NET:** **Using dotnet CLI:** ```bash dotnet nuget add source https://.jfrog.io/artifactory/api/nuget/nuget \ --name Fly \ --username \ --password \ --store-password-in-clear-text ``` **Using NuGet CLI:** ```bash nuget sources add -Name Fly \ -Source https://.jfrog.io/artifactory/api/nuget/nuget \ -Username \ -Password ``` **3. Push package:** **Using dotnet CLI:** ```bash dotnet nuget push .nupkg --source Fly ``` **Using NuGet CLI:** ```bash nuget push .nupkg -Source Fly ``` --- ## Download / Restore Package ### With Fly App Activate .NET in your Fly App to configure .NET globally with Fly, then restore as usual: **Using dotnet CLI:** ```bash dotnet restore ``` **Using NuGet CLI:** ```bash nuget restore ``` ### Manual Configuration **1. Generate an access token** in Fly Token Management **2. Configure .NET:** **Using dotnet CLI:** ```bash dotnet nuget add source https://.jfrog.io/artifactory/api/nuget/nuget \ --name Fly \ --username \ --password \ --store-password-in-clear-text ``` **Using NuGet CLI:** ```bash nuget sources add -Name Fly \ -Source https://.jfrog.io/artifactory/api/nuget/nuget \ -Username \ -Password ``` **3. Restore packages:** **Using dotnet CLI:** ```bash dotnet restore ``` **Using NuGet CLI:** ```bash nuget restore ``` ### From Public Registry When you restore a package that isn't in your Fly Registry, JFrog Fly automatically fetches it from nuget.org and caches it for future use. **Using dotnet CLI:** ```bash dotnet restore ``` **Using NuGet CLI:** ```bash nuget restore ``` --- ## Upload/Download Packages with CI To push and restore .NET packages with CI, update your GitHub Actions workflow to include the Fly action. Simply ask your coding agent: **"Configure my workflows with Fly"** and Fly MCP will configure your GitHub Actions workflow yml file, as follows: **1. Add permissions** (top level, after `on:`): ```yaml permissions: contents: read id-token: write ``` **2. Add Fly Action** (after `actions/setup-dotnet`, before dotnet/nuget commands): ```yaml - uses: jfrog/fly-action@v1 # Setup Fly package managers ``` ### GitHub Action Example ```yaml name: Build and Publish .NET Package on: push: branches: [main] permissions: contents: read id-token: write jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - uses: actions/setup-dotnet@v5 with: dotnet-version: '10.0' - uses: jfrog/fly-action@v1 # Setup Fly package managers - run: dotnet restore # Dependencies from Fly registry - run: dotnet build --configuration Release - run: dotnet pack --configuration Release - run: dotnet nuget push ./bin/Release/*.nupkg # Push to Fly registry ``` --- *Back to [Package Managers →](../)* --- # FAQ URL: https://docs.fly.jfrog.com/faq/ Markdown: https://docs.fly.jfrog.com/faq/index.md > Frequently Asked Questions about JFrog Fly: setup, package management, workflows, deployment, and access control. --- This section covers common questions, edge cases, and troubleshooting for JFrog Fly. --- ## Overview - **Onboarding & Setup** - Account creation, subdomains, and GitHub connection - **Fly App** - Local setup, coding agents, and platform support - **Package Management** - Uploading, downloading, and public registry behavior - **CI & Releases** - Workflow configuration and release creation - **Runtime & Deployment** - Environments, tracking, and Kubernetes - **Troubleshooting** - Symptom-based fixes for common issues --- ## Quick Links ### Onboarding & Setup - [What is a "team subdomain" and why does it matter?](#what-is-a-team-subdomain-and-why-does-it-matter) - [Can I change my team subdomain later?](#can-i-change-my-team-subdomain-later) - [Do I need to be an admin of my GitHub organization to connect it?](#do-i-need-to-be-an-admin-of-my-github-organization-to-connect-it) - [How do I enable two-factor authentication?](#how-do-i-enable-two-factor-authentication) ### Fly App - [What is "Fly MCP" and do I need it?](#what-is-fly-mcp-and-do-i-need-it) - [What Coding Agents are supported?](#what-coding-agents-are-supported) - [Is Fly available on Windows or Linux?](#is-fly-available-on-windows-or-linux) ### Package Management - [What public registries does Fly proxy?](#what-public-registries-does-fly-proxy) - [What happens to public dependencies I download?](#what-happens-to-public-dependencies-i-download) - [Can I upload files that aren't packages?](#can-i-upload-files-that-arent-packages) ### CI & Releases - [Can I edit a release title or description?](#can-i-edit-a-release-title-or-description) - [Can I search for releases using natural language?](#can-i-search-for-releases-using-natural-language) - [How do I skip specific package managers in CI?](#how-do-i-skip-specific-package-managers-in-ci) ### Runtime & Deployment - [Do I need to create an environment from Fly Web?](#do-i-need-to-create-an-environment-from-fly-web) - [How can I see my deployments in Fly?](#how-can-i-see-my-deployments-in-fly) - [What happens when I delete an environment?](#what-happens-when-i-delete-an-environment) ### Troubleshooting - [Why isn't my workflow creating releases?](#why-isnt-my-workflow-creating-releases) - [Why does Next.js fail to download SWC packages in CI?](#why-does-nextjs-fail-to-download-swc-packages-in-ci) - [Why do I get a 401 error when pulling packages in CI?](#why-do-i-get-a-401-error-when-pulling-packages-in-ci) - [Why do I see "Organization already connected" when connecting my GitHub org?](#why-do-i-see-organization-already-connected-when-connecting-my-github-org) --- ## Onboarding & Setup ### What is a "team subdomain" and why does it matter? Your **team subdomain** is the unique identifier for your team's Fly Registry, created when you pick your team name during account creation. **Format:** `.jfrog.io` Your subdomain is used in every registry URL across Fly: - **Package managers:** `.jfrog.io/artifactory/api/npm/npm/` - **Docker images:** `.jfrog.io/docker/my-image:latest` - **Maven/Gradle:** `.jfrog.io/artifactory/maven` - **CI/CD workflows:** All Fly action configurations **Example:** If your team subdomain is `acmecorp`, all your developers will use URLs like: - `acmecorp.jfrog.io/docker/api:v1.2.3` - `acmecorp.jfrog.io/artifactory/api/npm/npm/` --- ### Can I change my team subdomain later? **No.** Your subdomain is permanent and cannot be changed. All registry URLs, workflows, and configurations depend on it, so choose carefully. --- ### Do I need to be an admin of my GitHub organization to connect it? **Yes.** You must be an owner or admin of the GitHub organization to install the JFrog Fly GitHub App. If you're not an admin, ask one to connect it. For personal repositories, you only need to own the repository. --- ### How do I enable two-factor authentication? Go to **Account Settings > Password & Authentication** in Fly Web. In the Two-factor authentication methods section, click **Add** on the Authenticator App card and scan the QR code with your authenticator app. See [Team Management →](../fly-platform/team-management/) for details. --- ## Fly App ### What is "Fly MCP" and do I need it? **Fly MCP** (Model Context Protocol) connects your coding agent directly to Fly, so you can take any action with natural language. With Fly MCP enabled, your coding agent can do everything: - *"Configure my repo to work with Fly"* - *"Push this image"* - *"Deploy the release with the authentication fix to production"* - *"Is production up to date?"* - *"Find the release where I fixed the login bug"* - *"Create a staging environment"* **Requirements:** Fly App installed and the coding agent connection toggled on in the app. Once it's on, you're connected. --- ### What Coding Agents are supported? **Currently supported:** Cursor, Copilot, Claude Code, and OpenCode. The Fly App automatically detects and integrates Fly MCP with supported Coding Agents. --- ### Is Fly available on Windows or Linux? Fly App supports **macOS and Windows**. Fly Web, CI/CD integration, and Registry work on all platforms. --- ## Package Management ### What public registries does Fly proxy? | Technology | Public Registry | |------------|-----------------| | **npm** | https://registry.npmjs.org | | **pip / UV** | https://files.pythonhosted.org (PyPI) | | **Maven** | https://repo1.maven.org/maven2 (Maven Central) | | **Docker** | https://registry-1.docker.io (DockerHub) | | **Helm** | https://registry-1.docker.io (DockerHub) | | **Go** | https://proxy.golang.org | | **NuGet** | https://www.nuget.org | | **Gradle** | https://repo1.maven.org/maven2 (Maven Central) | --- ### What happens to public dependencies I download? Fly checks your uploaded artifacts first, then fetches from the public registry and caches it for your team. Cached packages download faster and are available even if the public registry is down. --- ### Can I upload files that aren't packages? Yes. Ask your coding agent to upload any file to Fly. Release binaries, build outputs, signed archives, or anything your team needs to version and share. Fly stores and organizes them as generic packages. See [Generic →](../package-managers/generic/) for details. --- ## CI & Releases ### Can I edit a release title or description? Yes. Open any release's detail page in Fly Web and click on the **Title** or **Description** to edit. Changes are saved immediately and reflected in semantic search. --- ### Can I search for releases using natural language? Yes. You can search for releases from any interface: your coding agent, Fly Web, or even Slack. Simply ask semantically: - *"Find the release where I fixed the login bug"* - *"Show me Jon's last deployment"* - *"Releases from last week with API changes"* --- ### How do I skip specific package managers in CI? By default, the Fly action configures all supported package managers. To skip specific ones, use the `ignore` input: ```yaml - uses: jfrog/fly-action@v1 with: ignore: docker,pip ``` See [CI →](../where-to-use-fly/ci/) for more CI configuration options. --- ## Runtime & Deployment ### Do I need to create an environment from Fly Web? No. Ask your coding agent: *"Create a staging environment"* and Fly handles it. You can also create environments from Fly Web if you prefer. --- ### How can I see my deployments in Fly? Connect your environment with an environment-scoped token applied as a Kubernetes image pull secret. Once connected, every image pull is tracked automatically. Open any environment in Fly Web and select the **Deployments** tab to see a chronological history of deployments, including what changed between them. --- ### What happens when I delete an environment? Deleting an environment revokes all associated tokens and removes historical data. This action cannot be undone and requires explicit confirmation. --- ## Troubleshooting ### Why isn't my workflow creating releases? A release is created only when **all** of these conditions are met: 1. Workflow has the Fly action configured 2. Workflow has the required OIDC permissions block 3. Workflow completes successfully 4. At least one artifact is uploaded to Fly Registry **Check these:** 1. **Verify the Fly action** is present in your workflow: ```yaml - uses: jfrog/fly-action@v1 # Setup Fly package managers ``` 2. **Verify the permissions block** is at the top level: ```yaml permissions: contents: read id-token: write ``` 3. **Check workflow logs** for Fly action output 4. **Confirm artifact upload succeeded** in package manager logs (npm publish, docker push, etc.) --- ### Why does Next.js fail to download SWC packages in CI? **Symptom:** `next build` fails with a 401 error downloading SWC binaries like `@next/swc-linux-x64-gnu`, even though the Fly action is configured. ``` Failed to download swc package from https://.jfrog.io/artifactory/api/npm/npm/@next/swc-linux-x64-gnu/-/swc-linux-x64-gnu-16.1.5.tgz unhandledRejection Error: request failed with status 401 ``` **Cause:** This is a [known Next.js bug](https://github.com/vercel/next.js/issues/59081). When Next.js detects missing SWC binaries in your lockfile, it tries to download them using its own internal HTTP client, which does not send the npm auth token from `.npmrc`. The request hits the registry without authentication. This happens with any authenticated registry, not just Fly. **Fix:** Regenerate your lockfile locally so SWC binaries are resolved as proper dependencies: ```bash rm -rf node_modules package-lock.json npm install ``` Commit the updated `package-lock.json` and push. When `npm ci` runs in CI, it installs the SWC binaries through npm (with auth), and `next build` finds them already present. --- ### Why do I get a 401 error when pulling packages in CI? **Symptom:** Package install or pull fails with a 401 (Unauthorized) error in your GitHub Actions workflow, even though the Fly action is configured. **Common causes:** 1. **Missing OIDC permissions.** The permissions block must be at the top level of your workflow file, not inside a job: ```yaml permissions: contents: read id-token: write ``` 2. **Fly action placed after package commands.** The Fly action must run *before* any package manager commands (`npm install`, `docker pull`, etc.). 3. **Tool-specific auth bypass.** Some tools (like Next.js SWC downloads) use their own HTTP clients that don't read npm/pip/Docker auth config. See [Why does Next.js fail to download SWC packages in CI?](#why-does-nextjs-fail-to-download-swc-packages-in-ci) --- ### Why do I see "Organization already connected" when connecting my GitHub org? **Symptom:** You try to connect a GitHub organization to Fly, but nothing happens or you see an "Organization already connected" error. **Cause:** The GitHub organization already has the JFrog Fly GitHub App installed and is bound to a different Fly account. Each GitHub organization can only be connected to one Fly account at a time. **Fix:** To move the organization to a different Fly account, uninstall the JFrog Fly GitHub App from the organization on GitHub (Organization Settings > GitHub Apps > JFrog Fly > Uninstall), then reconnect from the new Fly account. --- ## Still Have Questions? If you can't find the answer you're looking for: 1. **[Use Fly Chat →](https://fly.jfrog.ai/)** - Ask your question in natural language in the Fly Web 2. **[Browse Documentation →](../)** - Explore the detailed sections of this guide 3. **[Contact Support →](mailto:fly-support@jfrog.com)** - Reach out to JFrog support for assistance --- # Slack URL: https://docs.fly.jfrog.com/where-to-use-fly/slack/ Markdown: https://docs.fly.jfrog.com/where-to-use-fly/slack/index.md > Get Fly notifications in Slack. Releases, deployments, and your custom watches arrive where your team already works. --- ## Overview Stay informed about Fly without leaving Slack. You'll know the moment a release ships, a deploy lands, or something you watch happens. From Slack you can: - **Get the notifications you need.** Releases, deployments, and custom watches all land in your channels. - **Bring the team along.** Subscribe channels to the releases and environments your team should track. - **Ask Fly anything in chat.** Queries, searches, and watch management, all in natural language. Fly meets your team where they already work. --- ## Setup 1. **Connect Fly to your Slack workspace.** In **Fly Web → Settings**, click **Connect to Slack** and authorize the Fly app. (Admin-level, one time.) 2. **Link your Slack account.** Open the **Fly Slack app**, go to the **Home** tab, and click **Connect to Fly**. Now Fly responses in Slack are scoped to you. --- ## Using Fly in Slack - **`/fly`** — In any Slack channel or DM, type the slash command followed by what you want. Quickest way to ask Fly or set a watch. - **Fly Slack app** — In your Slack sidebar, click the **Fly** app. The Home tab has connection status, channel subscriptions, and a personal chat space. Pick whichever fits. --- ## Notifications in Slack Set a watch on what you care about, and Fly notifies you when something matches. Set watches through `/fly`, the Fly Slack app, or your coding agent. Notifications can be delivered as: - **Personal notification** — Fly DMs you when the watch matches. - **Channel notification** — Fly posts in a specific Slack channel. - **Team notification** — Fly notifies your whole team. Fly notifies you about: | Event | What you see | Example watch | |---|---|---| | **Release** | What was released, a short summary, when, and by whom. | *"Notify me when a new release is created for payment-service."* | | **Deployment** | What was deployed, the repository, when, the image version, and which environment. | *"Notify me when a new version is deployed to production."* | | **Distribution** | Who distributed it. Where to find it. | *"Notify me when a new public version of my-app is distributed."* | --- ## Ask Fly in Slack Understand everything happening with your team, directly from Slack. Ask anything through `/fly` or the Fly Slack app: - *"What's the latest release from payment-service?"* - *"Notify me when a new release is created for payment-service."* - *"Is the login fix live in production?"* - *"List my watches."* --- ## Next steps - [Notifications →](../../fly-platform/notifications/) - The watch model and semantic matching - [Where to Use Fly →](../) - The other interfaces --- # Workflows URL: https://docs.fly.jfrog.com/fly-platform/workflows/ Markdown: https://docs.fly.jfrog.com/fly-platform/workflows/index.md > Every push automatically creates a searchable release with full traceability, no tokens or secrets needed. --- ## Overview Every push automatically creates a searchable release with full traceability -- no tokens or secrets needed. A workflow is a GitHub Actions workflow file (`.github/workflows/*.yml`) that defines your CI/CD pipeline. When configured with the Fly action, a workflow becomes the bridge between your code and Fly's release tracking. Once configured, every push automatically publishes artifacts to Fly Registry and creates a release with an AI-generated summary, linked PRs, commits, and full traceability -- no tokens or secrets needed. --- ## How It Works ### Configuration Model Configuring a workflow means adding two things to the workflow YAML file: **OIDC permissions** for secure, token-free authentication: ```yaml permissions: contents: read id-token: write ``` **Fly action** to configure package managers on the CI runner: ```yaml - uses: jfrog/fly-action@v1 # Setup Fly package managers ``` For Docker and Helm, the Fly action exports your registry hostname as `FLY_REGISTRY_SUBDOMAIN` (e.g., `acmecorp.jfrog.io`), so your image path becomes `acmecorp.jfrog.io/docker/my-app:tag`. See [CI →](../../where-to-use-fly/ci/) for full configuration details. ### Configuration Status Each workflow has one of two states: **Configured** -- The workflow includes the Fly action. It can push and pull artifacts from Fly Registry, creates releases automatically, and has full traceability. **Not Configured** -- The workflow exists but isn't using Fly. Artifacts aren't tracked and no releases are created. ### What Happens After Configuration Once merged, every push that runs the workflow: 1. Authenticates with Fly Registry via OIDC (no tokens needed) 2. Publishes artifacts to Fly Registry 3. Creates a release with AI-generated summary, linked PRs, commits, and artifacts 4. Produces a job summary with collected artifacts and transfer results 5. Notifies Fly when the CI session ends for proper session tracking --- ## From Your Coding Agent The recommended way to configure workflows is through your coding agent. Fly scans your workflow files, generates the changes, and opens a pull request -- no manual YAML editing required. ### Configure All Workflows *"Configure my workflows with Fly"* Fly scans your `.github/workflows/*.yml` files and opens a pull request with the required changes. Review, merge, and you're done. ### Configure a Specific Workflow *"Configure this workflow for Fly Registry"* Opens the current workflow file and adds the Fly action and permissions. ### Manual Configuration Add the OIDC permissions block at the top level (after `on:`, before `jobs:`) and the Fly action step within your job (after setup steps, before artifact operations). [Full examples →](../../where-to-use-fly/ci/) --- ## In Fly Web Fly Web shows the configuration status of all workflows in each repository, so you can quickly see which workflows are connected to Fly and which still need setup. ### Workflow List Navigate to **Git Repositories** → select a repository → **Workflows** tab. | Column | Description | |--------|-------------| | **Workflow Name** | Name from the workflow YAML file | | **File Path** | Location in `.github/workflows/` | | **Status** | Configured or Not Configured | | **Last Run** | Most recent workflow execution | | **Runs** | Total number of executions | ### Actions - **Configure Workflow** -- Opens the coding agent flow or links to manual configuration - **View on GitHub** -- Opens the workflow file directly on GitHub --- ## Next Steps - [Releases →](../releases/) - What workflows produce - [Git Repositories →](../git-repositories/) - Repositories that contain workflows - [CI →](../../where-to-use-fly/ci/) - Full CI/CD configuration guide with examples --- # Maven URL: https://docs.fly.jfrog.com/package-managers/maven/ Markdown: https://docs.fly.jfrog.com/package-managers/maven/index.md > Your private Maven artifacts and public dependencies from Maven Central, all managed through one registry. --- ## Overview Your private Maven artifacts and public dependencies from Maven Central, all managed through one registry. --- ## Supported Clients JFrog Fly supports Maven artifacts with: - **Maven CLI** (`mvn deploy`, `mvn install`) - The standard Apache Maven build tool --- ## Upload / Deploy Artifact ### With Fly App Activate Maven in your Fly App to configure Maven globally with Fly, then deploy as usual: ```bash mvn clean deploy ``` ### Manual Configuration **1. Generate an access token** in Fly Token Management **2. Configure Maven credentials** by editing `~/.m2/settings.xml`: ```xml fly-maven fly fly-maven https://.jfrog.io/artifactory/maven true true fly ``` **3. Configure your project's `pom.xml`** - add the distribution management section: ```xml fly-maven https://.jfrog.io/artifactory/maven fly-maven https://.jfrog.io/artifactory/maven ``` > [!IMPORTANT] > The `` value (`fly-maven`) must match the server id in your `settings.xml`. **4. Deploy artifact:** ```bash mvn clean deploy ``` --- ## Download / Install Dependencies ### With Fly App Activate Maven in your Fly App to configure Maven globally with Fly, then install as usual: ```bash mvn clean install ``` ### Manual Configuration **1. Generate an access token** in Fly Token Management **2. Configure Maven** by editing `~/.m2/settings.xml` as shown in the Deploy section above. **3. Install dependencies:** ```bash mvn clean install ``` ### From Public Registry When you install a dependency that isn't in your Fly Registry, JFrog Fly automatically fetches it from Maven Central and caches it for future use. ```bash mvn clean install ``` --- ## Upload/Download Artifacts with CI To deploy and install Maven artifacts with CI, update your GitHub Actions workflow to include the Fly action. Simply ask your coding agent: **"Configure my workflows with Fly"** and Fly MCP will configure your GitHub Actions workflow yml file, as follows: **1. Add permissions** (top level, after `on:`): ```yaml permissions: contents: read id-token: write ``` **2. Add Fly Action** (after `actions/setup-java`, before Maven commands): ```yaml - uses: jfrog/fly-action@v1 # Setup Fly package managers ``` ### GitHub Action Example ```yaml name: Build and Deploy Maven Artifact on: push: branches: [main] permissions: contents: read id-token: write jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - uses: actions/setup-java@v5 with: java-version: '25' distribution: 'temurin' - uses: jfrog/fly-action@v1 # Setup Fly package managers - run: mvn clean deploy # Build and deploy to Fly registry ``` --- *Back to [Package Managers →](../)* --- # Tokens URL: https://docs.fly.jfrog.com/fly-platform/tokens/ Markdown: https://docs.fly.jfrog.com/fly-platform/tokens/index.md > Give Kubernetes clusters, CI tools, and external systems secure access to your Fly Registry. --- ## Overview Give Kubernetes clusters, CI tools, and external systems secure access to your Fly Registry. If you're using the Fly App locally, you don't need tokens: authentication is handled automatically. Tokens are for systems that can't use the Fly App: Kubernetes clusters pulling images, external CI tools, deployment scripts, or manual package manager configuration. A token is a credential that provides controlled access to your Fly Registry. Tokens come in two permission levels (read-only or read & write) and can be scoped to a specific runtime environment for deployment tracking. --- ## How It Works ### Token Types **Read & Write Token** -- Full access to artifacts: upload, download, view metadata, create releases from external CI. Use cases: manual local development, external CI/CD systems, automated deployment scripts. **Read-Only Token** -- Limited access: download and view only. Use cases: Kubernetes environments pulling images, deployment environments, sharing with partners/customers. ### Environment-Scoped Tokens Tokens can be associated with a specific runtime environment. When scoped to an environment, every image pull using that token is tracked against the environment, enabling Fly to show deployment history and drift detection. Environment tokens can be generated during environment creation or from the environment profile. See [Runtime Environments →](../runtime-environments/) for details. ### Security Model - Token values are shown **once** at creation -- copy immediately - Tokens can be revoked instantly, invalidating all systems using them - Revoked tokens cannot be unrevoked - The system tracks token creation, usage, and status - Admins can revoke any token; Developers can only revoke their own --- ## From Your Coding Agent Your coding agent can generate tokens and configure package managers for you. This is especially useful when setting up new environments or connecting external systems. ### Generate Tokens *"Generate a deployment token for production"* *"Create a read-only token for staging"* Fly generates the token, optionally associates it with an environment, and provides the credentials. ### Use Tokens for Package Managers Tokens can manually configure package managers in environments without the Fly App: **Docker:** ```bash docker login .jfrog.io -u -p ``` **npm** (add to `.npmrc`): ``` registry=https://.jfrog.io/artifactory/api/npm/npm/ //.jfrog.io/artifactory/api/npm/npm/:_authToken= ``` **pip:** ```bash export PIP_INDEX_URL=https://:@.jfrog.io/artifactory/api/pypi/pypi/simple ``` See [Package Managers →](../../package-managers/) for all package types. --- ## In Fly Web Fly Web provides a token management dashboard where you can create, view, and revoke tokens. Access it from your user avatar in the top-right corner. ### Creating Tokens 1. Click your **user avatar** (top-right) → **Token Management** 2. Click **Create Token** 3. Configure: **Name**, **Permission** (Read & Write or Read-Only), **Expiration** (date or "Never") 4. Click **Create** 5. **Copy token immediately** -- shown only once ### Viewing Tokens | Column | Description | |--------|-------------| | **Name** | Token name | | **Username** | Token-specific username for authentication | | **Permission** | Read & Write or Read-Only | | **Created By** | User who created the token | | **Created** | Creation timestamp | | **Expires** | Expiration date | | **Status** | Active, Expired, or Revoked | ### Revoking and Deleting Tokens - **Revoke** -- Immediately invalidates the token. Any systems using it lose access. Admins can revoke any token; Developers can only revoke their own. - **Delete** -- Removes expired or revoked tokens from the list. Cannot delete active tokens. --- ## Next Steps - [Runtime Environments →](../runtime-environments/) - Environment-scoped tokens and pull secrets - [Package Managers →](../../package-managers/) - Manual package manager configuration with tokens --- # Gradle URL: https://docs.fly.jfrog.com/package-managers/gradle/ Markdown: https://docs.fly.jfrog.com/package-managers/gradle/index.md > Your private Gradle artifacts and public dependencies from Maven Central, all managed through one registry. --- ## Overview Your private Gradle artifacts and public dependencies from Maven Central, all managed through one registry. --- ## Supported Clients JFrog Fly supports Gradle artifacts with: - **Gradle CLI** (`./gradlew publish`, `./gradlew build`) - The Gradle build tool with wrapper --- ## Upload / Publish Artifact ### With Fly App Activate Gradle in your Fly App to configure Gradle globally with Fly. The Fly App automatically creates an init script at `~/.gradle/init.d/` that configures both dependency resolution and publishing. Then publish as usual: ```bash ./gradlew publish ``` ### Manual Configuration **1. Generate an access token** in Fly Token Management **2. Configure Gradle:** **Option A: Project Configuration** Edit `build.gradle`: ```groovy plugins { id 'java' id 'maven-publish' } repositories { maven { url "https://.jfrog.io/artifactory/maven" credentials { username = "" password = "" } } } publishing { publications { maven(MavenPublication) { from components.java } } repositories { maven { url "https://.jfrog.io/artifactory/maven" credentials { username = "" password = "" } } } } ``` **Option B: Global Configuration** Create an init script at `~/.gradle/init.d/fly.gradle`: ```groovy def flyUrl = "https://.jfrog.io/artifactory/maven" def flyUsername = "" def flyToken = "" // Configure project repositories for dependency resolution allprojects { project -> project.repositories { maven { name = "Fly" url = uri(flyUrl) credentials { username = flyUsername password = flyToken } } } // Configure publishing for projects that apply maven-publish plugin project.plugins.withId('maven-publish') { project.publishing { repositories { clear() // Ensure Fly is the only publishing destination maven { name = "Fly" url = uri(flyUrl) credentials { username = flyUsername password = flyToken } } } } } } ``` > [!NOTE] > This init script applies to all Gradle projects. The `plugins.withId` pattern ensures publishing configuration only applies to projects using the `maven-publish` plugin. The `clear()` call ensures Fly is the only publishing destination. **3. Publish artifact:** ```bash ./gradlew publish ``` --- ## Download / Build Dependencies ### With Fly App Activate Gradle in your Fly App to configure Gradle globally with Fly. The Fly App automatically creates an init script that configures dependency resolution from Fly. Then build as usual: ```bash ./gradlew build ``` ### Manual Configuration **1. Generate an access token** in Fly Token Management **2. Configure Gradle** as shown in the Publish section above (Option A or Option B). **3. Build project:** ```bash ./gradlew build ``` ### From Public Registry When you build a project with dependencies that aren't in your Fly Registry, JFrog Fly automatically fetches them from Maven Central and caches them for future use. ```bash ./gradlew build ``` --- ## Upload/Download Artifacts with CI To publish and build Gradle artifacts with CI, update your GitHub Actions workflow to include the Fly action. Simply ask your coding agent: **"Configure my workflows with Fly"** and Fly MCP will configure your GitHub Actions workflow yml file, as follows: **1. Add permissions** (top level, after `on:`): ```yaml permissions: contents: read id-token: write ``` **2. Add Fly Action** (after `actions/setup-java`, before Gradle commands): ```yaml - uses: jfrog/fly-action@v1 # Setup Fly package managers ``` ### GitHub Action Example ```yaml name: Build and Publish Gradle Artifact on: push: branches: [main] permissions: contents: read id-token: write jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - uses: actions/setup-java@v5 with: java-version: '25' distribution: 'temurin' - uses: jfrog/fly-action@v1 # Setup Fly package managers - run: ./gradlew build # Dependencies from Fly registry - run: ./gradlew publish # Publish to Fly registry ``` --- *Back to [Package Managers →](../)* --- # Notifications URL: https://docs.fly.jfrog.com/fly-platform/notifications/ Markdown: https://docs.fly.jfrog.com/fly-platform/notifications/index.md > Describe what you care about in plain language, and Fly notifies you in Slack when it happens. --- ## Overview Stay connected to what's happening with your team and your product. Know about everything that ships and deploys. Describe what you care about in plain language, and Fly notifies you in Slack. --- ## Manage your watches A watch is a free-text description of what you want to be notified about. ### Set up a new watch Tell Fly what you care about in plain language. Fly uses semantic matching, so your watch doesn't need exact keywords. *"Alert me when something hits production"* matches deployment events to your prod environment. When you set up a watch, you decide: - **What you want to be notified about** — a release, deployment, or distribution event. - **Where notifications go** — your DM, a channel, or your whole team. Notifications arrive in Slack regardless of which interface you used to set the watch. Multiple watches can overlap; Fly deduplicates equivalent ones automatically. ### Watch types Fly notifies you about: | Event | What you see | Example watch | |---|---|---| | **Release** | What was released, a short summary, when, and by whom. | *"Notify me when a new release is created for payment-service."* | | **Deployment** | What was deployed, the repository, when, the image version, and which environment. | *"Notify me when a new version is deployed to production."* | | **Distribution** | Who distributed it. Where to find it. | *"Notify me when a new public version of my-app is distributed."* | ### Notification levels Each watch can be delivered as: - **Personal notification** — Fly DMs you when the watch matches. - **Channel notification** — Fly posts in a specific Slack channel. - **Team notification** — Fly notifies your whole team. ### Where to set watches Set, list, edit, or remove watches from any of these. All work in plain language: - **Your coding agent.** Ask in natural language. - **Fly Web.** Ask Fly Chat in your web interface to set a watch for you. - **Slack.** Use `/fly` from any channel or DM, or open the Fly Slack app. Each team can have up to **50 watches**. ### Edit or remove watches Edit or remove watches the same way you set them up. Any interface, in plain language: *"Remove the watch about production deployments."* *"List my watches."* > [!NOTE] > Make sure your Fly Slack app is connected. See [how to set up Slack](../../where-to-use-fly/slack/). --- ## Next steps - [Slack →](../../where-to-use-fly/slack/) - Set up Slack to receive notifications - [Releases →](../releases/) - Release events that trigger notifications - [Runtime Environments →](../runtime-environments/) - Environment events for deployment notifications - [Distribution →](../distribution/) - Distribute artifacts publicly and track downloads --- # Generic URL: https://docs.fly.jfrog.com/package-managers/generic/ Markdown: https://docs.fly.jfrog.com/package-managers/generic/index.md > Upload, download, and distribute any file through Fly Registry, organized by package name and version. --- ## Overview Upload any file to Fly Registry and organize it by package name and version. Generic storage works with any file type -- you choose a package name and version, and Fly stores your files under that path. --- ## How It Works Generic storage organizes files by **package name** and **version**: | Concept | What it is | Example | |---------|-----------|---------| | **Package name** | A name that groups related files | `my-app`, `ml-models`, `config-bundle` | | **Version** | An identifier for a specific set of files | `1.0.0`, `latest`, `nightly-2025-03-18` | | **Files** | One or more files stored under that package and version | `app.dmg`, `checksums.txt` | A file's full path in Fly Registry is: `.jfrog.io/artifactory/api/generic///` Use generic storage for anything that doesn't go through a package manager: release binaries, build outputs, signed archives, configuration bundles, or any file your team needs to share and version. ### Parameters | Parameter | Required | Description | |-----------|----------|-------------| | `--name` | Yes | Package name to group your files under | | `--version` | Yes | Version label for this set of files | | `--exclude` | No | Wildcard pattern to skip matching files (can be used multiple times) | | `--output-dir` | No | Directory to save downloaded files to (download only) | Files are listed at the end of the command. You can specify one or more file paths, or use wildcards like `*.zip`. --- ## Upload Package ### With Fly App Ask your coding agent: *"Upload my release files to Fly under my-app version 1.0.0"* Or use the terminal directly -- Fly App handles authentication automatically: ```bash fly upload --name my-app --version 1.0.0 dist/app.dmg ``` Upload multiple files or use wildcards: ```bash # Multiple files or wildcards fly upload --name my-app --version 1.0.0 release/*.zip build/**/*.bin # Skip specific files fly upload --name my-app --version 1.0.0 --exclude '*.log' release/* ``` When you use a pattern like `dist/**`, Fly uploads every file it finds inside that folder tree. Folders and symlinks are skipped -- only files are uploaded. Each file is stored under its **filename only**, with no folder path. So `dist/linux/app` and `dist/macos/app` would both arrive as `app` and clash. When that happens, the upload stops and lists which files collided. Rename them, or skip one with `--exclude`. ### With an Access Token To upload without Fly App authentication, use an access token with cURL: ```bash curl -u : \ -T my-file.bin \ https://.jfrog.io/artifactory/api/generic/my-app/1.0.0/my-file.bin ``` --- ## Download Package ### With Fly App Ask your coding agent: *"Download my-app version 1.0.0 from Fly"* Or use the terminal directly: ```bash fly download --name my-app --version 1.0.0 app.dmg ``` Download multiple files to a specific folder: ```bash fly download --name my-app --version 1.0.0 --output-dir ./release file1.zip file2.tar.gz ``` > [!NOTE] > Unlike upload, download expects exact filenames -- glob patterns are not expanded. ### With an Access Token To download without Fly App authentication, use an access token with cURL: ```bash curl -u : \ -O https://.jfrog.io/artifactory/api/generic/my-app/1.0.0/my-file.bin ``` --- ## Upload Package with CI Ask your coding agent: **"Add my app (generic package) version 1.0.0 to my workflow"** -- Fly will configure it for you. **1. Add permissions** (top level, after `on:`): ```yaml permissions: contents: read id-token: write ``` **2. Add Fly Action and upload step** (in your job's `steps:`): ```yaml - uses: jfrog/fly-action@v1 # Setup Fly package managers - uses: jfrog/fly-action/upload@v1 # Upload artifacts with: name: my-app version: '1.0.0' files: | dist/*.zip dist/*.tar.gz ``` --- ## Download Package with CI **1. Add permissions** (top level, after `on:`): ```yaml permissions: contents: read id-token: write ``` **2. Add Fly Action and download step** (in your job's `steps:`): ```yaml - uses: jfrog/fly-action@v1 # Setup Fly package managers - uses: jfrog/fly-action/download@v1 # Download artifacts with: name: my-app version: '1.0.0' files: | installer.dmg checksums.txt exclude: | # Skip files matching pattern *.log output-dir: ./release ``` --- ## GitHub Action Example A complete workflow with both upload and download: ```yaml name: Release Artifacts on: push: tags: ['v*'] permissions: contents: read id-token: write # Authentication jobs: release: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - uses: jfrog/fly-action@v1 # Setup Fly package managers - uses: jfrog/fly-action/upload@v1 # Upload artifacts with: name: my-app version: ${{ github.ref_name }} files: | dist/*.zip dist/*.tar.gz - uses: jfrog/fly-action/download@v1 # Download artifacts with: name: my-app version: ${{ github.ref_name }} files: installer.dmg output-dir: ./release ``` --- ## Distribution Generic artifacts support public distribution -- make a specific version downloadable by anyone without authentication. Once you distribute a version, your customers download it directly from a public URL, no sign-in required. To manage and track your distributions, see [Distribution →](../../fly-platform/distribution/). ### Distribute with CI Add the distribute step after your upload: ```yaml - uses: jfrog/fly-action@v1 # Setup Fly - uses: jfrog/fly-action/distribute@v1 # Distribute publicly with: name: my-app version: '1.0.0' type: generic ``` To distribute multiple artifacts, add a step for each: ```yaml - uses: jfrog/fly-action/distribute@v1 with: name: my-app version: '1.0.0' - uses: jfrog/fly-action/distribute@v1 with: name: my-lib version: '2.3.1' ``` | Input | Required | Description | |-------|----------|-------------| | `name` | Yes | Package name to distribute | | `version` | Yes | Version to distribute | | `type` | No | Package type (defaults to `generic`) | ### Public Download URL Once a version is distributed, anyone can download it using this URL: ``` https://.jfrog.io/public/generic/// ``` | Parameter | Description | Example | |-----------|-------------|---------| | `` | Your Fly organization subdomain | `acme` | | `public` | The public registry path (fixed) | `public` | | `generic` | The package type (fixed) | `generic` | | `` | The generic package name | `my-app`, `ml-models` | | `` | The distributed version | `2.1.0`, `nightly-2025-03-18` | | `` | The filename to download | `my-app.dmg`, `checksums.txt` | **Example:** ```bash curl -O https://acme.jfrog.io/public/generic/my-app/2.1.0/my-app.dmg ``` ### Latest Version To always point to the most recently distributed version, use `[LATEST]` in place of the version: ``` https://.jfrog.io/public/generic//[LATEST]/ ``` `[LATEST]` resolves to the most recently distributed version **by time**, not by version number. If you distribute versions `1.0.0`, `2.0.0`, and then `1.9.9` in that order, `[LATEST]` serves `1.9.9`. `[latest]`, `[Latest]`, and `[LATEST]` all work the same way. The `[LATEST]` URL redirects to the actual latest version. Browsers and most download tools follow the redirect automatically. With `curl`, add the `-L` flag so the download follows it: ```bash curl -L -O https://acme.jfrog.io/public/generic/my-app/[LATEST]/my-app.dmg ``` > [!NOTE] > `[LATEST]` is only available for public downloads. It cannot be used as a version when uploading -- use a concrete version like `1.0.0` instead. --- ## Verify Results After each upload or download, you can verify your files were transferred successfully. The action outputs a summary for each file: ```yaml - name: Upload artifacts id: upload uses: jfrog/fly-action/upload@v1 with: name: my-app version: '1.0.0' files: dist/*.zip - name: Check results run: echo '${{ steps.upload.outputs.results }}' # [{"name":"app.zip","status":"success","message":"..."}] ``` --- *Back to [Package Managers →](../)* --- # Team Management URL: https://docs.fly.jfrog.com/fly-platform/team-management/ Markdown: https://docs.fly.jfrog.com/fly-platform/team-management/index.md > Manage your team's access to Fly. Add members, assign roles, and control permissions. --- ## Overview Manage your team's access to Fly. Add members, assign roles, and control who can do what. The first user to create the account becomes the team Admin. --- ## How It Works ### User Roles JFrog Fly has two role types: **Admin** -- Full access to all Fly functionality: | Permission | Admin | |------------|-------| | Push/Pull artifacts | Yes | | View artifacts and releases | Yes | | Manage workflows | Yes | | **Invite users** | Yes | | **Update user roles** | Yes | | **Delete users** | Yes | | **Create/revoke all tokens** | Yes | | **Manage team settings** | Yes | **Developer** -- Standard development access: | Permission | Developer | |------------|-----------| | Push/Pull artifacts | Yes | | View artifacts and releases | Yes | | Manage workflows | Yes | | View user list | Read-only | | Create tokens | Yes | | Revoke own tokens | Yes (only tokens they created) | | Invite users | No | | Update roles | No | | Delete users | No | | Revoke others' tokens | No | ### User Status **Active** -- User has completed sign-up, can access Fly Registry, and appears in searches and @mentions. **Pending** -- User has been invited but hasn't signed up yet. You can resend the invitation if needed. --- ## In Fly Web Team management is currently available through Fly Web. You can view all team members, invite new users, assign roles, and remove members. ### Viewing Team Members Navigate to **Team Management** to see: | Column | Description | |--------|-------------| | **Name** | User's full name | | **Email** | User's email address | | **Role** | Admin or Developer | | **Status** | Active or Pending | | **Last Login** | Most recent login timestamp | | **Actions** | Available actions (based on your role) | ### Inviting Users (Admin Only) 1. Click **Invite User** 2. Fill in: **Email Address** (required) and **Role** (Admin or Developer) 3. Click **Send Invitation** 4. User receives an email with a welcome message, team name, and signup link ### Updating User Roles (Admin Only) 1. Navigate to **Team Management** 2. Click on the user 3. Select **Change Role** 4. Choose new role and confirm The system ensures at least one Admin always exists. ### Removing Users (Admin Only) 1. Navigate to **Team Management** 2. Click on the user 3. Select **Delete User** 4. Confirm deletion --- ## Password & Authentication Manage your password and two-factor authentication from **Account Settings > Password & Authentication** in Fly Web. ### Password Update your password at any time. Click **Edit** to change it. ### Two-Factor Authentication (TOTP) Add an extra layer of security with an authenticator app (Google Authenticator, Authy, 1Password, etc.): - To enable: click **Add** on the Authenticator App card, then scan the QR code with your authenticator app - To disable: click **Disable** on the Authenticator App card Admins can see which team members have MFA enabled in the Team Management table. --- ## Next Steps - [Tokens →](../tokens/) - Token permissions by role --- # Distribution URL: https://docs.fly.jfrog.com/fly-platform/distribution/ Markdown: https://docs.fly.jfrog.com/fly-platform/distribution/index.md > Share artifact versions with your customers so they download or pull them directly, track every download, and revoke access anytime. --- ## Overview Get a release into your customers' hands. You shipped a version you're confident in -- distribution is how you hand it to the people outside your team who need it. Pick the version you want to share, make it public, and Fly gives you a link or command your customers use to get it directly. Every download is tracked, and you can revoke access the moment you're done. --- ## Distribute Distributing an artifact version makes it available to your customers. Once a version is publicly available, anyone you share the link or pull command with can download or pull it directly, without a token. Distribution never changes your private registry. Your internal artifacts stay private -- distribution takes the specific version you choose and makes that copy available to your customers. You decide which versions to share, and you can revoke access at any time. Distribution currently supports the following package types: - **Generic artifacts** -- [Manage generic distribution →](../../package-managers/generic/#distribution) - **Docker images** -- [Manage Docker distribution →](../../package-managers/docker/#distribution) ### How to Distribute #### From Your Coding Agent Simply prompt your agent to distribute your version: *"Distribute my-app version 2.1.0 publicly"* Fly makes the version public and hands back the download URL or `docker pull` command to share with your customers. #### From Fly Web 1. Find the artifact or release you want to share -- from the **Artifacts** page or a **Release** page 2. Open the actions menu and select **Manage Distribution** 3. Toggle distribution on Fly generates the public download URL (for generic artifacts) or pull command (for Docker images) right there for you to copy and share. #### From CI Add the distribute step after you upload or push, so every release you publish is shared automatically. **Generic artifact:** ```yaml - uses: jfrog/fly-action@v1 # Setup Fly - uses: jfrog/fly-action/distribute@v1 # Distribute publicly with: name: my-app version: '1.0.0' type: generic ``` **Docker image:** ```yaml - uses: jfrog/fly-action/distribute@v1 # Distribute publicly with: name: myorg/my-image version: '1.0.0' type: docker ``` ### How to Pull Your customers retrieve the version directly, with no authentication. The command depends on the package type. #### Generic Artifact Customers download any file in the version from its public URL: ```bash https://.jfrog.io/public/generic/// ``` For example: ```bash curl -O https://acme.jfrog.io/public/generic/my-app/2.1.0/my-app.dmg ``` #### Docker Image Customers pull the image anonymously, with no `docker login`: ```bash docker pull .jfrog.io/docker-public/: ``` For example: ```bash docker pull acme.jfrog.io/docker-public/myorg/my-image:1.0.0 ``` --- ## Track Distribution Keep track of what you've shared -- how many times each of your releases has been downloaded, and what's currently public. Check in anytime by asking your coding agent, or open Fly Web to view and manage it directly: - **Public badge** -- Distributed versions display a **Public** badge on the artifact version and on the release it belongs to. Hover the badge to see who distributed the version and when. - **Download activity** -- Expand a distributed version on the **Artifacts** page to see its public activity: - **Download count** -- how many times the version was downloaded or pulled publicly, updated in real time. - **Copy link** -- copy its public download URL or pull command to share with customers. Want to keep tabs on what's public? Ask your coding agent to notify you whenever a new distribution happens -- and you're all set. Read more in [Notifications →](../notifications/). --- ## Remove Distribution Stop sharing a version whenever you need to. When you remove its distribution, the version becomes private again immediately -- the public download URL and pull command stop working, and your customers can no longer access it. Removing distribution only turns off public access. The artifact itself stays in your private registry, so you can distribute the same version again later. To remove it, ask your coding agent: *"Revoke public access to my-app version 2.1.0"* Or toggle it off in Fly Web: 1. Find the distributed artifact or release -- from the **Artifacts** page or a **Release** page 2. Open the actions menu and select **Manage Distribution** 3. Toggle distribution off > [!NOTE] > If you delete the original artifact, Fly removes the public copy and all distribution data automatically. --- ## Next Steps - [Distribute Docker images →](../../package-managers/docker/#distribution) - Push an image, then make it publicly pullable - [Distribute generic artifacts →](../../package-managers/generic/#distribution) - Upload a file, then share a public download URL - [Artifacts →](../artifacts/) - Browse and manage all your artifacts - [Releases →](../releases/) - Releases that produce artifacts - [Notifications →](../notifications/) - Get notified when distribution events happen --- # Search URL: https://docs.fly.jfrog.com/search/ Markdown: https://docs.fly.jfrog.com/search/index.md ---