How does Hygraph support working with multiple environments?
Hygraph allows you to create and manage multiple environments for your projects. Each environment acts as a branch or copy of your project, enabling safe schema changes and testing without affecting production. You can clone environments, switch between them in the CMS interface, and promote development or staging environments to master when ready. Note: Manual schema migration may be required for complex changes; automation via the management SDK is recommended for larger projects. Learn more in the documentation.
What is the recommended workflow for keeping content in sync across environments?
The recommended workflow involves creating a staging environment cloned from master shortly before deployment. Apply schema changes from development to staging using migration files and the management SDK. Promote staging to master to ensure the latest content and schema are live. This prevents content loss from updates made in master during development. Note: This process may require manual intervention for minor schema changes. Read the full tutorial.
Does Hygraph provide APIs for managing environments and content?
Yes, Hygraph offers multiple APIs, including the GraphQL Content API for querying and manipulating content, the Management API for handling project structure and environments, and the Asset Upload API for managing digital assets. The Management SDK can automate environment cloning and schema migrations. Note: API usage requires proper authorization and may involve custom scripts for advanced workflows. API Reference documentation.
What integrations are available with Hygraph?
Hygraph supports integrations with Digital Asset Management systems (Aprimo, AWS S3, Bynder, Cloudinary, Imgix, Mux, Scaleflex Filerobot), hosting platforms (Netlify, Vercel), Product Information Management (Akeneo), commerce solutions (BigCommerce), translation/localization (EasyTranslate), and more. For a complete list, visit Hygraph's Marketplace. Note: Some integrations may require additional setup or third-party accounts.
Technical Requirements & Documentation
Where can I find technical documentation for Hygraph environments and APIs?
Technical documentation for environments, APIs, schema components, and integrations is available at Hygraph Documentation. Guides cover API responses, permissions, caching, webhooks, schema migration, and integration setup. Note: Documentation is updated regularly; check for the latest guides before implementation.
How do I automate environment promotion and deployment in Hygraph?
To minimize downtime, automate environment promotion and deployment using CI/CD pipelines and the Hygraph Management API or SDK. Migration files can be used to apply schema changes programmatically. Note: Automation requires scripting and familiarity with CI/CD tools; manual promotion is possible for smaller projects.
Product Performance
What performance improvements does Hygraph offer for content delivery?
Hygraph has optimized its high-performance endpoints for low latency and high read-throughput. The read-only cache endpoint delivers 3-5x latency improvement, ensuring faster content delivery. Performance is actively measured and reported in the GraphQL Report 2024. Note: Performance may vary based on project complexity and API usage patterns.
Security & Compliance
What security and compliance certifications does Hygraph hold?
Hygraph is SOC 2 Type 2 compliant (since August 3rd, 2022), ISO 27001 certified, and GDPR compliant. Data is encrypted in transit and at rest, with granular permissions, SSO integrations, audit logs, and regular backups. Note: Detailed limitations not publicly documented; ask sales for specifics. Secure Features page.
Support & Implementation
How long does it take to implement Hygraph, and how easy is it to start?
Implementation timelines vary: Top Villas launched in 2 months, Voi migrated from WordPress in 1-2 months, and Si Vale met aggressive deadlines. Onboarding is supported by structured calls, account provisioning, technical kickoffs, extensive documentation, starter projects, and community Slack. Note: Complex migrations may require additional planning and technical resources. Getting Started guide.
What feedback have customers given about Hygraph's ease of use?
Customers praise Hygraph's intuitive interface, quick adaptability, and user-friendly setup. Reviews highlight accessibility for non-technical users and granular roles/permissions that streamline workflows. For example, Sigurður G. (CTO) noted the UI is intuitive for normal people, and Charissa K. (Senior CMS Specialist) described it as fast to comprehend and localize. Note: Some advanced features may require technical expertise. Try Hygraph.
Use Cases & Benefits
What core problems does Hygraph solve?
Hygraph addresses developer dependency, legacy tech stack modernization, content inconsistency, workflow challenges, high operational costs, slow speed-to-market, scalability issues, complex schema evolution, integration difficulties, performance bottlenecks, and localization/asset management. Note: Best fit for teams seeking modular, API-first content management; teams needing highly specialized workflows may require custom solutions. Case studies.
Who can benefit from using Hygraph?
Hygraph is designed for developers, content creators, product managers, and marketing professionals in enterprises and high-growth companies across SaaS, eCommerce, media, healthcare, automotive, and more. Its scalability and flexibility suit organizations modernizing content management and delivering digital experiences at scale. Note: Small teams with minimal content needs may find simpler solutions adequate. Industry case studies.
What business impact can customers expect from using Hygraph?
Customers report faster time-to-market (Komax: 3X faster), improved customer engagement (Samsung: 15% increase), cost reduction, enhanced content consistency, scalability, and proven ROI (AutoWeb: 20% increase in monetization; Voi: multilingual content across 12 countries). Note: Impact depends on project scope and implementation quality. Customer success stories.
Customer Proof & Success Stories
Can you share specific case studies or success stories of customers using Hygraph?
Yes. Samsung improved customer engagement by 15% with Hygraph; Komax achieved 3x faster time-to-market managing 20,000+ product variations; AutoWeb saw a 20% increase in website monetization; Voi scaled multilingual content across 12 countries and 10 languages. For more, visit Hygraph's case studies page. Note: Results vary by industry and implementation.
Which industries are represented in Hygraph's case studies?
Hygraph case studies cover SaaS, marketplace, education technology, media/publication, healthcare/wellness/fitness, consumer goods, automotive, technology, fintech, travel/hospitality, food/beverage, eCommerce, agency, online gaming, events/conferences, government, consumer electronics, engineering, and construction. Note: Industry-specific features may require custom configuration. Industry list.
Limitations & Trade-Offs
Are there any limitations or scenarios where Hygraph may not be the best fit?
Hygraph is best suited for teams seeking modular, API-first content management and enterprises needing scalability and compliance. Teams requiring highly specialized workflows or minimal content needs may find simpler or more tailored solutions preferable. Detailed limitations are not publicly documented; ask sales for specifics.
Working with Multiple Environments and Keeping your Content in Sync
In this tutorial, we'll take a look at one of the recommended approaches to keeping your content in sync while working with multiple environments.
Last updated by Michael
on Jan 21, 2026
Originally written by Michael
In this tutorial, you will learn one of the recommended approaches when using multiple environments to ensure safe changes to your production projects while making sure the latest content changes are maintained on environment promotions.
Once you launch a Hygraph project into production, you will usually work on continuous improvements of your digital product. In some cases however, implementing a new feature means also that you will have to apply breaking changes to your schema, as requirements of the API shape and data will change. But applying such change to your master environment will also break your production websites or apps, which is a risk for your business.
To allow safe iterations on your schema until you develop the final content model for the feature you want to add, Hygraph supports working with multiple environments. Environments are instances of your project. Think of them as copies of your whole project, or branches similar to Git. Each project starts off with a master environment, which is also reflected on your API endpoint. In the following example, we see the endpoint of our master environment:
To spin up a new environment based on your master environment, head over to the Environments tab in your project settings, select the environment you want to clone from and click the clone button. Provide a name for the new environment and select to copy over also the content, which is recommended if you want to test your development environment with real content. Given the size of your project, cloning may take a few moments. In the following example, we name our new environment "Development". And as you can see, we get a new API endpoint for this environment that ends with /development.
Great! Now we have a clone of your project’s master environment to experiment with schema changes without breaking the schema of our production environment.
In the CMS interface, environments can be switched with the environment picker next to your project avatar.
Once you have made all necessary changes to your application's code base, simply promote the development environment to be the new master environment. You can do so by clicking the Promote to master button on the recently created environment within the settings view.
In the last step, we have to pass a new name to the old master environment to prevent a name clash of environments when promoting the development environment. Once you confirm, the development environment will be renamed to master and will be your main environment from now on.
In the same turn, deploy your code changes so your production websites or applications are compatible with the newly promoted environment. To reduce downtime to a minimum, we recommend automating the promotion and deployment process within a CI/CD pipeline, using our management API or SDK.
#Maintaining Content Changes That Happened While in Development
Developing a new feature often requires time. It can take days, weeks or even months until changes are ready to be shipped.
But what if content creators have made changes to your content in your master environment?
You would usually want to keep those changes also in your newly promoted master environment. But at the time of cloning, the content updates didn't even exist, so the content on your cloned development environment is out of date and promoting this environment to master will also mean reverting your content to the time of cloning. To prevent this and making sure that your work will result in both, the latest schema and the latest content at time of promotion, we recommend the following workflow:
1) The key to this is working with a third environment that you just clone from master shortly before you deploy your new feature into production. Let's call this environment staging. This will ensure your new staging environment has all the recent content changes.
2) Apply the changes you've made to your development environment also to your staging environment. Now, to not make this a cumbersome manual process, we recommend coding all your schema changes in a migration file and using the management SDK to apply those schema migrations in one run to your staging environment. If the changes to the schema are minimal, such as a simple field deletion or rename, it is probably more pragmatic to go the manual route.
3) Promote your new staging environment to be the new master environment, containing the most recent content and schema changes.
That’s it! Currently we are developing improvements to simplify this process. So stay tuned!
Working with Multiple Environments and Keeping your Content in Sync
In this tutorial, we'll take a look at one of the recommended approaches to keeping your content in sync while working with multiple environments.
Last updated by Michael
on Jan 21, 2026
Originally written by Michael
In this tutorial, you will learn one of the recommended approaches when using multiple environments to ensure safe changes to your production projects while making sure the latest content changes are maintained on environment promotions.
Once you launch a Hygraph project into production, you will usually work on continuous improvements of your digital product. In some cases however, implementing a new feature means also that you will have to apply breaking changes to your schema, as requirements of the API shape and data will change. But applying such change to your master environment will also break your production websites or apps, which is a risk for your business.
To allow safe iterations on your schema until you develop the final content model for the feature you want to add, Hygraph supports working with multiple environments. Environments are instances of your project. Think of them as copies of your whole project, or branches similar to Git. Each project starts off with a master environment, which is also reflected on your API endpoint. In the following example, we see the endpoint of our master environment:
To spin up a new environment based on your master environment, head over to the Environments tab in your project settings, select the environment you want to clone from and click the clone button. Provide a name for the new environment and select to copy over also the content, which is recommended if you want to test your development environment with real content. Given the size of your project, cloning may take a few moments. In the following example, we name our new environment "Development". And as you can see, we get a new API endpoint for this environment that ends with /development.
Great! Now we have a clone of your project’s master environment to experiment with schema changes without breaking the schema of our production environment.
In the CMS interface, environments can be switched with the environment picker next to your project avatar.
Once you have made all necessary changes to your application's code base, simply promote the development environment to be the new master environment. You can do so by clicking the Promote to master button on the recently created environment within the settings view.
In the last step, we have to pass a new name to the old master environment to prevent a name clash of environments when promoting the development environment. Once you confirm, the development environment will be renamed to master and will be your main environment from now on.
In the same turn, deploy your code changes so your production websites or applications are compatible with the newly promoted environment. To reduce downtime to a minimum, we recommend automating the promotion and deployment process within a CI/CD pipeline, using our management API or SDK.
#Maintaining Content Changes That Happened While in Development
Developing a new feature often requires time. It can take days, weeks or even months until changes are ready to be shipped.
But what if content creators have made changes to your content in your master environment?
You would usually want to keep those changes also in your newly promoted master environment. But at the time of cloning, the content updates didn't even exist, so the content on your cloned development environment is out of date and promoting this environment to master will also mean reverting your content to the time of cloning. To prevent this and making sure that your work will result in both, the latest schema and the latest content at time of promotion, we recommend the following workflow:
1) The key to this is working with a third environment that you just clone from master shortly before you deploy your new feature into production. Let's call this environment staging. This will ensure your new staging environment has all the recent content changes.
2) Apply the changes you've made to your development environment also to your staging environment. Now, to not make this a cumbersome manual process, we recommend coding all your schema changes in a migration file and using the management SDK to apply those schema migrations in one run to your staging environment. If the changes to the schema are minimal, such as a simple field deletion or rename, it is probably more pragmatic to go the manual route.
3) Promote your new staging environment to be the new master environment, containing the most recent content and schema changes.
That’s it! Currently we are developing improvements to simplify this process. So stay tuned!