How Alchemy handles versions
Alchemy Subgraphs uses a “live version” promotion system:- Each subgraph has a live version that serves traffic at a static endpoint
- Each subgraph version also gets its own version-specific endpoint
- When deploying a new subgraph, the first version is automatically set to live
- When deploying new versions of existing subgraphs, they are not automatically promoted to live; you manually promote versions to live via the dashboard or API, or enable auto-promotion for a version to become live once it finishes syncing.
How Goldsky handles tags
Goldsky uses a simpler, explicit tagging system:- Subgraph endpoints are named after the subgraph name and version by default
- You create tags explicitly using the CLI to create stable endpoint aliases
- Tags can be moved between versions seamlessly
- No concept of “live version” - tags are the primary mechanism for stable endpoints
Migrating your workflow
Step 1: Create a tag for your production endpoint
Instead of promoting to “live”, create a tag that represents your production environment:Step 2: Update your application code
Replace your Alchemy endpoint with the Goldsky tag-based endpoint: Before (Alchemy):Step 3: Deploy new versions and update tags
When you deploy a new version, the tag workflow is straightforward:Benefits of Goldsky’s approach
- More explicit: Tags are clearly defined, not implicit “live” promotions. While this means additional effort in switching the tags once a subgraph is sycned, it allows for more explicit control over when frontend changes go live.
- Multiple stable endpoints: Create as many tags as you need (prod, staging, dev, etc.), and name them as appropriate in your workflow. This is a simpler mental model where all tags are just pointers to a specific subgraph version, there is no special “live” state.