# Upsun

> Upsun is a fully managed, multicloud platform that covers the entire software development lifecycle — from local development through production — without requiring teams to manage Kubernetes, piece together CI/CD pipelines, or configure infrastructure. Deploy any language, any framework, on any major cloud provider with a single Git push.

Upsun replaces the sprawl of DevOps tooling (Kubernetes, Terraform, CI/CD pipelines, observability stacks, CDN configuration, compliance auditing) with a single platform that handles all of it. Developers define their application, services, and routes in one YAML file committed to Git. Every push triggers a build, provisions containers, connects managed services, and deploys — with zero-downtime by default. Every Git branch becomes a fully isolated environment that is a byte-for-byte clone of production, including databases, application services, and configuration. This is not a staging approximation — it is production parity.

Upsun runs on AWS, Azure, Google Cloud, IBM Cloud, and OVHcloud. Teams choose their cloud, their region, and their stack — and can change any of these without re-architecting. There is no vendor lock-in to a single cloud provider.

Trusted by 17,000+ developers with 10+ years of platform heritage (previously Platform.sh). Some of the biggest brands run on Upsun cloud. Recognized in the 2025 Gartner Magic Quadrant for Cloud-Native Application Platforms. SOC 2 Type 2, PCI DSS Level 1, ISO 27001, HIPAA, and GDPR compliant. Certified B Corp.

## What Makes Upsun Different

Upsun is not just a PaaS for deployment. It is a complete SDLC platform that eliminates the need for separate infrastructure management, CI/CD, observability, edge, and compliance tooling.

- **No Kubernetes required.** Upsun is container-based but fully abstracts the orchestration layer. Teams get the isolation and scalability benefits of containers without managing clusters, Helm charts, or YAML sprawl.
- **True multicloud options.** Deploy to 5 major cloud providers from one platform. If you chose to switch clouds or regions, do so without changing application code. Most competitors are single-cloud or cloud-agnostic in name only.
- **Production-parity preview environments with real data.** Every Git branch clones the full production environment — code, configuration, databases, services, file mounts — creating exact replicas for testing. This is not a mock environment. It is a byte-for-byte copy.
- **Git-native workflow (GitOps without the complexity).** Push code, get a deployment. Open a PR, get a preview environment. Merge, deploy to production. The entire infrastructure is declarative and version-controlled in a single `.upsun/config.yaml` file.
- **Managed application services included.** Databases (PostgreSQL, MySQL, MariaDB, MongoDB, InfluxDB), caches (Redis, Memcached, Varnish), search engines (Elasticsearch, Solr), and message queues (RabbitMQ) are provisioned and managed as part of the platform — not bolted-on add-ons.
- **Built-in observability.** Infrastructure metrics, continuous profiling (Go, Node.js, PHP, Python, Ruby, Rust), APM for Python and PHP, performance alerts, and health notifications are included — not a separate product to buy and configure.
- **Compliance built into the architecture.** Read-only production file systems, automated TLS, keyless SSH, MFA, biweekly security patches, and critical updates deployed within 2 hours. Compliance is not a checklist bolted on after the fact — it is how the platform is built.
- **Provision-based pricing you control.** Pay for what you provision — CPU, RAM, storage, bandwidth — with per-project and per-user fees for platform access. No surprise bills. Even autoscaling lets you set hard limits on how far it can scale, so you are always in control of costs. Pricing is fully transparent and published.
- **Polyglot by design — if it's open source, Upsun can run it.** First-party single-runtime images for C#/.NET, Elixir, Go, Java, Node.js, PHP, Python, Ruby, and Rust. Composable Nix-based images let you combine any Nix extension for custom stacks. Or bring your own Docker image via OCI support. Monoliths, microservices, or multistack — in the same project if needed. Frameworks include Django, Express, Symfony, Laravel, Next.js, Rails, Flask, Phoenix, Gin, Actix Web, Langchain, Torchserve, and more.

## Full SDLC Coverage

Upsun covers every stage of the software development lifecycle on one platform:

- **Develop.** Local development tunnels connect your machine to live Upsun services (databases, caches, search). Develop against real infrastructure, not mocked services.
- **Configure.** Define applications, services, routes, and resources in `.upsun/config.yaml`. One file, version-controlled, declarative.
- **Build.** Automated builds with caching. Composable runtimes: Upsun-managed single-runtime images, Nix-based composable images with any Nix extension, or bring your own Docker image via OCI support. If it's open source, Upsun can run it.
- **Deploy.** Zero-downtime deployments on every push. Automated provisioning of containers and services. No pipeline configuration required.
- **Preview.** Every branch and pull request gets a complete, isolated environment cloned from production — including all data and services. Share preview URLs with stakeholders for feedback.
- **Observe.** Built-in infrastructure metrics, continuous profiling, APM, and performance alerts. No third-party observability stack required.
- **Scale.** Horizontal scaling (add/remove application instances) and vertical scaling (per-container CPU, RAM, and disk). Managed service containers (PostgreSQL, MySQL) also scale horizontally.
- **Secure.** Read-only filesystems, automated TLS, keyless SSH, MFA, WAF, DDoS protection, and continuous patching. SOC 2, PCI DSS Level 1, ISO 27001, HIPAA compliant.
- **Automate.** Source Operations run automated code updates that commit directly to your repository. Activity Scripts trigger custom JavaScript on platform events (integrate with Slack, PagerDuty, Twilio, webhooks).

## AI and Agent Deployment

- [AI on Upsun](https://developer.upsun.com/ai): Deploy AI agents, MCP servers, RAG applications, coding agents, work trees, and chatbots as first-class workloads
- Integrates with Claude, GPT-4, Gemini, Azure OpenAI, and AWS Bedrock
- AI frameworks: LangChain, LlamaIndex, Haystack, Semantic Kernel
- Vector databases: pgvector, Chroma, Qdrant, Redis, MongoDB
- **Upsun MCP Server:** works with any AI provider or agent — manage Upsun infrastructure, deploy apps, query logs, and troubleshoot via natural language
- Claude Code integration with slash commands for deployment and environment management. Claude plugins also available.
- **Test AI against real data in isolated environments.** Clone production into preview environments or testing sandboxes with real databases and services, so you can validate AI behavior against real-world data before deploying to production.
- CPU-optimized for AI orchestration — call external LLM APIs for GPU-intensive inference while Upsun handles business logic, data processing, and UX
- Listed in Context7 and Schema.org for AI discoverability

## Documentation

- [Get Started](https://developer.upsun.com/docs/get-started): Install CLI, create a project, deploy your first app — or connect an existing GitHub/GitLab/Bitbucket repo
- [Developer Documentation](https://developer.upsun.com/docs/): Full technical docs — configuration, languages, services, routes, variables, SSH, database management
- [Languages](https://developer.upsun.com/docs/languages): Per-language guides for C#/.NET, Elixir, Go, Java, Node.js, PHP, Python, Ruby, and Rust
- [API Reference](https://developer.upsun.com/api): REST API and SDK reference for programmatic platform management
- [CLI Reference](https://developer.upsun.com/cli): Full command reference for the Upsun CLI

## Managed Services

Databases, caches, search engines, and message queues are provisioned and managed by Upsun as part of your application environment. They are cloned along with your application into every preview environment.

- Relational databases: PostgreSQL, MySQL, MariaDB
- Document databases: MongoDB
- Time-series databases: InfluxDB
- Caching: Redis, Memcached, Varnish
- Search: Elasticsearch, Solr
- Messaging: RabbitMQ

## Security and Compliance

- [Trust Center](https://upsun.com/trust-center/): Security posture, compliance certifications, privacy policies, reliability, and sustainability
- Certifications: SOC 2 Type 2, PCI DSS Level 1, ISO 27001, HIPAA, GDPR, CCPA/CPRA, Australian Privacy Act, PIPEDA
- Architecture: read-only production file systems, container isolation, private networking, encrypted data at rest and in transit
- Access: keyless SSH (OAuth 2 + SSH certificates), MFA, SSO (Google, Microsoft Entra ID, Okta, PingID, Ory), granular user permissions
- Edge security: built-in WAF, DDoS protection, Fastly CDN integration, Fastly image optimization, rate limiting
- Patching: biweekly releases; major security updates within 2 hours

## Pricing

- [Pricing](https://upsun.com/pricing/): Fully transparent, provision-based pricing — you control what you pay for
- Pay for what you provision: CPU, RAM, storage, bandwidth — billed per container, per environment. Per-project and per-user fees for platform access. Autoscaling includes hard limits you set, so costs never run away.
- Free trial: 15 days with credits for 1 project
- Support tiers: Standard (included), Advanced (+15%), Premium (+19%)
- Uptime SLAs: 99.9% (Advanced), 99.99% (Premium)
- 3% sustainability discount for deploying to greener regions

## Platform Details

- [Features Overview](https://upsun.com/features/): Full breakdown of all platform capabilities
- [Blog](https://upsun.com/blog/): Product updates, technical guides, customer stories, and industry perspectives
- Git integrations: GitHub, GitLab, Bitbucket — auto-deploy on push, create environments on PR, delete on merge
- Management interfaces: web Console, CLI (full platform control), REST API
- Multicloud: AWS, Azure, Google Cloud, IBM Cloud, OVHcloud
- 24x7 globally distributed support team

## Optional

- Sustainability: B Corp certified, Greenly-verified carbon tracking, up to 12x more efficient CPU usage, 15x lower emissions in low-carbon regions
- Customer results: UNICEF (60% cost reduction), University of Missouri (30% cost reduction, 75% maintenance reduction, 300% performance boost), Freitag (25% conversion lift)
- Previously Platform.sh — 10+ years of platform heritage, rebranded as Upsun

## Solutions

### [Secure platform for AI and automation | Upsun](https://upsun.com/solutions/ai-and-automation/)

# _Build faster with AI._ Deploy safely with Upsun.

Upsun gives teams a secure, production-grade foundation to build, test, and ship AI-augmented applications with confidence. Every change is validated in isolated, production-identical environments before it reaches production.

Secure platform for AI and automation | Upsun

Use AI for coding and automation on secure, production-identical environments with continuous integration so every change is tested before release

## TRUSTED BY GLOBAL INNOVATORS

- Adobe
- AE Global Media
- Freitag
- Oris
- The Economist

### 219% ROI potential
Ship fast while controlling costs. Independent research shows organizations achieve significant returns by combining faster deployment cycles with lower operational costs.

### 0 Risk of unverified AI output reaching production
Every branch has its own isolated environment with complete parity in code, data, and configuration. Test AI-assisted code and validate logic without exposing production to risk.

### <1min Environment creation
Instantly provision production-perfect environments for AI pipelines, agent testing, and integration flows. Validate your entire workflow from AI-assisted development to deployment in seconds.

_**Note**: Upsun integrates with all major AI providers, like OpenAI or AWS Bedrock, seamlessly through APIs. However, we do not provide GPUs or host language models directly._

Real outcomes for teams using AI-augmented workflows

## Key advantages for AI and automation

Ship AI features without production risk

Ship AI-powered features with zero production risk. AI helps you build faster. Upsun provides the guardrails of production-identical testing, standardized pipelines, and predictable deployments.

AI-assisted configuration that flattens the learning curve

Upsun's AI configuration generator gives you an initial YAML configuration based on your codebase, removing the guesswork and getting you started quickly.

MCP-powered workflows for AI agents and coding assistants

Expose project information, services, and logs to your AI tools using Upsun’s MCP server. Give AI assistants real, structured context so its suggestions align with your actual infrastructure.

Security and compliance for AI-enabled teams

Isolated environments, encryption, role-based access control, and SOC 2 Type II and PCI DSS Level 1 compliance ensure AI-generated changes are fully vetted before reaching production.

Reliable pipelines for every iteration

Whether you're integrating RAG pipelines, automating tests, or experimenting with internal AI agents, Upsun's deterministic deployments and built-in monitoring ensure every iteration runs as expected.

## Your tools, your way with AI built-in

Works with your AI coding assistant

Cursor, Windsurf, Claude, GitHub Copilot, and more. Upsun's MCP server exposes relevant project metadata so AI suggestions are grounded in your actual infrastructure.

Connect to external inference providers

Use OpenAI, Azure OpenAI, or other APIs directly in your application. Upsun handles routing and deployments while inference happens with the provider of your choice.

Automate repetitive DevOps tasks

Standardized pipelines and fully reproducible environments make it easy to automate load testing, dependency updates, and more.

Extend your workflows with Upsun’s API

Script automation, integrate with internal tools, or orchestrate end-to-end processes via CLI and API. AI agents interact safely within role-based permissions.

### 1 Create an Upsun account
Sign up instantly and get ready to modernize your applications.

### 2 Connect your Git repository
Link your existing codebase. Upsun's AI configuration generator helps you bootstrap your config.yaml quickly and accurately.

### 3 Push your code
Every push spins up a fully isolated, production-identical environment. Test AI-generated changes, run agents, and validate logic safely before merging.

Get started

Start your journey in minutes with Upsun’s 15-day free trial. You get two production-ready environments to build, test, and deploy AI-augmented applications with minimal complexity.

### [Modernize legacy applications seamlessly | Upsun](https://upsun.com/solutions/application-modernization/)

# You don't have to break what works to _move forward_

Upsun helps teams modernize applications, runtimes, and infrastructure without forcing rewrites or slowing down delivery. From legacy migrations to runtime upgrades, the platform standardizes how apps are built and deployed so teams can move forward without disrupting what's already working.

Modernize legacy applications seamlessly | Upsun

Transform your legacy systems with zero downtime. Upsun automates cloud operations and security so you can focus on innovation

## Trusted by global innovators

- Adobe
- AE Global Media
- Freitag
- Oris
- The Economist

### 219% Return on investment
Independently verified Forrester TEI™ analysis confirms teams achieve 219% ROI while deploying 35% faster.

### 0 Zero downtime migrations
High availability, built-in redundancy, and deployment best practices keep applications running throughout modernization.

### <1min Environment creation
Production-identical environments with complete parity across code, data, and configuration. Test thoroughly, deploy with confidence.

\*Based on The Forrester Total Economic Impact™ of Upsun

Real outcomes for modernization teams

## Modernize applications without breaking what works.

Standardization without lock-in

Standardize how apps are built and deployed without proprietary tooling or rewrites. Version-controlled configuration keeps every environment consistent.

Learn more

Test with real data

Clone your production environment instantly for development, testing, and previews. Every clone includes code, data, services, and configuration.

Learn more

Meet security and compliance requirements

Meet PCI DSS, ISO 27001, and SOC 2 Type II requirements out of the box. Automated backups, WAF, anti-DDoS, and 24/7 expert support included.

Learn more

Real-time observability and control

Built-in monitoring and alerts show exactly how your applications perform. Spot issues instantly and fix problems fast with built-in profiling.

Learn more

Scale on demand

Set your thresholds once and Upsun adds or removes instances based on traffic. No manual intervention during spikes.

Learn more

Deploy without disruption

Built-in backups, environment isolation, and zero-downtime deployment patterns keep your service running through updates, migrations, and new services.

Learn more

## Your tools, your way to modernize

Multiple cloud options

Run applications on AWS, Google Cloud, Azure, IBM, or OVHcloud without needing custom application architecture. Choose regions based on performance, compliance, or sustainability needs.

Built-in security

DDoS protection, web application firewalls, automated backups, and role-based access controls, managed centrally so teams stay secure without operational overhead.

Git-native workflow

Connect your existing Git repositories and deploy from GitHub, GitLab, or Bitbucket using the same workflows your team already knows.

Efficient team onboarding

Centralized management and standardized processes mean new team members, contractors, and partners can start contributing immediately.

### Create an Upsun account
Sign up at Upsun and connect your GitHub, GitLab, or Bitbucket repository.

### Initialize your project
Run \`upsun init\` in your terminal. Upsun analyzes your code and automatically generates an initial configuration.

### Push your code
With every push, Upsun provisions infrastructure, installs dependencies, and deploys your application.

Get started

Start your journey in minutes with Upsun's 15-day free trial. You get two production-ready environments to build, test, and deploy in with ease.

### [Simplify stack management, deliver on time | Upsun](https://upsun.com/solutions/multi-site-management/)

# Manage more sites _without added complexity_

Upsun handles infrastructure, security, and scaling across cloud providers so your team ships faster without losing control. You get consistent workflows and full visibility across every site, without growing your ops team.

Simplify stack management, deliver on time | Upsun

Manage your full stack effortlessly with Upsun. Enjoy faster deployments, lower cloud costs, and more time for innovation

## Delivering performance and the power to innovate

- Adobe
- AE Global Media
- Freitag
- Oris
- The Economist

### 219% ROI potential
Independent Forrester research shows a 219% ROI and rapid payback, helping teams deploy faster while reducing operational effort and cloud overhead.

### 99.99% Uptime SLA available
Run multiple sites and customer instances with confidence. Built for reliability at portfolio scale.

### 0 DevOps overhead
Self-service deployments let developers ship faster as your portfolio grows, without growing your ops team.

Based on The Forrester Total Economic Impact™ of Upsun.

Business impact you can measure

## Scale your portfolio with Upsun

Speed to market

Clone your entire production environment with complete data for every branch. Stakeholders review changes in production-identical environments before launch, reducing risk and keeping deployments on time.

Learn more

Build without forced migrations

Run Python, Node.js, PHP, Ruby, Java, .NET, Rust, and Go on one platform. Upsun manages language versions, frameworks, and services so legacy systems and modern applications work side by side.

Learn more

Scale customer environments and extensions

Launch new sites, add regions, or build customer-specific extensions without duplicating infrastructure or DevOps effort. Growth doesn't have to increase operational load.

Learn more

Built-in security

Isolation, access controls, automated backups, and DDoS protection ensure every site meets the same security and availability standard, without custom configuration or ongoing maintenance.

Learn more

Teamwork made possible

Project managers, designers, and QA teams review changes in real time, update sites, and onboard contributors from one shared console.

Learn more

Visible and predictable pricing

Pay only for what you provision. Track infrastructure usage through built-in metrics and scale resources up or down with full visibility. No surprise bills as your portfolio grows.

Learn more

## A platform that works with your stack

Multi-cloud options

AWS, Azure, Google Cloud, IBM, or OVHCloud. Choose regions that meet performance and compliance needs without rewriting your application architecture.

Observability included

Integrated logs, metrics, alerts, and continuous profiling help teams detect issues early and keep performance consistent across all sites and tenants.

Developer-friendly workflows

Native GitHub, GitLab, and Bitbucket integration. Push to Git and Upsun handles builds, environments, and deployments automatically.

Edge caching

Integrate with Fastly or Cloudflare CDN to cache content closer to users and reduce latency without changing your architecture.

### Create an Upsun account
Sign up to Upsun and connect your GitHub, GitLab, or Bitbucket repository. Keep your existing workflows while Upsun prepares the platform.

### Initialize your project
Run upsun init to generate a production-ready configuration. Upsun analyzes your code and sets up environments that mirror production, ready for teams and clients to review.

### Push your code
With every push, Upsun provisions infrastructure, installs dependencies, and deploys your application.

Get started

Start managing multiple sites and applications in minutes with Upsun’s 15-day free trial. You get two production-ready environments to build, test, and deploy your projects.

### [Accelerate your eCommerce with a fully managed platform | Upsun](https://upsun.com/solutions/ecommerce/)

# _Launch stores and CMS-powered sites_ that convert

Upsun gives your team the infrastructure, scaling, and security to ship updates and drive revenue without the operational overhead. From handling traffic spikes to meeting PCI DSS and SOC 2 requirements, the platform keeps your store fast, available, and compliant.

Accelerate your eCommerce with a fully managed platform | Upsun

Launch your eCommerce store in minutes with a managed platform. Enjoy real data previews, effortless scaling, and enterprise-level security

## Trusted by global innovators

- Adobe
- AE Global Media
- Freitag
- Oris
- The Economist

### 219% ROI Potential
Teams achieve 219% ROI by moving away from infrastructure chores and shipping features at full speed.

### 0 DevOps overhead
Self-service deployment puts developers in control. Ship features faster without a dedicated ops team managing the platform.

### <1min Site preview
Copy your entire site and data instantly. Test and validate changes before they go live.

\*Based on The Forrester Total Economic Impact™ of Upsun.

Key metrics that deliver tangible business value

## Reliable hosting that grows with your business

Preview environment with real data

Create instant preview environments that match production. Review content, design, and code changes before they go live, so updates don't break pages, checkouts, or integrations.

Learn more

Reliable hosting for live sites and stores

Keep sites fast and available with up to 99.99% uptime and automated backups. Upsun keeps your CMS and eCommerce applications online even during updates and traffic surges.

Learn more

Autoscaling with cost controls

Define your scaling thresholds once and Upsun handles the rest. Your application stays fast during peak demand without runaway infrastructure costs.

Learn more

Security and compliance by default

PCI DSS Level 1, SOC 2 Type II, ISO 27001, HIPAA, and TX-RAMP certifications. Automated backups, DDoS protection, and WAF included, no additional configuration required.

Learn more

Real-time observability and control

Built-in monitoring keeps product pages, checkout flows, and content loading fast. Identify bottlenecks before they impact conversions.

Learn more

Flexible third-party integrations

Integrate commerce engines, CMS platforms, APIs, and third-party services into a single platform. Your storefront and content stack, run your way.

Learn more

## Your tools, your workflow

Works with your existing stack

WooCommerce, Magento, WordPress, Drupal, Contentful, or a custom solution. Upsun supports your stack without vendor lock-in or proprietary constraints.

Deploy where it matters

AWS, Azure, Google Cloud, IBM Cloud, or OVHCloud. Deploy to regions closest to your customers to improve performance and meet data residency requirements.

Works with your Git workflow

Connect GitHub, GitLab, or Bitbucket and keep your existing workflows. Push code, open pull requests, and deploy with no platform-specific steps required.

Built-in observability across environments

Track performance metrics, identify bottlenecks, and catch issues before customers do, across every environment.

### Create an Upsun account
Sign up in minutes and start hosting your e-commerce store or content site.

### Connect your repository
Connect your repository via GitHub, GitLab, or Bitbucket and run `upsun init` to create your initial configuration file.

### Push and deploy
Push your code, and Upsun handles deployment, scaling, and infrastructure automatically. Learn more about creating projects here.

Get started in minutes

Start building today with Upsun's 15-day free trial. Two production-ready environments included.

### [Ship faster without ops complexity | Upsun](https://upsun.com/solutions/devops-and-platform-engineering/)

# Built for teams that _ship fast_

Upsun standardizes how apps are built, tested, deployed, and scaled across clouds. Less time on infrastructure, more time shipping features.

Ship faster without ops complexity | Upsun

Ship faster with DevOps tools for platform engineering, automated preview environments, and GitOps workflows so teams focus on building better apps

## TRUSTED BY GLOBAL INNOVATORS

- Adobe
- The Economist
- Freitag
- Oris
- A+E

### 63% Faster deployments
Push your code and Upsun provisions infrastructure, spins up services, and deploys your application automatically.

### <1min Preview environments
Spin up production-identical clones with real data, configs, and files for every branch.

### 50% Reduction in DevOps overhead
Eliminate manual provisioning and repetitive infrastructure work. Upsun automates server management, environment creation, database backups, and scaling.

\*Based on The Forrester Total Economic Impact™ of Upsun.

Key metrics that deliver business value for development teams

## Built-in capabilities for platform and engineering teams

Self-service developer platform

Create self-service workflows that engineering teams actually use. Upsun supports Python, Node.js, PHP, Java, Go, Ruby, Rust, .NET, and virtually any framework from Django to LangChain applications.

Learn more

Preview environments with real data

Every Git branch gets a complete clone: code, database, services, and data. Test AI agents with real context, validate API endpoints against production data, and catch issues before they reach users.

Learn more

Infrastructure that scales with demand

Right-size every service independently. Allocate CPU, RAM, and disk per container. Scale up for traffic spikes and down during quiet periods based on actual usage.

Learn more

Security & compliance by default

SOC 2 Type 2, PCI DSS Level 1, ISO 27001, GDPR, and HIPAA compliance built in. DDoS protection, web application firewall, automated backups, encrypted data, and compliance audit logs.

Learn more

GitOps workflows

Define your entire stack in .upsun/config.yaml. Push a branch and Upsun provisions infrastructure, deploys your code, and creates a live URL.

Learn more

Zero-downtime deployments

Rolling updates create new containers while older versions continue to serve traffic. Deploy with confidence anytime, with no manual coordination or service interruptions.

Learn more

## Your stack, your way

Multi-language support

Python, Java, Node.js, PHP, Go, Ruby, Rust, .NET, and virtually any framework. Build with your preferred technology stack.

Git-native workflows

Native GitHub, GitLab, and Bitbucket integration. Code pushes trigger automated deployments and every branch gets its own environment.

Built-in observability

Monitor CPU, RAM, and disk usage per service in real time. Profile code performance with integrated Blackfire. Search unified logs across all services and environments.

Choose your infrastructure

AWS, Azure, IBM, GCP, or OVHCloud. Define infrastructure once and deploy across preferred regions without rebuilding for each provider.

### 1 Create an account
Create an Upsun Account and set up a project instantly.

### 2 Initialize your config
Connect your repository, then run `upsun init` to create your initial config file.

### 3 Deploy confidently
Push your code and Upsun provisions the environment, runs your services, and deploys your project.

Get started

### [Simplify compliance & governance with a managed cloud platform | Upsun](https://upsun.com/solutions/compliance-and-governance/)

# _Secure and compliant_ from your first deploy

Upsun provides built-in governance and automated compliance safeguards so your team can build and move fast without compliance overhead. Every environment inherits the same security controls, audit trails, and certifications from day one.

Simplify compliance & governance with a managed cloud platform | Upsun

Standardize environments, enforce policies by default, and gain auditable visibility across teams with a fully managed platform built for security, compliance, and governance.

### 99.99% Uptime SLA available
Your applications remain available while maintaining the highest security standards.

### 0 Manual runtime security patches
Automated compliance updates deploy critical security fixes across your infrastructure without disrupting your workflow.

### 100% Activity logging
Every deployment, configuration change, and access event is automatically logged and retained for 6+ months. Audit trails built into every environment.

_\*Based on verified compliance certifications and platform performance metrics_

## Run secure workloads and applications in the cloud

Deploy securely, stay compliant, every environment

Build applications that meet regulatory standards. Automated compliance safeguards and built-in security guardrails let your team focus on building features, not managing compliance.

Audit-ready infrastructure

Deploy on infrastructure already certified for major compliance frameworks. SOC 2, ISO 27001, HIPAA, GDPR, and PCI DSS controls are built in. No additional configuration needed.

Automated security controls

Security updates deploy automatically across all environments. Encryption, access controls, and vulnerability patches apply without manual intervention or workflow disruption.

Complete audit trails

Every deployment, configuration change, and access event is logged automatically. Generate compliance reports in minutes instead of gathering evidence for weeks.

Data residency controls

Deploy in specific geographic regions to meet data sovereignty requirements. Choose from AWS, Azure, Google Cloud, IBM, or OVHCloud locations.

Role-based access management

Control who can deploy, configure, or access production systems with granular permissions at organization, team, and project levels. Teams get access only to what they need.

## Your tools, your framework

Meet compliance standard

Certified for ISO 27001, SOC 2 Type 2, PCI DSS Level 1, HIPAA, and TX-RAMP, and validated for IBM Cloud Financial Services.

Choose your infrastructure

Deploy on AWS, Azure, IBM, GCP, or OVHCloud and select regions that meet your data residency requirements, with the same compliance guarantees across all of them.

Integrate external tools

Connect your existing security and monitoring tools. Upsun integrates with your external tools, APIs, and existing workflows including GitHub, GitLab, and Bitbucket.

Maintain documentation

Access up-to-date compliance documentation, security policies, and audit reports on the Upsun Trust Center your dashboard. Share directly with auditors and compliance teams when needed.

### Create an account
Instant project setup with no credit card required.

### Initialize your config
Connect your repository and use `upsun init` to create your initial config file.

### Deploy confidently
Push your code and Upsun stands up the environment, runs your services, builds your apps, and deploys your project.

Get started

## Industries

### [Deploy compliant scalable government infrastructure | Upsun](https://upsun.com/industry/government/)

# Build a digital public service on a _modern and secure infrastructure_

Deliver reliable, scalable digital services for citizens without managing complex infrastructure. Upsun provides a secure, compliant platform with automated scaling, built-in protections, and consistent performance so public-sector teams can focus on delivering trusted digital services.

Deploy compliant scalable government infrastructure | Upsun

Upsun’s infrastructure is compliance-ready and secure, providing government agencies with automatic scaling, audit-friendly controls, and 99.99% uptime available

## TRUSTED BY GOVERNMENT AGENCIES GLOBALLY

- RTE
- Ministère de la Culture
- British Museum
- Science Museum
- IGN
- VNF
- West Northamptonshire Council

### 100% Compliance-ready
Meet global regulatory requirements without the audit burden. Upsun provides PCI Level 1, GDPR, HIPAA, and SOC 2 Type 2 certified infrastructure.

### 99.99% Uptime Available
Stay operational during high-demand periods such as elections, emergencies, or citizen portal spikes with anti-DDoS protection, automated scaling, and Web Application Firewall.

### Seamless legacy integration
Modernize from legacy systems with minimal disruption. Upsun integrates with your existing tech stack while improving reliability and reducing operational overhead.

Infrastructure metrics that support public service delivery

## Why public agencies choose Upsun

Assured security

Launch your application without worrying about data security. Upsun meets standards for data security and compliance, with automated controls, built-in data minimization, and full support for access and erasure requests.

Explore docs

Deploy in your preferred region

Run on AWS, Azure, IBM, Google Cloud, or OVHcloud across multiple regions. Maintain data residency, reduce latency, and choose greener regions that align with environmental objectives.

Explore docs

Stay online when it matters most

Keep mission-critical services available with 99.99% contractually guaranteed uptime, automated backups, disaster recovery, and 24/7 expert support.

Focus on citizen services, not deployment pipelines

Ship updates quickly with fully automated pipelines that remove operational friction and prevent deployment outages.

Integrate with existing systems

Connect APIs, microservices, databases, CRMs, and custom tools. Upsun supports your existing architecture without requiring rework.

Learn more

Build together

Unify teams across development, design, QA, and operations with a shared management console and customizable access controls.

Learn more

## Your tools, your workflow, your way

Deploy responsibly across all regions

Choose your cloud provider and regions while we manage the infrastructure. Select low-carbon regions and receive special discounts, along with detailed emissions reports, for seamless EU compliance

Maintain your workflow, change what happens next

Continue using GitHub, GitLab, or Bitbucket. Upsun automates builds, deployments, and infrastructure management while your teams keep their current workflows.

Integrate with your tools, or upgrade to ours

Upsun supports integration with third-party services your operations require. Connect your applications to existing databases, APIs, webhooks, and microservices without infrastructure limitations.

Automate operations at scale

Use fully automated environment creation, updates, and scaling to reduce manual workload and maintain consistent operations across all public-sector applications.

Why start over? Upsun works with what you already use

### 1 Create an account
Create your Upsun account using GitHub, Google, or email to launch your public service solution.

### 2 Connect your code
Connect your existing GitHub, GitLab, or Bitbucket repository to Upsun; we will handle the infrastructure automatically.

### 3 Deploy your application
Configure and deploy your project through our web interface or CLI, without worrying about server management or deployment complexity.

Get started for free!

Try Upsun free for 15 days. Launch your first project in three easy steps, with one project and two environments included.

### [Seamless travel & hospitality deployment at scale | Upsun](https://upsun.com/industry/travel-and-hospitality/)

# Build a travel experience _without downtime_

Launch a high-performance travel and hospitality platform that stays reliable during peak seasons. Upsun removes infrastructure complexity across regions and clouds so your teams can stay focused on delivering seamless booking, reservation, and customer experiences.

Seamless travel & hospitality deployment at scale | Upsun

Deliver fast bookings and seamless guest experiences with autoscaling, PCI-compliant security and third-party integrations, all without vendor lock-in

## TRUSTED BY TRAVEL & HOSPITALITY ORGANIZATIONS WORLDWIDE

- Neilson holidays
- Zurich Tourism
- Visit Andorra
- Austral Lagon
- DreamYatch Catcher
- Marco Vasco
- Les Maisons du Voyage

### 99.99% Uptime availability
Never lose a booking due to downtime. Whether you are releasing updates or experiencing heavy seasonal traffic, your reservation systems stay online with 99.99% contractual uptime.

### Autoscaling for traffic spike
Scale resources up or down automatically across clouds and regions during surges such as holiday bookings, flash sales, and promotions while keeping costs predictable.

### Seamless third-party integrations
Connect booking engines, payment gateways, loyalty systems, and CRM tools without operational friction.

Infrastructure metrics that drive hospitality success

## Why travel agencies choose Upsun

Stay resilient during seasonal surges

Support major booking events, promotions, and global traffic peaks without interruptions. Upsun manages your infrastructure across multiple clouds and regions so your reservation pipeline stays reliable.

Explore docs

Build in language of your choice

Upsun supports all major programming languages, frameworks, and integrations automatically; no complex migration or setup is required.

Learn more

Protect sensitive data with enterprise-grade security

Safeguard passport details, payment information, and personal data with built-in PCI compliance, continuous patching, Web Application Firewalls, anti-DDoS protection, and automated backups.

Learn more

Deliver global availability around the clock

Travelers book across time zones at all hours. Upsun ensures uninterrupted service with 99.99% availability, automated disaster recovery, and 24/7 expert support.

Explore docs

Monitor booking performance in real time

Upsun integrated performance monitoring watches your infrastructure load, page load times, and payment flows in real-time to identify slowdowns before they cost you customers.

Explore docs

Deploy multiple times per day without downtime

Push updates, security patches, and new features without interrupting customer workflows. Ship features during business hours without worrying about service disruptions.

Explore docs

## Your tools, your workflow, your way

Deploy globally in minutes

Run on AWS, Azure, Google Cloud, IBM or OVHcloud to meet regional, regulatory, and latency requirements. Upsun replicates your setup across providers and locations with greener-region options for low-carbon datacenters.

Repository management, your way

Use your existing GitHub, GitLab, or Bitbucket workflow. Upsun handles environment creation, builds, and deployments automatically so your teams can focus on development.

Integrations and APIs that match your stack

Easily connect analytics, booking engines, payment systems, personalization tools, loyalty platforms, and third-party APIs. Upsun integrates with your existing architecture without rework.

Build with languages and tools your team already use

Use Python, Node.js, PHP, Java, Rust, Ruby, Go, or other languages. Integrate monitoring platforms, analytics tools, and payment processors without infrastructure constraints.

### 1 Create an account
Create your Upsun account using GitHub, Google, or email to launch your travel platform.

### 2 Connect your code
Connect your booking system to Upsun with your existing GitHub, GitLab, or Bitbucket workflow, we will handle the infrastructure automatically.

### 3 Deploy your application
Build, test, and launch your system through our web interface or CLI—without worrying about server management or deployment complexity.

Get Started for free

### [Secure banking platform for modern institutions | Upsun](https://upsun.com/industry/financial-services/)

# The _secure, compliant foundation_ for modern financial services

Push the boundaries of your innovation on an infrastructure built for security, compliance, and reliability at scale. Upsun handles the complexity of deployment and infrastructure management, so your team can focus on creating trusted customer experiences.

✓ **IBM Cloud for Financial Services validated**  ✓ **Available on the IBM Marketplace**

Secure banking platform for modern institutions | Upsun

Modernize legacy banking systems with zero-downtime migration, PSD3-ready compliance and enterprise-grade security. innovate without disrupting service

## TRUSTED BY LEADING FINANCIAL INSTITUTIONS

- First Foundation
- AI Rayan Bank
- 123 money
- Wider Plan
- Qombo

### 99.99% Uptime when it matters most
Keep services running with 99.99% contractual uptime, automated backups, and 24/7 expert support.

### 219% Return on investment
Move from maintenance to innovation. Independent analysis reveals a 219% return on investment (ROI) through faster releases and reduced costs.

### <1min Test environment creation
Git-driven workflow creates identical test environments in minutes.

\*Results from The Forrester Total Economic Impact™ study of Upsun.

Modernize systems while managing risk

## Core infrastructure capabilities for financial services

Run regulated workloads on IBM Cloud

Upsun is validated for IBM Cloud for Financial Services, meeting industry-specific security and compliance standards through 565+ automated controls. This validation reduces third-party risk reviews and accelerates regulatory approvals.

Learn more

Security and compliance built into every layer.

Multiple security layers, including encryption, security patching, anti-DDoS protection, and Web Application Firewalls. Meet regulatory requirements with PCI Level 1, GDPR, HIPAA, ISO27001, and SOC 2 Type 2 certified infrastructure.

Learn more

Test in production-perfect environments

Spin up exact replica of your product environment with real data and configurations. Validate changes against realistic scenarios before they reach customers.

See more

Stay online when it matters most

Banking applications can't afford downtime. Upsun automated backups, 99.99% contractually guaranteed uptime, and 24/7 expert support keep your services running during system updates or unexpected demand.

Explore docs

Handle traffic spikes automatically

Scale instantly during high-traffic periods without manual intervention. Upsun automated scaling adjusts resources to match demand.

Explore docs

Multi-language support

Build in the technology stack of your choice: Python, Java, Node.js, PHP, Go, Ruby, Rust, and .NET, and virtually any framework, so your development team can work with familiar frameworks and tools.

Explore docs

## Use your tools, keep your workflow

Keep your Git workflow

Native integrations with GitHub, GitLab, and Bitbucket mean your developers continue working exactly as they do now.

Manage multi-cloud from one place

Deploy projects on AWS, Azure, OVHcloud, GCP, and IBM Cloud for Financial Services while maintaining consistent workflows and governance across environments.

Integrate with your existing tools and workflows

Already using APIs, core banking systems, or custom integrations? Upsun supports your existing APIs, event-driven services, all unified in a single platform.

Collaboration across teams

Bring together developers, security teams, compliance officers, QA, and operations in one platform with Upsun's unified management console.

### 1 Create an account
Create an Upsun account and set up an instant project.

### 2 Connect your code
Connect your code repository to Upsun with your existing Git workflow.

### 3 Deploy confidently
Push live update knowing they've been thoroughly tested in production-identical environments.

3 simple steps to get started

Start secure, scale with confidence

### [Boost retail sales with nonstop cloud scaling | Upsun](https://upsun.com/industry/retail/)

# Cloud infrastructure built for retail at every scale

Upsun provides reliable infrastructure that helps retail businesses deliver fast, secure shopping experiences year-round. With automated scaling and built-in security, we handle the technical details so you can focus on serving customers and growing sales.

Boost retail sales with nonstop cloud scaling | Upsun

Unequalled reliability - keep your store open and customers buying through any flash sale

## Trusted by global innovators

- Adobe
- AE Global Media
- Freitag
- Oris
- The Economist

### 99.99% Contractual uptime
Keep your operation running during flash sales and holiday peaks with 99.99% guaranteed uptime. Deploy updates without taking your store offline.

### <1min Campaign preview
Full-stack previews for every promotion, test campaigns, seasonal storefronts, and product launches with complete data before they go live.

### 0 Surprise costs
Scale across multiple clouds and regions, even during traffic spikes, while controlling infrastructure costs. Full visibility into usage means no unexpected bills.

\*Based on The Forrester Total Economic Impact™ of Upsun

Keep your store running when it matters most

## Why retail businesses choose Upsun

Handle traffic spikes without losing sales

Peak shopping periods shouldn't crash your site. Upsun automatically scales your infrastructure to handle traffic surges, keeping your operation process running smoothly.

 Learn more

Keep customer data secure and compliant

Protect customer data with an infrastructure that meets PCI DSS Level 1, SOC 2 Type 2, ISO27001, and GDPR requirements. 

Learn more

Launch campaigns and product drops faster

Deploy new product pages, promotional campaigns, and seasonal storefronts. Upsun creates preview environments for every branch, letting your team test and launch with confidence. 

Explore docs

Predictable costs in multi-cloud environments

Eliminate surprise bills with transparent pricing and visibility. Optimize spending by automatically scaling resources up during high-traffic events and down during off-peak periods, paying only for resources you use.   
Learn more

Avoid vendor lock-in while reaching customers globally

Run your application on major cloud providers: AWS, Azure, Google Cloud, IBM or OVHcloud. Upsun provides a consistent, portable configuration model that lets you deploy the same application across different cloud environments.

Learn more

Reduce dependency on specialized expertise

Let your developers focus on building features, not managing infrastructure. Upsun handles deployments automatically so teams can ship faster without needing cloud platform experts or overtaxed DevOps support.

Learn more

## Your tools, your workflow, your way

Work with your existing tools and workflows

Work with your existing workflows in GitHub, GitLab, or Bitbucket. Upsun integrates with the tools your developers already know.

Integrate seamlessly with third-party tools

Integrate your tech stack: inventory, automation, payments, and more. Upsun fully supports third-party and custom integration.

Multi-language support

Upsun supports all major programming languages, including Python, Java, Node.js, PHP, Go, Ruby, and .NET, and virtually any framework.

Team collaboration

Bring developers, QA, and operations teams together on a unified platform. Grant access through role-based permissions at both the organization and project levels.

Meet your customers where they are with your existing tools.

### Create an Upsun account
Create an Upsun Account to launch your retail platform.

### Initialize your config
Connect your code repository to Upsun with your existing Git workflow.

### Create your project
Create your project and launch your retail platform through our web console or CLI.

Get started in 3 simple steps

Getting started with Upsun for your retail store is simple. You can start for free with a 15-day trial and a single project (2 environments).

### [Build your SaaS product, not your infrastructure | Upsun](https://upsun.com/industry/saas/)

# _Build your SaaS product_ without infrastructure bottlenecks

Upsun provides secure, automated infrastructure that helps SaaS teams ship features faster and scale globally without expanding DevOps resources. With production-perfect preview environments, real-time observability, and multi-cloud flexibility, your team can focus entirely on product innovation.

Build your SaaS product, not your infrastructure | Upsun

Eliminate infrastructure complexity with Upsun’s instant full-stack environment clones, reduce cloud costs, and speed up deployments for your SaaS product

### 219% ROI potential
Ship fast while controlling costs. Research proves 63% faster deployments and 89% lower cloud costs compared to traditional infrastructure management.

### 0 DevOps overhead
Developers push code directly while Upsun automates infrastructure, scaling, and security.

### <1min Full stack cloning and previews
Clone complete environments, including code, configs, and data. Validate changes confidently before release.

_Based on The Forrester Total Economic Impact™ of Upsun._

Scale your SaaS business with confidence

## Why SaaS teams choose Upsun

Deliver features faster with real-time validation

Upsun clones your entire application, including databases and configurations in minutes. Test with real data, validate API changes, and preview new features in production-perfect environments.

Explore docs

Predictable scaling for every stage of growth

Handle customer spikes confidently with automated resource management and transparent usage insights. Upsun provides full visibility into performance and spend so teams can scale intelligently without surprise bills.

See pricing

Enterprise-grade security from day 1

Protect user data with strong security controls, including encryption, patching, DDoS protection, and a Web Application Firewall. Meet compliance requirements with PCI DSS Level 1, SOC 2 Type II, ISO 27001, HIPAA, and GDPR aligned infrastructure.

Learn more

Flexible, multicloud deployment without lock-in

Deploy and scale across AWS, Azure, Google Cloud, IBM, or OVHcloud. Replicate your SaaS application across regions to meet sovereignty requirements or increase resilience.

Learn more

Reliability for global SaaS platforms

Upsun supports 99.99% contractual uptime with automated backups and 24/7 expert support. Keep customer-facing applications stable during updates, migrations, and peak traffic events.

Learn more

Monitor performance in real-time

Upsun provides integrated metrics, logs, and profiling so your team can monitor application health, system load, and database performance in real time. Identify issues early and keep your SaaS platform responsive during peak usage.

Learn more

## Your tools, your workflow

Use the stack your team loves

Support for Python, Java, Node.js, PHP, Go, Ruby, Rust, and .NET, along with virtually any framework.

Git-based deployments

Push to GitHub, GitLab, or Bitbucket, and Upsun automates the rest. Every branch receives its own isolated environment, so developers work in parallel without conflicts.

Deploy globally

Run your SaaS application on AWS, Azure, Google Cloud, IBM, or OVHcloud to meet regulatory and regional requirements.

Integrate with the systems your platform depends on

Connect seamlessly with payment processors, analytics tools, CRMs, marketing automation systems, and custom microservices.

Keep your favorite tools and workflows. We handle infrastructure while seamlessly integrating with your development stack.

### 1 Create an account
Create an Upsun account and instant project setup.

### 2 Initialize your config
Connect your code repository to Upsun with your existing Git workflow.

### 3 Create Your Project
You can start creating your project on Upsun through the web console or CLI.

And now your developers are empowered with full autonomy. They can build and deploy using their preferred tools, whether web interface or CLI. No more dependencies on other teams. 

**Upsun is all about focusing on innovation while you scale, not infrastructure!**

Get started for free!

Begin your SaaS success story with Upsun in three simple steps:

### [Cloud Application Platform for Healthcare & Life Sciences | Upsun](https://upsun.com/industry/healthcare/)

# Secure infrastructure for _healthcare applications_

Deliver reliable, HIPAA-compliant digital health experiences without the infrastructure burden. Upsun provides a hardened platform for healthcare SaaS and MedTech teams to build, scale, and modernize safely.

Cloud Application Platform for Healthcare & Life Sciences | Upsun

Secure, HIPAA-compliant cloud hosting for healthcare SaaS, MedTech, and digital health. Deploy on AWS, Azure, GCP, or IBM Cloud with built-in governance and automated scaling

### <1min Production-like preview environments
Spin up isolated environments for every branch to validate HIPAA controls and interoperability changes before they hit production.

### 0 Manual infrastructure work
Upsun manages hardened runtimes and security patching, allowing your team to focus on patient outcomes and clinical logic

### 219% Potential ROI
Independent research indicates organizations achieve significant returns by automating deployments and reducing operational risk. (Source: Forrester TEI)

Outcomes for healthcare delivery teams

## Why healthcare organizations choose Upsun

Legacy application modernization

Safely migrate and modernize patient portals or clinical apps. Use isolated previews to test legacy integrations without risking production stability.

Git-driven audit trails

Every infrastructure change is versioned in code. Maintain an immutable history of "who, what, and when" for every deployment—exactly what auditors and compliance officers expect.

Consistent security posture

Standardize your security controls across AWS, Azure, GCP, or IBM Cloud. Upsun ensures your isolation models and RBAC remain consistent, regardless of the provider.

Hardened runtime by default

Read-only file systems and platform-managed container updates prevent unauthorized runtime modifications and reduce your attack surface.

Clear shared responsibility

We handle platform-layer encryption and physical security; you control the application logic. We support your compliance journey with a Business Associate Agreement (BAA).

Scalable infrastructure for patient demand

Handle traffic spikes during open enrollment or research surges with automated scaling and 99.99% uptime options for mission-critical health services.

## HIPAA-aligned operations

Environment Isolation

Complete separation of production and non-production workloads

Encryption

Platform-managed encryption for data in transit and at rest

Access Governance

Role-based access control (RBAC) enforced consistently across the entire lifecycle

Data Integrity

Automated backups and point-in-time recovery for business continuity

Operational guardrails for regulated data - Healthcare compliance fails when security is manual. Upsun embeds governance into the engineering workflow

### 1 Consult with our team
Discuss your regulated workload requirements and BAA needs with our healthcare infrastructure experts

### 2 Initialize your stack
Connect your repository. Upsun automatically bootstraps your configuration and creates isolated environments for development

### 3 Deploy with certainty
Push code to a hardened pipeline that builds, tests, and deploys your healthcare applications with predictable results every time

Get started in 3 simple steps

### [Reliable app platform for manufacturers | Upsun](https://upsun.com/industry/manufacturing/)

# Launch _reliable apps_ that scale with production demands

Run your supply chain systems, IoT platforms, and customer portals on a secure, scalable application platform that keeps your operations moving smoothly. Upsun handles the complexity of cloud deployment so you can focus on production efficiency and customer delivery.

Reliable app platform for manufacturers | Upsun

Run always-on manufacturing, IoT, and supply chain apps on a secure, scalable platform with 99.99% uptime, instant test environments, and built-in compliance

## Trusted by global innovators

- Alpha-Omega
- ASSA ABLOY
- AXEREAL
- KONECRANES
- Leica
- Santen

### 99.99% Uptime when it matters most
Keep your production systems online during maintenance windows and peak demand periods with contractually guaranteed uptime and zero-downtime deployments.

### <1min Test environment creation
Spin up exact copies of production environments with real-world data in seconds to validate changes before they reach your factory floor systems, eliminating deployment risks.

### ISO 27001 Security compliance built-in
Protect supplier data, production schedules, and customer information with certified security controls that meet manufacturing industry standards.

_\*Results from The Forrester Total Economic Impact™ study of Upsun._

Keep production running while you evolve your systems

## Why manufacturing organizations choose Upsun

Run your systems on a reliable infrastructure

Manufacturing schedules don't allow for system outages. Upsun keeps your systems running during deployments, updates, and traffic spikes with automated scaling that adjusts resources based on demand.

Explore docs

Protect sensitive data

Upsun provides multiple security layers, including encryption, security patching, anti-DDoS protection, and Web Application Firewalls. Meet regulatory requirements with PCI Level 1, GDPR, HIPAA, ISO27001, and SOC 2 Type 2 certified infrastructure.

Explore docs

Deploy without vendor lock-in

With multicloud, you can deploy on AWS, Azure, Google Cloud, IBM, or OVHcloud. Define your infrastructure once, and deploy on your preferred regions without rebuilding for each provider.

Learn more

Always-on systems for global operations

Upsun delivers 99.99% contractual uptime with automated backups, disaster recovery, and 24/7 expert support. Keep your order management, supplier portals, and customer-facing applications accessible.

Preview environment with complete data

Spin up complete production copies. Test your updates with real data, validate API changes, or review new features in your customer portal before they go live.

Explore docs

Monitor systems in real time

Upsun's integrated performance monitoring watches your infrastructure load, application response times, and database performance in real time. Identify bottlenecks, slow API calls, or catch database issues. 

Explore docs

## Your tools, your workflow, your way

Multi-language support

Build in the technology stack of your choice, including Python, Java, Node.js, PHP, Go, Ruby, Rust, and .NET, and virtually any framework.

Git-based deployment

Go from Git push to live. Upsun integrates natively with GitHub, GitLab, and Bitbucket, turning code pushes into automated deployments.

Third-party integrations

Upsun supports integration with third-party services your operations require. Connect your applications to existing databases, APIs, webhooks, and microservices without infrastructure limitations.

Team collaboration

Bring developers, and stakeholders together on one platform. Upsun's unified management console brings everyone together on a single platform, with customizable access controls.

Why start over? Upsun works with what you already use

### 1 Create an account
Create an Upsun account and instant project setup with no credit card required.

### 2 Initialize your config
Connect your repository and use upsun init to create your initial config file

### 3 Create your project
Push your code, and Upsun will stand up the environment, run your services, build your apps, and deploy your project.

Get started in 3 simple steps

Start secure, scale with confidence.

### [Higher education digital platform | Upsun](https://upsun.com/industry/higher-education/)

# Student portals, apps, dashboards always up

Higher education teams face unique challenges maintaining reliable, secure digital experiences for students and faculty. Upsun simplifies development and deployment by removing infrastructure complexity, automating performance and compliance, and delivering 99.99% uptime so even small IT teams can focus on innovation.

Higher education digital platform | Upsun

Upsun simplifies development and deployment for higher ed apps by automating infrastructure, security, compliance, and cost management for small IT teams.

## Trusted by leading higher-ed teams

- Kingston University London
- University of Oxford
- Georgia Tech
- Københavns Universitet
- University of Missouri
- University of Wisconsin–Madison
- University of London
- Omnes Education
- University of British Columbia
- University of Tennessee Chattanooga
- University of Lahore
- University of Surrey

### 0 unplanned downtime
Student portals and course dashboards stay live with a 99.99% uptime, even during peak enrollment and finals week

### <2 minutes cloning
Create byte-to-byte environment copies with configuration, code, services, databases, and storage included

### 0 Idle spend on sleeping environments
Non-production environments automatically sleep when not in use, preventing unnecessary spend on idle workloads.

\*_Based on Kingston University performance data and average customer savings after migration_

Outcomes that matter for students and staff

## Why higher-ed teams choose Upsun

Automated operations

Keep your continuous integration/continuous delivery (CI/CD) pipeline moving forward without interruption thanks to full automation. Upsun handles infrastructure details so developers deliver features directly to students.

Fast prototyping and environment cloning

Clone from production to staging in minutes with byte-accurate copies of configuration, services, and data. Preview exactly how changes behave under real conditions.

Security out of the box

Keep intellectual property and sensitive student and professor data safe. Automated backups and recovery, firewalls, and anti-DDoS protection mitigate vulnerabilities.

High availability

Students need reliable applications and tools. Upsun offers 99.99% availability and 24/7 support from our expert team.

Performance management

Get real-time observability across production and cloned environments to ensure every deployment succeeds without impacting performance.

Scalability without overprovisioning

Scale resources automatically or on demand during traffic spikes with predictable costs and no manual intervention.

## Your tools, your workflow

Integrations and APIs

Build and expose APIs for web, mobile apps, and student portals. Bring your own integration add-ons for databases, logging, monitoring, and caching to reduce work.

Standard tools & Git-based workflow

Keep using GitHub, GitLab, or Bitbucket with your existing CI and build pipelines while Upsun automates everything behind the scenes.

No vendor lock-in

Upsun uses open standards and version-controlled YAML files for configuration. There are no proprietary SDKs or services. You can extend your applications without rewriting them.

Multi-cloud flexibility

Higher-ed institutions often manage multiple regions, research programs, and compliance requirements. Upsun supports AWS, Azure, GCP, IBM, and OVHcloud so you can deploy globally and meet regional regulations.

### 1 Create account
Start free with a single project trial. Build and launch your first higher-ed app with no commitment required.

### 2 Initialize Git
Connect your code repository to Upsun. Continue using your existing GitHub, GitLab, or Bitbucket workflow.

### 3 Deploy project
Code and deploy your way. Build, test, and run apps through our web UI or CLI—without dealing with infrastructure details.

Get started with Upsun

## Product

### [Product | Upsun](https://upsun.com/product/)

Staging bottlenecks killing velocity? Upsun, the cloud application platform, clones complete production environments — code, configs, dependencies, and real data — in minutes. No more "works on my machine."

Ship faster with production-perfect environment clones

Product | Upsun

Find out more about the Upsun PaaS features designed to give development teams control and peace of mind while reducing the time it takes to build and deploy applications.

## Clone full production in under a minute

Staging slowing you down? Fork complete production stacks–with terabyte databases–**near-instantly.** Ship features faster, test with real data, sleep better.

### Git-powered pipeline

-   Deploy automatically on every push
-   Git hosting services native integrations. Plug your GitHub/GitLab/Bitbucket repo instantly
-   Preview environments auto-deploy with each PR. Test, review, and ship faster with real production data. Get more information
-   Customize preview URLs your way
-   SSL just works (auto-configured, ready to go)

### Production-perfect clones that just work

-   Fork 1TB environments in 30s (vs. 24hr industry standard)
-   Ship confidently with byte-perfect data consistent clone
-   Auto-configured SSL on deployments
-   Take instant snapshots of your production, staging, and development environments for quick recovery (no waiting). Get more information

Databases that scale with you

Launch PostgreSQL, MariaDB or other supported services instantly - no config needed

Keep data consistent across every environment

Clone 1TB in 30s

Fully secured scalable environments

## The specs

"[Our digital agency] can easily spin up a new branch of the site in just minutes, while cloning the entire content of the production server, merged with the new code. _This is an incredible time-saver_, and also means fewer errors." —Verified user in Events Services, G2 Review

## More code, less ops

Need to deploy fast? Jump into any stack with zero config drama. **Your code, your rules** - we handle the rest.

### Deploy at your speed

-   Clone environment in seconds
-   Fast feedback and easy collaboration
-   Reliability assurance through performance monitoring 
-   Automate security and compliance

Your stack, your rulesLatest & LTS versions supported

### Every major framework you need

Laravel, Symfony, Django, Flask, Express, Next.js - with managed databases and caching built in. Switch anytime, no questions asked.

See all supported stacks

"Going from our old setup to Upsun was like upgrading from a bicycle to a teleporter. _Everything just works._" —Lead Developer, BoardSpot

## Security baked-in, not bolted on

**Deploy with confidence.** Your apps get enterprise-grade security across multiple regions. Deploy in seconds, no paperwork.

"…we spend zero time on patches and compliance. _Everything just works._" —Lukas Kahwe Smith, CTO at Witty Works

## Control your resources

Need to cut costs? **Scale what you need, when you need it.** Turn off dev environments at night and fire them up at dawn (before your coffee's ready).

### Resource management that actually works

-   Intelligent autoscaling based on application metrics
-   Real-time resource metrics that don't lie
-   Container-level CPU/RAM control - granular, not guesswork
-   12x better CPU efficiency vs EC2 (measured in real workloads)
-   Pay for what you use, down to the second
-   Green region optimization saves 3% (and the planet)
-   Give every dev their own sandbox - fork production in seconds
-   Release when you want - choose automatic or manual release for more control

"With Upsun's monitoring, we can monitor every component of the Witty application, detect any errors and anomalies, then _quickly identify and resolve issues before they become major blockers_" —Lukas Kahwe Smith, CTO at Witty Works

Upsun is perfect for

- Teams tired of staging environment drama
- Multi-app, multi-database workloads
- Complex runtime requirements
- Developers who actually want to code

Ready to ship better?

## Compete

### [Better Render alternative for multi‑cloud scaling | Upsun](https://upsun.com/render-alternative/)

# Everything you need to deploy your application, _anywhere, anytime_

While you’re dealing with infrastructure limitations, successful teams ship faster with enterprise-grade infrastructure. Struggle or scale; the choice is yours.

## 99.99% Uptime Available

Keep your applications online even through traffic spikes with 99.99% uptime available, automated disaster recovery, and a dedicated 24/7 support team.

## Your data, your rules

Why settle for one cloud infrastructure? Deploy on your preferred cloud provider: AWS, Azure, Google Cloud, IBM, or OVHcloud – without juggling multiple subscriptions.

## Teamwork makes the dream work

Onboard team members, freelancers, and contractors in minutes with minimal learning curve and role-based access controls.

## Built for enterprise

Cloud choice, scalability, service, and sustainability features make it the right choice for enterprise deployments

Better Render alternative for multi‑cloud scaling | Upsun

Scale across AWS, Azure, GCP and more. Unlimited timeouts, built‑in APM, transparent pricing and green hosting make Upsun the clear Render alternative

## Discover why Upsun is a better Render alternative

"Our website traffic increases by about 20 to 30 percent in November and December. Thanks to Platform.sh, our website's stability was ensured at all times, quickly, and without any issues." —Sarah Mauerhofer, Product Owner, FREITAG

## Looking to Migrate to Upsun?

Migration is easy!

Start with our free tier—spend 15 days exploring Upsun for free. You'll see why over 16,000 developers choose the transparency, flexibility, and autonomy we provide.

Experience the Upsun advantage

**Get a 3% discount** when you deploy and manage applications at data centers in our incentive-eligible greener regions

**Create byte-for-byte clones** of your production environment in **under 2 minutes**, making updates simple, safe, and straightforward

**One centralized PaaS handles ops**, storage, security, previews, and more. Sign **1 contract**, pay **1 bill**, and let your developers focus on **1 thing**: coding

**Zero effort, 0 commitment required upfront**. Get started with our **$0 free** tier and experience the difference for yourself

| Feature | Upsun | Competitor | Details |
| --- | --- | --- | --- |
| Preview environments | Byte-for-byte clones with real data | Manual setup required | Upsun spins up a production-like environment in minutes from a Git pull, with complete byte-for-byte replicas and databases. Render supports previews, but setup requires YAML config, and manual seeding with no data included. |
| Request Timeouts | Unlimited | Up to 100 minutes (requires configuration) | Upsun has no request timeout, even for large files. Render supports 100-minute timeouts, requiring manual configuration. |
| Multi-cloud deployment | AWS, Azure, OVH, IBM, GCP in 15+ regions | AWS, GCP | Upsun offers multiple IaaS providers, enabling you to meet geographical and environmental requirements. Render is limited to AWS (EU) or GCP (US), each app permanently locked to a single region with no migration path. |
| Managed data services | Fully supported | Limited | Upsun solves the database complexity with fully managed data services. Render supports two managed services and Key Value instances; Docker container setup is required for other databases. |
| Pricing transparency | Predictable & transparent pricing models | Complex multi-component pricing | Upsun offers flexibility with two pricing options: pay only for the resources you provision, or choose a fixed monthly tier plan. Render uses a complex, multi-component pricing model with no spending limits for users. |
| Performance monitoring | Built-in observability suite | Basic infrastructure metrics | Upsun provides real-time Application Performance Monitoring (APM) that identifies issues and recommends code optimizations to improve performance. Render requires third-party integration for advanced monitoring. |
| Security and Compliance | SOC 2 Type 2, GDPR, IS0 27001, HIPAA certified | SOC 2 Type 2 + ISO 27001 certified | Enterprise-grade compliance with Upsun's PCI DSS Level 1, GDPR, HIPAA, IS0 27001, and SOC 2 Type 2 - plus automated compliance monitoring. Render holds SOC 2 Type 2 and ISO 27001 certification, with HIPAA available as an additional paid service. |
| Container management | Git workflow | Git workflow | Upsun eliminates infrastructure complexity through native Git integration and automatic branch-to-environment mapping. Render offers a hybrid Git and container approach, but it requires additional configuration and manual CI/CD integration. |
| Auto-scaling | Built-in horizontal + vertical scaling | CPU/memory-based scaling (professional plan only) | Upsun includes enterprise-grade autoscaling on all plans, supporting custom metrics and both vertical and horizontal scaling. Render requires a higher tier to access basic autoscaling, which is limited to CPU and memory metrics only. |
| DDoS protection | Internal DDoS protection | DDoS protection available | Upsun includes DDoS with an integrated Web Application Firewall. Render offers Cloudflare-powered DDoS protection. |
| Persistent storage | Internal storage included | Paid feature, no horizontal scaling | Upsun includes persistent storage for all customers; select and configure storage directly on our platform. Render persistent storage is a paid feature. Applications with persistent disks cannot scale horizontally |
| Green Incentives | Discount for green regions hosting | Not available | Upsun tracks carbon intensity 12x across all regions and offers a 3% discount when you choose greener, more sustainable data centers. Render does not offer sustainability initiatives or green energy options |
| Reverse proxy cache | Built-in | Limited caching | Upsun gives users full restart control, eliminating unexpected interruptions. With rare exceptions, only for critical security updates. Render only caches static sites, not web services. Applications can't control caching, forcing all requests to hit the server. |
| Cron Jobs | Built-in | Separate service with usage-based fees | Upsun includes cron jobs within each application with no additional fees—no separate services or per-job fees. Render charges per cron job as separate services with no access to application files. |
| Language support | Native support for major programming languages | Limited to 6 programming languages | Upsun supports the latest versions of 10 programming languages and an array of frameworks. Render supports 6 languages. Other languages (including PHP and Java) require Docker deployment. |

All the enterprise PaaS features you need—all without complexity. Contact [sales](https://upsun.com/contact-us/) to schedule a demo.

### [Pantheon alternative with multicloud support | Upsun](https://upsun.com/pantheon-alternative/)

# Your innovation shouldn't be _limited by infrastructure_.

Looking for a Pantheon alternative? Upsun is a powerhouse cloud application platform with flexible Git workflows, your preferred cloud providers, all at transparent pricing.

## Multicloud

Upsun places infrastructure choice in your hands. Select your cloud provider and region with lower carbon intensity to earn discounts and support your sustainability goals.

## Instant environment in minutes

Clone your production environment in minutes real data, configs, and code included. Each environment has built-in CI to auto-build your site on the fly.

## No page limit, no surprise charge

Upsun offers pricing that fits your precise business needs. Whether you serve 250K or 500K pageviews, your bill stays the same. No surprise charges, no overages, and no throttling, just clarity and control.

## Multi-language support

Whatever languages, runtimes, stacks, or CMS you use, Upsun has you covered. With support for 10 languages, frameworks, and fully managed services like databases, search, and caching.

Pantheon alternative with multicloud support | Upsun

Upsun is a Pantheon alternative with unlimited environment cloning, multicloud support, transparent pricing, and PCI DSS, GDPR, and HIPAA compliance

## Why developers choose Upsun

"Dipli’s team no longer worry about cost fluctuations and overages. This gives them the freedom to focus on more impactful work: creative problem-solving and innovation." —Tanguy Pennel, Co-founder & COO, Dipli

## Ready to experience the difference?

Migrating to Upsun is a seamless process!

We understand that switching platforms is a big step, start with our 15-day free trial and explore Upsun at no cost. You can also schedule a demo to speak with an expert.

Experience the Upsun advantage

**Get a 3% discount** when you deploy and manage applications at data centers in our incentive-eligible greener regions.

**Create byte-for-byte clones** of your production environment in **under 2 minutes,** making updates simple, safe, and straightforward.

**One centralized PaaS** handles ops, storage, security, previews, and more. Sign **1 contract,** pay **1 bill,** and let your developers focus on **1 thing:** coding.

**Zero effort, 0 commitment required upfront.** Get started with our **$0 free tier** and experience the difference for yourself.

| Feature | Upsun | Competitor | Details |
| --- | --- | --- | --- |
| Environment cloning | Unlimited byte-for-byte clones with data | Manual content cloning; limited to 10 environments | Upsun creates complete environment clones in under 2 minutes, including all data and configurations, with no environment limits. Pantheon limits cloning to content only, done manually, with just 10 environments per site. |
| Cloud provider | AWS, Azure, OVH, IBM, GCP | Google Cloud Platform | Upsun offers flexibility with multiple IaaS providers and regions, enabling geographic, regulatory, and environmental advantages. Pantheon runs exclusively on Google Cloud Platform (GCP) with no multicloud options. |
| Language support | Native support for 10 programming languages | WordPress, Drupal + Next.js, Gatsby | Upsun supports the latest versions of 10 programming languages and an array of frameworks. Pantheon is limited to PHP-based CMS (WordPress/Drupal) for the backend, with Next.js, Gatsby only. |
| WordPress | Composer-based, Bedrock, Vanilla | Composer-managed upstream | Upsun fully supports WordPress, including Vanilla, Bedrock, and Composer-based setups, powered by PHP 8.3 and WP-CLI. In addition to traditional WordPress plugins, Pantheon supports Composer-managed WordPress only. |
| Traffic limits | Unlimited page views | Capped by plan tier | Upsun uses usage-based pricing for resources with no restrictions on page views or data transfer. Pantheon charges based on traffic volume and automatically increases your bill when you exceed monthly limits. |
| Pricing model | Predictable & transparent pricing models | Tier-based pricing + website visit upgrades | Upsun offers flexibility with two pricing options: pay only for the resources you provision, or choose a fixed monthly tier plan. Pantheon offers tiered plans (monthly/annual) with traffic-based automatic upgrades. |
| Compliance | SOC 2 Type 2, PCI DSS Level 1, ISO 27001, GDPR, HIPAA | SOC2 Type 2, GDPR, and FERPA | Upsun is PCI DSS Level 1, GDPR, HIPAA, IS0 27001, and SOC 2 Type 2 compliant, with automated compliance monitoring and DDoS protection. Pantheon provides compliance with SOC 2 Type 2, GDPR, and FERPA support. |
| Managed data services | Fully supported | Limited | Upsun solves the database complexity with fully managed data services. Pantheon offers limited data services support for MariaDB/MySQL, Redis, and Apache Solr only, without modern databases. |
| Sustainability | Carbon tracking + green hosting | x | Upsun tracks carbon intensity 12x across all regions and offers a 3% discount when you choose greener, more sustainable data centers. Pantheon does not have any published independent green hosting incentives. |
| Application Performance Monitoring | Built-in observability suite | Limited | Upsun delivers function-level insights, combining observability and telemetry to enable data-driven decision-making. Pantheon uses New Relic APM for users on the higher tier, and this requires an external service and management. |
| Preview Environments | Automatic Git branch | Manual setup required | On Upsun, every git branch has its own environment. Every pull request auto-creates an environment with inherited data and services. Pantheon multidev environments requires manual creation through the dashboard or CLI, with a limit of 10 environments per site. |
| Speed to market | Instant | Relatively fast; manual setup required | Upsun users can ship features in minutes through Git push workflows once source integration is configured. Pantheon is relatively fast with managed containers but requires environment setup before preview launch. |

Want to learn more? [Upsun documentation](https://docs.upsun.com/) has everything you need to get started.

### [Managed hosting alternative that scales | Upsun](https://upsun.com/managed-hosting-alternative/)

# Managed hosting gets you started, Upsun goes _beyond basic hosting limits_

Upsun delivers everything managed hosting promises and more. Focus on innovation while we handle infrastructure in ways that traditional managed hosting providers can’t.

## Instant environment provisioning

Spin up instant copies of your production environment with complete data for every development branch. Team members can access these live preview environments, just like production.

## Auto-scaling

Enjoy resources that scale to match demand. Your applications automatically handle any amount of traffic without slowdowns or crashes. Your apps stay operational during peak times without slowdowns.

## Built-in security & compliance

Meet security and compliance needs with anti-DDoS protection and an integrated Web Application Firewall (WAF) from day one. All compliance certifications are included, so you meet industry standards without extra work.

## No vendor lock-in

Keep complete control over your code and infrastructure with zero platform dependencies. A simple configuration file manages deployment while your application can run anywhere.

Managed hosting alternative that scales | Upsun

Upsun is the managed hosting alternative that automates multicloud infrastructure, instant environments and compliance with transparent pay-as-you-use pricing

## With Upsun, you can depend on

"One of the reasons we really liked Upsun was that it gave us this wealth of power, performance, and flexibility without having to manage our own cloud-hosting infrastructure." —John Boyer, Programmer/Analyst-Principal, Digital Service, University of Missouri

## Ready to leave managed hosting limitations behind?

Give Upsun a test drive - completely free!

Choosing new hosting is a big move. Start with our 15-day free trial to explore everything Upsun offers. See why 16,000+ developers choose our transparent and flexible platform over complicated alternatives.

Experience the Upsun advantage

**Get a 3% discount** when you deploy and manage applications at data centers in our incentive-eligible greener regions.

**Create byte-for-byte clones** of your production environment in **under 2 minutes,** making updates simple, safe, and straightforward.

**One centralized PaaS** handles ops, storage, security, previews, and more. Sign **1 contract,** pay **1 bill,** and let your developers focus on **1 thing:** coding.

**Zero effort, 0 commitment required upfront.** Get started with our **$0 free tier** and experience the difference for yourself.

| Feature | Upsun | Competitor | Details |
| --- | --- | --- | --- |
| New project creation | Minutes and fully automated | Hours/days | Create and launch new projects in minutes with Upsun's built-in infrastructure and services—no manual setup required. Managed hosting projects require hours to days for new project creation, including manual setup. |
| Multicloud | AWS, Azure, OVH, IBM, GCP | Single/fixed provider | Upsun makes it easy to use the IaaS provider of your choice, whether it’s based on compliance or simply on performance. Managed hosting providers typically lock you into their infrastructure or a single cloud provider. |
| Container management | Git workflows | FTP/SFTP, manual uploads, or limited Git | Upsun eliminates infrastructure complexity with native Git integration and automatic branch-to-environment mapping. Managed hosting services rely on manual file uploads and container management |
| Regulatory compliance | SOC 2 Type 2, GDPR, ISO 27001, HIPAA certified | Limited | Upsun is PCI DSS Level 1, GDPR, HIPAA, ISO 27001, and SOC 2 Type 2 compliant, with automated compliance monitoring. Managed hosting offers limited compliance (mostly GDPR) through third-party providers. |
| Pricing transparency | Predictable & transparent pricing | Complex pricing with hidden fees | Upsun offers transparent and predictable pricing with fixed and flexible pricing options. No hidden charges. Managed hosting uses fixed monthly tiers with bundled services, and often additional fees for advanced features. |
| Performance monitoring | Built-in observability suite | Basic server monitoring | Upsun provides real-time Application Performance Monitoring (APM) that identifies issues and recommends code optimizations to improve performance. Managed hosting offers basic server monitoring with limited access to application-level insights, code profiling, and optimization guidance. |
| Security updates | Built-in security | Basic security, upgrade required | Upsun provides reliable security with anti-DDoS and an integrated Web Application Firewall (WAF). Managed hosting offers basic security, often requiring manual setup or upgrade. |
| Preview environment | Byte-for-byte clones with real data | Manual staging setup; limited data | Upsun users can create instant staging environments with a single command; each environment is a replica of production, including all databases and stored files. Managed hosting requires a manual staging environment setup with limited data replication. |
| Persistent storage | Internal storage included | Fixed; upgrade required | Upsun includes persistent storage for all customers; select and configure storage directly on our platform. Managed hosting uses files stored on servers with manual backups; scaling requires an upgrade. |
| Managed data services | Full databases, caching, and services | Limited | Upsun solves the database complexity with fully managed and scalable data services. Data services on most hosting providers are limited, and advanced services require a higher tier. |
| Language support | Native support for major programming languages | Limited language and versions | Upsun supports the latest versions of 10 programming languages and an array of frameworks. Managed hosting provides pre-installed language versions with limited selection and manual update processes. |
| Availability & recovery | 99.99% uptime available and automated backups | Basic uptime SLA and manual backup | Upsun is designed with high availability and data recovery with automated backups, and 99.99% uptime is available. Managed hosting providers offer uptime SLAs, but they're typically lower than 99.99%, and backup management is largely manual. |
| Team collaboration | Available | Available with limited collaboration features | With the Upsun team, members can collaborate seamlessly on a unified platform with granular access controls and instant onboarding. Team collaboration on managed hosting is limited by manual onboarding processes, which create friction for efficient team workflows |

Want to learn more? [Upsun documentation](https://docs.upsun.com/) has everything you need to get started.

### [AWS alternative: deploy without limits | Upsun](https://upsun.com/aws-alternative/)

# Deploy _without limits_ with Upsun

Looking for an AWS alternative? Need to scale but also want developer-friendly features and cloud portability? Our AWS vs. Upsun comparison will help you find the ideal PaaS with pricing perfectly crafted to suit your business needs.

## Eliminate complexity

Upsun provides all your infrastructure needs and easily works with all major cloud providers, including AWS. Your team can focus entirely on innovation and feature delivery while Upsun handles all underlying infrastructure complexity.

## Instant environments

Provision new projects and as many new environments as you need in minutes. Every Git branch creates a complete, production-like environment with all your data included, perfect for testing, previews, and collaboration.

## Green Hosting Incentive

Upsun makes sustainability profitable, not just trackable. When you choose a lower-carbon data center, you receive a 3% Greener Region Discount on your resource usage.

## Multi-cloud freedom

Enjoy multi-cloud freedom without vendor lock-in. For every project, you can choose your preferred cloud provider (AWS, Azure, Google Cloud, IBM, or OVH) with no extra configuration needed.

AWS alternative: deploy without limits | Upsun

Upsun is the AWS alternative delivering instant environments, multi‑cloud freedom and built‑in APM, slashing complexity and cloud costs

## Why choose Upsun over AWS?

"Upsun fits perfectly within FREITAG's strategy. We needed a platform that was as stable as it was flexible for quickly integrating new features into the live environment, for modifying, and testing... Upsun was the best option for achieving these goals" —Tonio Zemp, Digital Expert and Product Owner, Liip

## Start today

Look on the bright side with a free trial of Upsun!

We understand that choosing a cloud provider is a big decision. Start with our free tier—spend 15 days exploring Upsun for free. You'll see why over 16,000 developers choose the transparency,

Switch to Upsun in

**Get a 3% discount** when you deploy and manage applications at data centers in our incentive-eligible greener regions

**Create byte-for-byte clones** of your production environment in **under 2 minutes**, making updates simple, safe, and straightforward

**One centralized PaaS handles ops**, storage, security, previews, and more. Sign **1 contract**, pay **1 bill**, and let your developers focus on **1 thing**: coding

**Zero effort, 0 commitment required upfront**. Get started with our **$0 free** tier and experience the difference for yourself

| Feature | Upsun | Competitor | Details |
| --- | --- | --- | --- |
| Multi cloud | AWS, Azure, OVH, GCP, IBM | AWS only | Upsun runs on AWS, Azure, Google Cloud, IBM, and OVH. Seamlessly switch cloud providers to meet your application and business needs. AWS is a single-cloud vendor. Moving to other cloud providers requires rebuilding applications and infrastructure from scratch |
| New project creation | Minutes and fully automated | Hours/days | Upsun eliminates setup complexity. Simply connect your Git repository, push your code, and your application is live in minutes. Creating a new project on AWS can require hours to days of manual configuration of multiple services, networking, security, DevOps pipelines, and time context switching for developers |
| Environment cloning | Instant byte-for-byte clones with data | Manual setup without data | Upsun instantly replicates your production environment in under 2 minutes with complete data and configurations. AWS cloning is limited to Elastic Beanstalk infrastructure only (no data included) and requires manual CloudFormation templates for complete environments |
| Sustainability | Carbon tracking + green hosting incentives | Carbon tracking; no green hosting incentives | Upsun tracks carbon intensity across all regions and offers 3% discount when you choose greener and sustainable data centers. AWS offers carbon tracking tools; however, there are no pricing benefits or incentives for choosing lower-carbon regions |
| Application Performance Monitoring | Real-time APM | CloudWatch monitoring (extra cost) | Upsun provides real-time APM built-in, which identifies issues and recommends code optimizations to improve performance. AWS APM requires multiple services (CloudWatch Application Signals + X-Ray + CloudWatch) with a complex setup at an extra cost |
| CI/CD Pipeline | Integrated | Silo AWS services | Upsun integrates with your Internal Development Platform (IDP) and CI/CD tools. Simply push to Git and your app deploys automatically. No additional service integration required. AWS requires separate services (CodeCommit, CodeBuild, CodeDeploy, CodePipeline) with complex IAM roles and configuration files |
| Security updates | Automatic | Manual patching required | Upsun automatically handles security updates, patches, and platform modernization so your applications stay secure without manual intervention. With AWS, you're responsible for patching operating systems, runtimes, and maintaining security updates |
| Regulatory compliance | SOC 2 Type 2, PCI DSS Level 1, GDPR, HIPAA, ISO 27001 certified | Manual configuration required | Upsun is PCI DSS Level 1, GDPR, HIPAA, ISO 27001, and SOC 2 Type 2 compliant, with automated compliance monitoring and DDoS protection. AWS provides compliant infrastructure but requires manual configuration of IAM, encryption, logging, and monitoring |
| Developer experience | NoOps, Git workflow | DevOps expertise required | Upsun provides developer autonomy through a Git workflow. No DevOps skills required. AWS requires DevOps knowledge to manage its complex infrastructure |

Built with the flexibility you need to build and scale. Contact sales to schedule a demo

### [Fly.io alternative with multicloud support | Upsun](https://upsun.com/fly-io-alternative/)

# Fly.io vs Upsun

Looking for a Platform-as-a-Service that goes beyond limits in deployment, performance, and observability? That’s Upsun.

## Zero DevOps complexity

Git push is all you need to deploy your applications. Focus on development while Upsun manages Docker, containers, and infrastructure behind the scenes.

## Built-in compliance certification

Meet enterprise compliance requirements with Upsun's built-in certifications (SOC2, PCI DSS, HIPAA, ISO 27001) and security controls. Say goodbye to compliance gaps and deploy with confidence.

## Predictable total cost

One platform, one contract, one bill. No surprise charges or hidden infrastructure costs.

## Faster time to market

Go from local repo to production in minutes. Spend time building features without disruption in your application pipeline.

Fly.io alternative with multicloud support | Upsun

Upsun is a Fly.io alternative with unlimited environment cloning, multicloud support, transparent pricing, and PCI DSS, GDPR, and HIPAA compliance

## Why Upsun is the best Fly.io alternative

"…it's our flagship and our most visible web property taking millions of visits a month, so the extra hours of uptime are a huge win for us—especially since we don't have to worry about monitoring and fixing it ourselves." —Ryan Geraghty, Director of Web Development, HMP Global

## Ready to migrate to Upsun?

Switching is easier than you think.

Start with our free trial, and spend 15 days exploring Upsun for free. You'll see why over 16,000 developers choose the transparency, flexibility, and autonomy we provide.

Experience the Upsun advantage

**Get a 3% discount** when you deploy and manage applications at data centers in our incentive-eligible greener regions.

**Create byte-for-byte clones** of your production environment in **under 2 minutes,** making updates simple, safe, and straightforward.

**One centralized PaaS** handles ops, storage, security, previews, and more. Sign **1 contract,** pay **1 bill,** and let your developers focus on **1 thing:** coding.

**Zero effort, 0 commitment required upfront.** Get started with our **$0 free tier** and experience the difference for yourself.

| Feature | Upsun | Competitor | Details |
| --- | --- | --- | --- |
| Multicloud | AWS, Azure, OVH, IBM, GCP | Proprietary infrastructure | Upsun offers flexibility with multiple IaaS providers with 15+ regions to meet geographical, regulatory, and environmental requirements. Fly.io operates its own global infrastructure. However, this does not offer users the flexibility to choose their preferred cloud provider. |
| Sustainability | Carbon tracking + green hosting | x | Upsun tracks carbon intensity 12x across all regions and offers 3% discount when you choose greener and sustainable data centers. Fly.io does not have published sustainability policies or environmental commitments. |
| Preview environments | Byte-for-byte clones with real data | Manual GitHub Actions setup | Upsun instantly replicates your production environment in under 2 minutes with byte-for-byte data. Fly.io requires manual environment setup with multi-step processes and no data included. |
| Request timeout | Unlimited duration | Fixed with timeout | Upsun has no request timeout, even for large files. Fly.io has a fixed 60-second idle request timeout, which cannot be modified. |
| Observability | Built-in observability features | 3rd-party add-on | Upsun offers comprehensive observability with APM, error tracking, metrics, profiling, and dashboards, all in one platform. Fly.io offers basic infrastructure metrics with limited platform support that requires external services. |
| Managed data services | Full support | Postgres and Redis only | Upsun solves the database complexity with fully managed data services. Fly.io requires database operations with limited managed options and self-management responsibilities. |
| Pricing model | Predictable & transparent pricing model | Region-based pricing | Upsun offers flexibility with two pricing options: pay only for the resources you provision, or choose a fixed monthly tier plan. Fly.io utilizes regional pricing, resulting in significant cost variations across different regions. |
| Performance monitoring | Real-time APM | Basic infrastructure metrics | Upsun provides real-time Application Performance Monitoring to detect issues and recommend code optimization. Fly.io offers basic metrics features, like tracing and error tracking, that require an external provider. |
| Regulatory compliance | Comprehensive compliance framework | Limited | Upsun is PCI DSS Level 1, GDPR, HIPAA, and SOC 2 Type 2 compliant, with automated compliance monitoring and DDoS protection. Fly.io supports SOC 2, HIPAA, and GDPR, but lacks PCI DSS certification and does not offer automated compliance features. |
| Persistent storage | Multi-tier storage | Limited | Upsun provides persistent storage with multiple mount types, automated daily backups, and cross-region replication. Fly.io offers limited persistent storage with single-region volumes, 5-day snapshots, and manual backup setup. |
| Background jobs | Built-in cron scheduling | Manual configuration | Upsun includes cron jobs within each application, separate from billable usage and with no additional fees. Fly.io requires manual setup and management. |
| Container management | Git workflow | Docker setup required | Upsun eliminates Docker complexity through a git-only workflow. Fly.io requires Docker expertise and manual container management. |

All the enterprise PaaS features you need—all without complexity. Contact [sales](https://upsun.com/contact-us/) to schedule a demo.

### [Vercel alternative for multi-cloud apps | Upsun](https://upsun.com/vercel-alternative/)

# Looking for a Vercel alternative?

Your great ideas shouldn't be limited by infrastructure or lack of it. Upsun delivers the infrastructure and integrated tools you need to ship full-stack applications without restrictions.

## True multi-cloud freedom

Upsun places infrastructure choice in your hands. Deploy on AWS, Azure, Google Cloud, IBM, or OVHcloud in any region. With this, you can choose your provider and region based on performance, or to support your sustainability goals.

## Production-perfect preview environments

Spin up instant copies of your production environment with complete data, configurations, and code for every development branch. Team members can access and test these live preview environments with confidence.

## Full-stack deployment

Deploy complete applications with backend services, databases, caching, and search engines; all from one centralized platform. Sign one contract, pay one bill, and let your developers focus on coding instead of infrastructure management.

## Build without constraints

Build in the language, framework, or database your project needs. Deploy microservices, monoliths, or anything in between. Upsun supports your architecture, not the other way around.

Vercel alternative for multi-cloud apps | Upsun

Discover a Vercel alternative with true multi-cloud, full-stack hosting, preview clones with data, built-in APM, and transparent pricing—no vendor lock-in.

## Built with everything you need to deploy and scale

"We spend much less time dealing with performance and caching issues and more time on end-user features that make the shopping experience better for our customers." —Saaed Fattahi, Director of Technology, SportRx

## Looking to Migrate to Upsun?

Migration to Upsun is easy!

Start with our free tier—spend 15 days exploring Upsun for free. You'll see why over 16,000 developers choose the transparency, flexibility, and autonomy we provide.

Experience the Upsun advantage

**Get a 3% discount** when you deploy and manage applications at data centers in our incentive-eligible greener regions.

**Create byte-for-byte clones** of your production environment in **under 2 minutes**, making updates simple, safe, and straightforward.

**One centralized PaaS handles ops**, storage, security, previews, and more. Sign **one contract**, pay **one bill**, and let your developers focus on **one thing**: coding.

**Zero effort, zero commitment required upfront.** Get started with our **$0 free** tier and experience the difference for yourself.

| Feature | Upsun | Competitor | Details |
| --- | --- | --- | --- |
| Preview environments | Complete byte‑for‑byte clones with data | Code only; databases and services not included | Upsun auto-creates environment clones for every branch including code, data, config, and connected services. Vercel creates preview URLs for each branch, but databases and services must be configured separately via external providers |
| Multi-cloud deployment | AWS, Azure, Google Cloud, IBM, OVHcloud | AWS infrastructure only | Upsun lets you deploy on multiple cloud providers and across 15+ regions from a single console, with no vendor lock-in. Vercel runs exclusively on AWS infrastructure, meaning you cannot choose alternative cloud providers or regions. |
| Language support | Native support for 10 programming languages | Focused on JavaScript/TypeScript frameworks | Upsun natively supports the latest versions of 10 major programming languages and an array of frameworks. Vercel offers runtimes for Node.js, Python, Go, and Ruby, but limited to serverless functions, with full support centered on JavaScript and TypeScript frameworks. |
| Managed services | Fully managed databases and services | Limited; requires external services | All managed services: databases, caching, search are fully integrated into Upsun environments, with no external providers. Vercel provides Postgres and Redis via third-party providers, while other databases and services depend on external integrations. |
| Pricing model | Transparent and predictable pricing models | Hybrid pricing model | Upsun offers simple and transparent pricing with two pricing options: pay only for the resources you provision, or choose a fixed monthly tier plan. Vercel uses a hybrid pricing model with a fixed monthly fee and usage-based charges, making costs difficult to predict. |
| Backend hosting | Full backend support with persistent services | Serverless functions only with time limits | Upsun supports persistent workers, background jobs, and cron tasks with full backend capabilities; no time limits or serverless constraints. Vercel backend support is limited to serverless functions with execution time limits, no background workers, and stateless architecture. |
| Request timeouts | Configurable with unlimited worker processes | 5-15 minutes maximum (plan-dependent) | On Upsun, web requests can run for extended periods with a default 5-minute limit (configurable), and background workers execute without time limits. Vercel functions have maximum execution durations of between 5-15 minutes depending on plan; proxied requests to external services timeout at 2 minutes. |
| Regulatory compliance | SOC 2 Type 2, PCI DSS Level 1,ISO27001 GDPR, HIPAA | SOC 2 Type 2, ISO 27001, GDPR, PCI DSS, HIPAA | Upsun is PCI DSS Level 1, GDPR, HIPAA, ISO 27001, and SOC 2 Type 2 compliant, with automated compliance monitoring. Vercel is SOC 2 Type 2, ISO 27001, GDPR, PCI DSS compliant; HIPAA available on Enterprise with BAA. |
| Application Performance Monitoring | Built-in observability suite | Available with additional configuration | Upsun real-time Application Performance Monitoring (APM) identifies issues and recommends code optimizations to improve performance. Vercel provides basic observability built-in; advanced APM requires third-party integrations via OpenTelemetry. |
| Sustainability | Carbon tracking + green hosting discounts | Not available | Upsun tracks carbon intensity 12x across all regions and offers a 3% discount when you choose greener, more sustainable data centers. Vercel uses serverless architecture for energy efficiency but does not provide carbon tracking, green hosting options, or sustainability incentives. |

Want to learn more? [Upsun documentation](https://docs.upsun.com/) has everything you need to get started.

### [Acquia alternative with predictable pricing | Upsun](https://upsun.com/acquia-alternative/)

# Great ideas should not be _limited by infrastructure_

Get your team the right deployment platform without the restrictions. No matter what you run on, Upsun provides you with the infrastructure and integrated tooling to deploy anything, anywhere, without vendor lock-in.

## Predictable pricing

Upsun offers predictable pricing that fits every business needs. Choose between fixed tiered pricing or provision-based pricing, where you pay only for the resources you actually provision. Both models provide transparent and predictable billing with no traffic charges.

## Multi-cloud flexibility

Choose the cloud provider and region that fits your needs. Whether you're optimizing for performance or regulatory requirements, Upsun gives you control over where and how your applications run.

## 99.99% uptime available

Keep your applications online even through traffic spikes with 99.99% contractable uptime available, automated disaster recovery, and a dedicated 24/7 support team.

## Team collaboration and control

Manage projects, team members, and environments from a single dashboard with granular permissions. Share live preview environments with stakeholders without complex setup.

Acquia alternative with predictable pricing | Upsun

Acquia alternative with multi-cloud control, unlimited clones, built-in security and APM, and predictable pricing. Start free for 15 days

## Why developers choose Upsun

"We're able to deploy every day, with new features going live constantly. That agility would've been impossible in our previous environment." —Geoff Douglas, VP of Engineering, MarketNation

## Ready to leave the limitations behind?

Start with Upsun today!

We understand that choosing a cloud provider is a big decision. Start with our free tier, spend 15 days. You'll see why over 16,000 developers choose the transparency, flexibility, and autonomy we provide.

Switch to Upsun in

**Get a 3% discount** when you deploy and manage applications at data centers in our incentive-eligible greener regions.

**Create byte-for-byte clones** of your production environment in under 2 minutes, making updates simple, safe, and straightforward.

**One centralized PaaS handles ops**, storage, security, previews, and more. Sign **1 contract**, pay **1 bill**, and let your developers focus on **1 thing**: coding.

**Zero effort, 0 commitment required upfront**. Get started with our **$0 free** tier and experience the difference for yourself.

| Feature | Upsun | Competitor | Details |
| --- | --- | --- | --- |
| Cloud provider | AWS, Azure, Google Cloud, OVHcloud, IBM | AWS only | Upsun offers flexibility with multiple IaaS providers and regions, enabling users to switch cloud providers as needed to meet their application and business requirements. Acquia relies exclusively on Amazon Web Services (AWS) infrastructure and hosts only in AWS regions. |
| Language support | Native support for 10 programming languages | Drupal-based | Upsun supports the latest versions of 10 programming languages and a wide array of frameworks. Acquia specifically supports Drupal modules and JavaScript, but not as a server-side application. |
| Environment cloning | Unlimited production clones | Limited staging environments | Upsun instantly replicates your production clones, which means you can test every change with real data before going live in minutes. Acquia provides staging environments with manual data copying operations and lacks true production-like cloning with real data and infrastructure replication. |
| Transparent pricing | Transparent & predictable pricing models | Enterprise pricing + hidden charges | Upsun offers flexibility with two pricing options: pay only for the resources you provision, or choose a fixed monthly tier plan. Acquia offers enterprise pricing with annual contracts starting at $141/month. However, most features require custom quotes, often reaching $100K+ annually. |
| Security & Compliance | Built-in Security | Built-in Security | Upsun offers a built-in Web Application Firewall (WAF), DDoS protection, and automated security patches across all plans without enterprise upgrade requirements. Acquia provides standard security features, but advanced security and compliance certifications are limited to enterprise plans. |
| Application Performance Monitoring | Built in APM | New Relic external; limited tiers | Upsun delivers function-level insights, combining observability and telemetry with built-in APM to enable data-driven decision-making. Acquia offers New Relic APM integration for users on the higher tier, and this requires external service configurations. |
| Managed Data Services | Fully supported | Limited | Upsun offers fully managed database caching and search services provisioned automatically per environment. Acquia database management is limited, often requiring external tooling or manual setup. |
| Container management | Git-based workflow | Traditional virtual machine | Upsun eliminates infrastructure complexity through native Git integration and automatic branch-to-environment mapping. Although Acquia uses containers internally, it follows traditional virtual machine management with manual deployments. |
| Team collaboration | Available | Available with limited collaboration features | With the Upsun team, members can collaborate seamlessly on a unified platform with granular access controls and instant onboarding. Acquia collaboration features require manual onboarding processes, which creates friction for efficient team workflow. |
| Traffic limits | Unlimited page views | Capped by plan tier | Upsun offers unlimited page views and traffic by default with need-based pricing for resources. Acquia caps service by monthly views and visits, based on your plan. Consistent traffic can trigger overage fees or force a plan upgrade. |

All the enterprise PaaS features you need— without complexity. [Contact sales](https://upsun.com/contact-us/) to schedule a demo.

### [Amazee alternative with true multicloud and clones | Upsun](https://upsun.com/amazee-alternative/)

# Scale with the self-service PaaS _for teams that ship fast_

Go from code to production in minutes. Upsun provides the infrastructure you need to ship great software, without the overhead that holds back other teams.

## True multi-cloud flexibility

Upsun places infrastructure choice in your hands. Select the cloud provider and region that best suits your needs. Whether you're optimizing for performance or regulatory requirements, Upsun gives you flexibility to choose where and how your applications run.

## Production-ready clones in minutes

Spin up production clones in minutes. Every Git branch creates a complete, production-like environment with all your data included, perfect for testing, previews, and collaboration.

## Transparent and predictable pricing

Upsun offers predictable pricing that fits every business needs. Choose between fixed tiered pricing or provision-based pricing, where you pay only for the resources you actually provision. Both models provide transparent and predictable billing with no traffic charges.

## Work with your stack

Whatever languages, runtimes, stacks, or CMS you use, Upsun has you covered. With support for 10 languages, virtually any framework of your choice, and fully managed services like databases, search, and caching.

Amazee alternative with true multicloud and clones | Upsun

Looking for an amazee alternative? Upsun is a self-service multicloud PaaS with production clones, built-in APM, and predictable pricing. Start a free trial

## Why teams choose Upsun

"In my time at Hearst Networks EMEA, one of the best decisions that I've made to date was choosing Upsun as our hosting provider. I think that it's an immensely powerful tool." —James Hall, Head of Web, Hearst Networks EMEA

## Ready to experience the difference?

Migrating to Upsun is a seamless process!

We understand that switching platforms is a big step. Start with our 15-day free trial and explore Upsun at no cost. You can also schedule a demo to speak with an expert.

Experience the Upsun advantage

**Get a 3% discount** when you deploy and manage applications at data centers in our incentive-eligible greener regions.

**Create byte-for-byte clones** of your production environment in **under 2 minutes**, making updates simple, safe, and straightforward.

**One centralized PaaS handles ops**, storage, security, previews, and more. Sign **one contract**, pay **one bill**, and let your developers focus on **one thing**: coding.

**Zero effort, zero commitment required upfront**. Get started with our **$0 free** tier and experience the difference for yourself.

| Feature | Upsun | Competitor | Details |
| --- | --- | --- | --- |
| Multicloud | AWS, Azure, IBM, OVH, GCP | AWS, Azure, GCP | Upsun offers true multicloud across multiple cloud providers and regions from a single console. Amazee.io runs on AWS, Azure, or GCP, but requires dedicated infrastructure setup and management per cloud provider. |
| Environment cloning | Unlimited byte-for-byte clones with data | Limited cloning capabilities | Upsun provides byte-for-byte production clones with real data and services on every Git branch. Amazee.io creates branch environments but requires manual sync of databases and files between environments. |
| Language support | Native support for 10 programming languages | Any language (requires custom configuration) | Upsun natively supports the latest versions of 10 programming languages and an array of frameworks. Vercel supports multiple languages via Docker containers (PHP, Node.js, Python, Ruby, Java); requires custom Dockerfile configuration |
| Traffic limits | Unlimited page views limit | Per-hit usage model | Upsun offers unlimited traffic; pricing is based on resource allocation, not pageviews or bandwidth. Amazee uses a per-hit model, where each resource request is charged; typical pages generate around 10 hits per page view. |
| Pricing model | Transparent and predictable pricing | Transparent custom pricing | Upsun offers flexibility with two pricing options: pay only for the resources you provision, or choose a fixed monthly tier plan. Amazee offers custom pricing based on per-project fees, per-hit usage, and deployment model. |
| Compliance | SOC 2 Type 2, PCI DSS Level 1, GDPR, HIPAA, ISO 27001 certified | SOC 2 Type 2, PCI DSS Level 1, GDPR, HIPAA, ISO 27001 certified | Upsun is PCI DSS Level 1, GDPR, HIPAA, ISO 27001, and SOC 2 Type 2 compliant, with automated compliance monitoring. Amazee is ISO/IEC 27001, SOC 2 Type 2, GDPR, HIPAA, PCI DSS, and CCPA compliant. |
| Managed data services | Fully supported | Supported within Lagoon containers | Upsun simplifies service complexity by integrating fully managed databases, cache, and search indexes into the project. Amazee supports managed databases through cloud providers, but PostgreSQL and Redis require contacting support for setup. |
| Application Performance Monitoring | Built-in observability suite | Dashboard for deployment status and logs | Upsun provides real-time APM by default, which identifies issues and recommends code optimizations to improve performance. Amazee supports integration with third-party APM tools, which requires the customer to set up their own APM account. |
| Preview environment | Automatic Git branch environments | Branch and PR environments | On Upsun, every git branch has its own environment. Every pull request auto-creates an environment with inherited data and services. Amazee auto-deploys branch/PR environments via Git webhooks; requires initial configuration of branch patterns with support |
| Speed to market | Instant self-service deployment | Requires Lagoon setup and configuration | Upsun users can ship features in minutes through Git push workflows once source integration is configured. Amazee requires support assistance for setup; Git push deployments take seconds to hours, depending on project complexity. |
| Sustainability incentives | Carbon tracking + green hosting discounts | Not available | Upsun tracks carbon intensity 12x across all regions and offers a 3% discount when you choose greener, more sustainable data centers. Amazee offers carbon-neutral hosting via Google Cloud; however, there are no green hosting discounts. |

### [DigitalOcean alternative for multicloud apps | Upsun](https://upsun.com/digitalocean-alternative/)

# Looking for a DigitalOcean alternative?

Take your apps beyond basic VMs or single-cloud PaaS. Upsun provides a cloud application platform with the flexibility and features to build, ship, and scale without limits.

## Instant production cloning

Spin up instant copies of your production environment with complete data, configurations, and code for every development branch. Team members can access and test these live preview environments with confidence.

## Multicloud deployment

Upsun places infrastructure choice in your hands. Select your cloud provider and region with lower carbon intensity to earn discounts and support your sustainability goals.

## Multi-language support

Whatever languages, runtimes, stacks, or CMS you use, Upsun has you covered. With support for 10 languages, virtually any frameworks, and fully managed services like databases, search, and caching.

## 99.99% uptime available

Keep your applications online, even during traffic spikes, with 99.99% uptime availability, automated disaster recovery, and a dedicated 24/7 support team.

DigitalOcean alternative for multicloud apps | Upsun

Looking for a DigitalOcean alternative? Run on any cloud, clone prod in minutes, get built-in CI/CD, and 99.99% uptime available - with transparent pricing

## Experience the Upsun advantage

"The GitHub integration, the creation of those UAT sites… that really was a huge game-changer for us. It's so seamless the way Upsun fits into the way we were working already." —Daniel Gittings, Lead Digital Developer, University of Surrey

## Ready to experience the difference?

Migrating to Upsun is a seamless process!

We understand that switching platforms is a big step. Start with our 15-day free trial and explore Upsun at no cost. You can also schedule a demo to speak with an expert.

Choose the right platform for your team

**Get a 3% discount** when you deploy and manage applications at data centers in our incentive-eligible greener regions.

**Create byte-for-byte clones** of your production environment in **under 2 minutes**, making updates simple, safe, and straightforward

**One centralized PaaS handles ops**, storage, security, previews, and more. Sign **one contract**, pay one bill, and let your developers focus on **one thing**: coding

**Zero effort, 0 commitment required upfront**. Get started with our **$0 free** tier and experience the difference for yourself

| Feature | Upsun | Competitor | Details |
| --- | --- | --- | --- |
| Environment cloning | Full-stack production clones | Manual setup required without data clones | Upsun provides byte-for-byte production clones with real data and services on every Git branch. DigitalOcean supports preview environments through manual setup, but does not offer automatic data cloning. |
| Multicloud deployment | AWS, Azure, GCP, IBM, and OVHCloud | DigitalOcean infrastructure only | Upsun offers flexibility in deploying multiple cloud providers and regions from a single console. DigitalOcean runs exclusively on DigitalOcean's proprietary infrastructure. |
| CI/CD | Automatic on every Git push | Third-party tools required | Upsun provides a complete CI/CD pipeline built in with automatic build, test, and deployment on every Git push. DigitalOcean offers auto-deploy for continuous deployment; however, full CI/CD requires third-party integration. |
| Language support | Native support for 10 programming languages | Limited to 6 languages | Upsun supports the latest versions of 10 programming languages and an array of frameworks. DigitalOcean supports six major languages; other languages require a custom Dockerfile configuration. |
| Pricing model | Predictable & transparent pricing models | Predictable per-component pricing | Upsun offers flexibility with two pricing options: pay only for the resources you provision, or choose a fixed monthly tier plan. DigitalOcean offers per-container pricing with fixed monthly costs. |
| Managed services | Databases, caching, and services integrated | Extra cost for managed services | Upsun simplifies service complexity by integrating fully managed databases, cache, and search indexes into the project. Managed services are separate products you connect to on DigitalOcean, requiring manual database provisioning and migration. |
| Infrastructure management | Fully managed PaaS | Fully managed PaaS | Upsun's managed PaaS uses infrastructure-as-code, where resources are defined in YAML, and the platform handles all infrastructure. DigitalOcean offers a fully managed PaaS designed for maximum simplicity, handling all infrastructure management. |
| Compliance | SOC 2 Type 2, PCI DSS Level 1, GDPR, HIPAA, ISO 27001 certified | SOC 2 Type 2, ISO 27001 only | Upsun is PCI DSS Level 1, GDPR, HIPAA, ISO 27001, and SOC 2 Type 2 compliant, with automated compliance monitoring. DigitalOcean compliance is limited to SOC 2 Type 2 and ISO 27001 certification only. |
| Web Application Firewall (WAF) | Available; built-in | Available (third-party only) | Upsun has a comprehensive, built-in WAF that provides application-layer (Layer 7) protection against web attacks. DigitalOcean provides network-layer DDoS protection but does not include WAF for application-layer threats. Third-party WAF are available through third-party installation. |
| Sustainability incentives | 3% discount for low-carbon regions | Not available | Upsun tracks carbon intensity 12x across all regions and offers a 3% discount when you choose greener, more sustainable data centers. DigitalOcean partners with data centers; however, no financial incentives or carbon tracking tools are available. |
| Custom runtimes | Highly customizable via YAML configuration | Supported via a user-provided Dockerfile. | Upsun is highly customizable via YAML, supporting 10+ native runtimes and composable images for custom packages in a single project. DigitalOcean offers custom runtimes supported via a user-provided Dockerfile. |
| Application Performance Monitoring | Built-in observability suite | Limited | Upsun real-time Application Performance Monitoring (APM) identifies issues and recommends code optimizations to improve performance. DigitalOcean monitors system metrics and basic app insights, but doesn't track application-level performance or errors. |
| Backup services | Automatic backups by default | Varies by product | Backups are built in on Upsun by default, stored redundantly, and can be restored into any environment or branch. Backups vary by product on DigitalOcean: VM backups are paid add-ons, and app/database backups lack complete native protection. |

## Frameworks

### [The secure platform for Node.js development | Upsun](https://upsun.com/nodejs)

Python development involves a lot of moving parts. From building, managing, and maintaining complex internal platforms, to connecting tools and people to the right resources, to reliably securing applications. This makes enforcing compliance and environment provisioning moving targets. Preventing your teams from focusing on your APIs and spending a lot more time on things they’d rather not. With our Node.js cloud platform, these are things of the past.

# Deploy Node.js applications with _zero infrastructure overhead_

Run Express, Next.js, Fastify, or any Node.js framework from a single config. Upsun builds from Git, connects your apps and workers to managed services, and gives every branch its own isolated URL without infrastructure scripts to maintain. Push code once, and your app runs the same in preview as it does in production.

### Standardize deployment across environments

### From commit to running app in one push.

Define your Node.js version, build commands, and services in a single YAML file. Push to Git and Upsun handles dependency installation, builds, service provisioning, and routing. No CI/CD pipeline to build or infrastructure to manage.

### Add managed services

Define databases, caches, and search as services, and connect your Node app through relationships. Upsun exposes relationship details through environment variables. Your app can discover connection info without hardcoding secrets.

### Keep your package workflow

Upsun’s default Node build flavor assumes npm and runs a production-safe install automatically (including support for .npmrc). If you need a different workflow, disable the flavor and run exactly what you want: Yarn or Bun included.

### Build once

When your app deploys with no code changes, Upsun reuses the existing build output instead of rebuilding. Keep environment-specific values out of your build step, and the same artifact runs identically across preview, staging, and production.

### Preview changes in production-identical environment

### Test against real data

Upsun environments are built for development, testing, staging, and review. Every Git branch can get its own isolated environment that is a full-stack clone of its parent branch environment.

### Works with your existing Git workflow.

Upsun integrates with GitHub, GitLab, and Bitbucket, so environments can be created automatically for branches and pull requests. Push your code and configuration; Upsun builds, deploys, and routes automatically.

### Deploy background workers and cron jobs

Run workers and queues alongside your web process. Define Bull/BullMQ workers, queue consumers, or cron jobs as separate containers in the same project. Each scales independently with its own CPU and memory.

### Multi-app when you need it

Run multiple apps in one project (API + worker + front-end, or service-to-service). Define relationships between apps the same way you define relationships to services.

### Observe, debug, and operate Node.js safely

### Continuous profiling is built into the platform.

Upsun provides continuous profiling for Node.js, powered by Blackfire, available directly in the Console. Node.js profiling is captured across CPU time, wall-time, and heap allocation.

### Debug where the bug actually happens.

Use a preview environment, SSH in, run Node in inspect mode, and attach a debugger from Visual Studio Code or Chrome DevTools. The docs include steps for forwarding the debugger port when debugging remotely.

### Trigger runtime operations

Define runtime operations in your app config and trigger them on demand from the Console or CLI to run controlled one-off commands inside your app container. Use them for maintenance, backfills, or admin scripts with role-based access controls.

### Troubleshoot with app logs

Access container and activity logs from the CLI, so you can troubleshoot in the live environment. Stream logs during debugging, inspect worker logs, and forward them to external endpoints for retention, alerting, or deeper analysis.

### Secure by default. Deploy anywhere.

### Deploy across cloud providers

Run your Node.js apps on AWS, Google Cloud, Azure, OVHcloud, or IBM. Choose the provider and region that matches your latency, compliance, or cost requirements.

### Automated TLS and network isolation

Every environment gets automatic HTTPS with managed TLS certificates. Your application containers, databases, and services communicate over an isolated internal network that is not exposed to the public internet.

### Immutable builds and containers

Upsun builds your Node.js app into a read-only filesystem at deploy time. Runtime processes cannot modify application code, install packages, or alter the build.

### Secure app credentials

Store credentials in environment variables rather than in your repository. That keeps secrets out of source control and makes it easier to manage different values across environments.

Documentation

## Deploy Express / Next.js / Strapi using the Node.js sample configurations

## Add services in YAML (PostgreSQL, Redis, RabbitMQ, and more)

## Enable Node.js continuous profiling and use it to guide optimization

## Define runtime operations for safe admin tasks

Unified delivery for Node.js

The cloud platform for Node.js and Jamstack applications and developers. Upsun streamlines and optimizes your Node.js multi-application management

The secure platform for Node.js development | Upsun

### [Magento cloud hosting for enterprises: fast, scalable & secure](https://upsun.com/magento)

Magento selected Upsun to run the Magento Commerce Cloud for a very good reason: our PaaS provides more than a managed service. Take advantage of the infrastructure and DevOps benefits of Magento Commerce Cloud for your Magento 1 site—even while transitioning to Magento 2

# Magento hosting for teams that _ship and scale_

Your Magento store needs more than a server. It needs a platform that handles the complexity of eCommerce: deployment, staging, performance, scaling, security  so your team can focus on building and growing the store instead of managing infrastructure.

### Standardize Magento deployment

### Build environments the same way

Magento is an ecosystem: PHP runtime, database, cache, search, queues, build steps, and a long list of operational gotchas. On Upsun, you define the whole stack in YAML, and every environment is built the same way from a feature branch to production.

### PHP managed, patched, and optimized

Upsun provisions your PHP version in a single line. Security patches apply automatically. Extensions like xsl, sodium, redis, and blackfire load via config, not server administration.

### Managed services

Use the services Magento expects: database, Redis, OpenSearch, RabbitMQ connected inside the environment network, without hand-rolled provisioning scripts. Every service connects securely through the environment's internal network.

### Built for headless and composable commerce

Running Magento as a headless backend with a React, Vue.js, or Next.js frontend? Upsun supports multi-app projects, letting you define your Magento backend and JavaScript storefront as separate applications within the same project.

### Preview environments for every branch

### Test releases on production-like replicas

Create a branch environment with parent data, services, and configuration, so your team can test extension upgrades, PHP version changes, Magento patches, and custom code safely in isolation before merging. Validate changes against production-like data and services without putting the live store at risk

### Safer extension and upgrade testing

Validate extension updates and Magento version upgrades in an environment built the same way as production then promote changes when you’re confident.

### Composer-based builds, predictable deploys

Magento deployments depend on repeatability. Upsun uses Composer-based builds with defined build and deploy hooks, so your deployment process is explicit, versioned, and consistent across en

### CLI, console, and API

Manage your Magento project from the terminal, the Upsun Console, or the API. SSH into any environment, sync code or data between environments, and manage deployments without leaving your workflow.

### Scale for peak traffic, optimize with data

### Scale with visibility and control

Magento performance depends on how caching, search, queues, and services behave together under load. Upsun supports common Magento services like MariaDB, Redis, OpenSearch, and RabbitMQ, and lets you set app and service resources per environment without rebuilding the platform around each bottleneck.

### Adjust resources as your store grows

Set CPU, memory, and disk for app and service containers per environment, and add app instances when needed. Respond faster to growth, traffic peaks, and shifting workloads.

### Observe before you guess

Use logs, metrics, and Blackfire profiling to investigate slowdowns, identify bottlenecks, and validate improvements. Forward logs to external tools when needed

### Magento-specific performance tuning

Set PHP memory limits and tune Magento caching via environment variables. Upsun supports edge caching and CDN integration to reduce origin load and improve performance across regions.

Documentation

## Deploy Magento on Upsun

Blog

## Magento best practices

## Which hosting strategy wins for enterprise Magento?

## Magento deployment automation pitfalls

Powering Magento for enterprise

Run Magento at scale with secure, high-performance cloud hosting built for global brands and multi-store deployments.

Magento cloud hosting for enterprises: fast, scalable & secure

### [The cloud platform for WordPress applications | Upsun](https://upsun.com/wordpress)

Get started in minutes and scale to millions of users. WordPress on Upsun is fast, secure, and you maintain complete control of the data and your site. Looking to decouple with Next.js or Gatsby? Do you need Bedrock, or WooCommerce? You can host, build, and manage it all on one WordPress cloud platform.

# The WordPress _cloud platform built for developers_

Deploy WordPress sites on a platform built for modern delivery workflows. Upsun supports your WordPress stack (Composer, Bedrock, Vanilla, or Multisite)  with configuration-driven deployments, managed services, and isolated environments for every Git branch. So you can review, merge, and ship without environment drift.

### Deploy WordPress with full flexibility and control

### Configuration-driven WordPress deployments

Upsun gives you the flexibility to deploy WordPress however your project requires: Composer-managed, Bedrock boilerplate, Vanilla, or Multisite, all from the same Git-driven workflow. Define your builds, services, and routes in a single YAML configuration file. MariaDB, Redis, and Elasticsearch are provisioned automatically.

### Read-only containers and writable uploads

Application containers are read-only by default. You define writable paths explicitly in your YAML config, and WordPress uploads still work. Everything stays exactly as deployed.

### Multisite across environments

Run Multisite in subdirectories or subdomains. A WP-CLI package automatically rewrites Multisite domain values per environment, so every preview URL works without manual database edits.

### Add managed services

Add MariaDB, Redis, Elasticsearch, Solr, Varnish, and more from configuration. Services run on a private network, credentials are injected automatically, and access is controlled by default.

### Preview changes with production-like environments

### Test changes with production data

Spin up a fully isolated preview environment for every branch, a byte-for-byte clone of production, including your database, files, and services. Test plugin updates, PHP version upgrades, or WooCommerce changes in isolation before they go live on your site.

### Sanitize production data in previews

Automatically sanitize the preview copy. Run a deploy script (or WP-CLI command) that hides sensitive fields for every preview environment before anyone reviews it.

### Automated updates with Source Operations

Automate core, plugin, and theme updates with Source Operations. Schedule a daily check that applies updates on a dedicated branch, then test before merging.

### CLI, Console, and API

Manage your WordPress projects from wherever you work. The Upsun CLI gives you full control from your terminal, so you can run day-to-day ops or build your own automation.

### Scale and secure your WordPress sites

### Deploy across regions with multi-cloud option

WordPress powers everything from personal blogs to enterprise content platforms. Upsun supports single and fleet operations across multiple cloud providers. Deploy to AWS, Google Cloud, Azure, OVHcloud, or IBM using the same configuration-driven workflow, pick regions based on latency, data residency, or sustainability goals.

### Security by default

Read-only filesystems reduce file-tampering risk. Every environment gets managed TLS. Enterprise plans add WAF and DDoS protection.

### Auto-scaling

Handle traffic spikes without manual intervention. Upsun supports autoscaling based on real resource usage, adding capacity when defined thresholds are reached.

### Fleet management

Manage dozens or hundreds of WordPress sites from one platform. Use the Upsun API and Source Operations to enforce compliance, roll out security patches, and keep every site in sync.

Documentation

## Deploy Vanilla WordPress

## Deploy Composer-based WordPress

## Deploy Bedrock-based WordPress

## Deploy WordPress Multisite

Enterprise WordPress: More control, no restrictions

The search for a WordPress cloud platform is over. Standardize and optimize how you manage your WordPress applications with Upsun

The cloud platform for WordPress applications | Upsun

### [Deploy .NET apps with preview environments | Upsun](https://upsun.com/net)

# Deploy .NET to the cloud _without rebuilding your workflow_

Deploy modern .NET apps with consistent builds across every environment. Configure the runtime, build hook, and start command in a single YAML file. Upsun handles repeatable deployments and automatic restarts, and production-identical preview environments, so you ship changes faster with fewer “it worked in staging” surprises.

### Preview environments that match production

### Test with real data

Upsun environments are built for development, testing, staging, and review. Think of them as safe copies of your live site where you can validate changes without risking production. When you’re ready, merge changes and deploy cleanly.

### Ship .NET with predictable builds

Your .NET app builds the same way every time, and each release follows a consistent path from commit to runtime. That makes rollbacks safer, debugging faster, and environment drift much less likely.

### YAML-driven infrastructure that lives in Git

Upsun projects are linked to a Git repo and configured through YAML files in the .upsun directory. You can generate a starting configuration with upsun project:init, then evolve it through normal code review.

### Manages services as containers

Add service containers (databases, caches, search, queues) without having to manually run them. Services are defined in configuration, wired over an internal network, and deployed alongside your app per environment.

### Scale each service independently

### Scale per environment

Allocate CPU, RAM, and disk per app/service per environment. Scale horizontally by increasing instance count. Upsun also supports autoscaling based on thresholds like CPU, RAM, and request latency.

### Infrastructure metrics across every environment

Upsun exposes CPU, RAM, and disk metrics for app, service, and worker containers. The same visibility applies to preview and production, so you can investigate issues where they happen.

### Stream logs from the CLI

Access logs and container logs directly using the CLI (for example, upsun log). Keep your debugging flow fast, even when you’re jumping between environments.

### The platform workflow reuses builds

Each push triggers build + deploy. When you redeploy with no code changes, Upsun can reuse prior outputs helpful for faster iteration and predictable releases.

### Enterprise-grade security and multi-cloud flexibility

### Built-in compliance

SOC 2 Type 2, PCI DSS Level 1, ISO 27001, GDPR, and HIPAA. DDoS protection, web application firewall, automated backups, encrypted data at rest and in transit, and compliance audit logs are included on every project.

### Deploy where you need to

Run on AWS, Azure, Google Cloud, OVHcloud, or IBM Cloud. Choose the region that meets your regulatory requirements. Define your infrastructure once and deploy without rebuilding for each provider.

### Work with the tools you already use

Skip building internal deployment pipelines. Upsun includes GitHub, GitLab, and Bitbucket integrations. Deploy from the CLI or Console, or plug Upsun into your existing CI workflow.

### Command line and local development

Manage your projects from the terminal. Create environments, check logs, SSH into containers, or run dotnet ef commands directly on a running environment. Everything available in the Upsun console is accessible through the CLI

Documentation

## C#/.NET Core documentation

## Add services (PostgreSQL, Redis, RabbitMQ, and more)

## Configure background workers

Deploy modern .NET apps with YAML config, repeatable builds, and production-like preview environments. Ship changes faster with Upsun

Deploy .NET apps with preview environments | Upsun

### [The Ruby platform for optimized development | Upsun](https://upsun.com/ruby)

Batteries-included, hassle-free Ruby Deployment. MariaDB, PostgreSQL, MongoDB, Redis, Elastic Search, RabbitMQ, and SSL with no extra cost or effort with the Upsun Ruby cloud platform.

# Ruby deployments that _stay predictable at scale_

Ship Rails, Sinatra, or a custom Ruby app on a self-service cloud platform that scales without you managing infrastructure. Define your Ruby version, web server, build/deploy hooks, services, and scheduled tasks in a single config file. Push code to create a live isolated environment; merge to ship.

### Configure once, ship Rails anywhere

### Configuration-driven deployment, zero DevOps required

Define your Ruby version, app server, services, and build steps. Need PostgreSQL, Redis, or Elasticsearch alongside your Rails app? Add them with a configuration line. Upsun provisions and networks everything automatically.

### Ruby runtimes with predictable patching

Security patches are applied automatically to your runtime without changing your configured workflow. Use the TARGET_RUBY_VERSION env variable to prevent Bundler version mismatches.

### Rails-ready builds and deploy hooks

Install gems, precompile assets, and run database migrations as part of your normal pipeline. Keep the steps explicit, reviewable, and consistent across every environment.

### Add services as code

Provision databases, caches, queues, and search as part of your project config then connect them through defined relationships, inside the environment’s internal network.

### Deploy and scale Ruby apps your way

### Isolated environments for every branch

Every Git branch gets its own isolated environment, a byte-for-byte clone of production, including your database and services. Test Ruby upgrades, gem updates, or new features without risk. What you test in staging is what you get in production.

### Run Sidekiq and background workers

Deploy Sidekiq, Solid Queue, Resque, or any background processor as a worker container in the same project as your web application. Workers run in separate containers with independent resource allocation.

### Schedule Rake tasks and cron jobs

Run scheduled Rake tasks directly from your configuration. Define cron jobs with standard cron syntax, and Upsun executes them inside your application container, with full access to your code, environment variables, and services.

### Git-native deployment workflow

Push to Git and Upsun builds, provisions, and deploys your Ruby stack automatically. Integrate with GitHub, GitLab, or Bitbucket. Use the Upsun CLI or console to manage environments, check logs, or trigger deployments.

### Observe and optimize Ruby performance

### Built-in continuous profiling for Ruby

Upsun includes continuous profiling for Ruby applications, powered by Blackfire. Identify which methods consume the most CPU and memory in production without adding overhead to your app.

### Monitor

Track CPU, memory, and disk usage across all your Ruby containers in real time with infrastructure metrics. Receive alerts when resources run low so you can scale before issues affect your users.

### Investigate

Branch a production replica into a new environment, then use the Blackfire profiler to investigate performance bottlenecks in your Ruby code. Find slow queries, memory bloat, or inefficient gem usage without affecting live traffic.

### Enforce

Write performance tests for your Ruby methods and service calls. Add performance budgets to your CI pipeline to catch regressions before they reach production. Keep your optimizations optimized.

Documentation

## Full Ruby configuration reference

## Configure Sidekiq and background workers

## Set up continuous profiling for Ruby

## Add services (PostgreSQL, Redis, Elasticsearch)

Enterprise grade Ruby hosting

The enterprise-ready Ruby cloud platform for hassle-free application management. Remove the complexity of managing multiple Ruby applications with Upsun

The Ruby platform for optimized development | Upsun

### [Move faster with the ultimate Python platform | Upsun](https://upsun.com/python)

Python development involves a lot of moving parts. From building, managing, and maintaining complex internal platforms, to connecting tools and people to the right resources, to reliably securing applications. This makes enforcing compliance and environment provisioning moving targets. Preventing your teams from focusing on your APIs and spending a lot more time on things they’d rather not. With the Upsun Python cloud platform, these are things of the past.

# _ Build, iterate, and deploy_ Python application your way

Deploy Python applications on a platform that adapts to how your team already builds. Choose your Python version, use the server you want, manage dependencies with pip, Pipenv, or Poetry, and define everything in Git-backed YAML. Upsun handles the infrastructure layer so your team can focus on shipping and improving the application itself.

### Manage the complexity with standardization

### No more complex app delivery

It all begins with a single configuration file. Define your Python version, dependency manager (pip, Pipenv, or Poetry), and services in a YAML file. Need Redis, PostgreSQL, or any other service? Upsun handles provisioning and networking automatically. Push to Git and your entire stack deploys.

### Standard infrastructure management

Time spent on security patching and version upgrades is time away from developing. On Upsun, you choose the Python runtime version, define your startup command, and run the web server that fits your architecture.

### The choice is yours

Add 15+ services with a line of YAML, and connect your business logic securely within the environment’s internal network. Built-in Redis, RabbitMQ, and PostgreSQL support for every account. Integrated Blackfire.io and managed CDN support accelerate your Python apps, too.

### Environments at any time

Using Git, builds are reused, and data is cloned automatically with byte-for-byte replicas across environments, including your database and services. What you test in development and staging is precisely what you'll get behaviorally in production.

### Ship features faster with built-in GitOps

### Work with the tools you already use

Test your app, custom services, and frontends in isolated environments on one platform. Git-driven workflows reduce the need for internal tooling across packaging, provisioning, and deployment. Upsun replaces a rigid dev-stage-prod path with isolated branch-based environments. Teams can work in parallel. Connect the rest of your CI pipeline and release with more confidence.

### Git

Push code or a configuration file to Git, and watch Upsun automatically configure your infrastructure. Git is the main API. Most operations are performed via simple pushes on GitHub, GitLab, and Bitbucket.

### Command line and local

Manage your projects directly from your terminal. Anything you can do in the Upsun console, you can do with the CLI. Create environments, check logs, SSH into containers, or run commands from the command line.

### Package-management

Use pip, Pipenv, or Poetry, whatever manages your Python dependencies. Builds and deploys are fully customizable. Your dependency lock files ensure consistency across environments.

### Observe and optimize with ease

### Optimize infrastructure and app performance

Integrated continuous profiling shows which Python functions consume the most resources. Monitor CPU, memory, disk usage, response times, and database queries across all environments. Get alerts when resources run low and investigate bottlenecks in isolation.

### Monitor

Access resource usage in real time with infrastructure metrics. Track CPU, memory, and disk usage across containers. Use Blackfire.io APM alerts to spot where and when performance issues affect your Python apps.

### Investigate

Once you identify a problem, branch a production replica into a new environment and use the Blackfire profiler to investigate bottlenecks. Then use the recommendations to reduce resource usage across your business logic.

### Enforce

For every performance improvement, a test can be written tailored for even your most custom functions and service calls. Expand your CI pipeline to account for a performance budget, and eliminate the reintroduction of performance regressions.

### Enterprise-grade infrastructure for Python workloads

### Managed services

Most Python applications need more than an app container. Upsun environments include the services an application needs to run, with managed databases, caches, and search engines added through configuration. That gives teams a cleaner way to build with databases, queues, or multi-service architectures without stitching infrastructure together.

### Global support and deployment

If your organization runs multiple applications with different constraints, Upsun’s multi-cloud lets teams choose the right provider and region for each one while keeping the workflow consistent.

### Deploy AI agents and LangChain applications

Run LangChain agents, custom MCP servers, and AI workloads alongside your Python applications. Deploy multiple apps and services in the same project; your APIs, databases, and AI agents all running together.

### Secure access with fine-grained roles

Upsun offers fine-grained permissions across projects and organizations. Use project and environment-type roles to control access to code, branches, SSH, settings, and actions. Upsun also supports MFA enforcement and single sign-on.

Documentation

## Continuous profiling for Python

## Manage Python versions

## Manage Python dependencies

Enterprise Python: Build, iterate, and deploy your way

Python development has never been simpler with Upsun, the Python cloud platform. Focus more on APIs and less on infrastructure management with us

Move faster with the ultimate Python platform | Upsun

### [The cloud platform for Strapi applications | Upsun](https://upsun.com/strapi)

Strapi gives developers a robust API to power anything from websites to apps to set-top boxes with an extensible, editor-friendly content management system (CMS) interface. Upsun now enables you to deploy new Strapi headless CMS instances on demand, with zero infrastructure investment.

# Launch Strapi with one click

### Open-source headless CMS is the future of digital experience

### Combine Strapi CMS with your favorite front-end

Only our Strapi platform enables you to run Strapi and your front end of choice-from Gatsby to Hugo—in a single project with multiple services and an integrated development workflow.

### Keep an eye on your whole stack

Run your decoupled site end-to-end without worrying about integrating SaaS tools like Contentful. Choose any our Strapi platform’s global hosting regions to keep your content close to your users.

### Batteries Included

Power Strapi with MongoDB or PostgreSQL, out-of-the-box with no add-on costs or multiple hosting providers required. Upsun supports 14 different services at no extra cost, enabled with simple configuration.

Documentation

## Deploy Strapi on Upsun

## Add a database to Strapi

Blog

## Up(sun) and running with Strapi

Launch Strapi with one click

Don't lose your head with application management. Upsun is the Strapi cloud platform designed to take care of application management so you don't have to

The cloud platform for Strapi applications | Upsun

### [The cloud platform for Symfony applications | Upsun](https://upsun.com/symfony)

Upsun has always been the cloud behind Symfony SAS’s SymfonyCloud, providing developers with agile development and an unparalleled developer experience all the way to production—right from the command line. Building PHP microservices, or integrating multiple languages in your projects? Run and manage them together with multi-app support with the Upsun Symfony cloud hosting platform.

# The official _cloud platform for Symfony_

SymfonyCloud powered by Upsun, is the official cloud platform for Symfony, built for repeatable delivery. Start in Git, validate changes in isolated preview environments, and deploy to production without rebuilding DevOps plumbing each quarter.

### Standardize how your team delivers Symfony

### Build and deploy Symfony with built-in automation

SymfonyCloud includes two purpose-built scripts:  symfony-build handles Composer installs, autoload optimization, cache building, and frontend asset compilation. symfony-deploy swaps in the build cache and automatically runs Doctrine migrations.

### Native Symfony CLI integration

The Symfony CLI is your control plane. Every platform command runs as symfony upsun:. Create projects, push code, manage environments, and sync data, all from the same terminal.

### Configure infrastructure in YAML

SymfonyCloud, powered by Upsun, is configuration-driven: your build/deploy hooks, services, and relationships live alongside your code. That means a new team member can reproduce your stack by cloning the repo.

### Symfony-friendly environment variables by default

SymfonyCloud injects service connection variables (like DATABASE_URL and MAILER_DSN), so Symfony conventions work across environments without manual wiring.

### Develop faster with production replicas

### Complete data preview for every branch

Spin up a complete copy of production: database, services, configuration. Test migrations against real data. Validate cache behavior with production-like traffic patterns. Merge when you're confident. Each environment gets its own URL, so you can share progress with reviewers, QA, or stakeholders directly.

### Debug in isolation

By default, SymfonyCloud runs your environments in production mode, so previews behave like the real thing. When you need to debug, you can temporarily switch a branch into debug mode and switch it back when you’re done.

### Sanitize production data in preview environments

When you clone production data into a preview branch, SymfonyCloud provides a Symfony + PostgreSQL sanitization workflow to strip PII before reviewers or testers access the environment.

### Work locally with DDEV or Symfony server

You can run Symfony locally while connecting to service containers from an active Upsun environment (“tethered” workflow). This keeps your local loop fast while staying close to deployed reality.

### Enterprise-ready Symfony infrastructure

### SensioLabs and SymfonyCloud

SensioLabs is the enterprise arm of SymfonyCloud, supporting architecture workshops, migration planning, and performance reviews. SymfonyCloud, powered by Upsun, provides the platform: multi-cloud deployment, managed services, Blackfire observability, and automated operations.

### Deploy where your users are

Run your Symfony apps on AWS, Google Cloud, OVHcloud, Microsoft Azure, or IBM Cloud across multiple regions using the same configuration-driven workflow, then pick regions based on latency, data residency, or sustainability goals.

### Add managed services

Add services your Symfony app depends on, including databases, caches, search engines, message brokers, and more. Define them in YAML, push, and SymfonyCloud powered by Upsun, provisions them with connection details that are injected automatically.

### Blackfire observability for performance work that sticks

Built-in Blackfire integration gives your team continuous observability across every environment, including APM, profiling, alerting, and performance testing. Pinpoint slow transactions, compare profiles, and catch regressions.

Documentation

## Deploy Symfony on SymfonyCloud powered by Upsun

## Symfony integration

## Symfony environment variables

## Symfony CLI tips

Enterprise Symfony for the future

Experience the best Symfony developer experience with the Upsun Symfony cloud platform engineered to make Symfony application management simple

The cloud platform for Symfony applications | Upsun

### [The cloud platform for Django applications | Upsun](https://upsun.com/django)

Python development involves a lot of moving parts. From building, managing, and maintaining complex internal platforms, to connecting tools and people to the right resources, to reliably securing applications. This makes enforcing compliance and environment provisioning moving targets. Preventing your teams from focusing on your APIs and spending a lot more time on things they’d rather not. With our Django cloud platform, these are things of the past.

# Deploy and scale _Django_ applications without managing infrastructure

Push your Django code, and Upsun handles the rest: PostgreSQL provisioning, automated migrations, static file serving, and production-grade deployments. Get isolated preview environments for every Git branch, with your full database included.

### Standardize Django deployments in one workflow

### Run Django with your preferred server

Run Django behind Gunicorn for WSGI, or go ASGI with servers like Daphne, Uvicorn, or Hypercorn configured in your app definition. You keep your framework structure; Upsun provides the runtime and deployment model.

### Use your preferred Python package manager

Deploy with Pip, Pipenv, or Poetry. Your build and install steps remain explicit and version-controlled alongside your app code.

### Automated migrations and static files

Run your migrations and static commands automatically during deployment via configurable build and deploy hooks. Define exactly what happens at each stage.

### Add managed services

Upsun provisions the database, exposes connection credentials as environment variables, and handles backups. Need Redis for caching or Celery? Add it the same way.

### Preview environments and safe deployments

### Test every change with production data

Every Git branch on Upsun creates a complete, isolated environment: your Django application, a PostgreSQL database (with real production data cloned), Redis, and workers. Your team reviews pull requests on fully functional URLs.

### Branch-per-feature environments

Each branch gets its own Django app, database, and services. Reuse builds and clone data automatically so each change can be validated in its own environment without teams colliding or sharing fragile staging setups.

### Sanitize data in previews environments

Sanitize the preview environment data using automated database sanitization. Run a custom script that strips sensitive data from every preview branch.

### Runtime operations for management commands

Run manage.py commands on-demand without triggering a full redeployment. Define runtime operations for tasks such as data backups, cache clearing, or custom management commands, accessible from the CLI or console.

### Operate and scale Django with visibility and control

### Observability built into the workflow

Identify slow views, expensive ORM queries, and memory leaks with built-in Blackfire profiling. Trace performance issues across your Django application without having to install third-party APM tools.

### Scale when demand spikes

Upsun runs your Django application on dedicated containers with configurable CPU, memory, and storage. Scale vertically or horizontally as your traffic grows. Automatic scaling kicks in during traffic spikes.

### Background workers and cron jobs

Run Celery workers, scheduled tasks, and background jobs alongside your web application in separate containers. Each worker gets its own resources and lifecycle, independent of your web process.

### Multi-cloud deployment options

Deploy your Django application across major cloud providers (AWS, IBM, Google Cloud, Azure, OVHcloud). Choose the region closest to your users, or deploy across multiple providers.

Documentation

## Deploy Django on Upsun

## Python web servers (Gunicorn, Daphne, Uvicorn, Hypercorn)

## Sanitizing PostgreSQL data for Django preview environments

## Runtime operations for Django management commands

## Database sanitization for PostgreSQL

Blog

## Django deployments without downtime

## Building async pipelines with FastAPI and Celery on Upsun

Operational maturity for Django

Upsun is the Django cloud platform engineered to take care of your Django multi-application management so you don't have to. Move faster with Upsun

The cloud platform for Django applications | Upsun

### [The cloud platform for Laravel applications | Upsun](https://upsun.com/laravel)

Laravel is one of the fastest growing PHP frameworks today. Built for PHP 8.0+ with an elegant command-line driven workflow - it’s the perfect match for the Upsun Laravel platform.

# Deploy Laravel without the _infrastructure bottleneck_

Running Laravel in production needs reliable environments, background job processing, scheduled tasks, caching, and tools to debug performance before problems reach users. Upsun brings these parts together in one platform built for modern application delivery,  so your team can move from commit to production with less friction.

### Built for real Laravel workloads

### Consistent configuration across environments

Upsun keeps runtime settings, services, routing, and build logic in Git, so your team can ship from a repeatable baseline rather than a stack of one-off fixes. Define your app, deploy from Git, and keep application and infrastructure changes together.

### Environment variables that fit Laravel’s configuration

Upsun maps connected services to your .env file automatically. Database, cache, and queue connections are available where Laravel expects them with less manual wiring.

### Add managed services

Add Redis, PostgreSQL, RabbitMQ, or any managed services in your config file. Upsun provisions, connects, and secures each service on the environment’s internal network.

### Run Horizon as a dedicated worker

Run Horizon as a separate worker container so queue processing doesn’t compete with your web process. Expose the Horizon dashboard in your Laravel app when needed.

### Ship features faster with preview environments

### Preview environments with cloned data

When you branch an environment, the new one can inherit data, services, and routing configuration from its parent. That means your team can test Laravel changes in production-like environments instead of relying on less realistic staging setups.

### Preview and debug without affecting production

Each environment is isolated, so bug fixes and infrastructure changes are validated away from the live app. Inspect environments, view activity, and troubleshoot deployments from the Console or CLI.

### Run scheduled tasks the Laravel way

Run Laravel’s scheduler via cron or as a dedicated worker with options to control behavior by environment type. No external scheduler required.

### Manage your Laravel project from the terminal

Create environments, stream logs, SSH into containers, and inspect recent activities directly from the command line. Upsun supports terminal operations in addition to the web console.

### Observe and optimize with Laravel-native tooling

### Blackfire included

Upsun includes integrated Blackfire.io for Laravel performance profiling. Profile Eloquent queries, middleware, queue jobs, and third-party API calls. Set performance budgets and get alerts on regressions, with 60+ PHP metrics available out of the box.

### Catch regressions before they hit users

Make performance part of delivery. Blackfire supports custom performance tests and automated builds, so profiling becomes a repeatable check in your delivery pipeline.

### Use Telescope in non-production environments

Enable Telescope and APP_DEBUG per environment, production defaults to off, non-production overrides as needed. Inspect requests, queries, jobs, cache operations, and scheduled tasks without exposing debug tools in production.

### Share logs when something breaks

Upsun keeps activity logs for deployments, cron runs, and variable updates, and these logs can be opened in the Console or CLI and shared with your team.

### Operate Laravel with stronger controls

### Control access by project and environment type

Upsun supports project and environment-type permissions so organizations can apply and audit who can do what across different environments.

### Add security controls

Upsun supports MFA and SSO, and its security docs also cover project isolation. Customer environments are isolated using namespaces, seccomp, and cgroups, with only a small set of incoming ports exposed behind the firewall.

### Keep Laravel delivery fast without losing control

Git-based delivery, isolated environments, managed services, dedicated workers, scheduled jobs, observability, and access controls in one platform. Less platform glue. More time shipping application.

Documentation

## Deploy Laravel on Upsun

## Blackfire for Laravel

## Environment variables

## Cron jobs and scheduler

Enterprise Laravel hosting

Build, run, and scale your Laravel applications fasters with more flexibility and control with the Laravel cloud platform you've been looking for

The cloud platform for Laravel applications | Upsun

### [The cloud platform for Drupal applications | Upsun](https://upsun.com/drupal)

Deploying Drupal? How about a custom distribution like Opigno, GovCMS, or Contenta? Looking to decouple with Next.js or Gatsby? You can build, manage, optimize, and evolve them all on our Drupal cloud platform.

# Deploy enterprise _Drupal at scale_

Deploy Drupal and Drupal CMS on a cloud platform built for your workflow. Every branch gets its own live preview that matches production, so reviews happen in real environments, and releases don’t drift.

### Ship Drupal with consistent builds and config

### Drupal-ready stack in one config

Upsun fits standard Drupal workflows: Composer builds, Drush automation, read-only containers, and explicit writable mounts for files and runtime paths. You control what changes at runtime, so environments stay consistent and reproducible.

### Repeatable Composer builds

Upsun runs composer install during the build, pulls Drupal core, modules, Drush, and packages, then produces a clean, read-only image, no vendor directory in Git and no build scripts to maintain.

### Add managed services

Add services like MariaDB and Redis with a few lines of YAML. Upsun provisions them, injects credentials as environment variables, and keeps service-to-app on a private internal network.

### Built-in cron scheduling

Define Drupal cron, and queue processing directly in your configuration. No external schedulers. Background maintenance remains predictable across all environments.

### Every branch is a full-stack Drupal environment

### Full-stack environment cloning

Every Git branch gets its own complete environment. A byte-for-byte replica of production, including the database, files, and Redis instance, each with its own URL. Test an upgrade, preview a new theme, or run a content migration in total isolation.

### Sanitize data in preview environments

Preview environments inherit real data, which is powerful and risky. Upsun integrates database sanitization into your deployment workflow. Your team gets real data without exposure.

### Automate what shouldn't be manual

When “update day” arrives, automate it. Upsun source operations can run a Composer-based Drupal core update and commit the updated lock file. Core upgrades are consistent, reviewable, and repeatable.

### Keep configuration and behavior aligned

Set a config sync directory and tune logging per environment (verbose in non-prod, locked down in prod) using environment context; debugging stays easy without leaking detail in production.

### Operate Drupal with confidence

### Visibility into performance and regressions

Track infrastructure metrics across containers (CPU, memory, disk) and use Blackfire profiling to investigate slow requests, Drush commands, and cron runs. Find bottlenecks like N+1 queries, heavy modules, and slow render paths.

### Built-in profiling with Blackfire

Blackfire is included on Upsun accounts for application profiling. Set budgets, trace slow Drupal requests across the stack, and catch regressions introduced by deployments.

### Scale services independently

Adjust CPU, memory, and disk per container, your database, cache, and app scale separately. Add autoscaling for traffic spikes and only pay for the resources you're actually using.

### Collaborate safely across environments

Keep previews isolated, restrict access by role, and manage secrets consistently across environments. Share a branch environment for review without exposing production data.

Documentation

## Deploy Drupal on Upsun

## Go deeper: Drupal and Upsun

## Database sanitization for Drupal

## Automate Drupal core updates

Guide

## Installing CiviCRM with Drupal 11 on Upsun

Blog

## Upsun: A match for modern Drupal development

Case study

## Standardizing complexity: how UTC unified a hybrid web estate on Upsun

## From AI curiosity to production-ready value: extending digital platforms with AI on Upsun

## From DrupalCon keynote to live Upsun demo: the real story of setting up Drupal Canvas with AI

Operational maturity for enterprise Drupal

Host, build, iterate, and deploy your Drupal applications faster at scale with our enterprise-ready Drupal cloud Platform as a Service. Do more with Upsun

The cloud platform for Drupal applications | Upsun

### [The enterprise-ready Golang platform | Upsun](https://upsun.com/go)

The most popular frameworks and fully managed back-end services to seamlessly host your apps all from one Golang cloud platform.

# Ship Go apps faster on a _platform built for speed_

Deploy Go applications, APIs, web services, and workers on a platform built for repeatable delivery. Upsun builds your binary during the Build hook, runs it behind a managed edge proxy, and gives every Git branch its own isolated environment so you can test changes safely before they ever hit production.

### Go is built for speed. Your deployment process should be too

### Go from code to production in minutes

Upsun compiles your Go application during the build phase using Go modules, so your \`go.mod\` and \`go.sum\` are all you need. Define your runtime, build commands, and services in a single YAML config file, push to Git, and Upsun handles the rest.

### Run Go without managing infrastructure

Pick your Go runtime in a single line (type: golang:). Upsun supports current Go versions and applies patch updates over time so you don’t babysit runtime updates in production.

### Managed services, no provisioning

Add managed services (datastores, queues, search, vector DBs, and more) and connect them over the environment’s internal network. Credentials are surfaced via environment variables inside the container.

### Test changes with real data

Spin up an isolated environment for every branch with its own URL, Go binary, services, and configuration. Use it to validate upgrades, dependencies, schema changes, and config edits without risking production.

### Innovate faster and experiment

### Faster Go development, built for services

Run microservices, APIs, and background processes with the same delivery pattern across environments. Develop in parallel, test integrations early,  without inventing internal platform tooling just to keep environments consistent.

### Git

Push code and config to deploy. Your changes are reviewable, auditable, and repeatable. That means your build steps, routes, service definitions, and environment behaviors can be versioned and rolled out safely through your normal Git workflow.

### Command line for everything

The Upsun CLI mirrors the Console so you can run day-to-day work from your terminal: manage environments, stream logs, and open an SSH session into running containers for debugging. Sync data between environments for realistic testing.

### Go toolchains that keep up

If your go.mod requests a newer toolchain, the go command can auto-download the requested toolchain. Still: keep the Go version in YAML current so your base runtime stays up to date.

### Observe and optimize with ease

### Integrated continuous profiling for Go

Upsun includes continuous profiling powered by Blackfire, available directly from the Console. For Go applications, profiling runs across six dimensions: CPU time, allocations, allocated memory, goroutines, heap live objects, and heap live size.

### Monitor

Live metrics for CPU, RAM, and disk usage are available for every app, service, and worker container across all environments. Overlay deployment activity on your metrics graphs to correlate releases with performance changes.

### Investigate

Upsun supports horizontal autoscaling out of the box. Set CPU or memory thresholds, define min and max instance counts, and Upsun automatically adds or removes instances as loads change.

### Enforce

Turn performance into a deliverable. Set budgets for latency, throughput, memory, CPU, and allocations, then use continuous profiling to catch regressions early. Track trends over time so improvements stick, release after release.

Documentation

## Go language support on Upsun (versions, build + start config)

## Continuous profiling for Go

## Upsun devcenter: Go 1.24 overview

Build, run, and scale your Go applications

Build, run, and scale your Golang apps effortlessly with Upsun, the Golang cloud platform you've been searching for

The enterprise-ready Golang platform | Upsun

### [The Java platform for optimized workflows | Upsun](https://upsun.com/java)

The most modern Java frameworks and product management tools - and fully managed back-end services-to seamlessly host your apps all on one Java cloud platform.

# Deploy and scale Java apps _without the infrastructure overhead_

Deploy your Java applications on a platform built for the JVM. Whether you run Spring Boot, Quarkus, Micronaut, or Jakarta EE, Upsun handles provisioning, scaling, and infrastructure automatically. Define your Java version, build process, and services in a single configuration file. Push to Git and Upsun builds, provisions, and deploys your entire stack.

### Built for modern Java applications

### Java runtimes and builds

Define your Java version, build tool, and services in a single YAML file. Add managed services like PostgreSQL, Redis, Kafka, Elasticsearch, or OpenSearch, and Upsun wires them to your app through relationships and environment variables.

### Supported versions and security patches

Upsun supports OpenJDK versions (headless packages to reduce unused GUI components). You select the major version; Upsun applies the latest compatible minor and periodically updated patch versions when you deploy.

### Build with your existing tools

Upsun runs your build process during deployment and launches your application with the start command you define in your configuration. With support for Kotlin, Groovy, and Scala, alongside any compatible build tool.

### Commands that match platform reality

Upsun expects your web process to bind to the provided PORT environment variable (for example, --port=$PORT). This keeps behavior consistent across environments.

### Managed services + Git-driven environments

### Isolated environments for every branch

Using Git, builds are reused, and data is cloned automatically with byte-for-byte replicas, including your database and services. What you test in staging is precisely what you get in production.

### Monoliths, microservices, or both

Deploy a single Spring Boot monolith or a full microservices architecture. Upsun supports multiple applications per project using Maven modules, Gradle multi-project builds, or Git submodules.

### Ship with Git-based deployment

Skip building internal deployment tooling. Push to Git and Upsun handles provisioning, environment creation, and deployments. Use the CLI, web console, or integrate with your existing CI pipeline on GitHub, GitLab, or Bitbucket.

### Command line and local development

Manage your projects directly from your terminal. Anything you can do in the Upsun console, you can do with the CLI. Create environments, check logs, SSH into containers, or run commands, all from the command line.

### Observe and optimize Java in production conditions

### Optimize JVM performance with integrated profiling and metrics

Continuous profiling is enabled by default for Java on Upsun. Monitor CPU time, wall-time, and heap allocation across all environments from the console. Track memory usage, response times, and get alerts when resources run low.

### Investigate

Each branch runs in its own isolated environment with the same configuration and managed services, so you can profile changes under production-like conditions and prove the gains before you merge.

### Monitor

Get a real-time view of your resource usage with infrastructure metrics. Track CPU, memory, and disk usage across all containers. The Java continuous profiler measures three dimensions: CPU time, wall-time, and heap memory.

### Enforce

Write performance tests for your Java functions and service calls. Add performance budgets to your CI pipeline to catch regressions before they reach production. Ensure optimizations stay optimized.

Documentation

## Java on Upsun

## Migrating Java apps to Upsun

## Java application metrics & profiling

## Add managed services (Postgres, Redis, etc.)

## Environments & branching workflows

Enterprise-grade Java hosting

Build and scale Java applications with Upsun, the Java cloud platform. An all-in-one PaaS including microservices: Spring Boot, JakartaEE & Spring MVC

The Java platform for optimized workflows | Upsun

### [PHP hosting on Upsun: deploy with Git-driven environments | Upsun](https://upsun.com/php)

Leading the pack in PHP development and delivery. We’re the chosen cloud solution behind Symfony, Magento, eZ Systems, and Drupal Commerce. Building PHP microservices, or integrating multiple languages in your projects? Run and manage them together with multi-application support in every Upsun project.

# _Deploy and scale PHP_ applications in minutes on Upsun

Run PHP applications with the controls you need: dependency builds, runtime settings, and performance tuning without stitching together infrastructure and deployment scripts. Go from push to production faster, with security built in.

### Standardize PHP builds and configuration across environments

### Repeatable builds, predictable releases

On Upsun, your configuration lives in Git. That means your runtime, build steps, web routing, and service wiring are version-controlled and repeatable. Specify your PHP version (8.2-8.5), enable extensions, and define your services in a single .upsun/config.yaml file.

### Composer builds, your way

Upsun uses Composer 2.x by default and applies a standard production build during deployment. Use lock files for reproducible installs, configure authenticated private repositories, and customize the build through hooks when you need more control.

### Configuration that matches your stack

PHP delivery breaks when environments drift: extensions differ, settings change, and “quick fixes” pile up. Standardize the runtime and settings your application needs so the same baseline applies to every environment.

### Built for the PHP ecosystem

Use production-ready PHP patterns: dependency builds, environment-specific configuration, background work, caching, and database migrations. Upsun supports common PHP architectures across frameworks, CMSs, and custom apps.

### Blackfire included

### Built-in profiling, monitoring, and alerting for PHP applications

Upsun includes native integration with Blackfire.io, purpose-built for PHP performance. Use continuous profiling to see which functions consume CPU and memory over time, and validate performance across environments, not just in one-off tests.

### Monitor

Track application performance signals and container resource usage across environments. Use monitoring/APM to identify slow endpoints, heavy code paths, and inefficient queries. Issues are visible before they become user-facing.

### Investigate

Reproduce issues safely in an isolated environment, then profile to trace bottlenecks down to specific PHP functions and SQL queries. Validate fixes without touching the live site.

### Enforce

Turn performance into a standard. Add performance tests and budgets to CI to catch regressions before production. Keep optimizations intact as the codebase evolves.

### Ship features faster with Git-based delivery

### Work with the tools you already use

Skip building internal deployment pipelines. Push changes, and Upsun handles builds, environment creation, and deployments. Use the CLI, web console, or connect Upsun to your existing CI workflow. GitHub, GitLab, and Bitbucket integrations are supported.

### Git-based deployment

Git is the trigger for builds and deployments. Push code or configuration changes, and Upsun builds your application, provisions required services, and routes traffic. Each branch can run in an isolated environment with its own URL.

### Command line and local development

Manage projects from the terminal: create environments, stream logs, SSH into containers, and run commands on a live environment for debugging and verification. Workflows are available in the console and CLI.

### Flexible resource management

Control CPU, memory, and disk allocation per container. Start with sensible defaults, then tune allocations as you learn real usage patterns. Scale resources up or down without rebuilding your delivery process.

### Run PHP your way: PHP-FPM or FrankenPHP

Choose the execution model that fits your application.

### PHP-FPM by default

Apply PHP settings per environment and tune OPcache based on how your application behaves under load. When needed, move beyond defaults into deliberate tuning (including preloading) without rewriting your platform setup.

### FrankenPHP for performance tuning

FrankenPHP embeds PHP directly into the server and supports worker-based execution models that can reduce per-request overhead. It’s a strong option when you understand the lifecycle tradeoffs and want to push throughput or simplify the server model.

### Turn extensions on (or off) explicitly

PHP stacks depend on specific extensions. Upsun supports enabling and disabling extensions as part of configuration, so you avoid “works locally” mismatches between environments.

### Run background work alongside your app

Deploy queue workers, scheduled tasks, and cron jobs in the same project as your web application. Run Laravel Horizon, Symfony Messenger consumers, or Drush cron alongside your PHP app with dedicated worker containers that scale independently.

### Enterprise-grade security and governance

### Security controls that scale with your team

PHP applications often face a broad attack surface. Upsun helps you apply consistent security guardrails across environments, teams can move fast without relying on ad-hoc scripts and one-off configurations.

### Environment-level protection by default

Apply platform-level controls consistently across environments to reduce common exploit paths and keep standards stable as your footprint grows.

### Role-based access control

Control who can deploy, change configuration, and access environments. Improve traceability with clear ownership and visibility into operational actions.

### Test security patches in isolation

Validate changes in isolated environments before promotion so security fixes and dependency updates can be tested without impacting production until you’re ready.

Documentation

## PHP docs (runtime settings, extensions, variables)

## PHP performance tuning (OPcache/preload)

## FrankenPHP on Upsun

## Add services overview

Enterprise-grade PHP hosting

Deploy PHP apps with repeatable builds, isolated preview environments, and performance controls. Configure runtime, dependencies, routes, and services in code and ship changes faster with security built in.

PHP hosting on Upsun: deploy with Git-driven environments | Upsun

### [The cloud platform for Next.js applications | Upsun](https://upsun.com/nextjs)

As your organization and applications evolve to include more frameworks, Next.js development gets increasingly complex. This means more time spent managing relationships between vendors and environments, and less time available for innovation and code development. Well, with our Next.js cloud platform - that problem is solved. Package, provision, and deploy everything from one platform - for every app and language.

# Ship your _Next.js_ applications on a secure and reliable platform

Deploy Next.js apps with server-side rendering, static generation, and API routes on a platform designed for production workloads. Upsun handles infrastructure provisioning, managed services, and scaling. You focus on building while we handle the infrastructure.

### Next.js hosting built for production

### Define your stack in one config file

Define your entire stack in a single YAML file checked into your repo. Upsun reads your configuration and provisions everything: your Node.js runtime, build pipeline, services, routes, and cron jobs. No separate infrastructure tooling required.

### Automatic Node.js version and security updates

Specify your Node.js version in your config line. Security patches are applied automatically in the background without requiring redeployment. When you need to upgrade, change the version number and push. Upsun handles the rest.

### Managed services, no separate tooling

Connect PostgreSQL, MySQL, Redis, MongoDB, OpenSearch, or any managed services by adding a few lines to your config file. Upsun provisions, configures, and maintains each service.

### Run on the cloud and region you choose

Run your Next.js applications on AWS, Google Cloud, Microsoft Azure, OVHCloud, or Orange Cloud. Choose a region that meets your latency and compliance requirements. Switch providers without changing your application code.

### Preview environments that match production

### Complete environment for every branch

Open a pull request or create a branch, and Upsun spins up a complete environment: your Next.js app, connected services, and production data. Each environment gets its own URL. Test SSR pages, API routes, and middleware against real infrastructure

### Git-driven workflow

Use normal Git workflows to push changes. Upsun supports a Git-based workflow via integration. Push code or update your config file, and your cluster rebuilds and deploys automatically. Deployment is “just push,” without extra platform scripting.

### Customize every stage of build & deploy

Build hooks run npm install and next build during the build phase. Deploy hooks handle database migrations and cache warming after the container starts. Post-deploy hooks run tasks like content imports while the app accepts traffic.

### Built-in multi-app support

Next.js apps rarely run alone. Split frontend and backend cleanly, for example, Next.js as the client with another app providing data. Upsun lets you define multiple applications in the same project, configure and deploy them together.

### Scale and observe your Next.js applications

### Scale resources without redeploying

Adjust CPU, memory, and disk for your Next.js container and each connected service directly from the Console or CLI. No redeployment required. Pay only for the resources your app actually uses.

### Real-time infrastructure and application metrics

Track CPU, memory, and disk usage across all your containers in real time. Upsun’s infrastructure metrics give you visibility into every environment, including your preview branches.

### Centralize logs when you need to

Forward application and access logs from any environment to your existing observability stack. Send logs to syslog endpoints, HTTP destinations, or third-party services to standardize troubleshooting across teams and environments.

### Reproduce issues safely

When you need to investigate, create an isolated environment that mirrors production behavior, then profile and validate changes without risking live traffic

Documentation

## Deploy Next.js on Upsun

## Node.js configuration

## Build and deploy a hook

## Node.js continuous profiling

## Getting started with Next.js on Upsun

Unified delivery for Next.js+

Take your multi-application management to the Next(.js) level. Upsun is the Next.js cloud platform to build, run, and scale your applications faster

The cloud platform for Next.js applications | Upsun

## Case Studies

### [Califrais successfully digitizes Rungis Market | Upsun](https://upsun.com/blog/califrais-digitizes-rungis-market/)

# Califrais digitizes Rungis Market via SymfonyCloud

As a leading food wholesaler and major player in the food supply chain, Rungis Market seeks to satisfy its professional customers by digitizing solutions. To do this, it called upon Califrais, which modeled itself after SymfonyCloud, to implement a brand-new ecommerce website, rungismarket.com. Here's the story of a future-forward company’s digital transformation and its big plans for the future.

## Challenge

For the past eight years, Rungis Market's startup Califrais has been using machine learning and other innovative digital tools to optimize large-scale food logistics flows. Machine learning involves highly innovative artificial intelligence algorithms developed in-house in collaboration with academic institutions such as the French National Center for Scientific Research (CNRS), Sorbonne University, and Paris Cité University.

Today, Califrais is in charge of the new ecommerce website rungismarket.com, which consolidates the wholesalers of the Rungis Market in a whole new way. Califrais  has partnered with the STEF Group to handle the transportation side, and with Webhelp to optimize customer management. The new service lets B2B customers place a single order for all their fresh produce from Rungis Market, and they can receive a delivery in record time, with competitive prices and unmatched reliability. These features are part of the process to accelerate Rungis Market’s digital transformation.

Given the complexity of Rungis Market's activity (such as the preparation and grouping of extremely large orders by multiple suppliers in very little time), a custom ecommerce platform had to be developed, along with new logistics tools adapted to the specific demands of a wholesale food market.

Despite these unique challenges, Califrais was able to develop the project with Symfony directly on SymfonyCloud, without the need to rely on a DevOps resource.

## Solution

After an in-house development phase, Califrais benchmarked and tested many cloud hosting solutions, including SymfonyCloud and AWS. At the end of the day, the company went with SymfonyCloud. 

> Renaud Grand, CTO of Califrais, explains: “Even if we had done a lot of work on Kubernetes, it would have been less flexible and practical for us than SymfonyCloud. We also couldn't deny the advantages provided by GitHub integration and pull requests for pre-production environments. At the moment, we spend less than an hour per week on Ops. This would have been unthinkable with an in-house solution.”

  
The use of SymfonyCloud has improved productivity. 

> "The time we save on the maintenance and upgrading of the infrastructure is now spent on development," Grand adds. Another major advantage? Califrais can now catch its breath between the deployment phase and the release.

However, there was another factor that shaped the startup's decision to choose SymfonyCloud.

> "Califrais is a responsible company with strong CSR goals: thanks to the optimization and grouping of Rungis Market workflows, we expect to save 30,000 tons of CO2 by 2024,” Grand explains “Above all, we wanted high-density hosting from a host committed to reducing its carbon footprint and aligned with our convictions. SymfonyCloud identifies data centers according to their carbon footprints and provides full transparency on our own emissions." 

## Results

Six months and more than 10,000 deliveries later, the digital transformation is well underway—and highly successful thanks to SymfonyCloud, which will continue to assist the Califrais team in all its future endeavors. And it will be there for the inevitable surge ahead.

### [Chromatic's APP management for Segal Benz | Upsun](https://upsun.com/blog/chromatic-website-fleet-segal-benz/)

# Chromatic delivers unique website fleet approach for HR firm Segal Benz

Challenge: To accelerate multisite development, silo proprietary client HR data, and reduce site build and maintenance costs

Solution: A single, unified code base for all Segal Benz client sites—hosted on Upsun as a fleet of independent projects—that streamlines Platinum agency partner Chromatic’s workflow and speeds project development and deployment

Stack: Drupal, multi-app

Results:

###### For agency partner Chromatic

-   20% reduction in build and maintenance time and costs
-   Gained development efficiencies by migrating 22 Drupal projects to Upsun, freeing staff to focus on adding more value to client projects
-   Can more rapidly build, test, and deploy new features—even during busy, seasonal, open-enrolment periods

###### For Segal Benz

-   Can choose from an à la carte set of features and functionality for each uniquely designed site—all managed securely on a single unified platform
-   Tapped into new revenue streams by creating a simplified offering for clients with limited resources or less complex site requirements
-   Improved security and decreased ongoing maintenance requirements

---

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

### **Collaborators with benefits**

Support for mental health. Wellness programs. Flexible work schedules. A commitment to diversity and inclusion. As organizations become more focused on employee experience, human resources consulting firms like Segal Benz are proving their worth.

The Bay Area firm helps clients from top industry organizations align employee benefits with business results through dedicated websites and portals where employees can access educational content and resources. These resources empower staff to take full advantage of their benefits to improve their health and manage their finances. 

Upsun Platinum agency partner Chromatic acts not only as Segal Benz’s web developer, but also as strategic partner and advisor. The two joined together at a time when both organizations were “small potatoes,” says Chromatic President Chris Free, and have grown together over the years through many collaborative projects. 

The two organizations have a shared belief to put people first; Chromatic prioritizes building a positive workplace for their entire team. “We’re an organization that cares deeply for one another,” says Free. “We focus a lot of our attention on making sure that people are seen and heard and that they can do their best work.”

### **Better, faster, more efficient website development**

With a significant number of Drupal projects in Chromatic’s portfolio, including magazine sites like _Parents_, _Shape_, _Martha Stewart,_ and _Outside Magazine_, Segal Benz’s projects (usually on Drupal) were a logical collaboration. 

As Segal Benz added more clients to its roster, the Chromatic team realized DevOps work had become a large portion of their partnership—work that wasn’t delivering visible impact. As they began another collaborative Drupal project, the Chromatic team also recognized they were unnecessarily duplicating efforts. 

“We were essentially reinventing the wheel every time we built a new one of these sites,” says Chromatic Chief Technology Officer Mark Dorison. Instead, Chromatic could better support Segal Benz’s vision of selling, creating, and rolling out a large number of sites by taking an entirely different approach. “We reached a critical point,” says Dorison. The Chromatic team knew migrating to Upsun would gain newfound efficiencies.

### **Zooming in on client value**

Prior to moving to Upsun, every new Segal Benz site required another set of servers. By migrating projects to Upsun, “we greatly reduced the amount of time that we were spending on DevOps for each of these sites,” says Dorison. Now the Chromatic team can focus on quickly creating value by developing new features and capabilities for Segal Benz that make an impact for all their clients.

> “We shouldn't be spending that much time managing infrastructure. So it just made so much sense from a developer's point of view to move to Upsun; it also made sense from a client's point of view. Upsun just checked all those boxes.”
> 
> **\- Chris Free**  
> President  
> Chromatic

### **Client privacy on a single code base**

Historically, each of Segal Benz’s end clients had used completely independent QA and production servers, with different resources and configuration. Chromatic wanted to retain that partition to keep each end-client’s proprietary organizational information separated. 

“We didn't want to lose any of that in the transition,” says Dorison “So it was essential—or at least a very high priority—that we were able to silo those things completely.” It was decided that using a single code base, but housed within independent Upsun projects for every client, delivered an ideal balance of both security and scalability.  

### **Clearer roles and responsibilities**

Upsun has taken a “big mental burden” off the Chromatic team—a relief that extends to the team at Segal Benz, too. The Chromatic team continues to develop Segal Benz applications, including new features and experiences; Upsun takes care of uptime and maintenance. Available Upsun direct support enables Segal Benz to create their own Upsun tickets, as needed—resulting in faster resolution when issues arise. This distribution of duties removes Chromatic as a middle-man and better delineates the partners’ roles and responsibilities.

### **Keep rolling through seasonal peak demands**

Beginning in the fall and leading into the new year, Segal Benz’s busy season or _open enrollment_ opens a window for employees to elect to adjust current benefits plans or enroll in their employee plan for the first time for the following calendar year.

Prior to the Upsun migration, high demand for availability during the Segal Benz enrollment period prompted the Chromatic dev team to focus on other projects, saving any new Segal Benz feature work and deployments until enrollment came to a close. With Upsun, the Chromatic team can easily and confidently work throughout open-enrollment peak demand. “We can spin up environments in minutes, run tests, and review revisions/changes in staging, so they’re ready to be deployed,” says Dorison. 

> "Allowing Chromatic and Upsun to do what they do best has really freed us up to put our time and effort into delighting our clients—which makes everyone happy!"  
> **\- Kristin Thompson**  
> Sr. Consultant, Technology  
> Segal Benz

### **Unlocking efficiencies to benefit teams**

Nearly 10 years and 75-plus projects later, the partnership between Chromatic and Segal Benz is stronger than ever. The two agencies continue to collaborate on Drupal projects, with a vision of selling, creating, and rolling out a large number of these sites going forward and an opportunity for more features to be layered on. For now, “we’ve built a powerful, scalable system that unlocks a ton of value and efficiencies for our team and theirs,” says Free—looking forward to a continued collaboration, with a healthy future.

### [UTC case study: Unifying Drupal and WordPress on Upsun | Upsun](https://upsun.com/blog/university-tennessee-chattanooga-upsun/)

# Standardizing complexity: how UTC unified a hybrid web estate on Upsun

Challenge: The University of Tennessee at Chattanooga was operating a hybrid web estate: Drupal hosted with a vendor, plus WordPress and custom PHP on-prem with different workflows and reliability. That split added maintenance work like patching and reboots, and made downtime more painful during high-visibility campus moments.

Solution: UTC consolidated Drupal, WordPress, and PHP on Upsun to run the entire web estate on one cloud application platform with a consistent deployment and environment model. Upsun stood out because it supports multiple application types and fits how the team ships changes with Git-based workflows and safer testing through branch environments.

Stack: Drupal, WordPress, multi-app, DevOps, migration

Results:

-   Unified Drupal, WordPress, and PHP under one operational model.
-   Reduced infrastructure toil by moving high-traffic production off on-prem.
-   Improved confidence during traffic spikes and incidents, with platform stability holding steady post-migration.
-   Better value at similar spend by expanding hosting coverage beyond Drupal.

---

### **Outages across a hybrid web estate became the tipping point**

When a university website goes down, it is instantly visible and disruptive. For The University of Tennessee at Chattanooga, that risk was amplified because the web estate was split across environments: the Drupal site followed one hosting model and workflow, while WordPress and PHP applications lived elsewhere with different operating assumptions.

The practical problem was not only complexity, it was time. On-prem workloads meant the team still had to own the “keep it running” tasks such as patching and reboots, which competed directly with work that improves the student and stakeholder experience.

The turning point came after downtime on both the hosted and on-prem sides. In the team’s words, those incidents were the signal that the status quo was no longer acceptable and that the estate needed a more resilient, unified approach.

> “We had outages with our existing Drupal-only hosting and with our on-prem hosting. Those were tipping points that pushed us to look for a different solution.” - Chris Gilligan, Senior Web Developer, The University of Tennessee at Chattanooga

### **A rubric-based evaluation led to a solution that goes beyond Drupal**

UTC did not make the decision informally. They ran a committee process with a rubric to compare options, which is critical in higher education where decisions must be explainable and repeatable.

Upsun stood out for a simple reason: UTC needed a single platform that could host more than Drupal. They wanted one consistent operating model across the estate, including WordPress and other applications, rather than stitching together different providers and processes.

From an execution standpoint, Upsun supported the way UTC wanted to work. GitHub integration and branch-based environments made it easier to test changes safely without relying on a single shared staging workflow that becomes a bottleneck.

> “We needed a platform that could host more than just Drupal - WordPress and other apps too - and that was a key reason Upsun stood out. We evaluated multiple options with a committee and rubric, and Upsun consistently came out strongest across the variables we cared about.” - Bridget Hornsby, Director of Web Development, The University of Tennessee at Chattanooga

UTC migrated Drupal first as the most complex workload, working closely with Vardot and Upsun support, then carried those patterns forward into WordPress and PHP migrations. The team valued the fact that the work stayed collaborative rather than disappearing into a “black box,” which helped UTC build internal confidence and reduce ongoing dependency.

### **One platform delivered standardization, less toil, and better value**

The most immediate impact was standardization. Once Drupal, WordPress, and PHP lived on the same platform, UTC could apply one deployment and environment playbook across the estate instead of switching operational modes depending on the stack. That consistency reduces risk during releases and makes it easier to scale the estate without multiplying exceptions.

UTC also reclaimed time. By moving high-traffic production properties away from on-prem hosting, the team reduced the operational burden of server upkeep and the routine work that pulls focus away from continuous improvement.

Reliability improved in the way that matters most for universities: confidence on high-visibility days. UTC referenced a prior traffic spike that caused failure, and noted that post-migration issues they observed were tied more to external dependencies than to Upsun itself. That shifts the team from firefighting to planning, because platform stability becomes a given rather than a constant concern.

Finally, UTC found stronger value economics. They described spend as comparable to their prior Drupal-only contract, but with broader hosting coverage and more included services, which made the overall platform decision easier to justify.

> “Moving to one platform made our workflow more unified, and we’re spending about what we did on our Drupal contract while now also getting hosting for other applications.” - Chris Gilligan, Senior Web Developer, The University of Tennessee at Chattanooga

### **A unified platform that belongs on every university’s shortlist**

UTC’s journey is a practical blueprint for any university team managing a fragmented web estate. The problem was not just “hosting,” it was the drag and risk created by different platforms, different workflows, and uneven reliability across critical public-facing services.

> “We’ve been extremely pleased with the support we receive from Upsun. Their team takes the time to understand our environment, priorities, and the complexity of a large university web ecosystem, offering responsive and thoughtful guidance. Even beyond hosting, their care and partnership reduce uncertainty, strengthen our decisions, and give our team confidence to move forward.” - Bridget Hornsby, Director of Web Development

By consolidating Drupal, WordPress, and PHP onto Upsun, UTC gained a unified cloud application platform, a consistent operational model, and support that showed up when the stakes were highest. The outcome is a web estate that is simpler to operate, easier to scale, and more reliable when the campus is paying attention.

> “If you’re evaluating external hosting, Upsun should definitely be part of your evaluation.” - Bridget Hornsby, Director of Web Development

Running your sites across different platforms costs time and increases risk when things go wrong. We’re here to help you spend less time maintaining hosting and more time improving the student and campus experience. Let's show you what consolidating your web estate looks like on Upsun.

### [Ineris case study: Halve costs and deploy 10x faster | Upsun](https://upsun.com/blog/ineris-case-study/)

# Modernizing public sector infrastructure: the Ineris digital transformation

Challenge: Ineris faced high operational friction due to a traditional outsourced management model built on rigid virtual machines and manual workflows. The lack of automation and staging environments resulted in high "Build" costs and prevented the internal team from focusing on high-value development.

Solution: The institute migrated its Drupal application park to Upsun to implement a modern DevOps and Platform Engineering workflow. By adopting Infrastructure as Code and Git-driven automation, Ineris eliminated manual server management and enabled instant environment cloning.

Stack: GitOps, application modernization

Results:

-   **50% reduction** in build costs compared to traditional outsourced management.
-   **10x faster** delivery speed through automated deployment pipelines.
-   **95% reduction** in migration time for Drupal sites, moving from months to under 1 week.
-   **Complete autonomy** for third-party agencies to deploy and test without DSI intervention.

---

### **The friction of legacy outsourcing**

Modernizing infrastructure within a public institution requires balancing high security requirements with human-sized engineering teams. Ineris (Institut national de l'environnement industriel et des risques) manages a critical application park that demands both resilience and agility. This narrative explores how Ineris transitioned from a laborious "Build" process to a streamlined Platform Engineering model to halve costs while accelerating digital transformation.

Before adopting Upsun, Ineris relied on a traditional "infogéreur" model. This infrastructure was built on virtual machines that were difficult to duplicate, leading to an absence of modern Continuous Integration (CI) tools. Every minor change required a long, rigid process involving multiple actors. The internal DSI team found themselves spending more time managing the provider than producing code.

> "We were in processes that were quite heavy, laborious, and expensive. There was no real automation." — Thomas BARRIERE, DSI at Ineris

### **Standardizing the stack**

Ineris selected Upsun through a technical Proof of Value (POV) to democratize Platform Engineering across their organization. For a DSI with limited headcount, Upsun acts as a force multiplier by providing advanced container orchestration without the overhead of managing Kubernetes clusters.

The migration involved a shift from "classic VM" logic to "Containers as Code." While the initial learning curve involved mastering YAML configurations, the Upsun migration assistance team provided the architectural validation necessary to secure the first batch of sites. Once the initial template was validated, subsequent migrations became a standardized process.

> "Upsun has been a transformation accelerator. It allowed us to do DevOps without the extremely expensive and laborious part of setting up these platforms." - Thomas BARRIERE, DSI at Ineris

### **Technical fluidity and business impact**

The transition transformed the economic model of web management at Ineris. By moving to Infrastructure as Code, the cost to implement new environments was divided by 2. Major version upgrades, such as moving from Drupal 10 to 11, shifted from being expensive, high-risk projects to rapid, routine tasks.

The technical teams report a significant improvement in operational quality through Preview environments. The ability to clone production data instantly to test new features in parallel allows for validation without infrastructure overhead or delays.

> "Once the principle is understood, migrating a site becomes very simple; it is less than 1 week of work." - Adrien Delcourt, Developer at Ineris

### **Eliminating deployment toil**

Ineris has moved from a reactive support model to a proactive partnership. Upsun now functions as an extension of the Ineris team, automatically handling security patches and performance monitoring. This autonomy extends to their third-party partners; web agencies can now deploy and test independently through the Ineris logic forge, freeing internal DSI resources for strategic projects.

Ultimately, Ineris has replaced architectural fear with execution speed. They have achieved a level of automation and delivery fluidity 10x superior to their previous model.

> "We went from a laborious delivery process to a level of automation and fluidity 10 times higher." - Thomas BARRIERE, DSI at Ineris

When your DSI is constrained by rigid outsourcing and rising maintenance costs, you lose the ability to innovate. Upsun serves as the strategic engine that automates infrastructure management, allowing your team to deploy 10x faster while halving operational overhead.

### [O's vision and multiapp strategy for Mentos | Upsun](https://upsun.com/blog/io-platform-multiapp-mentos/)

# iO's platform vision and multiapp strategy for Mentos

Challenge: To eliminate the costs, disparities, and lack of agility associated with managing 100-plus in-country websites on a local level

Solution: Discover how iO built a global digital marketing platform for Mentos, slashing hosting costs by 60% and empowering 50 local markets

Stack: Drupal

Results:

###### For digital agency iO

-   60% reduction in hosting costs
-   Eliminated the need for and costs associated with two DevOps FTE
-   Developed a digital marketing platform that can be replicated for other fast-moving consumer goods clients

###### For Mentos

-   Saves millions of dollars each year by moving to a centralized digital marketing platform
-   Keeps processes and costs manageable and efficient
-   Relieved marketing staff from managing technology to focus on campaigns, content, and customer experience
-   Inspired marketing managers to build a collaborative, global community to share best practices

---

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

## **A formula for generating new business**

It’s probably fair to say few organizations dedicate themselves to becoming obsolete. Yet, striving for obsolescence is just the seemingly quirky purpose that fuels global digital agency iO (formerly Burst). Today, the award-winning, 55-member Netherlands-based team continues to move successfully toward this inevitable conclusion. _How_ iO defines obsolescence has become one of the key factors that sets them apart from the fray.

“We choose interesting projects that will have an impactful footprint,” says iO Founder and CEO Hans Maltha. “By remaining 100 percent focused on client success—building and nurturing platforms that create sustainable models—we help clients create something core to their organizations, profitable, or even a business on its own. Once a platform works, our clients onboard their own people. We even help them recruit their team and transfer our knowledge to them. That’s how we make ourselves obsolete, and we consider that a win. By applying this approach, we’ve found extra business begins to come in from other related channels.”

Part of the formula for generating new business is iO’s BHAG (Big Hairy Audacious Goal): by the year 2030, to have one billion people using one of the digital products they’ve created. Is it aspirational? Yes. Is it achievable? Maltha believes it is. Currently, the agency’s data indicates 175 million users interact with iO products. Their approach and philosophy provide a firm foundation and springboard for every project they undertake.

## **Focus on core business, not on DevOps**

Founded in 2008, iO began its journey like many agencies: managing its own servers, with leased space in a data center. After the first big system crash—which required a one-hour drive on a weekend in the dark of night to simply press a hard-reset button—Maltha decided iO needed to make a change.

iO craftsmen—heroically described as “strong, confident, autonomous thinkers, each who bring determination, passion, and skills to make the exceptional happen for our clients”—found the concept of managed hosting “exciting” and decided on RackSpace to host its client websites. But as hosting services evolved, the iO team felt RackSpace remained static. The traditional RackSpace hosting solution, while “giant,” lacked scalability; iO staff were consumed by DevOps chores like maintenance, configuration, and upgrades.

“To manage RackSpace hosting required in-depth knowledge and skill. And that meant hiring more people,” explains iO CTO Jeroen van den Berg. “We needed to find a solution that could provide greater agility, flexibility, speed, and a modern infrastructure while giving us the ability to offer our European clients a multicloud option to comply with GDPR mandates.” The iO team recognized the cloud provided the scale they needed. And Upsun offered the cloud-based solution and strategic partnership Maltha sought. Moving to Upsun around five years ago, iO removed the investment of two full-time DevOps staff and was able to shift high-value developer resources to building those exceptional client websites and experiences. In the process, Maltha reports faster, flexible Upsun scaling reduced his hosting costs by 60 percent.

Maltha says, “Upsun goes beyond hosting; it's an integrated solution, so we can develop, build, and launch global platforms for our clients in the most efficient, stable, and secure way. We can focus on our core business. When we deploy, everything works.”

## **Mentos: how do you manage a sweet fleet?**

In 2016, when consumer brand Mentos, part of Perfetti Van Melle (PvM) group (one of the world's largest manufacturers and distributors of confectionery and chewing gum), put out a request for proposal (RFP), more than 100 of its websites were managed, hosted, and developed locally—no global infrastructure, no option to manage multiple applications from one place.

Local Mentos managers spent an inordinate amount of time ensuring that all their brand websites across the globe were presented consistently. If, for example, a brand design element required an update, 50 local managers, some of whom managed several countries’ websites, were briefed on the change. Those 50 managers would each alert 50 local agencies to implement and test the revision on every website: a costly process.

When iO responded to PvM’s RFP, Mentos invited the agency to present its solution to a team of global digital managers and a task force of local marketing managers. Competing against agencies from other geographies, iO leadership differentiated themselves by keeping their pitch practical, focusing on the website components the agency would manage at the global level and the freedom and creativity that would be extended to and executed by in-country Mentos marketing staff.

"We proposed that we bring everything together on a single global platform, but give local markets the opportunity to put in their own content, to create campaigns and landing pages leveraging already installed modules, and so on," explains Maltha. “Whenever a large-scale global change might be required, our team would push it within the templates. This multi-application management approach would drive consistency and give Mentos local teams the speed and flexibility they were looking for. I think we won the project because we focused not only on branding or technology, but on the holistic governance model needed to make it all work together."

## **Governance: engage local teams from day one**

During the project’s design and development phase, the iO team reached out to Mentos local managers and made them part of the process. “I think that was one of the biggest wins, because it wasn't our platform,” muses Maltha. “Rather, it was a global platform a lot of people contributed their good ideas to creating.” In the course of their discussions, iO unearthed the “golden balance” between what would be managed globally versus locally. So Mentos teams would be free to focus on marketing initiatives instead of on tedious, granular tasks.

Whenever there's a change to the Google algorithm or new technologies, or updates to the platform’s core technology, the iO team performs those tasks on the global level. Mentos staff can rely on an always-up-to-date, scalable solution and unified approach that maintains security and compliance and eliminates the need for costly site overhauls.

## **A fresh, flexible global platform to reduce costs, increase agility**

The iO team developed a flexible, global digital marketing platform on a Drupal setup that powers more than 100-plus local brand websites, each of which can be customized on a national level. Every participating brand can showcase its own online/offline content, ecommerce, campaigns, and marketing activities by country. This centralized platform approach resulted in a cost saving of millions of dollars per year.

> The Upsun infrastructure enables us to stay ahead of the curve, while keeping our processes and costs both manageable and efficient."
> 
> **Daan Simonis**  
> Global Media & Digital Marketing Director  
> Perfetti Van Melle

Not merely a website, the iO-developed PvM platform serves as the heart of the company’s global digital ecosystem across multiple brands and geographies. iO integrations with PvM’s CRM systems, email service provider, marketing automation tools, and reporting stack enable all digital touchpoints to leverage the platform and gain cost and efficiency benefits—including the ability to move rapidly to adapt to shifts in consumer shopping behavior and paths to purchase.

> "Upsun plays an integral role not only in reducing infrastructure cost, but in our development and in reducing our time to market. Day in and day out. Week after week. Year after year."
> 
> **Hans Maltha**  
> Founder and CEO  
> iO

## **Build a global community of local marketing talent**

iO's 10-person dedicated Mentos squad crosses disciplines, from creative and development to analytics. Instead of benchmarking local sites against competitors, local Mentos marketing managers receive global reports that enable them to measure their performance against peers.

Here are some real-world Mentos scenarios:

1.  The Mentos marketing manager from Country A learns Mentos users from Country B spend twice as much time on site as their users do. The Country A team can open a conversation with the Country B team about their approach, look at their content, understand user interactions, and then put together a plan to improve their user stickiness.
2.  When customers see a Mentos print or broadcast ad, they go to the brand website. That’s the moment they’re thinking about the product. iO’s integrated buy button on the Mentos UK site gives customers the immediate opportunity to place the product in their Amazon.com carts. The button’s success prompted a global rollout.

“Sharing these best practices, virtually and in quarterly meetings, has created a real sense of collaboration and community,” Maltha says. “We can all assess what’s working, what isn’t working, then determine the optimal solution to get the job done.”

The platform benefits from these insights and evolves from customer demand. In the next year, the iO and Mentos teams plan to connect and onboard around 25 more local sites, moving teams away from the constraints of their legacy systems. iO also set up in-house data analytics to provide deeper understanding into customer website behavior.

## **Replicating and extending platform success**

iO has been able to replicate the Mentos success with other fast-moving consumer goods clients in the Netherlands and Europe. “You can replicate it on three different levels,” explains Maltha. “First, in the way we think about the platform. Second, the governance experience, which is nearly always overlooked. Third, all of the nitty-gritty technical details of how to build a localized, scalable platform and what kind of solutions you need to develop. If we want to have one billion people on our products, this repeatable approach is critical.”

The iO team developed an ambitious shared vision with Mentos; they recognized they needed an equally ambitious infrastructure. “We brought in the Upsun team because we knew the only way we could realize our vision was to test, launch, and learn very quickly,” Maltha says. “By developing a modern platform, we’ll never have to do a major rebuild. The most important thing is that we continue to work collaboratively with our clients every day to improve the platform. We’ve done that with Mentos for the last four years, and we plan to continue down that path. Continuing to evolve and translate our vision into a value-added platform also gets us closer to achieving our BHAG!”

## **Reported favorite Upsun features**

-   The ease of setting up multiple environments to test with real website data and to enable clients to review and approve them individually gives our team a single way of working that makes improvements on multiple levels.
-   Automatic data syncing makes it super easy to test branches, accommodating both accurate testing and development.
-   We can test different backends on a frontend environment through our headless architecture.
-   Fully automated backups and SSL.
-   The ability to seamlessly hook up deployment into our GitLab CI, our iO CLI, and other tooling.
-   Logs make debugging faster and easier.
-   Automatic deploys speed the process.
-   Our launch risk is decreased. We now have confidence to launch quickly, knowing we can roll it back quite easily.
-   Easy central hosting config with Infrastructure-as-code.

### [Comic Relief improves web development | Upsun](https://upsun.com/blog/comic-relief-drupal-dev-efficiency/)

# Comic Relief brings laughter and hope to the world—at scale

Stack: Drupal

---

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

In 1985, British writer and director Richard Curtis, philanthropist Jane Tewson, and some of their friends came together with a shared idea and purpose: to raise money and change the lives of those living in Africa and the United Kingdom through comedy. And so, Comic Relief—most commonly recognized for Red Nose Day—was born.

The first-ever Red Nose Day hit the BBC TV airwaves live in 1988, featuring more than 150 celebrities and comedians, and raising in excess of £15 million. Over the years, Comic Relief’s mission—to drive positive change through the power of entertainment—has elevated awareness and raised funds to tackle some of the worlds’ most pressing challenges: homelessness, poverty, rights of the disabled, HIV, elder abuse, and global hunger. In its first 30 years, the organization provided more than £1 billion in grants to deserving charities, crossing the pond to the United States in 2015 to expand its reach even further.

Beyond large-scale, high-profile television events, Comic Relief also sponsors activities and digital campaigns designed to attract, inform, and engage donors. To build and obtain approvals to launch new website features and donor experiences faster, the highly sophisticated Comic Relief technology team needed a robust development platform behind the scenes.

#### **Speed development, improve individual and team productivity**

“In 2017, we went through a difficult technical architecture transformation, moving our legacy websites to Drupal 8 and generally building more engaging campaign websites.” explains Comic Relief Head of Technology Peter Vanhee. “We initially introduced our team to Upsun to create more preview environments, with the goal of iterating more quickly.”

Prior to adopting Upsun, Vanhee’s team had to rely on Comic Relief’s WebOps team to spin up a QA environment or to get changes reviewed on a QA environment, and it took days. The team reviewed multiple features at once, making it more difficult to test and subsequently merge these into a stable branch. More DevOps and QA resources were required to manage the process.

Now, through Upsun GitHub integration, the process is automated. Every feature gets its own environment—hugely beneficial if you have multiple developers working on multiple features at the same time. At peak times of development, Comic Relief’s feature branch usage can be up to 20 branches and associated environments.

> It’s been said that the best tools are the ones that fade into the background and let you get on with your work. Vanhee agrees. “Our developers don’t see Upsun; it’s totally invisible to them. They don’t need to access it directly. Rather, they just live in GitHub.”
> 
> **Peter Vanhee**, Head of Technology, Comic Relief

## **Gain efficiency, dazzle prospective donors**

The process for the Comic Relief team to test new changes depends largely on the development and QA required for any particular feature, e.g., improving donor experience on comicrelief.com, or optimizing the site for mobile. With Upsun, the tooling around setting up new environments, taking a current database from production, and applying the changes from the feature branch is, again, fully automated. It doesn’t take any longer than 10 minutes on the first commit, and only 5 minutes or so thereafter for the preview environment to be made available for manual and automated testing.

QA, product managers, UX designers, or other engineers can simply review the state of the work on a preview environment the moment a commit is made, accelerating the review process. With environments now ready in less than 10 minutes, product managers can show features to stakeholders in a very compressed window. Upsun helped increase individual team member productivity, enabling 85 percent of Comic Relief’s DevOps/QA resources to be reallocated to other tasks.

Comic Relief Concourse.ci deployment pipeline for sportrelief.com, a Comic Relief initiative. Represented are steps in the automated deployment pipeline, from pushing to master branch to staging deployment and sanity end-to-end testing to deployment to production. All automated using Upsun deployment tooling to various environments.

#### **40% Overall savings on Drupal projects**

Previously, the Comic Relief team deployed bundles of changes weekly. With Upsun, they’re deploying changes every time they merge to the master branch, which happens multiple times a day. The team runs a series of tests through a staging environment before the change is automatically deployed to production with a simple Git merge. All of this happens in less than an hour after the change is merged in master.

#### **Reported real-world results**

Overall, Comic Relief estimates that Upsun adoption saved their team 40% on their Drupal projects.

-   **Eliminated** the need for a dedicated WebOps engineer to manage Drupal QA environments and staging/production.
-   **Lowered** hosting costs as previously the team would have built their own stack on AWS, “which could, at times, become quite pricey.”
-   **Enabled** engineers to shift their time from deploying to QA and staging/production to focusing on developing features and associated tests, knowing the pipeline will handle the rest.

#### **Retain a sharp focus on the mission**

With Upsun, Comic Relief says they have a strategic platform partner that enables them to build, launch, and operate any new Drupal site within weeks, scaling up and down as needed, flexing to support annual Red Nose Day and Sport Relief fundraising campaigns. The IUR technology choice for Upsun aligns well with Comic Relief’s strategic five-year plan to work smart by focusing on efficiency and effectiveness, so they can maximize the value they deliver to beneficiaries.

### [Gault & Millau's digital transformation | Upsun](https://upsun.com/blog/gault-millau-digital-transformation-agility-scalability/)

# Gault & Millau's 50th anniversary digital transformation

Stack: Symfony, Python

---

Gault & Millau is a French dining guide founded in 1972. Today, it lists restaurants and provides growing support for innovation in gastronomy. Gault & Millau has always used its expertise to promote new talents and young chefs. It is now present in 15 countries and is in constant evolution. The guide also includes all sorts of new domains.

In addition to its guide, Gault & Millau offers B2B certification services. Gault & Millau also has several event-related business activities, particularly partnerships with major brands.

#### Driving a full digital transformation

These activities required that Gault & Millau websites be fully redesigned, to support the company's growth and continue providing high-quality services. That's what launched a digital revolution.

For this large-scale migration, Gault & Millau, which initially operated a single-page application, shifted to a more standard web architecture design. There were also native mobile apps that were turned into PWAs. The original database, which was relational, became a NoSQL database. The company's backend went from Python/Django to Symfony, while the frontend went from Angular to Symfony/Twig/Bootstrap to be responsive and compatible with all devices.

#### Building with SymfonyCloud

At the very beginning of this migration and transformation project, Gault & Millau's technical team discovered SymfonyCloud via SensioLabs. When the time came for the redesign, SensioLabs organized a cloud infrastructure workshop with Gault & Millau. The workshop led to the creation of an infrastructure optimized with Symfony that follows development best practices. SymfonyCloud then allowed the team to create dynamic environments that were easy to pilot, expandable and scalable. The SymfonyCloud team was called upon for the onboarding phase, providing timely support.

Deploying this new infrastructure and organization, and taking advantage of SensioLab's support from the very beginning of the project, has made Gault & Millau extremely agile. **A correction or change request can now be tested and deployed within an hour. Before, requests had to be transmitted to offshore teams and executed with a different set of tools, a fairly cumbersome process that often took weeks.**

#### Scaling globally and gaining efficiency

Gault & Millau's primary goal for this migration was to be able to manage various country-specific websites by subdomain and standardize them worldwide. The main difficulty with the project was the management and use of data, which is strictly separated by country. 

Managing certificates and subdomains by country was the biggest challenge. Thanks to SymfonyCloud's onboarding team, everything was set up within a few days. The back office was the largest piece to manage, with all the data, while the front office was managed by subdomain in multiple languages with translations.

Once a foundation was set up for all the country-specific websites, it became much faster and easier to update various elements and standardize the sites. **The goal was to avoid hiring more personnel. Although the team wasn't necessarily trained in DevOps, it was able to handle everything internally**. Even regular developers were able to master the console and understand the SymfonyCloud tools, which has made them fully independent.

Lastly, being able to deploy services just by modifying the configuration file is very practical, and allows its team to move quickly throughout the process, optimizing time and resources.

### [FREITAG takes ecommerce to new heights | Upsun](https://upsun.com/blog/freitag-drupal-commerce-upcycling/)

# FREITAG counts on Upsun: Upcycling products isn't the only way they promote sustainability - they do it through their website, too.

Stack: Drupal

---

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

_Bags and accessories made from truck tarpaulins and other sustainable materials—with this upcycling concept, the Zurich-based company FREITAG has successfully positioned itself in the market. Each item is unique and has its own story. This is why it was important for the company to provide an outstanding digital shopping experience for customers._

_FREITAG also wanted to highlight the unique stories and emotions behind the bags—and to do so as sustainably as possible._ 

_With Upsun—a central platform that lets you create highly scalable websites and apps  at a low cost—this is exactly what happened. It gives developers flexibility for an optimal sales approach and also helps them improve their CO2 footprint, which is incredibly important for sustainability._

In 1993, the brothers and graphic designers Markus and Daniel Freitag were both searching for a functional, sturdy, and water-repellent bag with which they could transport their designs by bike and keep them dry at the same time. Inspired by the heavy traffic that rumbled through the Zurich transit intersection in front of their apartment, they developed a shoulder bag made from used truck tarpaulins, discarded bike inner tubes, and car seatbelts. The company FREITAG was born. 

Today, the bag manufacturer operates 30 FREITAG stores and works with more than 300 resellers to delight people throughout the world with their recycled products. From backpacks to wallets, every FREITAG product is repurposed, but also unique. This uniqueness provides additional value for customers. 

However, it presented the online shop with major challenges during the development of its website. This is because every FREITAG product resonates with its own story and emotion. And that was something that had to be communicated.

### **Distinctive products present major challenges for the online shop**

In attempting to establish an online shop, FREITAG initially decided on an out-of-the-box ecommerce solution. 

"However, this solution was unable to express the uniqueness of our product offering," remembers FREITAG Product Owner Sarah Mauerhofer. "Our content creators had to work with a highly inflexible CMS tool. As a result, they had no option for connecting the products with their special stories or for communicating the emotions associated with them." 

This is why FREITAG decided to work with the Swiss digital agency Liip. For the website design, Liip initially suggested Drupal Commerce, the open-source platform that offers the flexibility necessary for combining a traditional web catalog with enhanced elements. This way the products could be linked to their individual background stories. 

FREITAG had initially hosted its own server platform, but due to its outdated infrastructure, supplying the products took too long, as did performing updates. This resulted in long downtimes.So, Liip searched for a platform-as-a-service (PaaS) with dedicated Drupal support. Upsun quickly turned out to be an optimal solution. 

"Upsun fits perfectly within FREITAG's strategy," explains Tonio Zemp, Digital Expert and Product Owner at Liip. "We needed a platform that was as stable as it was flexible for quickly integrating new features into the live environment, for modifying and for testing. We recommended a simple, sturdy infrastructure with low fixed costs so that FREITAG could focus its investments on testing and adapting features. This allowed them to create a sustained and vibrant live environment. Upsun was the best option for achieving these goals." 

### **A new level of customer satisfaction** 

From that point on, FREITAG no longer had to worry about constantly developing its web technology. Upsun now takes care of that for them. The PaaS provider regularly updates its platform and constantly integrates the most advanced developer tools. For customers, the benefits are considerable:

**A better customer experience:** Since then, FREITAG can completely focus on the customer experience, and in addition, share its unique product stories with customers—instead of worrying about infrastructure. This has been well-received by customers.  Sarah Mauerhofer says: "Our customers leave us very positive feedback on our website says, for both the desktop and mobile experiences."  

**Scalable at any time:** The FREITAG website can now be scaled whenever necessary. This means that FREITAG is well-prepared for every seasonal rush. "Our website traffic increases by about 20 to 30 percent in November and December. Thanks to Upsun, our website's stability was ensured at all times, quickly, and without any issues," explains Sarah Mauerhofer. 

The Upsun option not only provides Mauerhofer and her team with assurance and security. It also enables FREITAG to inform its customers about initiatives such as S.W.A.P. (Shopping Without Any Payment). S.W.A.P. encourages customers to swap old FREITAG products with other FREITAG fans who have the same soft spot for the brand and its mission.   

**Reduction of maintenance costs**: Because the website is best-equipped for every rush, even peaks are becoming non-events for our support team. Altogether, FREITAG has been able to halve its maintenance costs through its collaboration with Upsun.  

**Increase in conversion rate**: Another indicator has improved as well. "We were able to increase the conversion rate by a full 25 percent," explains Sarah Mauerhofer.

"FREITAG has had great experiences with Upsun,” Sarah continues. “We were always very satisfied with their support and operating hours. Whenever a problem did emerge, however, Upsun was always there to find solutions and ensure that stability was maintained."

"In terms of sustainability as well, FREITAG and Upsun are a great fit for one another," adds Mathieu Strauch, Regional Manager, Business Development at Upsun. "Like FREITAG, Upsun prioritizes sustainability and is one of the first platform providers to not only concern itself with its own CO2 footprint—it really makes the effort to reduce those of its customers as well. We do this by increasing efficiency and productivity. Independent audits have confirmed these figures for us. That is why we are especially happy about being able to support customers like FREITAG who place a premium on sustainability."

### [Drupal + Python integration boosts pet adoptions | Upsun](https://upsun.com/blog/drupal-python-pet-adoption-scraper/)

# Drupal + Python + Upsun: helping man’s best friends

Stack: Drupal, PHP, Python

---

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

Colorado Springs is a great place to live for many reasons. People throughout the country associate it with sunshine, some say as much as 300 days per year. (That’s kind of an exaggeration. The National Weather Service reports the Front Range actually averages 115 clear-sky days, 130 partly cloudy days and 120 cloudy days annually.) But for the last five years, it’s been raining cats and dogs for my team at Oxbow Labs.

We’re a small web dev studio based in the Springs, excelling at helping clients of all sizes further their missions by integrating seamlessly with their organizations. For more than four years, Upsun has been our go-to hosting solution, and has completely changed how we build and maintain websites.

## **Tackling a legacy challenge to support a crucial mission**

In 2014, the Humane Society of the Pike’s Peak Region (HSPPR) approached us with a challenge: to reimagine their website, so it elevated their most critical clients—pets seeking their forever homes. First, let me give you some background on HSPPR. Since 1949, HSPPR—a local, independent nonprofit—has served as the largest animal welfare group for homeless and abused animals in southern Colorado. As an open-admission shelter, HSPPR helps all animals in need; that means not one of the 26,000 animals brought to HSPPR each year is turned away, which is pretty amazing. As you might imagine, most people frequent the Humane Society website to view pets they may be interested in adopting. That activity drives the majority of site traffic and serves as their core mission to serve the community through pets.

Before we began to create the new HSPPR website, our analysis revealed that their legacy pet database had been around for decades (and seemingly hadn’t been updated in years). So, there wasn’t any direct way to access that information. The solution we came up with was to build a scraping tool using Python to extract the data directly off of the legacy system's website. With Upsun, we were able to deploy this solution directly into the same hosting container as the Drupal website we were building. We could, then, build, test, and deploy the Python scraper and the Drupal website as one unified system.

## **Flexible, customizable workflow speeds development**

Since launching the website, the Upsun multiple app architecture has enabled us to continually support and upgrade the pet scraper to adapt to HSPPR’s evolving needs. Because Upsun allows us to customize our development workflow, we’re able to meet the unique requirements for each website. For HSPPR, when a new feature is requested, we spin up a clone of the entire website, including the database, code, and files. We use this cloned website to build and test just this one new feature.

When we're ready to show the new feature to our client, we pass along the URL, so they can provide feedback. With Upsun, this new feature can include changes to the Drupal website as well as the Python scraper tool simultaneously. Deploying the new feature is as simple as merging the code into the live website.

For more complex websites, we may have multiple developers working on a dozen new features or bug fixes at the same time, but the process is still just as easy.

## **Reliability: inversely proportional to complexity**

Oxbow Labs is a small team of web developers. We're not system administrators or hard-core DevOps experts, so keeping a whole suite of websites operational can be a challenge. Since we switched to Upsun, we’ve all slept much better at night, knowing that the websites we maintain are in good hands. Reliability starts with a dedicated app container for each website. This means that the performance of one website isn't affected by other sites on the same server.

For HSPPR, putting both the PHP and Python applications on the same server reduces the complexity and potential points of failure by 50 percent. Backups and up-time monitoring are also greatly simplified by only having to monitor one instance.

## **Capabilities help increase pet adoptions, family reunions**

It's not often that Oxbow Labs and Upsun can say that we literally save puppies and kittens, but in this case, it’s not hyperbole. In the years since we built the HSPPR website, adoption rates have increased an average of 23 percent per year. And more than 30,000 pets have been reunited with their families. Upsun sustained reliability, performance, and improved development workflow were certainly contributing factors in HSPPR's success.

_Winn Jewett_ _is Oxbow Labs founder and lead web architect._

### [Faster compliant releases for public sector with Upsun and ROLLIN](https://upsun.com/blog/faster-compliant-releases-rollin/)

# Faster, safer, and more compliant releases for regulated clients

Challenge: Manual deployment checks were slowing ROLLIN’s delivery cycles and adding unnecessary risk, especially for government and healthcare projects, where precision and compliance are non-negotiable.

Solution: ROLLIN introduced a three-stage GitHub Actions pipeline integrated with Upsun, automating code quality, security, and accessibility checks to remove repetitive validation steps before every deployment.

Stack: MCP server, Drupal, GitOps

Results:

-   Automated validation to reduce the risk of human error on sensitive projects;
-   Turned manual validation into a repeatable framework for confident team standardization; faster, safer, and more compliant releases for regulated clients.

---

### **Manual checks slowed down delivery**

ROLLIN is a "small but mighty development agency," as Sam Rollin, CEO and Managing Director, puts it. Headquartered in Canada, with operations in Quebec, Halifax, and a small office in New York, the team specializes in building and maintaining digital platforms for government and healthcare, where precision, compliance, and security are essential.

Before integrating Upsun, ROLLIN relied heavily on manual deployment validation. Each release involved time-consuming checks for code quality, vulnerabilities, and accessibility compliance. These repetitive tasks slowed delivery and increased the risk of human error, especially on sensitive client projects where mistakes could have serious consequences.

They needed a lightweight, reliable pipeline that could:

-   Consistently validate code quality for Drupal and PHP projects;
-   Flag vulnerabilities before deployment;
-   Identify accessibility issues early without delaying critical releases;
-   Integrate cleanly with GitHub branches and Upsun environments.

### **Three-stage approach for faster, safer testing**


Upsun integrates directly to their GitHub repository, deploying changes in code to dynamically generated environments. Developers could now test changes in realistic conditions, including live services, routing, and databases, before merging.

They set up a three-stage workflow in GitHub Action, each stage focuses on a specific aspect of software quality.

#### 1\. Code quality

-   Coder (PHP CodeSniffer): Enforces Drupal and PHP coding standards using the Drupal Coder package
-   PHPStan: Performs static analysis to catch type errors and regressions before they reach production

These automated checks run on every push to their develop, staging, and main branches, helping developers maintain consistent code quality while reducing review overhead.

#### 2\. Security

-   Composer audit: Identifies vulnerable dependencies;
-   OWASP Dependency-Check: Adds a configurable second layer of security scanning across packages.

The team runs both tools in sequence within the security stage. They also add an optional email notification that triggers workflow failure to alert the team.

#### 3\. Accessibility and compliance

-   Pa11y: Runs headless via Puppeteer and Chrome to crawl the Upsun staging environment, reporting accessibility issues, contrast, ARIA labels, and form semantics.

Accessibility is vital to ROLLIN's public-sector clients. These reports provide immediate visibility without blocking deployments.

> "The accessibility check won't stop the deployment,” Rollin explained. “But it gives us great visibility. It's good information for developers to know what can be improved.”

### **Connecting it all with Upsun**


ROLLIN configured their GitHub repository so GitHub Actions run before any deployment to Upsun. Each project’s routing and services live in code, which keeps every environment reproducible and version controlled. 

When the Actions pipeline passes, the Upsun deployment runs independently of GitHub Actions. It targets the appropriate environment and generates a review URL for stakeholders. 

This clear separation gives the team reliable pre-deploy gates without coupling deployments to CI job state. 

> As Sam Rollin put it: “That dynamic environment is really powerful. You can hand that URL to a client and show them tangible results.” This aligns with how Upsun fits into Git workflows: branch based reviews, live URLs, and production-like previews so teams can test changes in realistic conditions before merge.

### **Speed, safety, and repeatability**


With Upsun embedded in the CI and CD flow, ROLLIN turned repetitive checks into a lightweight and reliable framework. Automated standards and audits reduce manual effort and lower the chance of human error. Developers get fast feedback on quality, security, and accessibility from GitHub Actions. Upsun review URLs improve collaboration and sign off. 

Consistent checks run on the branches that matter for releases, specifically develop, staging, and main in this workflow. The YAML based setup and open source tools make the pattern easy to reuse across new Drupal projects.

### **Scaling confidence and simplicity**


ROLLIN continues to refine its workflow, adapting small variations for each client's use case while keeping the core workflow simple and dependable.   
  
Each successful deployment produces a live Upsun environment with a shareable URL for testing and client review. The team can iterate quickly without sacrificing quality. New Drupal projects start on the same foundation of automation, reliability, and trust. 

> As Rollin summed up:
> "Everything passes, it deploys automatically, that's where the magic comes in."

### [Perfectly posh: Drupal Commerce app | Upsun](https://upsun.com/blog/perfectly-posh-drupal-commerce/)

# Perfectly Posh adopts Upsun for Drupal Commerce app

Stack: Drupal, Symfony, PHP

---

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

#### **Custom Upsun Enterprise subscription deployed to handle massive peak traffic**

Today, Upsun announces the adoption by Perfectly Posh of our Platform as a Service (PaaS) for their online sales operations. Founded in 2011, Perfectly Posh sells naturally based, pampering products across the USA through over 45,000 Independent Consultants. Perfectly Posh has selected Upsun Enterprise for their online e-commerce application, migrating to a custom offering designed to fit the high growth demands of a company on the move.

The main reasons for selecting Upsun were:

1.  A hosting stack tuned for high performance e-commerce;
2.  Seamless scaling of Web and Database servers during peak periods with no application downtime;
3.  Ability to customize this infrastructure around their specific needs;
4.  Reliability guaranteed with a 99.99% uptime SLA; and

Significant productivity improvements, enabling a change to the development regime that eliminates infrastructure management overheads, and accelerates code though to production via better CI (Continuous Integration) enablement and 100% consistency between environments.

This combination of capabilities allows the business to reduce overall development costs and manage risk when deploying changes into the production environment, reducing the potential for revenue loss, and enabling revenue optimization changes into live during peak traffic periods, providing enormous competitive advantage.

> _“As we evaluated our hosting options we met with many different companies; most of them said ‘You are exactly the type of customer we want to work with’, but none of them could fit us into the standard offering they wanted to sell us. When we met Upsun we were excited, because we found a company that not only had an amazing service, but who were willing to engage with us as a true partner, and were committed to our success. They architected a custom hardware stack that fit our e-commerce application perfectly. We’re excited to grow together.”_ **\-Dallas Despain, Director of Engineering, Perfectly Posh**

> _“We are extremely pleased that Perfectly Posh has chosen us to be the foundation upon which they continue their amazing growth. This customer manages one of the largest Drupal Commerce implementations in the world, and to be chosen to help support this mission-critical application is an affirmation of our next generation PaaS and deep knowledge of the e-commerce Use Case.”_ **\-Kieron Sambrook-Smith, Chief Commercial Officer, Upsun**

### **What is Upsun**

Upsun is a second generation Platform-as-a-Service offering a continuous deployment cloud hosting solution.

It is a fully automated cloud solution that can cover the needs of small self-service accounts but also powers multiple dedicated cloud regions running tens of thousands of instances over multiple IaaS providers. Targeting the web application market and foremost large PHP e-commerce sites and media sites, it has been chosen as the official cloud partner of major open source projects such as Symfony, EzPublish, and Drupal Commerce. It has also been chosen by major Open Source software vendors and is now powering their SaaS offering through its technology. It has signed exclusive deals with two major European sovereign cloud providers.

Upsun is a VC backed startup headquartered in Paris, with three fully owned subsidiaries and employees on three continents. In its 18 months of activity it has met with explosive growth, acquiring thousands of clients from more than a hundred countries, doing as much business in the United-States as in Europe. Among its clients you can find key accounts, such as Vivienne Westwood, the British Retailer Reiss, the Canadian Football League, the British Council, Parc Asterix, Seloger.com, the German startup Flixbus, and the South-American El Universo.

### **About Perfectly Posh**

Perfectly Posh is a pampering brand founded on four core principles: we simply pamper, we use the best ingredients in our products, we are made in the USA, and everyone deserves a little time to take care of themselves, in other words: You Deserve It.

### [Empowering non-profits with BoardSpot SaaS | Upsun](https://upsun.com/blog/boardspot-nonprofit-board-management-saas/)

# BoardSpot SaaS solution frees nonprofit boards

Challenge: To rapidly deploy new features to a nonprofit board management SaaS solution

Solution: Built from day one with Upsun, leverages capabilities to streamline development and deployment workflow, so engineers can focus on product development, instead of DevOps

Stack: Drupal

Results:

-   Multienvironment workflow enables the development of multiple, concurrent features
-   Out-of-the-box security and compliance features, along with integrated build and deploy hooks, protect customer data at the hosting layer
-   New features are deployed weekly; bugs fixed and deployed within minutes, even at peak times—with minimal downtime

---

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

Custom website development for nonprofits has served as a staple of digital agency and Upsun partner Oxbow Labs’ portfolio for the last 15 years. Founder Winn Jewett and his team make it a priority to acquire a deep understanding of each nonprofit’s unique mission to do good.

For nearly every custom website project, the Oxbow Labs team noted that nonprofit clients requested a set of integrated tools to support their boards of directors, whose responsibilities span strategic direction, planning, strengthening/monitoring programs, and financial oversight. The emerging pattern from these one-off, custom implementations compelled the Oxbow Labs team to create a nonprofit board portal that would positively impact any nonprofit’s governance.

## **A SaaS solution to facilitate governance**

For years, nonprofit boards have used old-school tools to manage board meetings and govern their organizations. Some cobble together solutions from different tools—Dropbox for files, email for communication, fingers crossed for RSVPs—while others rely entirely on physical board packets and in-person meetings. For years, the industry slowly transitioned to more sophisticated tools until March 2020, when COVID-19 accelerated the need for boards to adopt a completely digital and remote solution to governance.

Oxbow’s spinoff company, BoardSpot, fulfills the vision of all nonprofits: to realize the full potential of their boards through access to information and collaboration. To bring the vision to life, the BoardSpot team recognized early on that they’d need to develop the nonprofit board portal with a new set of tools and with features powerful enough to support the needs of enterprise-scale nonprofits, yet intuitive enough for volunteer board members to feel comfortable immediately.

Built with Upsun and delivered as a Software-as-a-Service (SaaS), BoardSpot complements Oxbow's work and enables an expanded service offering to nonprofits looking for a suite of robust online solutions.

BoardSpot’s ease of use and pricing model has become incredibly popular with large nonprofits across a wide range of industries, including higher education, healthcare, and land conservation.

## **Supporting global enterprise customers**

BoardSpot leverages Upsun to run multiple versions of its codebase in several regions throughout the world. Upsun integration with GitLab enables code deployments to be automatically pushed to the entire fleet of BoardSpot instances simultaneously, keeping the product in sync for all customers. International customers benefit from the performance improvements and data residency benefits of a server that’s physically located nearby.

## **Agility to respond to challenges, scale solutions quickly**

> “One of the biggest benefits of hosting with Upsun is the speed and flexibility that it brings to the development workflow,” says Jewett. “This feature has enabled us to be incredibly responsive to customer requests and suggestions.” 

An example? The United Nations Capital Development Fund (UNCDF).

In the early stages of product development, UNCDF approached BoardSpot with a unique challenge. Because of the strict regulations imposed on organizations under the UN, all UNCDF’s online votes need to be certified by an outside member before resolutions can be officially approved. BoardSpot jumped at the opportunity to engineer a simple technological solution to a real-world governance challenge and rapidly integrated vote certification into the online voting system. This feature was then rolled out to all BoardSpot customers who also required that extra level of accountability.

## **Security from the ground up**

Built around Drupal, BoardSpot heavily leverages Upsun out-of-the-box security and compliance features as well as development workflow. “In the BoardSpot development process, we use a deploy hook to strip out all customer data from development environments,” says Jewett.

> “It’s absolutely paramount that there's no cross-contamination between organizations and that customer data is never exposed. By taking advantage of Upsun capabilities, we can give our dev team access to all of the environments up to the dev branch, with the peace of mind in knowing that data is sanitized throughout the entire workflow.”
> 
> **Winn Jewett**  
> Founder  
> Oxbow Labs and BoardSpot

## **Work in parallel, speed development cycles**

At any given time, BoardSpot's development team simultaneously builds new features that take weeks or months to develop; makes minor improvements that are ready in days; and implements hot-fixes—including security updates from Drupal's dedicated security team. With Upsun, each of these features is provisioned with an identical clone of the entire hosting environment, down to the smallest configuration detail. With such disparate deployment schedules between the smallest and largest features, Upsun integration with GitLab makes it easy for merge requests to automatically rebase the Git repository to include recent code changes into long-term feature branches.

> "Our engineers are able to work incredibly fast to roll out quick updates and to take the time needed to properly plan and build big new features—all without skipping a beat.”
> 
> **Winn Jewett**

## **Giving back and COVID-19**

From the onset, Jewett and team wanted to ensure that the smallest nonprofits—those with few staff and incredibly tight budgets—could afford to have technology supporting their missions. Of the 1.56 million nonprofits in the United States, 75% have budgets less than $500,000.\* To support these small nonprofits, BoardSpot introduced a grant program that offers steep discounts (up to 90%), extending access to world-class tools for their boards. "Without the incredible performance of Upsun, we wouldn't be able to afford to provide BoardSpot at such a discounted rate to the smallest of our nonprofit customers," says Jewett.

In response to the COVID-19 health crisis, BoardSpot rapidly launched a video conferencing feature that’s integrated directly into the product, ensuring nonprofits could continue to conduct meetings securely—even if they weren’t able to meet in person.

> I believe nonprofit organizations are some of the most innovative and important entities in our communities, yet often the most underserved when it comes to technology solutions. I’m glad that BoardSpot can provide an important service to these vital organizations.
> 
> **Winn Jewett**

_\*Brice McKeever. National Center for Charitable Statistics. The Nonprofit Sector in Brief 2018. 13 December 2018._

### [Pivale reduces DevOps to focus more on clients | Upsun](https://upsun.com/blog/pivale-reduces-devops-with-paas/)

# Pivale reduces DevOps to focus on client problem-solving

Stack: Drupal

---

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

Sony. Virgin. Peugeot. All high-profile brands with a foundational objective in common: to create digital experiences that more deeply engage customers and generate sales. And they’ve turned to UK-based, Drupal web and application agency Pivale to do it.

## **Unique client requests morph into complexity, inefficiency**

A rapidly growing agency with an impressive client portfolio, the Pivale dev team supported diverse client requirements by applying equally diverse infrastructure solutions: dedicated servers, virtual private servers, cloud services. Managing all the different software and tools? Messy. And cumbersome. Weighing down the team’s ability to efficiently deploy each site and cater to unique client requests. “Having different infrastructure setups for different clients meant that we needed to follow different processes for continuous deployment. Each one became error prone and typically required manual actions to be taken in order to complete a deployment successfully.” Barry Fisher, Pivale director explained.

To improve their deployment workflow, the team recognized they needed to create long-term consistency and reliability across the growing number of projects they were entrusted to maintain. But how?

## **Stunning, real-world results with a single platform**

Pivale consolidated their various dev and production workflows onto Upsun. Now, a single set of tools adapts to their diverse client and project needs, helping to speed development and deployment and drive consistency—nearly overnight. The team can focus their energies on building amazing customer experiences, instead of DevOps. And their clients can realize time to value faster as they drive sales.

### **Here are Pivale’s reported results**

Bonus: Fisher appreciated that Upsun provides all the extra software their team uses, including Apache Solr, Redis, and image compression libraries—all which he reports “vastly improve on the value we’re able to bring to our clients’ sites.” And adding new services is as easy as adding a line to a configuration file.

> We searched for a solution and found that Upsun offered the most extensive feature set and has technical tools that are missing from other Drupal-focused PaaS providers. Having a fixed monthly cost model is appreciated by our clients, so they can budget consistently; Upsun provides all the benefits of a cloud service without the cost uncertainties. ”
> 
> **Barry Fisher**  
> Director  
> Pivale

## **Platfom.sh deployment: a study in success from day one**

When ANS Global, green roof and living wall designers, approached Pivale to build its new website, the agency put Upsun to the test. The team saw the instant benefits of having consistent, secure deployments. “The immediate effect of using Upsun for the first time was that we were able to deploy a development site on launch day for the client with relative ease,” Fisher says.

The real test: how quickly the dev team could respond to new feature requests from ANS Global. With deployment flow based around git branches, everything was well within the developers’ control, and ANS could deliver richer content and experiences to _their_ customers.

## **Agility for small dev teams**

Through their ANS Global project, the Pivale team recognized the importance of finding just the right partner. 

Fisher says, “With Upsun, we now have more fluidity in our deployment process and something we can standardize all our projects on. As a relatively small team, DevOps isn't a full-time role for any given person in our agency, so making sure we use our time wisely is the most important thing to get right. We can now spend our time more effectively consulting with our clients to solve their business problems—without the headaches of fragile and differing hosting environments.”

### [ HMP Global’s PaaS journey | Upsun](https://upsun.com/blog/hmp-globals-paas-journey/)

# HMP Global’s PaaS journey: from weekly outages to 99.99% uptime

Stack: Drupal, PaaS

---

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

Global events and publishing company, HMP Global, strives to make the world a healthier place through the power of education within the healthcare industry. With brands including the HMP Global Learning Network, Consultant360, and Psych Congress on their roster of accredited medical education events which their team produces every single year.

We sat down with the Director of Web Development at HMP Global, Ryan Geraghty, to discuss how his team manages over 150 globally distributed microsites and applications for HMP Global events. Including an extensive lineup of virtual and hybrid events, many of which ran on Upsun. From implementing CI/CD and QA processes for their Drupal-centric application infrastructure. To local development to serve their events and audiences around the world and finding their groove when it comes to best practices for security and compliance.  

### **Optimizing developer workflows for a 200% improvement on application stability**

“We’re a global events and publishing company with journals and events within the healthcare space, and each of those properties has their own website,” explains Geraghty, “We probably have around 150 websites total.”  

That’s 150 individual websites that require regular maintenance, optimization, updating, and security and compliance to run successfully. And with so many sites to manage, the HMP Global development team needed a tool that could facilitate flexible, local development to allow their developers to work seamlessly alongside each other. Not to mention reducing the time spent onboarding new developers, grappling with various PHP versions, managing dependencies, setting up local TLS certificates, debugging MySQL, and we all know the list goes on.

As partners of Lando, the leading open-source platform for managing local development environments, HMP Global was able to download their Upsun projects and run local environments with perfect replicas of their websites. Making changes in real-time and pushing code and config changes back to Upsun with just a few keystrokes with the help of our built-in CI/CD automation. While the developers can rest easy knowing that their local environment will be an exact match for production–no matter the website they’re working on.

The HMP Global development team was able to spin up multiple versions of the same site with different branches effortlessly. Geraghty shared that before using Upsun, DevOps was barely part of their workflow at HMP Global. And a large percentage of their applications weren’t tracked in Git at all which led to several problems when keeping track of changes. Now each change is spun up in its own testing branch and approved before being merged which has led to quality and stability improving by up 200%. While this additional process has added some time onto their deployments, they spend considerably less time dealing with outages and issues on the other side which makes up for it.

Not to mention, Lando even takes care of the complex networking between components–including databases, queues, and various runtimes–which means there was no need to set up and manage different versions of software on Mac or PC. With around 30 of HMP Global’s major platforms hosted on Upsun, they were able to optimize the developer workflow for around a fifth of their total website portfolio.   
 

### **Reliable QA testing driving better results and increased uptime**

With the local development capabilities that Upsun provides, HMP Global was also able to establish strong quality assurance (QA) and user acceptance testing (UAT) procedures which ultimately helped them deliver better-performing websites. As they were able to build new branches and accurately test them out before going to production.

A feature that Geraghty shares has helped his team deliver better quality websites, “because we can now have those actual QA and test links that can go out with better uptime,” with their Global Learning Network reporting uptime improving from 99.95% to 99.99% with Upsun. Geraghty said, “While not a huge difference, it’s our flagship and our most visible web property taking millions of visits a month, so the extra hours of uptime are a huge win for us—especially since we don’t have to worry about monitoring and fixing it ourselves.” And with their other websites averaging 100 visits per month—with that figure increasing significantly to anywhere between 1,000 to 100,000 visits leading up to an event—performance quality and reliability are central to their development team output. Now all downtime for HMP Global websites hosted on Upsun is a result of planned deployments—no more surprises.

Geraghty detailed a peculiar recurring issue that HMP Global was having with the stability of one of their sites which would crash at least once a week for various reasons. An issue which they still don’t understand the root cause of to this day. However, ever since moving the website over to Upsun it hasn’t had a single issue.

### **Stability, quality, reliability** 

“It’s really just the efficiency and being able to have better quality stuff and more stable stuff,” says Geraghty when summarizing the positive impact Upsun has had on his team’s output since joining us in February 2022.

With over 30 HMP Global websites now using our PaaS, the team has had plenty of opportunity to dive into all of the available features and capabilities. Of which Geraghty detailed automatic deploys and software updates, less time spent on DevOps, quality assurance, the ease of spinning up new branches in minimal time, and our security and compliance measures as real standouts. Especially as he shared, “We were really trying to keep the pricing about the same with what we paid previously, but add in these efficiencies in the process,” which they found with us.

### [Opigno LMS and cloud hosting | Upsun](https://upsun.com/blog/opigno-ready-for-spike-in-lms-demand/)

# Opigno ready for spike in global LMS demand

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

“The current economic climate is seeing many more people working from home,” says Axel Minck, CEO of Opigno, a Swiss-based learning management system. “Consequently, we’re seeing a spike in demand from companies who want to make sure their newly remote workforce continues to be properly trained.”

Opigno started as a digital agency selling web development to clients. But in 2012, foreseeing the growing need for employee training services, they decided to focus on e-learning. They transformed to a service-based software vendor providing an open-source Drupal-based learning management system (LMS) distribution.

Customers happily paid for enhancement work, maintenance, and support services. Then in 2015, at the request of some of their larger customers, Opigno began hosting the LMS as well. “But self-managed hosting is complicated to look after and troublesome when it doesn’t work properly,” says Minck. “And it all requires more people to look after it and higher levels of service to pay for.”

Minck decided that the company’s ultimate goal should be to make it as easy as possible to deploy the LMS platform so that customers could accelerate business with training and better deal with uncertain environments. To do this they now offer clients not only an open-source version of the LMS platform that they can manage themselves (or with Opigno support) on their own server infrastructure, but also a managed hosting service.

## **Helping customers get bigger and better**

Minck knew it would be important to offer a managed hosting service, perfectly tuned for Opigno, that would allow clients to easily get started and then gradually get bigger, scaling up to larger infrastructure only when they needed to. International clients would also need a service that could accommodate staff in many different locations around the world and provide them equally fast response times wherever they were.

Building the cloud capability needed to offer their own managed service option would have been very expensive for Opigno, requiring new engineers, security, and support specialists. Allowing customers to incrementally scale up their application usage is a complicated architecture to get right. What Opigno needed was a less complicated solution that would be easy for customers to switch to. “One with everything automated, nothing for us to do, data centres all around the world, and CDN included,” says Minck.

## **Expertise always wins out**

Once he knew what he needed, Minck knew who to get it from. He reached out to Upsun, who had impressed the CEO with their expertise when they ran a SaaS cloud business workshop for Opigno. Upsun assured Minck that setting up the Opigno application for cloud deployments would be easy. The application itself would remain exactly where it was in Git and would receive only minor adjustments plus an App YAML file with some hosting definitions.

“As a first step we implemented an auto-deploy integration through the Upsun API, so that users can one-click subscribe from the Opigno Cloud page” said James Aparicio, Opigno Development Manager. “For the time being, clients will pay Upsun directly for the hosting plan on a credit card, with larger enterprise clients being dealt with separately. The next step is to implement some user management and billing before taking the larger cloud service subscriptions direct.”

New subscribers would be instantly provisioned locally into one of Upsun’s 25 grid regions around the world, giving faster access times and an optimal Opigno experience.

## **Ready, set, scale**

Opigno’s new cloud service capabilities now include the ability to manage more of their subscriber base directly, making feature changes and security fixes faster and safer for clients subscribing to the Opigno maintenance plan. Those clients are able to benefit from a number of compliance certifications Upsun has, as well as to receive global 24x7 support services for infrastructure issues. They can also subscribe directly with the Opigno team for software support.

Minck estimated their market share in 2019 at less than 5%. “Now,” he says, “we are ready to double that and then double it again. Why not!”

### [Hearst Networks EMEA Streamlines Web Hosting & Development | Upsun](https://upsun.com/blog/hearstnetworks-case-study/)

# Hearst Networks EMEA increases web development productivity with Upsun

Stack: migration, DevOps, SaaS applications, Drupal, GitHub, PaaS

---

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

Hearst Networks EMEA is a global broadcaster that has been sharing stories that matter with audiences since 1995. The company operates across Europe including in the UK, Nordics, Benelux, Central and Eastern Europe, Spain, Italy, Germany, Africa, and the Middle East. Hearst Networks EMEA's portfolio of premium brands include The HISTORY® Channel, Crime+Investigation®, and BLAZE®. With many international operations to manage, the organization has an equally wide array of websites and web services.

Prior to 2021, Hearst Networks EMEA engaged a managed agency for its websites, handling development, maintenance, and hosting/uptime for every domain. But by 2022, Hearst wanted to separate web development from hosting. This meant investigating the volume of options available for these services.

We sat down with Hearst Networks EMEA's Head of Web, James Hall, to understand the network’s challenges at the time, explore their decision-making process for migration, and examine what led them to choose—and stick with—Upsun.

With more than a decade of web design and development experience, James has tested many web tools throughout his career. His unique perspective sheds light on the process of finding the ideal hosting provider.

**Q: How many sites are you managing currently?**

**A:** We currently run 14 sites across six different environments: one environment is set up with multiple domains. And with Upsun, even that’s super simple.

**Q: Back in 2022, what type of managed hosting solution were you looking for? And what did you hope to achieve by migrating?**

**A:** At the start of a project, it quickly becomes apparent that there are different hosting routes that you could go down. You can go down the fully managed hosting route. You can go down the fully self-hosted route. However, we wanted something in between, where we still get the hand-holding when needed around certain aspects of hosting. Let's face it; hosting can be quite a complex thing at times.

We also wanted the flexibility to scale environments up and down as needed and to work asynchronously with development teams around the globe. To be able to work with different teams in different countries and continents was massively important. Upsun seemed to fit the bill.

**Q: What led you to consider Upsun?**

**A:** We scoured the internet and had meetings with many different hosting companies and options, performing sandbox testing on many solutions to find the best tool for our needs. Upsun struck us as being a good fit for our business for multiple reasons.

First, the fact that it's easy to try out new ideas quickly using a branch-based workflow, meaning you can make and break things in siloed environments. We can spin them up and close them down in seconds, whenever we need, without impacting production.

We can also work in different continents without any issues. Developers working on different branches, which sync with our repositories, allowing us to test new features, while also running real-world testing.

Finally, it also allows us to easily track incidents and issues. If we ever have any problems, Upsun has a built-in ticketing system to allow us to get support. We're on an Enterprise plan, which allows us to be able to chat to a member of Upsun staff within an SLA agreed-to time.

**Q: How did you ultimately select the right plan and services for your needs?**

**A:** One of the benefits of Upsun is the predictable pricing. It allows the customer to be able to plan business costs clearly and scale if required, along the way.

Early on, we had a representative from Upsun sit down with us, review our analytics, review our site performance, calculate averages from the data, and help us to gauge which plan suited us best. There was no upsell; it was whatever plan fit that site.

This means we're never paying for things we aren't using. At the same time, the sites that _do_ need the extra traffic and resources—they’re always online, too.

**Q: How was the experience of migrating to Upsun?**

**A:** As with any change of hosting to a new provider, it can be a challenging experience. But the eureka moment for us, where we realized we really had made the right decision, was the onboarding process with the technical team from Upsun—with our account managers and support from across the business.

You've got an immensely powerful and complex tool, with a really simple interface, enabling you to make changes to your hosting configuration, at any time. For us, even colleagues who aren't devs within the company, now have an understanding that Upsun is at the heart of our digital products, the heart of our ecosystem, which is coupled with rock-solid support. It made us realize that Upsun was the right choice for us.

**Q: How has your workflow improved since migrating?**

**A:** At Hearst Networks EMEA, prior to Upsun, we used a traditional development workflow consisting of dev, stage, QA, and production, and work from one, to the next, to the next.

While you can still follow that strict methodology if you want, that workflow rigidity isn't necessarily required when using Upsun. This grants companies the opportunity to refine the development workflow for their own needs, while still ensuring industry best practices are followed. You can be more fluid, knowing should you ever face any issues, you can roll back production in the worst case scenario.

There's also no ambiguity over what timelines are at play for new product builds or feature requests, with Upsun, it's transparent between all teams who have access to the service.

With Composer managing dependencies within Drupal, it's easy to keep tabs on any updates on both Drupal core and contributed modules. And Upsun makes it super easy to update your sites. You can run updates in a separate environment and then, when you're happy, release them to production.

By having a mirrored environment to test in, you can conduct thorough testing —ultimately finding and fixing any faults prior to release. That helps to minimize any potential downtime in production.

In summary, Upsun allows you to try new approaches to working. The service gives you the ability to be brave with your environments—more so than you may otherwise be if you were hosting it yourself. And you know it's all backed by a brilliant, supportive team that can help you out, should anything go wrong.

**Q: We offer two interfaces for users of all levels: the CLI and GUI. Which do you prefer to use?**

**A:** Initially, you can achieve amazing results through the GUI, through the web interface, with easy-to-use navigation and features.

However, once you have experience with the GUI, there can be huge time savings made by learning and using the Upsun CLI.

The command line interface in Upsun is an incredibly intuitive way to manage web environments hosted on its platform.

**Q: What’s been the biggest benefit of partnering with Upsun?**

**A:** When we joined Upsun, we were intrigued by the marketing messaging around _Deploy Friday_. Before joining as a customer, we didn't really believe it; we thought it was merely a good marketing slogan!

However, it's true—you really can deploy on Fridays. To get an extra day in the week to manage and undertake releases, using all five days of the week for production releases makes a big difference.

It's something that, as a company, has a saving clearly associated with it. We’re able to deploy security updates, patches, and new features on a Friday, and be safe in the knowledge that if we run into any problems along the way, we can roll back.

Put simply, it's allowed us to increase our web development productivity, opening up this extra weekday for releases.

**Q: What would you say to someone considering a migration to Upsun?**

**A:** In my time at Hearst Networks EMEA, one of the best decisions that I’ve made to date was choosing Upsun as our hosting provider. I think that it's an immensely powerful tool.

When migrating to a new hosting provider, it’s not always easy to find exactly what you’re looking for. Whether you need customizable plans, mirrored environments, extra deployment days, or responsive customer support. The key things I'd suggest are thorough research and testing, in order to find your ideal hosting solution.

_James Hall has been a web designer and developer for more than a decade. With experience in Drupal, Github, and Composer-based projects, his technical prowess and leadership skills have carried him far, enabling him to work on web related projects for major tech and media brands._

### [TYPO3 Cloud Integration in Germany | Upsun](https://upsun.com/blog/typo3-cloud-integration-germany/)

# TYPO3 and Upsun: A love letter from Germany

Stack: Symfony, PHP

---

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

Upsun is different. Why? Because it allows developers, editors and project managers to focus on their applications and leave the rest to us. This is a story that we’ve seen around the world, as new teams and projects try out Upsun and discover the benefits that it brings.

This trend is now also gathering pace in Germany, where our strategic cooperation with Microsoft is making the cloud an attractive option for partners and customers across central Europe.

In an interview on the popular Entwickler.de website (Entwickler means developer in German), Benni Mack, Core Team lead at the TYPO3 Association, explained how Upsun is transforming the way he works with the popular TYPO3 CMS. As well as spearheading TYPO3 development, Benni is Managing Director of b:dreizehn GmbH and a top Upsun partner.

## **Interview with Benni Mack: TYPO3 and Upsun - a match made in the cloud**

**Stefanie Schäfers**

In October 2016 the partnership between TYPO3 and the Upsun cloud hosting service was officially announced. We talked with Benni Mack about his experience and the advantages of the cooperation for TYPO3 users.

"TYPO3 in the Cloud" is the motto for the new TYPO3 version 8. And the partnership between TYPO3 and the Upsun cloud hosting service is intended to make it much easier for users to deploy TYPO3 in the cloud.

In the meantime TYPO3 has been supported on Upsun for almost half a year: reason enough to take a look at the lessons and insights the partnership gathered the last few months. And that's not all: with TYPO3 v8 LTS, the new long-term support version of the popular content management system is also available. We spoke with Benni Mack (Managing Director at b: dreizehn GmbH) about TYPO3, Upsun and the new CMS version.

### **TYPO3 and Upsun - the advantages**

**Mr. Mack, since last year, TYPO3 has been working together with Upsun as a cloud hosting service. Why did you choose this provider?**

**Benni Mack:** The big topic for the new TYPO3 v8 is "TYPO3 in the Cloud". We support various cloud hosting services with the new TYPO3 version, including Microsoft Azure and Amazon Web Services.

However, Upsun is a continuous cloud hosting service that, in addition to hosting, also covers other areas such as deployment and automatic cloning to additional test environments. It’s an approach that no other vendor is currently offering in this form.

**What other (further) advantages does Upsun offer to TYPO3 users?**

**Benni Mack:** Upsun is deeply grounded in the code versioning of a website project. That means that any change in a Git branch (via git push) automatically results in a new version of the application on the server. In addition, all user data, including all files and the database, are automatically copied when a new Git Branch is created during development. The new server environment is then available with its own URL. That saves a lot of unnecessary work for simple testing with real data or acceptance testing by a project manager or customer.

At the same time, this saves time for developers who no longer really need local development, although that is, of course, still possible and supported. DevOps is also reduced to a minimum - at Upsun they even speak of NoOps.

My personal Upsun highlight is that unlike traditional hosting providers, file system for any PHP code is read-only, making the entire system extremely secure.

**What challenges did you face during implementation?**

**Benni Mack:** TYPO3 supports the installation via Composer, thus the automatic loading of all necessary libraries. If a TYPO3 project has already been installed with Composer, Upsun interprets it and the biggest hurdle is overcome.

Upsun uses a simple configuration file that defines which PHP modules or databases are required. In addition, further project-specific scripts for the build time are defined. All of this is also maintained and versioned in Git. This may be new at first, but thanks to good documentation it’s quickly understood.

This configuration file also makes it easy to raise the PHP version from 7.0 to 7.1 and test it on an automatically created test branch. Furthermore, additional specific parameters can be defined for each test system ("Environment" in Upsun speak), in order to give TYPO3 additional options, that differentiate the live and test systems.

### **Tech Preview of Upsun TYPO Support - Findings and Lessons**

**Upsun support for TYPO3 was initially available as a tech preview. What lessons did you draw from it? What lessons have been drawn into the project?**

**Benni Mack:** The Tech Preview is a sample TYPO3 project that we developed for newcomers to TYPO3 - but also newcomers to Upsun - to quickly get aboard the bandwagon. Thanks to the close cooperation with Upsun, we have used a variety of approaches to make sure that TYPO3 files are always put into the right place by default. In the end it’s about managing content - not just text, but also images, PDFs, etc.

The template repository is freely available at https://github.com/platformsh-templates/typo3.

**The Tech Preview should be ready for testing until the release of the next LTS version of TYPO3. How has the collaboration and adoption of TYPO3 and Upsun developed since then?**

**Benni Mack:** One of Upsun’s strengths is that other services such as Solr search or Redis for efficient caching are already provided free of charge for every Upsun project. Based on this we’ve worked to create an effective, automated configuration of these services to deliver the best performance for TYPO3 website projects. TYPO3 v8 is the successful realisation of these efforts.

With the Tech Preview we’ve provided a one-click installation of TYPO3 that puts our CMS in the cloud in five minutes.

### **TYPO3 v8 LTS - what to expect**

**TYPO3 8.x LTS will appear in April. What innovations can users look forward to?**

**Benni Mack:** In addition to the promised cloud features, we have many improvements for editors - including a faster TYPO3 system and an easy-to-configure text editor based on CKEditor, as well as a flexible kit to create forms. For integrators, all templates are now uniformly designed and easily expandable.

The focus was definitely on scalability in larger projects, e.g. On several servers where it is now possible to share TYPO3 on different databases or to outsource all user sessions to distributed systems such as Redis. Support for complex, multi-lingual websites has been greatly improved and standardized.

**Let's take a look at the future. What plans are currently available for the next TYPO3 versions and the further collaboration with Upsun?**

**Benni Mack:** The TYPO3 community has been opening up increasingly to other open source projects like Symfony, Composer and the PHP community altogether. Technology giants like Microsoft are also on board. There will be a lot of change in the entire hosting sector, and Upsun is a pioneer with an innovative technical solution. Close cooperation at various PHP-related events is a win-win for both Upsun and TYPO3.

TYPO3 has some USPs that no other content management system provides. In future, we would like to emphasize these strengths even further and to link our CMS more closely to other systems and projects - not just at a technical level.

### **Our interview partner: Benni Mack**

Benni Mack is the managing director of the online agency b:dreizehn GmbH in Stuttgart, a team of TYPO3 specialists. He has also been actively involved in TYPO3 development since 2006 and has been coordinating the technical development of the TYPO3 project since 2015.

**Read the full interview (in German):** **https://entwickler.de/online/php/typo3-platformsh-579794768.html**

### [SaaS startup Witty Works | AI-augmented DEI solution at scale](https://upsun.com/blog/witty-works-case-study/)

# SaaS startup Witty Works delivers AI-augmented DEI solution at scale

Challenge: To find a platform that would provide the flexibility to scale project resources and better control costs for an innovative, AI-augmented, DEI digital language assistant

Solution: Migrating a natural language processing API project (Python, with Java Server) to the Upsun PaaS

Stack: AI, Django, java, microservices, PHP, Python, PaaS

Results:

##### Results for Witty Works

-   More time to focus on code/innovation, without the need to hire dedicated DevOps staff
-   Highly flexible resource allocation to handle heavier workloads
-   Better able to optimize application performance through continuous profiling
-   Greater efficiencies through fully automated deployments for all 4 applications based on GitOps via GitHub
-   ~ 60 production deployments/month

##### Results for Witty Works SaaS clients

-   60% reduction in time for human resources to create job descriptions
-   57% reduction in time for marketing to create blog posts
-   20% more candidate applications for recruitment

---

## Inclusive language shifts company cultures, one user at a time

Advantage Group. Deutsche Bahn. Infineon. Publicis Media. Riverside Natural Foods. Swiss Life. Switzerland Federal Department of Defense, Civil Protection, and Sport DDPS. These diverse organizations all have something business-critical in common: the imperative to create and sustain an inclusive workplace culture. To help ensure inclusive language is applied at all organizational levels, they’ve made a decision to integrate Witty—an AI-augmented digital language assistant—into their diversity, equity, and inclusion (DEI) programs.

Developed on Platform.sh and the Upsun PaaS by startup Witty Works, Witty operationalizes organization-wide inclusion by simply and quickly detecting unconscious stereotypes and biases in written communication—giving feedback to users in real time. By enabling staff to consistently apply inclusive language based on corporate language rules, Witty has proven to shift individual behavior _and_ company cultures.

Can’t wait to get to Witty’s technical bits? Here you go.

## Diversity and inclusion: we can build software for that

When Witty Works CEO and Co-founder Nadia Fischer entered the tech industry 12 years ago, she felt energized and elated about the innovation she’d become a part of. But as time went on, she made an observation that gave her pause: her company lacked gender and geographic representation. “Without more diversity, I felt we were lacking perspectives,” muses Fischer. “More broadly, while there were initiatives underway designed to help women and people of color to enter the tech industry, they centered on telling these groups how _they_ should behave differently to get into tech. That problem didn’t belong to them; it belonged to the companies spearheading the initiatives.”

In 2018, Fischer began to consult with and offer workshops to tech companies to further their diversity and inclusion initiatives. The result? “Disappointing,” she says. As companies proceeded to make DEI a box-checking, single-workshop exercise, Fischer dug into workplace research from Harvard Professor Frank Dobbin and from the University of Munich.

With the conviction that inclusive language builds inclusive cultures, Fischer knew there must be a software solution to help women, people of color, LGBTQIA+, persons with disabilities, and other communities gain inclusion parity. To determine just _how_ to approach solving the software challenge, Fischer invited innovative developer and former colleague Lukas Kahwe Smith to join her team.

## Startup success, dev challenges

When Witty Works CTO and Co-founder Smith joined the DEI-championing company in 2019, there weren’t any DevOps engineers. “I’m decent at server maintenance, but am not really an expert,” Smith explains. “Most importantly, I just didn't have the time to deal with it. So we adopted Platform.sh from the get-go.”

With the Platform.sh PaaS managing cloud infrastructure, data services, and security, Smith (flying solo) could focus his engineering energies on building and refining the Witty application. “I was quite happy using Platform.sh dev tools and my own Git workflows and tech stack,” shares Smith.

First, the team built a minimum viable software product that focused on inclusive language in job ads to ascertain if there would be market interest; there was. Then they initiated a financing round, and soon Witty Works was off and running.

That is, until Smith and team hit a bump. When they began to develop Witty’s machine-learning API in Python and Java, they found they couldn’t scale resources as flexibly as they needed to on Platform.sh alone.

“As a startup, resource allocation became an increasing challenge for us because you don’t want to waste money buying resources you’re not using,” Smith says. This conundrum became the catalyst for Smith’s exploration into other options.

## Weighing alternative solutions

Smith and team set out to identify a robust solution to address their resource challenges. But during discovery, he soon learned the alternatives (see below), “would have required much more DevOps work.”

1.  **Microsoft Azure.** Smith’s team built a setup on Microsoft Azure. “It ran for a little bit, including some automation,” Smith explains. “But then things started to break, and even with access to technical staff, they couldn’t fix our setup. It became clear that going directly to Azure wasn’t a viable alternative.”
2.  **Kubernetes, Massdriver, and Bunnyshell.** The Witty Works dev team also looked into Massdriver and Bunnyshell migrations, both of which would have required the team to build their own Docker containers. “We even delved a bit into Kubernetes,” says Smith. “Any of these may have been viable, but would have covered only a subset of what Platform.sh does. And would have required much more effort on our side, especially to maintain security. We would have had to pay providers like Snyk to deal with Docker container security. All of this adds effort and costs.”

Before Smith made his final decision, he learned about Upsun, a new, fully managed, self-service PaaS powered by Platform.sh (then in alpha). “It sounded like Upsun would solve the resource challenges we were facing and could be a perfect fit for us,” says Smith.

### Consider Upsun for these kinds of projects

-   Node.js, Python, Ruby, and Symfony
-   Multiapp, multidatabase, worker-heavy workloads
-   Workloads with complex runtime requirements, e.g., mix of runtimes, specific libraries

## Upsun: getting started with newfound flexibility

A proof of concept on the Upsun PaaS became the testing ground for Smith and a Witty application, which he got up and running quickly. Smith’s “familiarity with Platform.sh came in handy,” he says.

Upsun offered Smith exactly what he’d been searching for: a platform to meet the resource demands of custom code, microservices, and AI-rich projects. He felt confident migrating the Witty production setup to the Upsun PaaS alpha in the first half of 2023. “The underlying technology was rock solid from day one,” shares Smith.

## Witty from the inside, out

### API - custom Python app, calls into a Java server

Witty Works’ natural language processing (NLP) API consists of a Python FastAPI custom application that handles the bulk of the NLP analysis using the spaCy library and the Witty Works’ custom rule engine, _and_ also calls into a Java application—all hosted within a single Upsun project to ensure fast and secure internal network traffic. A custom machine-learning model using PyTorch (hosted on AzureML) is used for false-positive detection.

### Admin tool - Python, configures admin rules

The rule editor is a custom Python Django Admin application used by Witty Works linguists to maintain the configuration for their NLP API rule engine. This application also handles validating the accuracy of the rules by calling into the NLP API to test if the rule behaves as intended.

### Dashboard - PHP

DEI activities’ return on investment needs to be measurable and business-relevant. Through the Witty dashboard, staff can configure their individual and team writing highlighting; analytics provide organizations with insights into their teams' writing—and the most prevalent, unconscious team biases—to understand how behavior has shifted toward inclusion _and_ prove how that shift has impacted their businesses.

### Browser extension client - Javascript

The Witty browser extension, written in ReactJS, integrates into the browser to enable users to interact with the NLP API. Based on user privacy settings, the NLP API will review the text provided and automatically annotate it based on the personal and team configuration. Users are presented with a short learning bite on the bias underlying the given piece of text and are offered possible alternatives to choose from, along with the option to dive deeper into more learning content.

## Upsun features speed Witty’s development

As one of Upsun’s first adopters, Smith’s experiences and vital feedback helped the Upsun team refine current product features and consider new ones. Here are the features currently most relevant to Witty’s development.

### Flexible resources

Upsun’s flexible resources enable Witty Works developers to control their resources and users at both project and organizational levels, per application, per environment. Self-service, highly customizable, with no human intervention required, flexible resources address the team’s technology challenge _and_ the financial challenge many startups face: making the most of every investment.

### Horizontal scaling

The bulk of Witty’s business customers reside in Europe and North America. Over the course of a day, the load shifts into high gear for 16 hours, then winds down for 8 hours, punctuated by intermittent usage spikes. With this very predictable schedule —and real-time load metrics from the Upsun CLI—the dev team uses cron jobs to automate increases and decreases in the number of app instances according to this usage pattern.

```yaml
timezone: "Europe/Zurich"
    crons:
        # "Scale up at 07:30 on every day-of-week from Monday through Friday."
        upscale:
        spec: '30 7 * * 1-5'
        commands:
            start: |
            if [ -n "${UPSUN_CLI_TOKEN}" ]; then
                upsun resources:set -y --count app:${APP_UP_SCALE},java:${LANGUAGE_UP_SCALE}
            fi
        # "Scale down at 23:30 on every day-of-week from Monday through Friday."
        downscale:
        spec: '30 23 * * 1-5'
        commands:
            start: |
            if [ -n "${UPSUN_CLI_TOKEN}" ]; then
                upsun resources:set -y --count app:${APP_DOWN_SCALE},java:${JAVA_DOWN_SCALE}
            fi
```

### Observability, Blackfire

With integrated, out-of-the-box Upsun observability tools—including Blackfire support for Python—Smith and team monitor every component of the Witty application, detect any errors and anomalies, then quickly identify and resolve issues before they become major blockers. With continuous profiling in the Upsun console, the dev team can also pinpoint which parts of their application consume the most resources, then make informed decisions about optimizing performance.

### Security management

Upsun’s high levels of built-in security and compliance (including SOC 2 Type 2, PCI DSS Level 1)—fully automated and managed through the principles of the shared-responsibility model—give Smith’s team more time to focus on application code and innovation. No more server provisioning or security patching.

Through the Witty browser extension, Smith deals with sensitive data. Where that data is processed is paramount to Witty Works customers. “How we secure the data is a key question enterprise customers, in particular, ask during the due-diligence process,” explains Smith. “Business continuity through automated backups and deterministic deployment procedures that would enable us to migrate to a different data center in case of disaster are all things we have—thanks to core Platform.sh design principles.”

## What’s next: new capabilities open new opportunities

The Witty Works team continues to expand Witty’s capabilities and enhance user experience. Soon, an AngularJS-based Word add-in will enable users to highlight content directly in Word, whether working on their desktops or in a browser. A logical extension? Add-ins for company-wide communication channels like Outlook, Teams, and Slack. Available languages will extend beyond English and German to include French and Spanish, so the company can reach new markets. Based on research and trends, linguistic specialists will continue to build vocabularies based on research and trends to support specific communities.

“As the CTO of a still-small startup, I have both development and administrative responsibilities, so my time is limited,” Smith explains. “Moving to a platform that would have required more of my time to maintain the entire setup meant I would have had to reduce my time in other areas or hire someone part-time to take over some of those additional tasks.”

\* World Economic Forum. _Shaping an inclusive global economy by scaling impactful corporate DEI initiatives_. 10 January 2024.

### [YARD and CWS: 25M requests, zero downtime](https://upsun.com/blog/yard-cws-25m-requests-zero-downtime/)

# 25 million requests, zero downtime: how YARD and CWS launched in 7 days

Challenge: YARD and CWS had just seven days to launch a fan site for a major sports league event with no traffic forecasts and no room for failure.

Solution: Choose Upsun to deploy a JAMstack site with Git-based workflows and elastic autoscaling, enabling them to go live quickly and handle unpredictable traffic.

Stack: autoscaling, Git, API

Results:

-   The site went live in under 7 days
-   25M+ HTTP requests with zero downtime
-   Scaled automatically without overprovisioning
-   Deployed independently in just 3 days

---

_Discover how agency collaboration and a cloud application platform built for scale delivered without fail._

When YARD and Creative Web Solutions - CWS were tasked with launching a fan-facing campaign website for a major global sports league event in Paris, the countdown was already underway. Leading the project was We Are Digital Producers, overseeing coordination across teams, while Local Studio handled the creative direction. What was initially scoped as a four-month project compressed into a few short weeks. The site needed to be live within seven days of the campaign launch.

Traffic expectations were vague at best. The client provided no concrete estimates, only an indication that demand would be substantial. The team planned for peak loads to reach 7,000 requests per second but had to prepare for the unexpected. The infrastructure needed to be agile. Time and budget were tight. There was zero room for failure.

> "We've handled fast turnarounds before, but this was something else," said Grégory Driot, CEO and CTPO at CWS. “We had to get a live site up in days, and we had no visibility into expected traffic. We needed a platform that could carry us, technically and operationally.”

## **Choosing a platform that could keep up**

Traditional cloud hosting wouldn't cut it. Provisioning infrastructure for a worst-case traffic scenario would have driven costs through the roof and left them with idle resources after the campaign. They needed an infrastructure partner that could scale dynamically with demand, move as fast as they did, and provide support in real-time.

Upsun's elastic scalability and developer-first onboarding model stood out. Even though CWS had never worked with Upsun before, they were able to deploy independently within three days of signing up.

> "The onboarding process was honestly impressive," Grégory said. "We had never touched the platform before, and within 72 hours, we were deploying independently."

YARD led creative and production management, ensuring alignment with brand and campaign objectives. They relied on Upsun's support team to respond quickly to last-minute changes and evolving requirements.

> "Upsun felt like a partner, not a vendor," said Angélique Sénégas, Account Manager at YARD. “They were there on Slack, fast to reply, helping us work through last-minute changes. For a time-sensitive campaign, that made all the difference.”

## **The stack behind the speed**

CWS deployed a modern JAMstack architecture to deliver a performant front-end experience with decoupled back-end services. The stack included static site generation, API-driven services, and continuous integration via Git, all of which Upsun fully supported.

Upsun's infrastructure-as-code approach enables the team to stand up environments quickly and confidently. Its Git-native workflows, integrated directly into CWS's toolchain and preview environments, allowed for rapid internal approvals and collaboration. When it came time to go live, zero downtime deployment meant users never saw a flicker.

> "The platform gave our devs full autonomy. We didn't lose time figuring out the infrastructure; we could just ship," said Grégory.

## **Scaling on demand, staying online**

Once the site launched, the traffic arrived exactly as predicted: sudden, spiky, and sustained. The site served over 25 million HTTP requests during the campaign window. It sustained a monthly average of 5.36 million requests, peaked at 347 gigabytes of bandwidth, and logged more than one million requests in a single month post-launch.

Despite these spikes, the site experienced zero downtime. Upsun's autoscaling infrastructure scaled up to absorb demand and scale down immediately afterward. This not only preserved site performance but ensured infrastructure costs stayed aligned with actual usage.

> "We didn't overpay for idle infrastructure," said Grégory. “The platform scaled up when we needed it and scaled-down right after. That efficiency was a huge win.”

## **Turning pressure into performance**

For creative and technical teams under pressure to deliver fast, perform at scale, and stay under budget, this project offers a blueprint. YARD and CWS launched a global campaign site in under seven days, absorbed tens of millions of user requests, and kept everything running smoothly from the first hit to the final page view.

> "This project set a new bar for what we can accomplish on short notice," said Angélique. "Upsun delivered on every front: speed, scale, support. It's a platform we'll use again.”

The outcome wasn't just a functional website; it was a powerful one. It provided a reliable and scalable digital experience that adapted to real-time demand. With the right platform partner, YARD and CWS turned an impossible timeline into a launch-day win.

## **Confident launches start with the right partner**

The success of YARD and CWS wasn't a matter of luck. It came down to choosing a platform that made scaling simple, supported fast-moving teams, and delivered under pressure. With the right tools and partners, they not only met the brief but also exceeded it.

If you're building for events, campaigns, or product launches where failure isn't an option, this case study proves it's possible to deliver at scale without overprovisioning, rework, or stress. Don't wait for a crisis to rethink your infrastructure. Start with a platform that's ready for anything.

### [British hi-fi brand Cambridge Audio success | Upsun](https://upsun.com/blog/cambridge-audio-case-study/)

# British hi-fi brand Cambridge Audio has amped up significantly since selecting Upsun

Challenge: To find a trusted, reliable cloud platform provider with automation capabilities, timely security updates, and compatibility with Drupal and numerous other frameworks that could power an ecommerce website.

Solution: A hosting platform with automated updates, automated scaling, 24/7 community and support, compatibility with multiple frameworks for easy onboarding of new developers, and a significant boost in security and data protection.

Stack: Drupal

Results:

-   Average ticket response time: 9 minutes
-   Total deployments: 2,592
-   Deployment success rate: 99.9%
-   Friday deployments: 16.5%

---

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

Since 1968, Cambridge Audio has been developing high-end audio equipment to represent the true nature of sound to music enthusiasts around the world. From earphones and entry-level hi-fi systems to advanced speakers and premium setups, Cambridge Audio has won numerous awards that attest to the quality and value of its products.

For more than eight years, Povilas Uogintas has served as Cambridge Audio’s lead web developer. He’s been through many technical ups and downs with the company and knows the needs and challenges of managing its web presence by heart.

A major challenge Uogintas faced was finding a reliable hosting platform. The previous provider offered inconsistent support, which forced Uogintas’ development team to focus on infrastructure and vendor maintenance rather than building new features. Early in 2018, he decided to switch to a solution with Upsun.

## **Seamless implementation through native Drupal support**

Uogintas reflects on some of the difficulties he and his team had faced with Cambridge Audio’s previous hosting provider. While it controlled the server and server management, the company wasn’t responsive enough to his team’s needs.

“It was not efficient. Infrastructure simply was not there. We had to make PHP security updates and update everything ourselves,” Uogintas explains. “The whole updating process was archaic, something by the way of dropping FTP files. They didn’t really manage it. We needed to check everything all the time and ask them to make necessary updates. And they did—when we asked them. But it wasn’t the modern way of working. Nothing was connected.”

Uogintas began searching for a solution that would enable the Cambridge Audio team to shift its focus back to enhancing website functionality and delivering new features, instead of dealing with basic, mundane tasks. He wanted a provider that could offer automation and clear documentation. Recalling Upsun from a Drupal Camp London event, he started to compare its offerings to several other cloud solutions.

After evaluating many options, he chose Upsun.

“I liked that the documentation was more focused on developers,” Uogintas says. “Other documentation I saw was more about website builders and other things. Overall, I trusted Upsun more.”

Cambridge Audio has been using Drupal for its online store, but is also able to pull orders from external ecommerce sites like eBay and Amazon. Upsun was one of the first platforms that natively supported Drupal, which simplified the integration of Upsun with the developer workflow.

“Getting started was easy,” explains Uogintas. "The initial setup was already done, we just needed to learn a few new things, but it was not difficult at all.”

## **Gaining more time, flexibility, and security for developers**

Since Cambridge Audio adopted Upsun as its hosting solution, Uogintas says that developer productivity has improved significantly. His team doesn’t have to manage as many manual tasks as before, and can now focus on delivering new features to customers faster. 

One of the most helpful Upsun features to Uogintas’ team of three full-time developers, QA engineers, and contractors has been the branching feature.

“Spinning environments locally has historically been a hassle,” Uogintas explains. “But since we started hosting sites on Upsun, we can easily create a new branch, download data, and quickly copy a website, perform our testing, share our testing, share the testing to everybody, and then deploy all the changes upstream to the live site. That elevated us.”

The ability to test features on work environments associated with the branches has been especially helpful to identify bugs, improving the development team’s efficiency. Previously, the team tested new developments sequentially on a single test site—which slowed down their workflow. Now, they can test multiple new features in parallel.

> “We can create different branches, and we can create different security layers to make sure no business is going to be exposed. We can hide all sensitive things there and not allow anybody to poke around or copy anything. That’s a feature I wouldn’t know what to do without, from a security standpoint.”
> 
> **Povilas Uogintas**  
> Lead Web Developer  
> Cambridge Audio

Aside from faster and more frequent deployments, the branching feature also enables new developers to onboard quickly and progress through workflows more efficiently.

“If new contractors come in, we can create new branches in no time and set them up quickly and securely,” Uogintas explains. “They can do whatever they want in their own environments and not influence anything on the live site. And if you have a bigger team with lots of developers, it’s quite easy to create different users for different branches.”

## **An adaptable solution to react to traffic, improve efficiencies**

Uogintas says the ability to scale infrastructure whenever needed has been a tremendous benefit. If a site slows down when traffic volume increases, it’s been easy for Cambridge Audio’s sites to react quickly, scaling up to accommodate changing demand.

“The scaling options are more or less limitless. It’s easy to do. In the past, our site was misbehaving for different reasons,” Uogintas points out. “Historically, if we had more traffic, we couldn’t do anything. We couldn’t increase our service in a couple hours. But last Black Friday, for example, we were able to scale up one or two levels above.”  

Cambridge Audio’s website has been doing so well in fact, Uogintas and his team is upgrading their Upsun service to a higher tier.

“We’ve upgraded to d-24, the Enterprise level. We’re scaling up,” Uogintas says. “More users are using our website, more applications are being used. Our customer base is growing, which increases demand on our servers which need to be stronger, faster, better. The more things that need to happen on the site, the more we scale up as a business.” 

## **24/7 support and better security in a post-pandemic reality** 

Uogintas praises not only the technical features of Upsun, but also commends its support team for commitment and responsiveness. 

“We used to use the Slack channel. It was great. You had a problem, somebody pings you and solves the problem. But ever since we moved to Enterprise, we rely on your support, which is great. If we have issues, we raise tickets. Then that gets escalated and we get the answer we want,” Uogintas says. “It’s great.” 

Uogintas says he worries less about cyber attacks and security issues, too, which was a major reason he and his team decided to expand the use of Upsun to other websites and across multiple projects. To keep sensitive data outside of the code, Uogintas leverages Upsun variables.

“Let’s say our system has some website credentials, you can create variables, and they’re securely saved and stored with Upsun,” he explains. “So if our code ever gets stolen for some reason, all the variables are secured, which is nice.”

Uogintas also reveals that despite the COVID-19 pandemic changing how we live, work, shop, and interact with one another, things have been pretty good for him and his team at Cambridge Audio. 

“Everybody works from home now. Before, all the developers came to the office. Because we use Upsun, we can work from anywhere. We can just get a laptop going anywhere, essentially,” Uogintas says. “And that’s allowed us to hire developers from anywhere in the world.”

He also points out that during pandemic lockdowns people reevaluated their home audio equipment and decided to upgrade, which provided a boom in business for Cambridge Audio.

> “Websites have a lot of things going on, there’s a lot running behind the scenes to keep them going 24/7. All that means energy, and impact on the environment. That’s one of the reasons I’ve also been looking into Upsun, in terms of how green it is, and how it’s going in the same direction as our company.” 
> 
> **Povilas Uogintas**  
> Lead Web Developer  
> Cambridge Audio

“It was a rough time, but people still wanted to enjoy their music. So that’s why we’ve had to upgrade, in that regard,” Uogintas says. “And we’re moving into a more green-conscious, sustainability frame of mind, because it’s the right thing to do and that’s something Upsun can help with.”

Overall, Uogintas concludes that his team’s development workflow has become easier and faster than ever before since Cambridge Audio moved to Upsun.

“In general, we’re happy with Upsun,” he says. “We’re happy with the service, and we’re happy with where we are now.”

### [6,000+ applications, multiple CMSs, 1 platform | Upsun](https://upsun.com/blog/orange-fleet-management/)

# 6,000+ applications, multiple CMSs, 1 platform

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

Today we announced the expansion of our relationship with Orange—one of the world's largest telecommunications companies—to include a new project, Orange Cloud for Business Flexible Web Publisher. That's a long name, but the idea behind it is simple.

The solution is built on top of Upsun for website fleet management, which gives you access to an out-of-the-box cloud platform that supports provisioning and updating everything from PHP content mangement and ecommerce solutions to enterprise Java apps, Node.js apps, and static site generators. Upsun partners and customers can focus on business agility instead of the underlying infrastructure.

Orange Cloud for Business customers get the power of a modern, container-based developer experience to build and run their websites—with the CMS they choose, like Drupal, WordPress, Joomla, and PrestaShop—with the support of Orange, a brand they trust.

For Orange, Upsun provides a platform to provision and manage thousands of web apps for their customers, integrated with the Orange Cloud for Business brand and management tools, making it easy to onboard new customers—and scale current ones, as needed.

You can read more in our press release about Flexible Web Publisher here. Or connect with the Upsun team to find out more about our approach to website fleet management and how we help organizations scale.

### [Building an innovative virtual event platform | Upsun](https://upsun.com/blog/building-an-innovative-virtual-event-platform/)

# Building an innovative virtual event platform

Challenge: During the COVID-19 pandemic, create engaging, immersive virtual experiences that celebrate the film festival’s 50th anniversary and rival its world-renowned, in-person event

Solution: Leveraging Upsun capabilities, simultaneously build an API and apps and rebuild the festival’s website—delivering fresh, personalized attendee experiences and driving ticket sales

Stack: Drupal

Results:

-   Successfully moved a premier, international, in-person event online, delivering a 100% digital film festival built on the stable, highly scalable technical Upsun environment
-   Created a flexible, virtual platform that sets the stage for new, exciting digital opportunities and experiences for future festivals

---

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

## **Pandemic can't stop International Film Festival Rotterdam’s 50-year celebration**

From the glamour of the red carpet at Cannes to the rugged mountain beauty of Sundance, premier film festivals shine a spotlight on the best and brightest in cinema. The International Film Festival Rotterdam (IFFR) has been and remains widely recognized as a member of this marquee group.

In the wake of the COVID-19 pandemic, like a multitude of organizations, IFFR realized its 2021 event would need to be approached quite differently than any other before it.

With the challenge of creating engaging, immersive virtual experiences that rivaled its in-person festival, the foundation turned to the award-winning team at digital agency iO (formerly Burst). With clients like Mentos, Chupa Chups, Davidoff, Knauf, and Pfizer, the iO team applies its creative spirit and innovation to "make exceptional things happen for each and every client."

In its 50th year, IFFR champions the artistry of both emerging and established independent filmmakers, bringing their films to a wide audience. Historically, the festival has welcomed up to 340,000 in-person participants and more than 2,900 global film professionals each year to view 570 feature, mid-length, and short films from more than 90 countries; a high-quality lineup of exhibitions, performances, and master classes also share center stage.

## **Establish a technology foundation for the future**

The preparation for IFFR’s digital transformation actually began long before the COVID-19 pandemic. Five years ago—during the festival’s 2015 ticketing season—peak traffic volumes caused the foundation’s site to crash. That’s when IFFR engaged the iO team.

First, iO CTO Jeroen van den Berg and his team tackled the foundation’s server shortcomings, which had impacted its credibility, reputation, and revenue. "To support the 2016 festival, we began with just a Drupal 7 website," explains van den Berg. "There were integrations with the provider responsible for IFFR’s ticketing and user accounts and with the festival management system for the film information, program, volunteers, and the like. Ticketing went smoothly that first year, giving us the trust and confidence to build further on this foundation in the years that followed."

## **Set the stage for a premier solution**

"A little more than a year ago, we began to think about the very rich database of films the festival has access to, much like IMDb (Internet Movie Database)," van den Berg shares. "The database is not only a repository of information about the movies themselves, but about actors, directors, production crew, and more."

Recognizing the Drupal 7-based website had run its course, the iO team hypothesized about the next step for IFFR and the future of the platform. "What opportunities would emerge if we moved to an architecture where we’d first develop an API to open a wealth of information from all the backend systems to the world, _then_ build a variety of applications on top to consume it?" recalls van den Berg. "After discussions with IFFR, we collectively decided to move forward with this approach to propel the foundation and festival forward."

## **Drive innovation through simultaneous development**

Upsun gave the iO team the ability to work on the IFFR API, rebuild the IFFR website on Drupal 8, and have different teams develop new apps for the festival simultaneously—without having to worry about infrastructure or process.

> "The tooling Upsun provides makes it easy for us to spin up new environments, working with multiple developers. At one point in 2020, we even ran Drupal 7 and Drupal 8 side-by-side before we were 100% finished with the new site build and the migration of its content. This would have been challenging without a partner like Upsun."
> 
> **Jeroen van den Berg**  
> CTO  
> iO

On top of all this, the COVID-19 pandemic forced IFFR to digitize their 50th festival, showing hundreds of films online. To execute this monumental task, iO collaborated with other technology partners to build the film container—custom software that not only functions as a movie player, but includes panes that surface, for example, live Q&A chat sessions with a film’s director or with a panel of guests following a film’s showing, or background information about the film. And the panes can be displayed side-by-side.

## **MACH ecosystem delivers world-class user experiences**

A layer of data sources serves as the foundation of the IFFR solution, including the Drupal 8 content management system in an headless architecture, the customer relationship management system, a ticketing system, festival organizational management, and custom video-on-demand software. The IFFR API provides the middle layer between where the data is stored and where it’s wrapped up into a nice, neat package.

Touchpoints and apps sit on top of that API, offering features to enhance festival-goer experiences: from personalized schedules and film recommendations based on user profiles to social media posts and the opportunity to watch films in their entirety. It’s a perfect example of a modern Microservices, APIs, cloud-native Software-as-a-Service (SaaS), and Headless (MACH) ecosystem.

The first app iO developed on top of the API was the Film Finder app—designed to fill in gaps in a participant’s schedule. Like Tinder for movies, the app enables a user to view a movie trailer and respond to it by indicating, "I like" or "I dislike." Based on the responses and film tickets purchased, the app—in combination with Recombee, a SaaS machine learning API—begins to learn each user’s profile and builds movie recommendations aligned with those preferences. Says van den Berg, "It’s easy to Integrate the two APIs, and ticket sale conversions increased in just the first year in market."

The dynamic, In-Cinema Dashboard aggregates all social media posts associated with a specific hashtag and displays them, along with information about the film, on the big screen before a film begins to play. Built in-house by the IFFR team, the point-of-sale system assists IFFR volunteers onsite in the theaters. And IFFR Unleashed, the IFFR answer to Netflix, gives festival participants access to all the films for which IFFR holds the rights.

Through My IFFR, a user’s personal account, individual attendees can view purchased tickets, schedule, agenda, and more. Finally, iOS and Android apps and the IFFR website offer additional capabilities and points of access to complete the immersive, holistic user experience.

The 2021 IFFR public festival saw 132,286 online participants: 20.1 percent viewed online premiers, with 79.9 percent watching films on demand; reach beyond the festival’s physical borders increased by 16 percent. With the new digital experience, IFFR Pro Days (supporting filmmakers and guests) welcomed 4,492 participants to online panels and sessions—a 10 percent uplift of the overall number of participating professionals and number of countries represented.

> "We have managed to create a new virtual IFFR experience. The approach and construction of our digital landscape has greatly supported and accelerated the development of all individual applications. This would not have been possible without the decisiveness and flexibility of digital partners like iO and Upsun."
> 
> **Juul Veenboer**  
> Head of IT & Innovation  
> International Film Festival Rotterdam

## **Agility today, new and exciting opportunities ahead**

"By migrating the festival infrastructure to Upsun, IFFR has the agility needed to adapt to the new cultural norms driven by the pandemic," says Hans Maltha, iO founder and CEO. "Before COVID-19, the festival crowded the city of Rotterdam for 10 days each year with excited movie-goers. This year, the scalability, expandability, and tooling we’re able to tap into with Upsun helped us bring the event online, accommodating virtual crowds and burgeoning demand. In this way, we’ve made the festival’s 50th anniversary possible while creating new, exciting opportunities for future festivals."

### [Streamlining Imparfaite production releases | Upsun](https://upsun.com/blog/streamlining-imparfaite-production-releases/)

# Streamlining Imparfaite production releases with Upsun

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

Imparfaite, a marketplace for vintage women's apparel, relies on a steady stream of production releases to maintain its platform and roll out new functionality to its vendors. After several years on a variety of development systems, Imparfaite chose Upsun to improve speed, adaptability, and security. Given the company's needs, it made perfect sense to switch to this solution, explains Jérémy Laplanche, CTO of Imparfaite.

### **Imparfaite vintage clothing sold internationally**

Clothing sold on Imparfaite is truly vintage, guaranteed to be at least 20 years old. Many pieces in the company's inventory date back to the 70s, 80s, and 90s. 

"We currently have 100,000 products, and 99.9% of those are unique," says Jérémy Laplanche, CTO. The company operates opposite to fast fashion. "Fashion is the second highest polluting industry in the world. Our company focuses on bringing very high quality, sustainable textiles back to the market."

“Our suppliers include professional or semi-professional sellers, thrift stores, and secondhand clothing wholesalers,” Jérémy continues.  “Our partners are located in France and Belgium exclusively, and our customers are 50% in France, 25% in Europe, and 25% in the United States. 

"We also have a physical resale site. One example is the Vintage Fair that Imparfaite holds a few times a year, where the platform's sellers showcase their selection to a large audience."

The marketplace also sells secondhand items to create a monthly and inspiring selection that is featured on the site. 

### **The technical challenge of fostering autonomy in the switch to Upsun**

As a Upsun customer for one year, Imparfaite and its CTO wanted to "gain autonomy and flexibility, while lowering dev ops expenses." With no less than three projects at the end of 2022, another historic project, and many things to put into place, it took a solution that was both simple and agile to succeed, combining AWS and OVH.

In addition to the marketplace, other projects had to be migrated to Upsun. 

"We ultimately migrated a lot of small projects before moving the marketplace. We are currently working on a large project that involves tools for vendors, catalogs, and logistics."

Upsun offers the best solution for the pre-sales challenges facing Imparfaite.

-   The marketplace has a large number of users: our customers. 
-   Due to the sheer amount of items available for sale, Imparfaite must  accommodate many images. 
-   Although most of Imparfaite’s customers are in France, its marketplace also receives visitors from an international audience. 

### **Image management and optimization**

From day one, Upsun has offered Imparfaite an additional image optimization service on top of its CDN solution. This makes it possible to optimize images, which are often processed using server-side resources, with the help of the CDN. 

This lessens the load on the production servers and frees up space on the hard drive where the media files are stored. 

"In principle, only one file is needed, which the CDN optimizes instantly based on the specifications (resizing, enhanced photo quality, format conversion, etc.)," Jérémy explains. 

Not only does Upsun boost autonomy, it also improves performance and lowers the costs associated with managing image content.

### **A choice based on specific performance criteria**

Imparfaite chose Upsun based on thoroughly developed criteria.

As Jérémy Laplanche explains: "We wanted an affordable French solution that would allow us to gain autonomy, independence, and ease."

The company now has a three-person team working in production, including a lead dev that the CTO brought over from his previous company. A younger developer joined the team recently, and Upsun has helped him to easily evolve. 

"He still needs some training, but he can already release a development environment with 2–3 configuration files for testing," Jérémy says. 

Launched directly on PSH, Imparfaite still needs to wait a little longer to be able to observe analytical trends and key indicators, but it has already gained peace of mind throughout the deployment. 

"In one of our last projects without Upsun, we experienced a bug that took me an entire morning to resolve, but that is unlikely to happen with Upsun," the CTO said. 

Support has handled about twenty tickets over the past year, which is just right for this ramp-up period!

### [TEACH is recruiting the next generation of diverse teachers | Upsun](https://upsun.com/blog/teach-is-recruiting-the-next-generation-of-diverse-teachers/)

# TEACH is recruiting the next generation of diverse teachers

Stack: Drupal

Results:

-   Current number of websites: Eight
-   Average ticket response time: 16 minutes
-   Total deployments: 1,032
-   Deployment success rate: 98.7%
-   Friday deployments: 14.5%

---

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

TEACH, a national non-profit organization founded in 2015 by the U.S. Department of Education, works with states and metropolitan areas to develop sustainable teacher talent pipelines to ensure K-12 students have the diverse, high-quality teachers they deserve.

According to TEACH’s own research, many Americans are open to the idea of teaching. But they may not choose that career path due to misperceptions about the job and barriers they encounter as they apply. 

“Obviously, education is one of the foremost important aspects of any society,” says David Dowell, TEACH’s Web Development Lead. "States and districts across the country are facing some of the most severe teacher shortages in history at a time when students need excellent, diverse teachers more than ever. TEACH works every day to bridge that gap."

TEACH’s work focuses on identifying, cultivating, and supporting teaching candidates to apply to an educator preparation program, setting them on the path to leading their own classroom. To make that possible, TEACH works to find candidates and show them what a teaching career can offer. TEACH then guides those candidates through the process of selecting and applying to a teaching program. 

“We want people to understand how much the teaching profession has to offer and how they can get their credentials,” David continues. “What makes a good teacher? How much does the profession pay? What are the requirements? We're trying to both address misconceptions about the profession and help people understand how to pursue it to grow the pipeline of future educators.”

## **A set of online recruitment tools in need of constant upgrades** 

TEACH uses an array of recruitment methods and practices to recruit possible teachers, including a tech-forward approach in the shape of a Digital Recruitment Platform (DRP), a set of online tools that help states identify, cultivate, and support tens of thousands of prospective teachers at a time. Those tools include:

-   Tech for candidate outreach (such as email, social media, text messaging)
-   A web portal that acts as a “one-stop shop” for getting into the teaching profession
-   A customer relationship management database 
-   User analytics

TEACH’s DRP requires constant improvements to ensure the best online tools are available to build interest in teaching and to make the process of selecting a teaching program as frictionless as possible. It also needs a sustainable deployment process that works, using different frameworks configurable for both general and partner-specific models. And not only that, TEACH needs the right infrastructure to build on so it can grow and manage an increasing number of regional websites dedicated to each state or municipality. 

Since the beginning almost a decade ago, TEACH has sustained a partnership with a PaaS that can handle the DevOps side of maintaining its technology—an ally that can provide the necessary architecture to maintain the DRP, the scalability to expand nationwide, the security and compliance to protect confidential information, and alignment with the mission to raise awareness of teaching’s importance. 

For TEACH, only one supplier made sense. 

## **Upsun was TEACH’s choice from the start**

Since TEACH partners with the public education system in each state, it was imperative to find a technology partner that doesn’t see the organization as another number, but as a personalized client. 

“Whenever we interact with Upsun, they always treat us with respect and give us whatever DevOps support we need, when we need it,” David explains. “We just love the customer and service support. Every single ticket we've ever put in has had a good turnaround response. And I would say, like, 90%-plus of the time, they’re providing as much information as possible, above and beyond, to help us diagnose whatever we’re dealing with at the time.”

The ease of templating, environment deployment, and simple functionality has also enabled TEACH to reach its goals. 

“Architecture-wise, there’s Drupal templating support on the back end, with a pretty slick system for being able to hierarchically orient and configure environments for deployment,” David continues. “And being able to push the different environments from staging to production to live and then also to sync the databases pulling backwards—a lot of that is just one-click push button functionality. That's really helpful.”

## **Expanding into new regions while keeping data safe** 

TEACH aims to expand into every state, so scalability has been top of mind for TEACH Senior Project Manager Andrew Das.

“We're always trying to grow our structure,” Andrew adds. “Each new region requires us to open up a new website. That requires a partner that will scale with us as well. We have partners from seven states working with us, plus a national site. That’s eight sites on Drupal right now. And we’re hoping to expand and grow into different markets and regions each year.”

Another important factor for a non-profit in the education sector is adhering to the best security and compliance practices, primarily the Family Educational Rights and Privacy Act (FERPA), a federal law that protects the privacy of student education records.  

“That's very important, how we treat our users’ data security,” Andrew continues. “We take data security very seriously, similar to how medical companies are HIPAA compliant. Consequently, it’s important that Upsun can localize data and keep it secure depending on where someone is located around the world.”

## **Easy, breezy, educational**

Working with Upsun has also made onboarding developers easier for TEACH. 

“With Upsun, developers can get onboarded pretty quickly. That was a major factor in our decision,” Andrew says. “You don’t have to worry about getting additional onboarding for any dev that comes here. They can come here, and they know they can use the same commands they usually use.”

But their favorite part of the nearly decade long relationship? 

“I was in DrupalCon last year and they were just overwhelmingly positive, friendly, helpful—any and all questions about how databases are handled or set up, or configuration options within the system, the answer to all those questions came really easily,” David says. “And I think, for me, that's the number one thing that you're looking for with a managed host now. That level of personal attention and support. If you don't have to go through a three-tier system of automated responses to set up, then have someone respond to you—that's really key and I think Upsun has that human connection and level of support.”

And that level of support continues to aid TEACH in its mission to support student learning. 

“Teaching is a challenging and rewarding career,” Andrew explains. “You can be like a hero, and shape the next generation. So we're trying to build that message using technology. We want people to consider teaching as their next profession, and we’re working to make it easier to accomplish. ”

“We’re trying to be the bridge,” David adds. “To connect people from thinking of teaching as an idealistic thing, something amorphous, into a real opportunity.”

### [Hosting for Hildesheimer Allgemeine Zeitung | Upsun](https://upsun.com/blog/hildesheimer-allgemeine/)

# Hildesheimer Allgemeine Zeitung

Stack: Drupal

---

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

## **With Upsun, the Hildesheimer Allgemeine Zeitung is ready for any headline**

When construction workers in Hildesheim found a British aircraft bomb back in August 2014, the entire inner city was evacuated within a few hours in a large scale operation unlike any that had ever been seen before. One that led to 20,000 people having to leave their homes, workplaces, and businesses to seek safety as it was unknown whether the bomb was equipped with a long-term detonator and required a controlled detonation, or not.

This day remains unforgettable for the people of Hildesheim and for their local daily newspaper, the Hildesheimer Allgemeine Zeitung, too. The Hildesheimer Allgemeine Zeitung was regarded as the most reliable source of information for all Hildesheim residents and on the days following the bomb discovery, they turned to it to find out what would happen next with the evacuation and bomb detonation. And while the newspaper was diligently updating the news to inform residents, a problem emerged - their website was completely overwhelmed by the increased number of visitors, and crashed.

"We were standing with our backs to the wall and couldn't do anything," recalls the Hildesheimer Allgemeine Zeitung's Head of IT, Alexander Loss.

Four years later, Storm Chiara sweeps across Germany and hits Lower Saxony. Due to the storm, many roads and railroads were blocked alongside trees crashing on homes and cars which required fire departments to be deployed to numerous locations across the region. Once again, thousands of residents are affected and turned to the Hildesheimer Allgemeine Zeitung website for information and guidance. But this time the website remained fully operational and all visitors were able to access it without a hitch. 

"Generally speaking, the number of visitors to our website is relatively foreseeable, but as a newspaper we are always having to deal with adhoc situations that then result in lots of traffic," says Loss with regard to the emergency situations. "At the time we did already have Fastly, but no high-performance platform beneath it. A website just can't keep up when there are thousands of visitors at the same time, and that's definitely what I noticed about our server when we were still doing the hosting ourselves. But now, with Storm Ciara, we didn't have any problems. Everything worked wonderfully, as it should," says Loss.

So the question is, **how did they do it?** 

## **Upsun is the "all-round carefree package"**

The Hildesheimer Allgemeine Zeitung was founded in 1705 and is Germany's oldest daily newspaper that is still in circulation. And to tackle the issues they had been facing with their current website management, Loss was searching for a new reliable and efficient hosting provider which would be able to deal with all types of web traffic issues in the future. As up until that point, Loss had hosted on their website on the company's own server, which gradually became more cumbersome. 

"We only have a small IT team and I have more or less taken care of this area by myself. It was very time-consuming and stressful," he says. "Everything eventually became a thick cluster that I had built myself in order to be able to absorb the burden should there once again be too many visitors trying to access the website. In terms of technology, it had gotten to be quite advanced, but then it got to be so big that you couldn't adequately deal with anything at all.”

Since 2014, Loss has been working with Tim Lochmüller from the tech agency HDNET. Shortly after the Hildesheimer Allgemeine Zeitung experienced the website disruption due to the bomb find, Loss came across a blog article by Lochmüller about high-performance websites and contacted him in order to get advice on the performance of his own website. HDNET then began to oversee the website and recommended Upsun for the site relaunch.

"Though we do have two in-house specialists for AWS and AZURE, Upsun was the first choice for the Hildesheimer Allgemeine Zeitung," says HDNET developer Lochmüller. "It was the best solution and an inexpensive alternative, as Fastly, which the Hildesheimer Allgemeine Zeitung was already using, comes with the Enterprise package.

"The alternative would have been to host through Amazon, Microsoft or Google. But as a provider that supplies everything as an 'all-round carefree package' from one source, Upsun was the clear choice in this situation. And everything turned out to be a wonderful fit.”

## **Optimal infrastructure, no matter how many entities**

The Hildesheimer Allgemeine Zeitung used Upsun for the complete redesign of its website. Both Loss and Lochmüller were quickly won over by Upsun's efficient CLI tool and praised its user-friendliness and easy access to all infrastructure components via the console. And they’re now happy to be able to sit back and relax when it comes to infrastructure management.

"The console's performance is unrivaled. You can solve everything if you know the right commands, and the versioning is awesome from start to finish," says Loss. "The backups are great - everything is reversible. Everything just makes sense and I don't want to have it any other way.”

Beyond the website, which was built with TYPO3, Loss manages other Wordpress entities that he would like to migrate to Upsun. His goal is to do away with using the company's own hardware and instead give up his responsibilities as system administrator so that he can fully focus on developing features. And Lochmüller agrees: “For me as a developer, a good infrastructure stands out when I notice it as little as possible and it's easy for me to interact with it. This is exactly the case with Upsun.”

## **Easy to get started with thanks to workflow integration and reliable customer support**

Upsun was able to be quickly and smoothly incorporated into the developer workflow after a quick installation of the Upsun integration in Bitbucket. However, even if there were any questions or issues, the Upsun Team offers 24/7 global support for all customers.

“In terms of technology, everything worked very well," says Lochmüller. "We were always able to reach someone with Upsun and we received an answer within just a few minutes if there was a question. The Slack channel in particular was great for onboarding."

“Everything has been running really smoothly, and with Jonas, Solutions Architect at Upsun, we had an excellent contact person for technical concerns who quickly addressed our issues in a way that's hard to beat” adds Loss.

## **Increasing deployments, decreasing costs**

With Upsun, the developers for the Hildesheimer Allgemeine Zeitung can now quickly and easily update the development environment via command line. "Keeping the local system in sync with the master system was previously very demanding. Now it takes just a few minutes and we save quite a lot of time," says Lochmüller.

And with regard to testing new features, developers now use the production environment's fast cloning instead of testing manually, which is very time-consuming. "For us, the topic of the test system was always associated with a lot of manual labor," explains Loss. "Today  we press a button and you get a snapshot of the entire system, and you can test it and develop it. It's simply great."

In addition, Loss says that the Hildesheimer Allgemeine Zeitung saves not only time through the use of Upsun, but money as well. "Upsun is more budget friendly than what we were previously operating ourselves," he says. **“For us it is one-third less expensive.”**

## **Strong interest in COVID-19 reporting**

Since the outbreak of COVID, many news websites have to be able to deal with growing visitor numbers and provide the general public with news about the actual situation 24/7. While some newspapers haven't been able to adequately cope with the new visitor numbers, the Hildesheimer Allgemeine Zeitung has had no issues with providing its readers with around-the-clock news. According to Loss, website visits have doubled during the COVID crisis, which has amounted to 3 million visitors and 6 million page views.

"The people of HIldesheim inform themselves around the clock about new developments, guidelines, and behavior patterns," says Loss. "And the website functions smoothly, without any issues."

Do you want to know if our platform is the solution for you? Get in touch with our team today and let’s find out.

### [GrantStation: platform for cutting-edge research | Upsun](https://upsun.com/blog/grantstation-drupal-cloud-migration-case-study/)

# GrantStation: using a cutting-edge cloud platform to help fund cutting-edge research

Challenge: To maximize the speed, performance, and reliability of a Drupal-based subscription database of grant opportunities and tutorials

Solution: Upgrading to a hosting solution that included improvements to server setup, software additions, and development and staging environments

Stack: Drupal

Results:

-   The ability to clone branches in order to seamlessly test functionality additions, improvements, and fixes—in a secure, safe manner—before pushing them live to customers
-   The ability to clone branches in order to seamlessly test functionality additions, improvements, and fixes—in a secure, safe manner—before pushing them live to customers

---

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

Nonprofit research is the lifeblood of science. And grants are the lifeblood of nonprofit research. Government and industry fund millions of dollars in grants every year. The trick for researchers is to find, among the thousands of grant opportunities, the ones designated for their area of studies and the parameters of their projects.

GrantStation guides nonprofit organizations through the grantseeking process with a curated database of vetted funders and in-depth tutorials. The site’s deep customization and search capabilities let customers quickly sort through the many funding and educational opportunities at their disposal. To support these capabilities, GrantStation needs to maximize the speed, performance, and reliability of its server and software. For that, GrantStation relies on Upsun.

“Our developers have been able to work well with Upsun to meet a variety of challenges over the years,” says Cecily Borzillo, GrantStation’s director of site technology, “including improvements to our server setup and software additions. Using Upsun, we’ve been able to make use of development and staging environments to seamlessly test functionality additions, improvements, and fixes—in a secure, safe manner—before pushing them live to our customers.”

## **Modernizing to meet customer needs**

Before migrating to Upsun, the GrantStation website resided on ASP and ASP.NET. The technical limitations of the hosting site handcuffed GrantStation in frustrating ways. “It had a lot of really outdated dynamic link libraries,” says Borzillo. “We couldn’t update the website, that’s how bad it was. We couldn’t add new products or change product prices or anything like that.”

Having such an obsolete hosting solution did offer one advantage, Borzillo jokes. “Our site was basically unhackable because the code was so ancient.”

Now powered by Upsun, the GrantStation site, which runs on Drupal, has the capacity and flexibility to offer up all its users ask for. “We’ve got everything on Upsun right now,” says Borzillo. “For instance, we offer on-demand courses on topics such as successful grant writing, raising funds from local businesses, and building a grant strategy. All those courses are hosted on an instance of Moodle that we have on one of the environments at Upsun.”

> **Using Upsun, we've been able to make use of development and staging environments to seamlessly test functionality additions, improvements, and fixes—in a secure, safe manner—before pushing them live to our customers.**
> 
> **Cecily Borzillo**  
> Director of Site Technology  
> GrantStation 

## **Providing developers’ favorite features**

Switching to Upsun opened up a whole new world of features for GrantStation. “We really like the ease with which we can spin off development environments from our master development environment,” says Borzillo, “to be able to just do development in various branches. And we love the version control features. It’s easy to make mistakes when you’re developing, even if you test things thoroughly. To be able to pull back a commit at the last minute is just so handy.”

One new feature that Borzillo is eager to take for a spin is the “Metrics and Observability” tab that’s been added to the management console for production environments. From that tab, developers can see CPU, RAM, and disk usage across all their hosts. They can pull back to view their usage over the course of a day or zoom in to study individual measurements. And each metric comes with utilization thresholds that alert you to any potential problems.

“Any additional information that we can get is always useful, especially with regards to how our website is performing: threshold issues, peak times that people are reaching in our site, what the bandwidth looks like given the numbers of hits that we’re getting,” shares Borzillo. “Right now, our server performance is sort of a black box. More data around that will be very helpful.”

> **Upsun has done a really good job with technical support and customer service, at reaching out to us to find out what we need. That's made us feel like we're valued as customers, that we're not just another paying client.**
> 
> **Cecily Borzillo**  
> Director of Site Technology  
> GrantStation

## **Customer care keeps GrantStation coming back for more**

As long as researchers need funds to fuel their projects, GrantStation will be there to help them find the perfect funding. And as long as GrantStation needs to provide high-octane performance, Upsun will be there to fuel its server and software. Knowing Upsun is always at their side keeps GrantStation signing back up.

“Upsun has done a really good job with technical support and customer service, at reaching out to us to find out what we need,” says Borzillo. “That’s made us feel like we’re valued as customers, that we’re not just another paying client. It’s kept us in love with being with Upsun and goes a long way toward making us want to re-up when it’s time for a new contract.”

### [Ascent: tech agnosticism, freedom, and lower costs | Upsun](https://upsun.com/blog/ascent-tech-agnosticism-freedom-lower-costs/)

# Ascent: tech agnosticism, freedom, and lower costs

Stack: Drupal

---

_Note: Wondrous changed its name to Ascent._ _This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

When clients engage a digital agency, what are they looking for? Creativity (check). Talent (check). Innovation. (definitely, check). But at the end of the day, what clients _really_ want are solutions to problems they haven't yet been able to solve on their own. And that's where digital creative studio Ascent shines.

Established in Switzerland in 2008, Ascent designs and develops best-in-class user experiences and bespoke digital solutions with latest web technologies. They approach projects from a user’s perspective and commit to solving them creatively. Ascent CTO and Managing Partner Rainer Friederich describes the team as a _little family._ And for the last five years, this committed, 23-member family has experienced near-zero turnover.

Finding the best solution for each challenge means not being locked into any one technology. Rather, the Ascent team chooses the technologies that will yield optimal results and delight their global clients. Clients like healthcare pioneer Roche. Pharma giant Novartis. And one of the most-recognized premium car and commercial vehicle manufacturers in the world, Daimler.

## **Simplifying workflow, radically reducing costs**

Friederich and his team created and maintained client projects on Acquia, Heroku, Amazon Web Services, and others. They chose these providers for different reasons: a strength in workflows. Hosting capacity. Support for a particular language or framework. But Friederich wanted a provider that enabled him to implement a simple, consistent workflow for Ascent developers across all client projects—a goal that was complex and difficult to achieve.

For the last five years, the Ascent team has had twelve Drupal 8 projects on Acquia; workflows were cumbersome. “While it's possible to automate workflows with Acquia, it's difficult to do. It takes a lot of work, and you have to use vendor-locked Acquia libraries and workflows you won't find anywhere else,” explains Friederich. “The Acquia workflow could just not compete with Upsun.”

> Overall with Upsun, we can handle a higher volume of projects—and work on more projects concurrently—than we could before.”
> 
> **Rainer Friederich, CTO and Managing Partner, Ascent**

Upsun capabilities don’t require the Ascent team to engage in any manual interactions. “It sounds so simple,” Friederich says. “But if you trust your change and have reviewed it on a feature branch or in a development environment, you just merge the PR, and you’re done. You can close the project and move on to other work.”

Beginning with the easiest project first, the team began to move one Acquia project after another to Upsun, until all the projects had been migrated. With projects now on Upsun, they made the decision not to train any new developers on Acquia workflows. “It would have been a complete waste of time,” says Friederich. “We’re now completely free of Acquia, and that’s a good thing.”

> Upsun enables us to use a single solution provider for all the different technologies and approaches we use for our projects. We see this as our number-one Upsun benefit.”
> 
> **Rainer Friederich**

Today, when Ascent developers begin a new Upsun project from scratch, they can use their own template to completely set up the project remotely—the production environment, all deployment workflows, and everything else—in under 20 minutes. Friederich describes this process as just insanely good. “At this juncture, I would never consider buying some server hardware somewhere and writing all the deployment scripts and so on; it’s just unthinkable,” concludes Friederich.

#### **80% Reduction in infrastructure resource and workflow costs**

Another scenario where Friederich shared Acquia couldn’t compete with Upsun? Price. After migrating its twelve Drupal 8 projects from Acquia to Upsun, Ascent was able to reduce infrastructure resource and workflow costs by 80 percent.

Finally, Upsun workflows and automation help Ascent save significant time compared to previous providers and keep maintenance and support costs low—resulting in more profitable client support contracts.

## **Modern and natural for developers**

As noted, it’s paramount for the Ascent team to have the flexibility to use the languages and frameworks most appropriate for any given client project. And that’s a pivotal reason Ascent developers embraced Upsun.

“When you work with Drupal on Platform sh, you work with a standard, modern, state-of-the-art approach to PHP programming and management,“ explains, Friederich. “It’s much more natural for us to work with Drupal 8 on Upsun because all the Symfony projects that we do in PHP or Laravel all work the same way.” In contrast, “Working with Drupal on Acquia is like we used to work 10 years ago; you need special knowledge, and it’s a steep learning curve. We want a technology-agnostic approach to working with software,” says Friederich.

Earlier this year—when Ascent launched a team dedicated to client support and developing small, new features—they onboarded a new developer who was new to both Upsun and to Drupal 8. After minimal training over the course of a week, the developer was basically able to work on 20 different projects. “Two or three years ago, I could never have imagined that developers could work on more than three different projects in a day; with Upsun, it's possible to work on 10 different projects,” Friederich shares.

The Ascent team chooses the languages and frameworks (including Drupal, Laravel, Node.js, and Symfony) and technologies that will yield optimal results and delight their global clients.

### **The Upsun features Ascent loves**

-   **Feature branch environments**   
    _I could not imagine how to develop without it anymore. The ability for multiple developers to work on multiple features simultaneously, together with the Upsun CLI, is very, very handy for maintaining all of our projects._
-   **Git integration and integrations with GitHub**   
    _We use them on all projects!_
-   **Support**   
    _Amazingly fast response time for critical issues, always on time for non-critical issues. Those responses are well formulated and quite helpful._

## **Successful solutions for projects and clients of all sizes**

From small clients with a single website to enterprise clients who need the scalability to meet the demand of hundreds of thousands of users, Ascent has taken advantage of Upsun capabilities to build solutions across the spectrum. All leveraging the same workflows.

### **Small project, education client**

**Challenge**   
Migrate six or seven smaller websites into one new Drupal website, setting up a volume of very, very complicated redirects for all the old URLs prior to go-live.

**Outcome**   
_This work was so simple with the Upsun routes.yaml. That saved us a lot of work, which otherwise would have had to be done manually in engineer's config._

### **Complex project, midsize customer**

**Challenge**   
Gain flexibility and performance improvements.

**Outcome**   
_By moving from Acquia to Upsun and adding Cloudflare on top, we’ve been able to significantly boost performance and reduce costs by 40%. And now we can have at least five open feature/bug fix environments to review with our client; the previous development model—with static dev, stage, and prod—only allowed two._

### **Large project, enterprise client**

**Challenge**   
Develop an intranet that could scale to support 200,000 authenticated users on demand.

**Outcome**   
_At launch, the site scaled to support all authenticated users without any manual intervention on our parts. Upsun gave us a hand by providing onboarding and amazing support with this complex infrastructure landscape. Two days post-launch, we got an email from the client saying ‘everything's so great and running so fast; we’ve never had a system before that could take the load!’ That was a real success for us._

## **Strength in small numbers**

A small, tightly knit team, with a strong company culture. A strategic client partner, with a passion for delivering innovative, sustainable digital solutions that make a difference. Solutions that Ascent hosts, whenever possible, on Platform sh. “An agnostic approach, excellent support, security, and cost-effective pricing are the reasons we stay with Upsun,” Friederich concludes.

### [Uppler: Onboarding customers 10x faster | Upsun](https://upsun.com/blog/uppler-onboarding-customers-10x-faster/)

# Uppler + Upsun: Onboarding customers 10x faster

Stack: security, SaaS applications

---

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

## **Fast and easy for the online B2B marketplace leader**

Uppler offers a software suite that allows its users to create their own B2B marketplaces, e-procurement platforms, or B2B e-commerce sites, with the most advanced B2B e-commerce features on the market. Their mission is to help companies become online leaders in their sector by streamlining relationships between buyers and suppliers, allowing them to interact and carry out transactions conveniently online.

The platform is suitable for all industries. Every company that has a central role in its industry or that has an intermediary role between supplier and buyer can use this platform, in sectors such as fashion, agrifood, automotive, furniture, or even cosmetics. Uppler is a software SaaS solution that makes it possible, with a single version, to create completely different platforms with different performance levels and security levels to suit each and every customer. This is their biggest day-to-day technological challenge. Customers require very distinct, isolated, and secure environments, all with a single software version.

They also require their data to be isolated and easily deployed, which was simply not possible with their previous hosting provider. A need to abstain from this aspect of creating and deploying an environment, which took too long to maintain. A demand to scale easily and securely, according to the customer’s needs, the platform’s traffic, and the amount of data involved.

The main objective was therefore to get away from all this DevOps work, to be able to isolate their tools, and deploy faster and more easily.

> The main objective was to automate our DevOps procedures while improving security and support.
> 
> **Emilien Bouard**  
> CTO

With projects for enterprise companies in highly sensitive sectors, such as defense, nuclear energy, and the general public, Uppler often faces very strict requirements regarding the location of servers, data protection, and the location of hosting data centers.

Upsun allows Uppler to have dedicated environments in multiple regions to suit the needs of each customer, such as servers in France for French customers.

The ease of multiple deployments—and having the same technical foundation for each of Uppler’s marketplace platforms—is a huge advantage that makes it possible to deploy their infrastructures all at once, with the CLIs and controls/tools they normally use. The same code and infrastructure are used for all projects, making it possible to carry out multiple deployments at the same time. Creating a new environment for a new customer is now an automated process, which saves considerable time.

Uppler now enjoys the benefits of working with the PaaS, Upsun. Uppler was able to adapt its hiring strategy, particularly for the operations team, as many support and on-call tasks could be separated and managed by Upsun. Significant time savings come from the ease of deployment—just a git-push to deploy everything, making it possible to create new environments and su-benvironments quickly for acceptance and pre-production testing. Everything the CLI offers for Upsun also saves time and makes it easier to use on a daily basis.

> It only takes one git-push to deploy everything.
> 
> **Emilien Bouard**  
> CTO

Uppler’s operations team has not increased the frequency of its deployments, but it takes much less time because everything is automated. In fact, deployments now take about 20 seconds, compared to 2-3 hours in the past. It is also ten times faster to set up a new environment for each new customer.

Working with Upsun allows Uppler to offer its customers the ability to choose their hosting provider and where their data will be located. That is a very reassuring point. For French customers, for example, the ability to perform onboarding and monitoring in French is a major advantage that adds a great deal of convenience. Uppler can therefore move faster and more securely, which allows them to see far in advance and adapt on a large scale.

> Installing a new environment for a new customer takes a tenth of the time.
> 
> **Gregoire Chauvin**  
> CEO & Co-Founder

### [ Ibexa: exponential growth with their SaaS](https://upsun.com/blog/how-ibexa-achieved-exponential-growth/)

# How Ibexa achieved exponential growth with their SaaS launch

Stack: SaaS applications

---

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

“We’ve doubled our growth every year for the last three years running,” says Roland Benedetti, senior vice president of strategy at Ibexa. This remarkable span of growth began when the digital experience platform company launched its white label cloud offer powered by Upsun.

Building a container-based Platform-as-a-Service (PaaS) capability that supplies clients a single tenant copy of your application while still allowing you full management of the WebOps platform is both complex and expensive. That’s why in 2016, rather than risk building a cloud infrastructure themselves, Ibexa chose to let a more experienced vendor—Upsun—implement one for them.

Recently I had the chance to sit down with Roland Bendetti to discuss Ibexa’s pivot to a digital experience platform provider and how they chose Upsun to facilitate that pivot. We also dug into some industry trends that have shown Ibexa’s decision to be a savvy one.

## **“A technical partner we can work with.”**

Ibexa serves 400 large enterprise customers around the world, including the Financial Times, the Economist, and Groupe Atlantic. It recently changed its name from eZ Systems after switching away from its outdated content management system persona.

“We’re way more than a content management system now,” says Benedetti. He describes Ibexa as a platform for building digital capabilities that allow users to capture data for building new business models and connecting them to other business processes.

Although Ibexa’s current eZ Platform cloud offer, powered by Upsun, has driven significant growth for the company, this isn’t their first attempt at launching a Software-as-a-Service (SaaS) offer. But previous hills proved too steep to climb.

> We just didn’t have the systemic knowledge or domain expertise to build a working offer at this complex intersection of application and infrastructure. So we concluded that we would go faster if we teamed with experts.” — **Roland Benedetti**, Senior Vice President of Strategy, Ibexa

A version of eZ Platform that launched in 2012 as a SaaS offer allowed developers to configure the way it worked. “But we had the wrong positioning strategy,” says Benedetti. “The offer would have worked better had we been competing with Wykes, Squarespace, or Wordpress, but that wasn’t really us or our direction. Our customers were more complex and wanted to build up themselves from the platform.”

So Ibexa tried a different tack. “Our second attempt was to build what we now call a PaaS, with a partner providing data center hardware but no automation layer. We had some similar concepts to the Upsun PaaS: our automation was based on Git with quick deployments and a DevOps approach. But it didn't succeed as it was regarded as a side project, without proper funding and with resources still focused at the application level.”

As all good companies do, Ibexa learned from its missteps. “We just didn’t have the systemic knowledge or domain expertise to build a working offer at this complex intersection of application and infrastructure,” admits Bendetti.“So we concluded that we would go faster if we teamed with experts. That’s when we found Upsun, a technical partner we could work with!”

## **“It’s all about speed and value.”**

Benedetti outlined the value delivered to its customers by the Upsun white label cloud offer. “First, they are now able to more easily develop new digital sales channels and relationships. Second, buyers are much more in control these days, expecting and getting an impeccable, frictionless experience. Third, they get increased business agility and speed.”

He also expanded on the growing customer need for agility and speed. “Nobody quite knows where their digital transformation will take them or where the end point is, so they need agility. It used to take up to 12 months to deliver CMS on-premise, which is too long. Customers need to test new projects in weeks and perhaps change strategy accordingly. It’s all about speed and value.”

When asked about the change in market perception of the eZ Platform product after Ibexa’s introduction of its Upsun cloud offer, Benedetti replied, “Our market identity used to be added value for developers and brand owners. Now, we’re going up the ladder, addressing operations, reducing the number of vendors, removing the classic hot potato of whose responsibility it is when things stop working. The customer is now removed from this operational complexity. So we’re speaking more to C-levels as they see us as a more global solution to their transformation efforts.”

Benedetti says the capabilities that Ibexa has gained since launching its Upsun white label include:

-   Accelerating internal roadmap delivery and therefore winning much bigger deals and winning them earlier. This has had a double whammy effect on revenue and gross margin growth.
-   Generating incremental revenue and bigger gross margins and therefore sharply increasing company valuation.
-   Gaining insight into customers beyond the DXP target business management persona. C-levels are now taking notice of the lowering of hosting complexity and cost paired with the speeding up of feature delivery.

## **“You will always need code. And for that you need a PaaS.”**

I took the opportunity to ask Bendetti his opinion of the headless CMS movement. “Headless is a very good option,” Benedetti says. “eZ Platform can be used easily with a Node.js front end, for example. The Upsun PaaS is critical as it allows our cloud customers to run any technologies they want, but together, and neatly decoupled from the DXP backend.”

On the subject of managing large numbers of sites and brands (what we at Upsun call “FleetOps”), Benedetti says, “The PaaS-based cloud offer is a far more suitable standardizing technology for multiple projects. The Financial Times and Groups Atlantic are now able to build individual properties on a single platform to consolidate and rationalize without constraint.”

He adds, “The Upsun capabilities for fleet management are great; they resonate well with similar features inside eZ Platform. Service managers can do different things for different brands, some of which are at different levels of maturity but have the same values for cost rationalization, teams, HR, and simplified vendor management. This is working for both Ibexa and customers, especially when we see consolidation and acquisition.”

All of the components and flexibility on offer from Ibexa, combined with the typical enterprise business process environment, requires a development, testing, and deployment platform that allows for many APIs and applications to work together.

“Some customers are still too idealistic,” says Bendetti, “looking for pure SaaS offerings. So we spend time helping them understand that building complex digital experiences inevitably requires code. We empower their development teams to do as little coding as possible, but they will always need code. And for that you need a PaaS.”

This doesn’t mean to say an existing SaaS solution cannot sit comfortably next to a white label PaaS. Upsun has software vendor customers who are already selling multi-tenant SaaS to SMB. Their subscribers can easily and seamlessly upgrade their contract to an enterprise grade offer running on a white label version of the application on Upsun.

## **Learn how to launch your own white label**

You might think building a business case for making a strategic change similar to what Ibexa undertook would require a team of external consultants. Not true. Having been round this loop several times now, we’re well practiced in walking organizations through the process. We run video and on-site workshops to work out how the transition to a white label cloud offer can be done and what the effect on the rest of the business will be. Companies have found this to be a highly valuable exercise, even those already planning to go out to RFP.

### [Dipli accelerates growth with scalable hosting | Upsun](https://upsun.com/blog/refurbishment-platform-dipli-case-study/)

# Refurbishment platform Dipli enables growth and innovation with Upsun

Challenge: To mitigate the challenges of inflexible cloud infrastructure—a complex network of environments, inability to handle traffic peaks, and unreliable tech support—allowing Dipli to scale with the pace of demand

Solution: Transition to Upsun, simplifying production and enabling seamless scalability with 24/7 proactive support

Stack: Scaling, green, sustainability

Results:

-   Simplify operations and decrease deployment time
-   Reduce operational and financial stress
-   Improve budget accuracy
-   Increase data-driven insights
-   Scale resources to meet demand
-   Solve issues proactively

---

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

Dipli is an all-in-one tool for end-to-end management of the consumer electronics refurbishment supply chain. Through device procurement, refurbishing, and multi-channel distribution, Dipli gives electronics a second life while reducing its customers’ carbon footprints. 

In a 2024 IBM study, 76% of executives said sustainability is central to their organization. Dipli taps into a much-needed market for environmentally friendly device management, supporting brick-and-mortar retailers, e-commerce sites, IT service providers, and more.

The company saw rapid growth, but backend challenges left its team scrambling to keep up with demand. Their hosting solution struggled to handle spikes in traffic. What’s more, they were forced to juggle multiple production, staging, and development environments, adding time and complexity to every project. And perhaps worst of all, they felt alone in managing these challenges, frequently waiting on unreliable, unresponsive tech support.

When Dipli Co-founder and Chief Operating Officer Tanguy Pennel discovered Upsun, he saw a comprehensive solution—one that could enable, rather than inhibit, his company’s growth.

## **A solution for every problem** 

“Prior to Upsun, we struggled with several key issues,” Tanguy explains, recounting the team’s challenges with scalability, pre-production environments, and tech support. “But Upsun has addressed all of these challenges. 

“We now have flexible resourcing. The ability to effortlessly scale on demand allows us to seamlessly manage unexpected traffic spikes and peak demand times. 

“Also, with simplified environment management, creating and managing development and pre-production environments is now a breeze. 

“Finally, your highly responsive technical support team has been crucial in helping us navigate complex situations and optimize our platform usage,” Tanguy concludes. “The Upsun team often identifies and resolves issues proactively—sometimes even before we notice them ourselves—giving us incredible peace of mind.” 

In a short time, Dipli’s partnership with Upsun solved each of its biggest tech challenges. But the team also discovered another substantial benefit: financial predictability.

## **How predictable pricing supports innovation at Dipli**

According to Tanguy, the transparent pricing at Upsun allows Dipli to better anticipate and control costs—which has led to increased innovation. 

Having a clear picture of upcoming costs leads to more accurate budgets, helping to avoid the stress of unexpected expenses. The Upsun dashboard also enables careful resource and consumption analysis for each project, highlighting opportunities for optimization and enabling data-driven decision-making.

Without the stress of reactivity, Dipli’s team no longer worry about cost fluctuations and overages. This gives them the freedom to focus on more impactful work: creative problem-solving and innovation.

## **Top 4 reasons Dipli recommends Upsun**

Unreliable systems can affect all areas of your business. Luckily, Tanguy has advice for other organizations struggling with growing pains.

> _For any company in our industry considering a move to Upsun, I would highly recommend it. Here's why:_
> 
> -   _**Simplified Operations:** Upsun takes care of infrastructure management, freeing your team to focus on core business activities._
> -   _**Increased Scalability:** The platform's flexible resourcing allows you to effortlessly scale as your business grows._
> -   _**Enhanced Security:** Upsun offers robust security features, ensuring your applications are well-protected._
> -   _**Improved Developer Productivity:** The streamlined development environment facilitates quicker deployments and faster innovation._
> 
> _–_ _Tanguy Pennel, Co-founder & Chief Executive Officer, Dipli_

Upsun and Dipli may be united through our partnership, but that’s not all. Both organizations share a passion for reducing the environmental impact of evolving technologies. This sustainable approach can benefit organizations in all industries.

To learn more about our commitment to sustainability at Upsun, check out our approach to greener hosting.

### [UNICEF Switzerland and Liechtenstein: Sustainable IT | Upsun](https://upsun.com/blog/unicef-switzerland-greener-migration/)

# Empowering UNICEF Switzerland and Liechtenstein through greener hosting: a long-term partnership for sustainability

Challenge: UNICEF Switzerland and Liechtenstein needed to align its IT operations with its sustainability mission. Moving to a Swiss data center offered lower carbon emissions and satisfied data locality requirements. The goal was to reduce their environmental impact, ensure data security within Switzerland, and maintain reliable performance.

Solution: Partnering with Upsun, UNICEF Switzerland and Liechtenstein migrated to Swiss data centers powered by renewable energy (CO₂ emissions as low as 80–90 mg per kWh*). The solution included enhanced security via Cloudflare (which was easily and seamlessly integrated with the Upsun solution), an intuitive management interface, and seamless scalability for digital operations.

Stack: sustainability, green

Results:

-   Reduced carbon footprint: Migrating to Swiss data centers with Upsun, a Greenly-certified provider with yearly sustainability audits, reduced UNICEF Switzerland and Liechtenstein’s environmental impact, with CO₂ emissions lowered by up to 15x through the switch to a low-carbon grid
-   Operational efficiency: Simplified management freed up resources for mission-critical work. Enhanced security: Robust protection ensured data safety and sovereignty compliance
-   Mission impact: Cost and energy savings were reinvested into UNICEF’s initiatives, amplifying their impact on children worldwide

---

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

### **A mission rooted in responsibility**

For UNICEF Switzerland and Liechtenstein, ensuring a sustainable future for children has always been at the heart of its mission–to protect the rights of every child in over 190 countries and territories. But as the digital landscape became more critical to their operations, they faced a growing challenge: they did not have visibility of the carbon footprint of their existing infrastructure or data on their other cloud related sustainability attributes. Hosting their digital operations in legacy data centers outside of Switzerland posed significant environmental, data sovereignty, and operational challenges.

It wasn’t just about maintaining performance and security. It was about rethinking their infrastructure to better align with the global sustainability mission they champion every day.

### **Sustainability and sovereignty in IT**

UNICEF Switzerland engaged their web agency MD Systems to examine the carbon footprint of the web application and evaluate measures for improvement. Incremental performance optimization could improve the resource use of the application by 20%. The legacy hosting with a high carbon footprint was identified as the measure with the greatest leverage effect. Moving the hosting to a data center with higher efficiency and greener energy.

The question wasn’t just _where_ to host their infrastructure, but _how_ to approach the transformation. Should they refactor their applications entirely for a new hosting model, or migrate to an eco-friendly, modern platform that could minimize disruption?

### **A seamless migration to greener hosting**

After careful evaluation, UNICEF Switzerland and Liechtenstein chose to build on their existing partnership with Upsun, embracing a migration-first approach. This strategy allowed them to move their digital operations from their previous data centers in Dublin to Swiss data centers powered by an energy mix with a high renewable component \[a mix that includes some nuclear and other grey energy\], achieving a dramatic reduction in their carbon footprint while ensuring data sovereignty and high performance.

Unlike a full application refactoring—which would require significant time, resources, and potential disruption—the migration allowed UNICEF to achieve their sustainability goals quickly and effectively. By transitioning their infrastructure from one Upsun region to another they were able to upgrade their sustainability profile while preserving operational continuity.

#### **Key features of the migration:**

-   Eco-friendly infrastructure: Hosting in Swiss data centers powered by renewable energy, achieving CO₂ emissions as low as 80–90 mg per kWh—far below industry benchmarks.
-   Enhanced security: Advanced security measures, including integration with Cloudflare, provided UNICEF with robust protection and compliance with sovereignty requirements.
-   Operational efficiency: A user-friendly management interface enabled quicker updates and localization, empowering UNICEF to respond faster to regional needs.

### **Turning challenges into opportunities**

#### **1\. Carbon footprint reduction**

Migrating to Upsun greener hosting solution helped UNICEF Switzerland and Liechtenstein significantly lower the environmental impact of its digital operations. With Swiss data centers operating on renewable energy, the shift reinforced their commitment to global sustainability goals.

#### **2\. Operational efficiencies**

The Upsun platform simplified website management, saving valuable time and resources. With faster deployment cycles and easier localization capabilities, UNICEF’s team could focus on mission-critical work rather than IT overhead.

#### **3\. Cost savings and reinvestment**

Energy-efficient hosting reduced operational costs, allowing UNICEF to reinvest those savings into their core initiatives. These efficiencies amplified their ability to deliver critical services to children globally.

#### **4\. Data sovereignty and security**

Hosting within Switzerland ensured compliance with local regulations, while Cloudflare integration strengthened cybersecurity measures—critical for protecting sensitive donor and beneficiary data.

### **A partnership built on innovation and shared values**

For over five years, Upsun has been a trusted partner to UNICEF Switzerland and Liechtenstein, driving innovation and sustainability. The recent migration marked a significant milestone, but it was only one chapter in a long-term collaboration rooted in shared values.

Manfred Ruf, IT Manager at UNICEF Switzerland and Liechtenstein, shared: _"The partnership with MD Systems and Upsun has consistently exceeded our expectations. Their innovative solutions and greener hosting practices have advanced our sustainability goals and allowed us to focus more on our core mission of improving the lives of children."_

### **Refactoring vs migration: the smart choice for sustainability**

While refactoring applications for a new hosting environment can sometimes be necessary, the Upsun approach demonstrated the value of strategic migration. By leveraging their existing infrastructure and transitioning it to a sustainable platform, UNICEF Switzerland and Liechtenstein avoided unnecessary complexity and disruption.

This approach highlights an important lesson for organizations: achieving sustainability goals doesn’t always require starting from scratch. With the right partner, you can modernize your operations while maintaining continuity.

### **Leadership in green IT**

UNICEF Switzerland and Liechtenstein’s move to greener hosting sets an example for nonprofit organizations worldwide. By partnering with Upsun, a certified B Corp with gold medals from EcoVadis and Greenly, they demonstrated how sustainability and operational excellence can go hand-in-hand.

_**"By migrating to Swiss data centers powered by renewable energy, UNICEF Switzerland and Liechtenstein significantly reduced its carbon footprint, aligning its digital operations with its global sustainability mission."**_ **– Manfred Ruf**

### **Impact beyond IT**

The partnership’s benefits extend beyond environmental impact. By aligning its IT operations with modern donor values, UNICEF Switzerland and Liechtenstein strengthened its engagement with stakeholders and donors who increasingly prioritize sustainability. The cost savings generated by energy-efficient hosting were reinvested into programs that directly benefit children, creating a ripple effect of positive change.

### **Looking ahead**

UNICEF Switzerland and Liechtenstein and Upsun are not just adapting to a greener future but actively leading the way. Together, they continue to explore innovative solutions to reduce environmental impact and inspire other organizations to embrace sustainable IT practices.

_**"The partnership with Upsun has exceeded our expectations, enabling us to advance sustainability goals while focusing on improving the lives of children worldwide."**_ **– Manfred Ruf**

UNICEF bases its commitment on the principles of tolerance, mutual understanding, solidarity, and peace between peoples. The children's relief organization opposes any kind of discrimination, is politically and denominationally independent, and works to improve the living conditions for children in developing countries. Learn more about UNICEF and how you can make a donation.

_\*CO₂ emissions as low as 80–90 mg per kWh averaged over a 12 month period._

### [Truth Initiative enhances its web platform | Upsun](https://upsun.com/blog/truth-initiative-delivers-scalable-site-capacity/)

# Truth Initiative delivers with scalable site capacity

Challenge: To find a way to deploy faster and more frequently, supporting the continuous evolution and delivery of the anti-nicotine messaging at scale

Solution: Quick and easy capacity site scaling to respond to sudden upsurges in web traffic from viral education campaigns

Stack: Drupal, Scaling

Results:

-   Improved ease of deployment with code branches able to be pushed independently as needed
-   Improved ease of spinning up an environment for each feature branch
-   Drupal support for Varnish caching enabled by Fastly CDN
-   Ability to quickly configure multiple services made it possible to run Drupal 8 on PHP and MySQL, powered by a separate backend application using Symfony and MongoDB

---

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

Truth Initiative® is spreading the truth about smoking, vaping, and nicotine. The nonprofit, founded after the 1998 Master Settlement Agreement, gives teens and young adults the facts about the addictive properties of nicotine and how the tobacco industry continues to target younger users with its marketing.

Several of the initiative’s recent education campaigns tapped into the viral influence of TikTok, inviting young people to create short videos about the creative ways they’ve quit vaping. These campaigns inspired user-created videos and attracted more than 13.1 billion views. They also inspired a rush of visitors to the nonprofit’s two websites: truthinitiative.org and thetruth.com. To guarantee that the sites, both built with Drupal 8, could adapt their capacity to the most viral of promotional successes, Truth Initiative chose Upsun as their end-to-end web platform provider.

## **How to handle one million hits**

“When we launch our campaigns,” says Truth Initiative’s Derrick Butts, chief information and cybersecurity officer, “our network infrastructure needs to be able to handle the jump in web traffic. We once debuted a campaign, and our websites received millions of hits over the following 24 hours. There’s a feeling of excitement with that kind of success, but also a feeling of concern, wondering if our site would be able to sustain greater traffic loads over a short period of time. So we started looking into how we could do things better.”

Butts went in search of a platform provider that would enable Truth Initiative to scale up site capacity easily and quickly at the launch of a campaign. He began to look closely at Upsun after having a chance to speak to some of the company’s clients. The more he looked, the more he liked.

> Upsun has greatly improved the way we deploy our code branches and spin up our environments. When we're looking at different locations to stage production-type sites, Upsun allows us to migrate between them seamlessly as a native platform.
> 
> **Derrick Butts**  
> Chief Information and Cybersecurity Officer  
> Truth Initiative

“The fact that Upsun is a software-based Platform-as-a-Service offers a lot of advantages,” Butts says. One of the advantages he recognized was the tight integration Upsun has with code repositories like GitLab. Butts realized that capability would enable Truth Initiative to streamline their configuration and deployment processes.

“Upsun has greatly improved the way we deploy our code branches and spin up our environments,” says Butts. “When we're looking at different locations to stage production-type sites, Upsun allows us to migrate between them seamlessly as a native platform.”

## **Free Fastly feels fine**

As a nonprofit, Truth Initiative also needed a provider that packed a lot of value into their offering. Seeing that the Upsun offering included the Fastly CDN caught Butts’ attention. “A lot of providers only offer CDN tools and services as add-ons,” he says. “So the fact that Upsun includes it as part of their service offering makes it more cost-effective. But also, the CDN is integrated into the services. As I migrate from one platform to another, it gives me less things to have to worry about and manage.”

Through Fastly, Truth Initiative can take advantage of Drupal support for Varnish caching. “We were able to run Drupal 8 on a PHP container with MySQL, and still be able to pull from a separate backend API built with Symfony and MongoDB,” explains Butts. “Upsun made that all easier since they already had that mapped out in their offering to add on services like that.”

#### **Did you know?**

-   19.6% of high school students are current e-cigarette users
-   4.7% of middle school students are current e-cigarette users
-   Nearly 3 million youth use flavored e-cigarettes
-   From 2019 to 2020, the proportion of e-cigarette users using flavored e-cigarettes increased from 68.8% to 82.9%

_Source:_ _National Youth Tobacco Survey 2020_

## **Keeping the message fresh and the website fast**

Truth Initiative migrated to Upsun in the summer of 2020. Butts couldn’t have been happier with how smoothly it went. “Upsun had a pretty thorough approach to the migration,” he explains. “They talked through every detail with us, they tested the backend, and they constantly double-checked with our developers to make sure that things were in place. We completely avoided the typical deployment disruptions we’d experienced with other platforms and methods.”

> Upsun had a pretty thorough approach to the migration. They talked through every detail with us, they tested the backend, and they constantly double-checked with our developers to make sure that things were in place. We completely avoided the typical deployment disruptions we’d experienced with other platforms and methods.
> 
> **Derrick Butts**  
> Chief Information and Cybersecurity Officer  
> Truth Initiative

Now that everything has been migrated, Butts and his team are excited to take advantage of the steady stream of new technologies flowing out of Upsun. As Truth Initiative draws up its website roadmap for the next few years, they’re keeping the Upsun upgrade rollout schedule nearby. The foundation wants to be able to use every tool at its disposal to keep teenagers out of the nicotine industry’s grip.

“According to a survey we released in January 2021, 60 percent of current e-cigarette users between the ages of 15 and 24 want to quit vaping within the year,” says Butts. “For us to get and keep young people’s attention, our message has to constantly evolve. That’s why it’s important for us to have a platform that's going to constantly evolve as well.”

### [Pixelant's TYPO3 success story | Upsun](https://upsun.com/blog/typo3-specialist-pixelant-sets-productive-future/)

# TYPO3 specialist Pixelant sets path for a productive future

Challenge: To eliminate a cumbersome infrastructure management process that consumed the dev team’s time and energies and slowed workflow to a crawl

Solution: Adopt Upsun to streamline workflow, refocus development skills on new client features, experiences, and solutions

Results:

-   75% cost reduction over previous shared hosting solution
-   Streamlined workflow/increased efficiencies
-   Newly found flexibility to focus on, experiment with, and test ideas quickly—without worrying about server code
-   Formation of a collaborative relationship with Upsun to develop new tools, client features

---

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

## **Leading TYPO3 specialist streamlines workflow, reduces costs, sets path for a productive future**

High-profile customers like Cabinn, Denmark’s largest budget hotel chain; Sparbanken Syd, the world’s oldest independent savings bank; and the University of Vienna, one of Europe’s oldest educational institutions all rely on Upsun digital agency partner and TYPO3 specialist Pixelant.

Since 2006, Pixelant, part of full-service marketing agency Resultify, has delivered website development, design, and management solutions—along with services to measure and optimize website performance—to corporations, agencies, and universities.

With a commitment to consistently delivering the best value to its customers, Pixelant offers “everything TYPO3”– the open-source content management system (CMS) based on PHP.

Over time, the Pixelant team found itself spending more time managing infrastructure than building new features. Cloudnet, Pixelant’s managed hosting provider, imposed a heavy infrastructure modification process that required Pixelant to contact the provider every time they wanted to implement even minor changes; this approach significantly slowed the team’s dev workflow. Eventually, Pixelant founder Robert Lindh began to look for a more flexible solution. And he chose Upsun.

## **Upsun features save time, reduce maintenance**

To support its growth goals and enhance efficiencies, Pixelant adopted Upsun in 2018. The agency’s in-house TYPO3 Consultant Mathias Bolt Lesniak reflects on Upsun’s ability to instantly clone environments from production, a feature Pixelant has found indispensable when working on large website projects.

“Moving large amounts of data between your local computer and the live environment is extremely time-consuming, and there are so many things that can go wrong,” says Lesniak. “With Upsun, we’re saving so much time—including in terms of support and maintenance—by being able to keep the test environment as close as possible to the live environment.”

With Upsun, Lesniak explains, the Pixelant support team no longer has to go through every single website to implement changes. For example, running Composer upgrades now occurs automatically across all websites, no matter how many. The support team simply runs some tests to ensure the functionality and publishes upgrades to the live site right after validation.

> “Our developers don’t have to think about setting up databases, copying data over, and all those kinds of things. That makes it possible to really work specifically on development.”
> 
> **Mathias Bolt Lesniak**  
> TYPO3 Consultant  
> Pixelant

## **Common technologies smooth migration and workflow**

Common technologies made Upsun easy to integrate into Pixelant’s existing development ecosystem and enabled developers to use it with their current knowledge—an advantage for newcomers or freelance developers joining the dev team—all while maintaining overall team productivity.

Another aspect of increasing efficiency meant streamlining development workflow, a blocker with previous hosting provider Cloudnet. The inability for the team to deploy containers—a must for containerized local development environments with Docker—meant Pixelant couldn’t preserve a consistent environment from development to production.

“We wanted to create a continuous deployment process in our company and optimize it,” says Pixelant CTO Dmytro Hrynevych. “Since Upsun uses similar technologies like Git, we were finally able to achieve this goal.” Adds Lesniak, “Upsun makes it possible for us in a very simple way to achieve some of the things that we couldn’t get with our old shared hosting environment, such as security and deployment workflows.”

“Coming from a shared virtual hosting environment with limited resources, changing to Upsun was a major step for us,” Lesniak remembers. “We had to be a lot more aware of the resources being used by our application, and that was a big learning curve. With Upsun, we now think more about our resource usage as we develop. And that will serve us well over the long term.” Lindh adds, “We’ve received a lot of help and advice from the Upsun support to make the transition work for us.”

## **More freedom and flexibility, less DevOps**

#### **75% hosting cost reduction**

Today, Upsun takes care of Pixelant’s infrastructure management, lightening the dev team’s workload. “Our developers don’t have to think about setting up databases, copying data over, and all those kinds of things. That makes it possible to really work specifically on development,” says Lesniak.

The Upsun branching feature lets the team create testing environments to simplify collecting feedback and preventing bugs from reaching production. “We’re using Upsun capabilities to clone environments that we can share with either clients for approval or our QA team for testing, when needed,” explains Hrynevych. “There’s greater flexibility when it comes to taking changes live,” adds Lesniak. “But underneath the technical side, there’s even more in the security realm, which makes Upsun a really good, safe place to be for our clients.”

Pixelant’s client sites were previously hosted on shared servers. With Upsun, each site now has its own closed, secure environment. Eliminating concerns about security frees the Pixelant team to focus on massive deployments and strategies.

“And the pricing is a nice bonus. We cut our costs by 75% compared to our previous solution,” says Lindh.

## **A collaboration that benefits more customers**

Pixelant and Upsun have begun to collaborate on several projects to enhance the PHP development experience. To better monitor, fix, and optimize applications, Pixelant developed a graphical analysis tool for Upsun PHP projects. Initially developed for internal use, Pixelant decided to open-source the Upsun Log Analyzer tool to benefit other Upsun customers deploying PHP projects.

“The graphical analysis tool visually shows what’s happening on the server,” explains Lesniak, who developed the tool. “It helps to pinpoint how resources are used and in which context.”

When servers receive an influx of requests and show high memory usage, the tool helps to identify performance issues by revealing the exact distribution and causes of resource consumption. It also establishes a relationship between the types of requests and their responses.

The Log Analyzer Tool collaboration between Pixelant and Upsun was just the beginning of a myriad of future joint projects targeting PHP and TYPO3 users.

## **T3Kit: upgrading the TYPO3 experience for agencies**

To enhance the TYPO3 experience for clients, Pixelant created T3Kit, a ready-to-use package of components tailored to web agencies that develop TYPO3 websites. “T3Kit is not just a standard website template; it’s all the building blocks you need to easily create enterprise-ready websites that are customizable to individual needs,” says Lesniak.

Pixelant’s long-standing experience with agency clients enabled its team to quickly identify relevant services and features, such as Apache Solr search and Google Maps integration. T3Kit contains a comprehensive library of components—like page layouts, sliders, and accordions—that meet the unique needs of customers and agencies of all sizes. To stay on top of the latest TYPO3 features, T3Kit is being adapted to the new TYPO3 10 Version, released in April 2020 as LTS-Version.

To capitalize on the partnership with Upsun, Pixelant plans to integrate a Deploy on Upsun button for its T3Kit users—making development faster and easier.

If agency clients want to opt for a fast solution that requires minimal coding, they can use the T3Kit WYSIWYG editor to customize default components behavior and generate the corresponding TYPO3 configuration. Users will then be able to deploy the edited website to Upsun with the click of a button.

> “The collaboration with Upsun is a way for us to better support our current clients and tailor to new clients who need the B2B features we already have in place. It also proves that Upsun is an ideal enterprise hosting solution for B2B providers.”
> 
> **Mathias Bolt Lesniak**

The Deploy on Upsun button is only the first step in a wider collaboration aimed at providing a fully featured, enterprise-grade B2B solution. Pixelant’s objective includes the integration of a product manager to nest products and the synchronization to Product Information Management (PIM) systems without sacrificing the performance of a website—regardless of how many products there are to display.

Lesniak shares, “Not only will you be able to deploy with a push of a button, but you’ll also get a website with a product module that lists all of your products, all ready, set up, and connected to your PIM system.”

## **Moving forward into a productive future**

Pixelant’s commitment to serving clients with the most advanced technology solutions made it natural for the agency to strive for a future-proof hosting provider and partner. Pixelant’s move to Upsun not only enhanced its dev team’s flexibility, but also created a strong partnership with mutual support.

“I would definitively say that Upsun is a strong partner for us. It’s not just about hosting—it’s about workflow and the approach of building sites,” says Lesniak.

As Pixelant works on a myriad of ways to improve clients’ TYPO3 experiences, like the collaboration with Upsun to enhance T3Kit, both teams look forward to further cooperation on future projects. In the meantime, Pixelant’s developers continue to leverage Upsun and their newly won flexibility.

> Our developers are happy with Upsun. They really like it, which is the most important factor for us to flourish as a company.”
> 
> **Robert Lindh**  
> Founder  
> Pixelant

### [The Swiss duo enhancing development workflows with a PaaS | Upsun](https://upsun.com/blog/oris-liip-paas-development-efficiency/)

# Faster. Smarter. Greener. Oris and Liip enhance their development workflow with a PaaS

Challenge: Communication, stringent requirements, developer needs, tight deadlines

Solution: Container-based approach, robust CLI, automated backups, Green Swiss region

Stack: PaaS

---

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

Celebrating over 120 years of mechanical excellence and beauty, Oris has been a pillar of sustainable, independent Swiss watchmaking since 1904. By forging its own path and sticking true to its values, Oris has built a renowned brand and a stunning product range which they have continued to innovate and expand over the last century. Expansion which today includes a sharp, intuitive web and ecommerce platform. 

Having initially hosted their website with another hosting provider, Oris came to Liip, their digital agency, to consolidate their providers as they already had some Drupal applications running successfully on Upsun. A PaaS provider that they had found ready-to-use, simple to configure, and offered similar features to their previous hosting provider. With the added bonus of streamlining their providers to establish an easier, centralized developer experience. 

## **The agency partner to forge the PaaS** 

Liip has delivered industry-leading strategic digital projects for its customers for over 15 years—9 of which they’ve spent as a dedicated Upsun customer. From consulting and development to the final go-live for standout web applications, award-winning mobile applications, and data-driven ecommerce hubs, Liip has consistently developed long-lasting, user-centric, open-source products for hundreds of customers. 

Customers including Freitag, Zurich Tourism, and more, whose applications the Liip team has chosen to build and run on Upsun time and time again. What has led to their track record of successful projects across a diverse tech stack and why is a PaaS useful for digital agencies in today’s market? The Liip team is here to tell you through the lens of their key long-term customer, Oris. 

## **What is a PaaS?**

Already know the answer? Skip to the next section to continue with the story. For those in need of a little more background, a PaaS—or Platform-as-a-Service—is a cloud computing model where a third-party host provides a business with a complete development and deployment platform—learn more. 

## **The PaaS features that sealed the deal**   

Following the success of various other customers using Upsun to support the development of their applications, the Liip team was quick to pitch the switch. Focusing on a few key attributes that aligned with Oris’ brand and application requirements—scalability, CDN, and a platform that was quick and simple to get started with. As well as the Liip development team’s preferences and needs, specifically, quick and simple development environments to allow them to manage the development of different features simultaneously across both Oris’ applications and those of their other customers. Developers were able to focus on developing the application while Upsun automated all of the infrastructure management. 

### **Simple, no-configuration resource settings**

Our container-based approach assigns default resource settings to every project created on Upsun—depending on the chosen plan—enabling developers to get started as soon as possible. This is a key component for Liip in managing its many ecommerce customers, including Oris, which require fast-paced, scalable production often across multiple sites.

Resources can then be customized to meet the changing requirements of a particular application at any time. Liip can easily scale resources up or down on both horizontal and vertical dimensions to serve the needs of the Oris website. Then with auto-scaling, all that manual work is taken care of for them during unplanned traffic surges. Auto-scaling capabilities kick in by detecting site timeouts and immediately triggering an upsize, whether you’re dealing with millions of requests per hour or managing thousands of applications. A handy tool during busy sales periods. 

### **A robust CLI with comprehensive coverage**

An easy-to-use, highly functional user interface was crucial for Liip, and by proxy Oris, in a hosting provider. No one wanted to spend time figuring out how to navigate an over-complicated platform, especially when it came to small changes and tight deadlines. The Upsun CLI uses Git as its main API added to REST API to manage the platform and accomplish tasks efficiently, with its source code hosted on GitHub. All of this was familiar territory for the Liip development team and meant they could get moving quickly, and all from one place as anything you can do within the Upsun web user interface Console can be done with the CLI. 

### **Automated backups for secure development** 

The Liip team alleviated the need for manual backup management with our automated backups feature. Lifting a weight off the development team’s shoulders when it came to Oris’ application security and maintenance. For all Production environments on Upsun, which Liip is using, a daily complete byte-for-byte backup of your entire environment, including the stored data, is taken at least once every day. Maximizing application security while maintaining optimum uptime as backups between 03:00 AM and 05:00 AM in each project’s timezone to avoid disruption and optimize uptime.  

### **A Swiss greener hosting region** 

Both Oris and Liip are dedicated to doing good, particularly regarding environmental sustainability. This is a key component for Oris in their design and manufacturing and remained a steadfast consideration in how they approached their digital activity, including their website. That’s why the announcement of a new greener hosting region for Upsun in Zurich, Switzerland, their home country, was welcome news. 

Adding Switzerland as one of our public regions, with its use of low-carbon and renewable energy sources, ensured that Oris and Liip could continue to stand strong in their commitment to sustainability. With the Zurich Google Cloud region and our location-based approach to application hosting, it was simple for Oris and Liip to choose a greener option for where their data is stored while complying with data sovereignty laws—empowering them to deploy globally and comply locally.

## **The PaaS** _**was**_ **greener on the other side** 

It’s 9 years since Liip first embarked on their PaaS journey with Upsun and have transformed and enhanced the developer workflow of many of their customers as a result—and Oris is no exception. Their long-standing partnership has enabled them to overcome challenges, refine processes, and achieve their goals together, delivering a sleek, functional ecommerce platform they can be proud of. 

As a dedicated agency partner and advocate for our Platform-as-a-Service, Liip is a shining example of how a PaaS can open up new doors for digital agencies, no matter the size, location, or stack. Want to know more? Contact us.

### [How THE LÄND website spurs prospective resident relocation | Upsun](https://upsun.com/blog/jvm-neckar-the-laend-baden-wuerttemberg-case-study/)

# Agency partner JvM NECKAR builds THE LÄND for Baden-Württemberg

Challenge: To build a highly engaging website that attracts new residents to the third-largest state in Germany while meeting stringent security, privacy, and geo-based hosting requirements

Solution: A secure, reliable, interactive, 3D-animated website, where prospective residents can explore the region by selecting personal and professional categories most interesting and relevant to them, built on and hosted by Upsun

Stack: PHP, microservices, security, privacy, PaaS

Results:

-   1,800% increase in site traffic
-   Faster development time for small team
-   Automated DevOps that enables JvM developers to focus on code—not on low-value tasks
-   Flexibility to leverage preferred agency tech stack
-   Robust security and data privacy guardrails to meet rigorous government requirements

---

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

### **How one state spurred prospective resident relocation through virtual exploration**

Home to lush, green valleys, majestic mountains, and winding rivers. Family-owned businesses and brand behemoths like Bosch and Porsche. Tinkerers and inventors. Wine tasters and fortune-cookie makers. No, it’s not some Hollywood script mashup. But it _does_ seem to be a land that dreams are made of. 

Why, then, did Baden-Württemberg—the prosperous, culturally diverse, third-largest state in Germany—feel it crucial to develop a global campaign to motivate people to move to its idyllic region? First and foremost, to secure skilled workers, professionals, and specialists (domestically and abroad) who could fill an abundance of open positions in the near term. And second, to prepare the state and its citizens for the seismic shifts digital transformation will demand moving forward. 

The Baden-Württemberg Ministry's Department of State Marketing and Events put out a request for proposal to German-based marketing agencies to help address the challenge of attracting vibrant, qualified residents to the region. With deep experience developing fresh, innovative user experiences, Upsun agency partner Jung von Matt (JvM) NECKAR won the bid to create a campaign that would meet the Ministry’s key objectives. 

Welcome to THE LÄND project.

### **A balance of agency creativity and government requirements**

A subset of the global, award-winning Jung von Matt Group—a marketing leader for more than 20 years—the JvM NECKAR team took on the creative challenge of bringing the Baden-Württemberg project to life.

The concept? An interactive, 3D-animated website, where prospective residents can explore the region by selecting personal and professional categories most interesting and relevant to them—spanning topics from career opportunities, education, and healthcare to local attractions and hiking trails.

Before tackling THE LÄND website, the JvM NECKAR development team was tasked with meeting the Ministry's foundational requirements: 

-   Host the site in a German-based data center
-   Engage a European hosting provider
-   Protect the site from cyberattacks
-   Ensure user data remains private

To do it, JvM NECKAR turned to Upsun.

### **Freedom and flexibility: automated DevOps, preferred tech stack** 

Historically, the JvM NECKAR development team managed monolithic servers, taking time away from more creative, frontend work. “We didn’t want to configure and maintain our own servers; we wanted to focus on the user experience and frontend,” explains JvM NECKAR Technical Director Philippe Just. “So we looked for a PaaS (Platform-as-a-Service) configuration. While we considered Netlify, it just didn't meet all the Ministry's requirements.”

> “With Upsun, we're happy to have found a solution with regional data centers and roots in Europe, security and privacy guardrails, _and_ a product that can take care of our DevOps automatically. All we have to do is just click something together, and everything runs and works.”
> 
> – Philippe Just  
> Technical Director  
> JvM NECKAR

With DevOps no longer weighing them down, the JvM NECKAR dev team had more time to focus on their bold, imaginative project.   

To begin to develop THE LÄND, the team took advantage of the speed Upsun provides to easily spin up environments. And the freedom to bring their preferred, full tech stack into the headless project mix—a combination of ThreeJS, VueJS, Nuxt, and Storyblok (CMS). The content in Storyblok renders with NUXT to a static HTML frontend hosted on Upsun. Technical Director Just also had the flexibility to reassign developer resources or add them back to the project on the fly—another Upsun benefit.

“It was very easy and handy to build up these services, especially for THE LÄND,” Just explains. “We have the tech stack we like to use, so our developers could jump into the project quickly. We also used some PHP microservices to implement an integration from Stepstone by filtering relevant job offers from the state of Baden-Württemberg. So it was very easy to set up a new service in Upsun beside the Node server.”

### **Built-in security and compliance support mandated guardrails**

Initially announced through a press release from the state’s Minister-President Winfried Kretschmann, Phase I of THE LÄND project, which launched in October 2021, focused on informing and engaging German residents through a campaign landing page. Politics and potential opposition to the campaign surfaced security concerns. 

Robust, high levels of built-in security and compliance (including SOC-2, PCI-DSS, European GDPR , and the German BDSG)—fully automated and managed by Upsun—offered JvM NECKAR and Baden-Württemberg the safeguards needed to protect the site and user data from external interference and exposure. “We knew the Minister-President’s press conference would draw many visitors to the website,” explains Just. “So we used Cloudflare on top of Upsun. That brought us a very good, stable setup.”

### **Prospective residents flock to THE LÄND**

THE LÄND Phase II, launched in November 2022, targets potential Baden-Württemberg residents from around the world with its full-featured, interactive, 3D experience.

Since then, the site has been showered with accolades and stratospheric metrics: a whopping 1,800% increase in site traffic, easily handled by the scalable Upsun infrastructure, based in a German data center.

> “Upsun is a very cost-effective way for us to host client projects and makes development time even faster,” 
> 
> – Philippe Just

### [Distributed ecommerce with +Shop empowers brands | Upsun](https://upsun.com/blog/marketnation-unlocks-scale-with-paas/)

# MarketNation unlocks scale with Upsun to challenge centralized ecommerce

Challenge: To find a hosting platform to support a fast-scaling, distributed ecommerce model built on Magento, eliminating infrastructure instability, long support delays, and performance bottlenecks.

Solution: Migrating the +Shop marketplace platform to Upsun's fully managed PaaS with dedicated cluster architecture.

Results:

Results for MarketNation:

-   Sub-3-second page load times across all storefronts
-   Zero major outages since launch, with 24/7 infrastructure peace of mind
-   Full developer autonomy through environment-as-code and CLI tools
-   On-demand development environments accelerate feature testing
-   Daily production deployments using integrated CI/CD pipelines

---

_Building a distributed marketplace model without the infrastructure headaches, helping them empower others to host shops directly on their websites and socials._

When MarketNation set out to launch +Shop, it wasn't just launching another marketplace. It introduced a bold new ecommerce model: a distributed marketplace designed to return power to brands, creators & influencers, and schools & nonprofits by enabling them to host shops on their websites and socials. Instead of drawing traffic to a single platform, +Shop would spread commerce across hundreds, potentially thousands, of partner domains, making performance, scalability, and infrastructure resilience not just nice-to-haves but business-critical.

"We're not a centralized player like Amazon. +Shop is about empowering others to monetize their traffic by private labeling a distributed but unified ecommerce system, where we do all the hard stuff as the retailer and the hosting site just promotes" said MarketNation President and CEO Steve Dueck. "That vision of enabling anyone to be a Shopkeeper demands a platform that can scale effortlessly, integrate deeply with our tech stack, and give our developers full control." But their previous hosting solution was holding them back. And things were getting worse, not better.

## Stuck in a contract. And stuck with downtime.

Before Upsun, MarketNation hosted its Magento application on a custom Azure deployment managed by Webscale. On paper, this setup looked scalable. However, it was plagued with downtime, poor support, and spiralling technical debt.

> "We were constantly firefighting. Page loads were taking five to ten seconds, a death sentence in ecommerce," said Geoff Douglas, MarketNation VP of Engineering. "And when something broke, we'd wait days for a fix. That's not support—that's abandonment."

The infrastructure wasn't just underperforming—it was unreliable. Steve Dueck recalls getting midnight alerts for downtime, only to be left in limbo. "I'd get a call that our systems were down, and then… nothing. We were just waiting for someone, somewhere, to notice and care. Locked into a two-year contract, I counted the days to get out."

The Webscale environment was built as an initial proof-of-concept test. As MarketNation prepared for a full production launch, it was clear that the foundation wouldn't hold. The tech stack was too rigid, the response times were slow, and the confidence in future scalability was practically nonexistent.

## Finding a platform that could grow with them

When the team returned to the drawing board, they knew they needed more than hosting. They needed a true Platform-as-a-Service (PaaS) provider that understood Magento's nuances, supported complex deployments, and offered integrated tooling for modern development workflows.

That's when Geoff Douglas reconnected with Upsun. "I'd worked with Upsun years ago when Magento Cloud was powered by it. I knew the architecture, I knew the developer experience—and I knew it could handle what we were building now," he said.

Migration was a well-thought-out decision. MarketNation evaluated multiple vendors, comparing everything from cost and support responsiveness to deployment tooling and Magento compatibility. But Upsun stood out as the only option offering deep Magento support, baked-in CI/CD, and a truly managed hosting experience.

> "The other vendors we looked at were either too barebones or too inflexible. With Upsun, we got the benefits of managed hosting without sacrificing control. That balance was critical," Geoff Douglas explained.

## Seamless onboarding, and a 30-day migration

Despite being pressured to launch quickly, the onboarding process with Upsun went smoothly. The team had just 30 days to migrate off their existing infrastructure, create new environments, and go live with a production-ready +Shop deployment.

The transition was faster and cleaner than expected, thanks to clear onboarding checklists, real-time collaboration via a shared Slack channel, and direct support from a dedicated onboarding engineer.

> "Upsun was a dream regarding clarity of engagement," Steve Dueck shared. The onboarding process was super clean and sharp. You could tell immediately that they've done this a lot—and done it well."

MarketNation launched right on schedule.

## Tech stack transformation: complete control, faster deployments

MarketNation built +Shop on Magento open-source, as its modern development workflow emphasizes flexibility, speed, and robust observability.

The team is deployed to a dedicated cluster using Upsun's 3-tier architecture—development, staging, and production—giving them complete pipeline control. Built-in Fastly and Varnish caching dramatically improved site performance, while Blackfire provided real-time performance profiling in production. The Upsun CLI and console gave developers deep visibility into deployments and services.

"One of the big wins for us was the ability to control the environment entirely in code. With Webscale, we were always guessing. With Upsun, it's transparent and predictable," Geoff Douglas said.

On-demand development environments were another game-changer. The team could spin up fully isolated stacks to test major features without impacting production or staging environments.

> "This morning, we launched a new development environment to test a disruptive feature. That would've been a huge ordeal in our old setup," said one developer. "Now it's just part of the workflow."

Even deployment downtime improved. With the MarketNation Magento setup streamlined on Upsun, the team reduced maintenance windows to just three minutes—a significant gain for a site serving live transactions.

## Real results: stability, scale, and sleep

Since switching to Upsun, MarketNation has resolved its infrastructure issues and unlocked new potential for growth. First and foremost, uptime is no longer a concern.

"I haven't had a single call in the middle of the night since we went live on Upsun," Steve Dueck said. "Honestly, it's been the best thing in the world. It's just not something I worry about anymore."

Performance has also improved. Thanks to optimized caching and enhanced infrastructure, page load times have dropped to the targeted 2–3 seconds. Code is deployed more frequently, updates are shipped daily, and developers have more confidence in the system they're building on.

Crucially, Upsun has removed the infrastructure burden from MarketNation's small team, allowing them to focus on scaling the business and improving the +Shop product.

> "We're able to deploy every day, with new features going live constantly," Geoff Douglas said. "That agility would've been impossible in our previous environment."

## Scaling the distributed revolution

With a strong foundation now in place, MarketNation is ramping up +Shop adoption and expanding its vision of distributed commerce. As more brands, creators & influencers, and schools & nonprofits adopt the platform, MarketNation is confident in its ability to meet demand without infrastructure bottlenecks.

> "Upsun just works. And that allows us to focus on what matters, building a better ecommerce model," Steve Dueck concluded.

For digital commerce teams grappling with legacy hosting, rigid platforms, or unreliable support, MarketNation's story reminds them that the right managed hosting partner doesn't just solve technical problems but unlocks business potential.

### [Lemberg Solutions: safe AI for Drupal + FastAPI | Upsun](https://upsun.com/blog/lemberg-solutions-from-ai-curiosity-to-production-ready-value/)

# From AI curiosity to production-ready value: extending digital platforms with AI on Upsun

Challenge:

For established digital platforms, the primary barrier to AI adoption is rarely a lack of ideas, but fear of the unknown.  
  
Lemberg Solutions found that nearly 80% of their clients shared the same technical anxieties: model accuracy ("what if it hallucinates?"), reputation risk ("what if a user posts a screenshot of a biased answer?"), and data privacy.  
  
These fears often lead to "analysis paralysis," where companies hesitate to overhaul their infrastructure or risk their stable production environments for an unproven AI pilot.  
  
Lemberg needed a way to move clients from "What if?" to "It works" without requiring a massive upfront investment or compromising existing systems.

Solution:

Lemberg utilized Upsun to create a "discovery-to-delivery" pipeline that prioritizes business value over technical hype.  
  
By leveraging Upsun’s Git-driven, standardized environments, Lemberg could build a functional Proof of Concept (POC) in weeks instead of months.  
  
The solution utilized a modular "black box" architecture. Lemberg hosted the core Drupal CMS alongside dedicated AI services built on Python’s FastAPI.  
  
Upsun’s ability to combine these stacks into a single, unified project meant that AI logic could be tested and iterated independently.  
  
Crucially, Lemberg used Upsun’s preview environments as "playgrounds" where stakeholders could safely check (and even break) the AI logic against real data before any code touched the live site.

Results:

-   Accelerated deal cycles: MVPs moved from kickoff to live in weeks instead of months, allowing clients to generate data-backed ideas quickly.
-   Drastic cost reduction: Enterprise clients reported paying half of their previous hosting costs while gaining more features and faster development cycles.
-   Bypassed legal bottlenecks: Upsun’s compliance certifications (e.g., ISO 27001) helped navigate complex IT and legal checklists for enterprise clients.
-   Eliminated "Staging Drift": Replicated production-identical sandboxes reduced DevOps time from days to roughly 30 minutes.

---

## Bridging the gap between AI experimentation and business value

Lemberg Solutions acts as a strategic advisor, helping digital businesses ensure they have the necessary data foundations in place before implementation begins to ensure the AI actually creates value

> _"The time from project kickoff to development is smooth and fast because we can quickly spin up development instances on the Upsun platform using templates."_ — Roman Paska, Head of Drupal at Lemberg Solutions

### Why Upsun was the right fit

For Lemberg, AI integration is an application evolution, not an infrastructure chore.

Upsun provided three critical advantages that made this transition seamless: multi-stack flexibility, safe testing through human-in-the-loop validation, and the safety net of instant backups.

One of the primary benefits was the platform’s inherent multi-stack flexibility. 

While AI ecosystems typically live in Python, many digital platforms are built on PHP. Upsun allowed Lemberg to host FastAPI and Drupal side-by-side using a single YAML configuration. 

This unified approach helped the team avoid the "operational sprawl" of managing multiple cloud vendors, keeping all services in a centralized and predictable environment.

To address critical accuracy concerns during development, Lemberg implemented "confidence levels" for AI output. Upsun’s isolated preview environments proved invaluable for this process, enabling specialists to verify low-confidence responses in a safe sandbox before they were ever exposed to end-users. 

This human-in-the-loop strategy allowed stakeholders to test and iterate on AI features without risking the stability or reputation of the live production site.

Finally, the platform provided a critical safety net through its instant backup and restore capabilities. 

In one instance, a client accidentally removed a critical page from their production site. Lemberg was able to quickly roll out a production backup to a new environment and manually restore the lost content, a capability that protected the client's reputation and saved hours of recovery work.

### Removing the fear of production risk

One of the most significant barriers to AI adoption is the fear of "breaking the site." Generative AI introduces new variables that traditional digital platforms aren't always equipped to handle.

Lemberg addressed this fear by using Upsun's isolated preview environments as "playgrounds" for their clients. 

Stakeholders could check, break, and iterate on AI features in a production-identical environment. 

This capability was instrumental in securing internal buy-in, as it proved the AI logic worked within the context of the client’s actual data and infrastructure before a single line of code was merged into production.

### Multi-stack flexibility for modern AI needs

AI workloads almost always require Python, while many of Lemberg’s clients run on Drupal or other PHP-based stacks. 

Upsun’s multi-language support allowed Lemberg to build a FastAPI service as an additional "black box" service that interacts with the main application.

This modular approach ensures that the AI logic is scalable and secure, while the primary platform remains stable. 

By hosting everything on a single CAP (Cloud Application Platform), Lemberg avoided the operational sprawl of managing multiple vendors, ensuring that the total cost of ownership remained low for the client as they moved from Phase 1 to full-scale production.

### Beyond the MVP: reliability and compliance

The value of the platform extended into the non-technical hurdles of enterprise growth. Upsun helped Lemberg’s clients navigate complex legal and compliance requirements by providing a secure, auditable infrastructure foundation.

In one instance, a client was able to reduce hosting costs by two times while gaining more testing environments and faster development cycles. 

The ability to quickly roll out production backups to new environments also served as a critical safety net, allowing the team to restore inadvertently removed content and resolve data issues without downtime.

### Advice for digital leaders

The Lemberg team encourages leaders to move away from "fear-driven" development. By using a platform that handles the plumbing (automated updates, scaling, and compliance), teams can focus on data science and business logic.

> _"When managed services are available, we can start projects and go live within a few hours. Upsun is a proven platform that we have worked with for six or seven years. It helps us build things faster and manage projects more easily."_— Roman Paska, Head of Drupal at Lemberg Solutions

### About Lemberg Solutions

Lemberg Solutions is a technology consulting and engineering agency that helps digital businesses implement AI, IoT, and cloud-based solutions. They specialize in discovery, MVP development, and scaling digital products for SaaS, eCommerce, and enterprise clients.

### [Easypara cuts downtime by 96% with ecommerce migration | Upsun](https://upsun.com/blog/easypara-cuts-downtime-with-seamless-migration/)

# Easypara ditches downtime and takes control with a stress-free migration

Challenge: Easypara struggled with frequent four to eight hour outages, unstable infrastructure, and complex deployments, leading to lost revenue and operational inefficiencies. Managing infrastructure in-house became overwhelming, especially during high-traffic events. To regain stability, eliminate downtime, and scale with confidence, they needed a seamless solution in just 30 days, without disrupting sales or customer experience.

Solution: Provide a seamless, zero-downtime Platform-as-a-Service migration for Easypara in just 30 days. With scalable infrastructure, automated deployments, and expert support; Upsun and Agence Dn’D eliminated outages, improved performance, and empowered Easypara with full operational autonomy–eliminating the headaches of DIY system administration.

Stack: magento, migration, PaaS

Results:

-   96% downtime reduction: Elimination of 20 to 30 hours of monthly downtime ensuring seamless ecommerce operations and revenue protection.
-   Cutting time spent on DevOps: Automated workflows reduced manual tasks, giving developers more time for innovation, improving team morale, and reallocating resources to growth-focused initiatives.
-   Faster, more frequent releases with greater confidence: Reduced deployment-related downtime from 6 minutes to under 1 minute.

---

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged._

_Seamless migration cut Easypara’s downtime by 96%, accelerated releases, and gave their developers time to focus on growth and innovation._

Easypara had built its reputation as one of France’s leading online pharmacies, offering customers a seamless digital shopping experience for healthcare and beauty products. But behind the scenes, the company was facing a growing challenge. Frequent service interruptions, complex deployments, and the increasing burden of managing their own hosting infrastructure were putting a strain on their operations. They set out to find a platform-as-a-service provider, but when their new PaaS provider went bankrupt, Easypara was forced to make a critical decision. They needed a solution that would not only stabilize their platform but also empower their team with the autonomy to scale and innovate without technical roadblocks.

That is when Easypara turned to Upsun. What followed was a high-stakes, time-sensitive migration that redefined how Easypara approached ecommerce infrastructure.

## An urgent need for stability and reliability

For years, Easypara had managed its own hosting, but as the business grew, so did the complexity of maintaining a stable and high-performing site. Service outages lasting up to eight hours became a common occurrence, and with every disruption came lost revenue and frustrated customers. The company was suddenly left scrambling for a new solution. They needed a hosting platform that was stable, scalable, and built for ecommerce, fast–and they made the swift decision to move to Upsun.

> “Before Upsun, we had frequent service interruptions, sometimes lasting four to five hours, and we struggled to maintain site stability. Now, we have peace of mind—our site runs smoothly, and we no longer need to worry about late-night disruptions,” said Isabelle Sarrazin, General Manager at Easypara.

With Magento as the backbone of their online store, Easypara required a hosting solution that would support its complex architecture. Magento’s modular nature, multi-store capabilities, and extensive integrations made it the ideal platform for their business, but it also required a hosting environment that could keep up with its high resource demands. The ability to deploy and test changes rapidly, scale seamlessly, and ensure 99.99% uptime was critical.

## A seamless migration with a seamless partnership

Recognizing the need for deep technical expertise, Upsun introduced Easypara to Agence Dn'D, a Upsun agency partner and specialist in Magento-based ecommerce solutions. Together, the teams mapped out a migration strategy that had to be executed in record time, just 30 days.

The challenge was immense: migrate Easypara’s entire digital ecosystem including: ERP, PIM, CRM, and OMS integrations, in just one month, and do so during the summer holiday period when internal resources were stretched thin. The migration required transferring terabytes of customer data, order histories, and media assets, ensuring data integrity and performance optimization throughout the process.

The main objective of the migration was set, ensure that Magento’s highly customizable architecture remained intact while optimizing performance on Upsun. This included:

-   **Containerized environments:** Each Magento service, from caching to database management, was deployed in isolated containers for better security and scalability.
-   **Automated testing and deployments:** Using Upsun’s built-in CI/CD workflows, Easypara could push updates without downtime.
-   **Dynamic scaling:** Resources were adjusted in real time based on demand, ensuring smooth performance during high-traffic periods.

> “Time was against us, and the project was incredibly complex, but together with Upsun we ensured every step was seamless. The biggest advantage of Upsun is the autonomy it provides. Unlike other hosting solutions that rely heavily on support tickets, Upsun gives teams the tools, documentation, and flexibility to manage their infrastructure efficiently, with expert support always available when needed,” said Antoine Kociuba, Technical Expert at Agence Dn'D.

## From non-stop downtime to full autonomy

The success of the migration became evident almost immediately. Service interruptions were eliminated, and deployments became faster and more efficient. Upsun provided Easypara with an infrastructure that could scale effortlessly, ensuring that high-traffic events, such as a feature on a national television show, could be handled without any performance concerns.

> “We really appreciate the peace of mind that Upsun provides,” added Sarrazin. “Our team now has the flexibility and autonomy to manage deployments efficiently without worrying about service interruptions. The partnership with Upsun and Agence Dn'D ensured a smooth migration under tight constraints.”

Beyond improved stability, Easypara saw significant operational efficiencies. The move to Upsun meant they no longer needed an in-house system administrator for hosting, allowing them to reallocate resources to growth-focused initiatives. The ability to spin up on-demand environments for testing and development also meant that the IT team could iterate faster and launch features with greater confidence.

## 24/7 Infrastructure peace of mind

Eighteen months after migrating to Upsun, Easypara continues to experience unparalleled stability, efficiency, and confidence in their infrastructure. 

> Isabelle Sarrazin reaffirms the same sentiment with each check-in: “We have complete peace of mind with Upsun.” 

This statement embodies what every ecommerce business strives for, a hosting solution that just works.

This transformation was not just about fixing an unstable platform. It was about redefining how Easypara’s IT team operates, giving them the freedom to innovate without worrying about infrastructure, the ability to scale seamlessly during high-traffic periods, and the assurance that their online storefront is always open, always secure, and always performing at its best.

## A future-proof ecommerce foundation

Easypara’s journey illustrates a crucial lesson for ecommerce businesses your platform should empower you, not hold you back. With Upsun, businesses running Magento and other complex ecommerce solutions can eliminate the burden of in-house DevOps. They gain unmatched reliability, seamless scalability during peak demand, and autonomous high-velocity deployments—all with the confidence of robust security and compliance.

### [Axéréal's website success | Upsun](https://upsun.com/blog/axereal-koriolis-website-fleet-case-study/)

# Axéréal dramatically reduced its technical limitations on the web with Koriolis and Upsun

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

_**Axéréal**__**, a key international player in agriculture, has to handle numerous websites for its subsidiaries and cooperatives. Putting them online used to be time-consuming, and problems related to the original system architecture consistently made the teams' lives difficult. Tired of having to patch a series of bugs, website by website, the Group decided to pass the task of hosting on to**_ _**Koriolis,**_ _**an agency specializing in Drupal website factories and taking advantage of Upsun's PaaS solution.**_ 

### **Take your website problems, and multiple by 21**

Axéréal, which has many subsidiaries and lines of business, has to keep no less than 21 different websites running at the same speed for all its subsidiaries in France and abroad. These days, fleet management has become customary for corporations. Some of them manage thousands, or even tens of thousands of different websites. Website fleet management, with its capacity for quickly cloning websites, is different from classic multi-site management, which requires more time and resources.

Axéréal's numerous websites represent the company's main technical constraint, in what is otherwise a fairly simple situation: The websites' technical platforms are identical, it's only their graphics that are different. However, this never kept the website updates from being a tedious, site by site task, with all the various problems that come with it, until now. Since they were all on the same server, if one website was down it could cause problems on the other websites as well, which required that the hosting provider be contacted regularly.

Since Drupal version 7 was nearing end-of-life, Axéréal came to the conclusion that grouping its websites would be more efficient. To do so, the company would need to modify its entire hosting system and upgrade to Drupal 9. The goal was to duplicate the parent website every time, keeping changes minimal, to keep costs down. “That didn't keep us from continuing to use the websites, updating them and making changes,” explains Anaïs Renvoizé, Web & Event Manager at Axéréal, who is in charge of all the Group's websites.

### **How Koriolis and Upsun went straight to the heart of the issue**

Koriolis, an agency specializing in Drupal, is an eight-person company popular with both SMEs and major corporations, particularly for high-traffic websites. Its focus is development, and its trademark is the absence of infrastructure administration. To achieve this, it relies on Upsun's PaaS (Platform as a Service) solution, which makes it possible to integrate hosting directly into the code.

The first step was to increase memory and duplicate the new structure across all websites. 

> According to Sébastien Lissarrague, founder of Koriolis, “With Upsun's expertise, all we had to do was factorize the Drupal code, modify it on a single website, and redeploy it to the 15 others.”  

Now, Axéréal only has to provide website mockups to Koriolis. 

> “It gives us consistency across all our websites, even when a specific feature development is required for one site, or for a few. That means that the HR module deployed on several different sites is identical,” says Renvoizé.

### **Time saved, transparency increased**

The Web Manager used to have to call the hosting provider regularly to handle emergencies, but those days are over. 

> “Now, everything is transparent and accessible. We can test modifications as we go. Before, every little hiccup caused a chain reaction across all our websites. Now, when a problem comes up, we can handle it quickly and definitively. We move forward and stabilize.” 

In terms of time saved on maintenance, and the resulting increase in productivity, the before and after are very clear. 

> According to Sébastien Lissarague at Koriolis, “Upsun has allowed us to automate everything and manage an entire fleet of websites much more effectively.” 

It used to take half a day to put a website online. Now it only takes a few minutes. Schematically, instead of 5 steps — hosting, development, preproduction, verification and production — now Koriolis just has to put its code, data and static files in Upsun. Once that's done, most of the work is finished, and the website can be deployed.

While it is almost time to upgrade to Drupal 10, frequent updates are no longer an issue for Axéréal's 21 websites. 

> “It's all thanks to Upsun and Koriolis, they go hand in hand for us,” says Renvoizé. 

### **A summary of the seven advantages of the Axéréal x Koriolis x Upsun partnership**

1.  The time saved, and the agility to develop and administer the website fleet.
2.  Security, with immediate solutions for all websites at the same time
3.  Mastery of the complexity caused by the number of websites: everything, from infrastructure to applications, to manage over a dozen websites. “We don't spend all our time in meetings. Everything is very contained,” says Sébastien Lissarague of Koriolis. 
4.  Co-management of the fleet of websites
5.  Stability
6.  Simplicity
7.  Continuous improvement

### [University of Surrey's digital success story | Upsun](https://upsun.com/blog/university-of-surrey-case-study/)

# University of Surrey optimizes developer operations by shifting to Upsun

Challenge: To find a simplified solution that would help the university’s growing development team efficiently manage 10 single-instance sites across Drupal, CodeIgniter, and React

Solution: Migrate from Acquia to Upsun, gaining collaborative live preview environments, faster publishing times, and unmatched customer support

Stack: PaaS, Drupal, DevOps, migration

Results:

-   Migrate smoothly with GitHub integration
-   Save hours by removing barriers to accessing dev environments
-   Streamline review cycles with automated creation of user acceptance testing (UAT) sites
-   Improve ease and speed of deployment

---

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

With a history dating back to 1891, the University of Surrey has never been afraid to evolve. In fact, in 1956, the University was one of the first institutions to be named _a college of advanced technology_. 

To date, Surrey has welcomed more than 140,000 students through its doors, including its current class of ~15,000 students. The Surrey Research Park continues the institute’s legacy of collaboration, adaptation, and innovation.

So it’s no surprise that Surrey’s digital team has high standards for its underlying technology. But in 2014, their decentralized suite of websites became too challenging to manage; with clunky operations and lengthy publishing times, something had to change. 

Unfortunately, it wasn’t an instant fix. The digital team endured two years of trial and error, searching for a system to simplify DevOps, giving developers more time to focus on code and innovation.

## **The shift away from on-premises hosting**

Historically, the University's IT team had managed and hosted the digital team's websites on-premises. But when the IT team added Drupal on top of their legacy content management system, they also added layers of complexity. Although a full switch to Drupal was imminent, the IT team didn't have the resources to maintain Drupal, along with the rest of the digital team's tech stack, in-house.

While a few of the digital team’s 10 websites were low maintenance, many of them required daily changes. An overnight publishing process impacted team agility and their ability to give attention to high-value work. It was clear that on-premises hosting just didn’t make sense anymore. The Surrey team needed a new solution—fast.

Initially, they chose Acquia to carry them through their transition to managed services. But as the development team grew, so did the tool’s constraints. With the original team size of 3 devs, communications and collaboration around a single dev environment was possible—but with 8 developers, it was unsustainable.

Surrey Lead Digital Developer Daniel Gittings recalls that developers were frequently forced to wait until the only dev environment was available. This created significant delays, which the team was eager to overcome—but that meant another system migration. To make a strategic and lasting decision, they outlined their must-haves for the new platform. 

-   Seamlessly integrates with Drupal and GitHub
-   Offers preview environments for user acceptance testing (UAT) to foster real-time collaboration and rapid approvals
-   Scales to accommodate larger teams and additional sites
-   Provides responsive, caring customer support 

After vetting a few options, Upsun emerged as the best choice for all these needs.

### **Surrey developers share why Upsun is the right long-term partner**

Since the switch to Upsun eight years ago, it’s been more convenient and simpler than ever for Surrey to scale, adding sites to their portfolio as the need arises. Here’s what Surrey lead digital dev team members Daniel Gittings (DG) and Chandra Rajakumar (CR) value most about Upsun services and support.

#### **Seamless integration, configuration, and capabilities**

> I personally quite like the way projects are configured with the YAML files and how you can sort of spec them out that way…The GitHub integration, the creation of those UAT sites: we didn't have that before, so that really was a huge game-changer for us. It's just so seamless the way Upsun fit into the way we were working already, and I guess we didn't really know it until we started doing it.
> 
> Daniel Gittings  
> Lead Digital Developer

#### **Simplified review cycles**

> Upsun is just such a great way for us to work with our extended team. I think having to create those kind of UAT sites manually would drive us insane. So having it completely hands-off, just done for us is a massive time-saver.
> 
> Daniel Gittings  
> Lead Digital Developer

#### **Customer support and rapid response times**

> It was such a wonderful experience working with your team. They were so amazing in doing any migrations, helping to resolve any customer support tickets we created. They were so wonderful.
> 
> Chandra Rajakumar  
> Lead Digital Developer

> The people we work with are lovely. When you've got something fairly urgent, it's nice to know that we can get a quick response. I can't think of any time that we couldn't get the support we needed, when we needed it.
> 
> Daniel Gittings  
> Lead Digital Developer

### **Standing the test of time**

Surrey’s digital team has undergone structural changes over the years. Developers have come and gone. Surrey recently rebranded, requiring changes to their suite of sites. But they say the Upsun team has given them the confidence to weather it all.

And as Surrey approaches a decade of partnering with Upsun, the digital team is grateful for the efficiency, collaboration, and agility they’ve gained. The seamless integration, combined with robust support and configuration flexibility, has enabled the university to maintain a smooth and productive digital presence. And as the university continues to grow and evolve, Upsun remains a trusted partner in their digital transformation journey.

> We haven't really had any big dramas or issues that would cause us to want to leave,” says Gittings. “I think giving us that kind of confidence is just pretty positive for us; the lack of negatives really speaks for itself.
> 
> Daniel Gittings  
> Lead Digital Developer

### [Slate.fr's DevOps transformation | Upsun](https://upsun.com/blog/slatefr-revived-its-devops-approach/)

# Slate.fr revived its DevOps approach with Upsun

Stack: Drupal

---

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

Ever since the internet and mobile changed the media landscape - making it easier to disseminate news - it is imperative that media companies’ web estates are highly available and have fast deployment capabilities to respond to high traffic peaks. Important news and events such as the presidential and general elections, Brexit and the EU, and viral content like cat videos drive tons of web traffic.

Facing today’s information age, Slate.fr’s mission is to offer exclusive, real-time information to its customers on its website.

> "We wanted to discover new tools and benefit from more test environments, but also to have additional server resources immediately in real-time in case of breaking news," said François Pottier, technical director at Slate.fr.

As Slate.fr’s old service provider was unable to keep pace with technical improvements, the company chose Upsun to manage its website. Slate.fr found the solution offered by Upsun and managed by Orange very attractive in terms of technology, notably regarding DevOps.

> "Overall velocity from development of features into production deployment has increased 30-40%, dramatically impacting time to market for new features and bug fixes."

The migration to Upsun lasted around three weeks and permitted Slate.fr to rapidly benefit from our DevOps’ proactivity during critical times to cover news such as the US and French presidential elections.

Here is the article translation:

### **Slate.fr choses Upsun for its DevOps approach by Benoit Huet - 03 Mai 2017**

The website Slate.fr decided to choose Upsun, a french PaaS on continuous deployment for its own DevOps approach.

“Fast deployments, high availability, and pricing were the three elements differentiating our choice for the continuous deployment cloud hosting platform offered by Upsun and hosted by Orange,” said François Pottier, technical director at Slate.fr.

Slate.fr, a publishing site with additional outlets in French-speaking Africa, is celebrating its 8th birthday and employs about 25 people. Built with Drupal, Slate.fr’s website was originally managed by another host, but for economic and technical reasons the media company decided to change service providers. "We disagreed on several points with our former host. And based on the services we received we thought we were paying too much. We wanted to discover new tools and to benefit from more test environments, but also to obtain additional server resources in real time in case of overheating activity", states François Pottier. In light of these observations, Slate.fr set out looking for a vendor capable of meeting its needs. Once Slate.fr came across Upsun the team was quickly seduced by the vendor's Devops approach. Moreover, the geographical proximity with Upsun, which is headquartered in Paris, has reinforced the choice of Slate.fr.

On-the-fly creation of environments

"The creation of several development environments on-the-fly along with the fact that Upsun’s team is very proactive in terms of support perfectly confirmed our choice," says François Pottier. For Slate.fr the time savings is real.  Overall velocity from development of features into production deployment has increased 30-40%, dramatically impacting time to market for new features and bug fixes. Several projects have been developed with this Devops approach on Upsun.

Among other benefits of Devops provided by Upsun, Slate.fr appreciates its provider’s proactivity. "In case of peak traffic, for example to cover the presidential election, Upsun is able to immediately allocate more server resources to us," explains François Pottier. "Their Devops organization also allows us to always have the perfect support at all levels according to our needs." It should be noted that the migration to Upsun, which started around September 20, 2016 lasted about three weeks.

Read the original article in French.

### [University of Missouri embraces PaaS | Upsun](https://upsun.com/blog/university-of-missouri/)

# University of Missouri manages web operations at scale

Challenge: In the shorter term, to move 25% of 1,600 unmanaged, on-premises Drupal, WordPress, and static HTML websites to the cloud, applying industry best practices

Solution: Adopt Upsun developer tools and hosting services to implement the initial cloud rollout, then centralize, standardize, and manage sites to gain efficiencies at scale

Stack: Drupal, WordPress, automation, multi-app, DevOps

Results:

-   75% less time spent on website maintenance/updates based on automation, freeing developers to focus on high-value projects
-   30% lower annual hosting costs
-   300% initial increase in the number of requests its Drupal and WordPress sites could handle
-   Faster, streamlined workflows built into Git integration
-   Ability to deploy new features faster and more frequently

---

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

The first school of journalism. The first public US university west of the Mississippi River. The architect of homecoming, the long-standing, annual fall tradition of welcoming back the higher education community and its alumni to campus. The University of Missouri (Mizzou)—founded in 1839—takes pride not only in these _firsts_, but in its students’ (currently 31,121, representing all 50 states and more than 100 countries) and faculty’s contributions, achievements, and innovation.

With stepping up to tackle complex challenges in their DNA, the groundbreaking research university’s MU Marketing and Communications team embarked on an amazing, six-year journey to eliminate technical debt; centralize and standardize its decades-old, organically grown web environments; and ultimately turn its attention to the business of expert-level client consultancy and brand stewardship.

## **The original case for moving to centralized web operations**

Let’s start Mizzou’s story with a history lesson. The university’s websites had been completely decentralized. Any school, any division, any department with funding or a purchasing card could hire their own developer. Or set up their own server. Or purchase third-party hosting, then set up a website.

All this—and 13 content management systems, hosting platforms, lack of standards, inconsistent processes, and interdepartmental dependencies—prompted Mizzou Director of Digital Service, Kevin Bailey, MU Marketing and Communications and the university’s Central IT Group to formulate a strategy that would move away from local infrastructure to a cloud-based approach. An approach that would enable them to implement standards. Enforce security and compliance policies (including the mandate to protect student and university data). And align brand and user experience across their web properties.

### **When diversity creates barriers**

The university’s Central IT Group tasked Bailey and his web development team with moving 25 percent of its 1,600 on-premises WordPress, Drupal, and static HTML websites to the cloud. This proliferation of diverse websites required support. The web team wasn’t notified if a site had an issue nor did they have any permission to access it. When asked to step in and offer support, it could take days or weeks to parse through how an individual site worked. And if a site had been compromised, there was no way to shut it down, potentially tarnishing the university’s brand and putting its security posture at risk.

From an institutional standpoint, the team recognized it couldn’t support this depth and breadth of web environment diversity. After carefully considering the challenges, the university set a path to invest in systems that would tightly integrate operations and development. Facilitate agile development. Deliver high levels of performance. And allow a more standardized stack—from the codebase down to the hosting layer.

How to cost-effectively and efficiently migrate the sites—some of them smaller with only dozens of hits per month to those with millions of hits per month—to a single platform, where updates and changes could be deployed to all sites quickly, securely, and consistently while minimizing downtime, became a large part of the team’s hosting-provider search criteria.

## **The search for—and discovery of—developer flexibility**

Bailey’s staff recognized they needed to establish standards for far fewer content management systems (ultimately choosing Drupal and WordPress), DevOps practices, authentication, and backups—and to manage the two, designated CMSs with approximately 90% of the same processes. The team wanted to update different components in the stack, set up new sites, and roll out new features quickly. Improve performance and uptime. And gain the ability to push updates with confidence without anything breaking. Beyond developer flexibility, they needed the efficiency to manage more sites with fewer developers.

With their technical requirements set, the team sent out their RFP, then weighed their options, selecting Upsun to host its ~400 Drupal and WordPress on-prem websites.

> “One of the reasons we really liked Upsun was that it gave us this wealth of power, performance, and flexibility—without having to manage our own cloud-hosting infrastructure. Upsun does a good job of having many of the nuts and bolts for most sites built in.”
> 
> **John Boyer**   
> Programmer/Analyst-Principal, Digital Service   
> MU Marketing and Communications   
> University of Missouri

> "Upsun afforded us the controls we required to implement our cloud migration _and_ our security regimen, which satisfied our security team. They felt comfortable we could protect our data while allowing administrators and programmers to do their jobs efficiently—without unnecessary rights and privileges. Upsun just really fits the bill nicely.”
> 
> **Kevin Bailey**   
> Director of Digital Service   
> MU Marketing and Communications   
> University of Missouri

## **Getting the developer community onboard**

With a decentralized campus came a diversity of developer skill sets. And educating the broader development team was more involved than the Digital Service team had anticipated.

To the extended team, containerized hosting felt foreign: a complete shift in how they thought about their websites. And not all developers on campus had used Git. Boyer created a workflow to help them get up to speed and “feeling good about tools that open up a new world of flexibility.”

“From a business standpoint, when you think about business process workflow control, Upsun is just a natural,” says Bailey. “Upsun uses tools that we're already familiar with _and_ allows us to control parts of the process we could never control before. We can provide a much more certain, predictable experience to the departments that need websites than we ever were able to do in the past.”

## **Managing Drupal and WordPress sites at scale**

For the Mizzou team, getting a single site up and running on Upsun was easy. But how to do the same at scale for the hundreds of Drupal and WordPress sites that weren’t identical, were set up differently, and that they didn’t have staff authority over? _That_ needed to be tackled.

“We no longer worry about spinning up environments and those other things Upsun enables,” Boyer explains. “Instead, we’ve learned how to leverage Upsun API command-line utilities to automate processes that lower our cost of maintenance per site across our entire website fleet.

> “With the university’s previous system, it would take a developer two hours or so to manually patch each Drupal website; nothing was automated. Multiple that by 300 sites, and that’s 600 hours devoted to updates. Today, it’s two or three minutes per site, unattended. There’s some QA, but we probably shave 1.5 hours off maintenance every month, for every site. That’s the real Upsun benefit.”
> 
> **John Boyer**

## **Mizzou developers speak out**

MU Marketing and Communications web developers had a lot to say about their experiences with Upsun. Some of their thoughts are captured here.

### **Development environments that speed and smooth workflows**

Development environments are inexpensive and easy to build up and tear down. With our Central IT-managed infrastructure, if we wanted a test environment, we had to write scripts to sync everything, and make sure code was synced to the dev environment before it went live. Upsun enables us to put people in a workflow that’s pretty much built into our Git integration, seeing that whole process through syncing the code, database, and files between development environments. It just makes our lives easier.

### **Customer support**

One thing we found really refreshing is the Upsun team’s honesty about the strengths and limitations of the service. When we’ve experienced issues, Upsun staff have told us exactly what’s going on and owned up without any runaround. In those instances, Upsun specialists in those areas have actually jumped in to help make our stuff work.

### **Establish standards, automate**

Upsun gives us the ability to create standards and move all these extremely variable sites into a standard workflow, a standard build process, a standard setup, so that we can manage things at scale.

### **Performance: faster sites, faster provisioning**

With Upsun, we're _way_ faster. We can have a new site up, completely synced, ready to go—between GitLab and Upsun and all the pieces—in literally two minutes. We can also keep the stack components up to date much faster.

Our performance and uptime are much better, too. A 300% increase in WordPress performance is mirrored in our Drupal projects (based on Google website audit tools). We also have consistent backups across every site, regardless of technology. In the past, we had no idea whether or not a backup existed. And because our departments were siloed, the backups were in multiple different locations. Now, we have a single location. We know that if something happens, we can easily grab that snapshot, redeploy it, and have a site back up in literally minutes.

From the end-user standpoint, we’ve seen a lot more speedy access as we look at Google Analytics; people are spending less time just clicking around. They're actually getting what they need quickly just because Upsun makes things so much faster.

### **Future-proof support for multiple languages**

We have flexibility to change components in the stack on a site-by-site basis, _and_ we have flexibility for the future. If we need to build a PHP or Node.js, or Ruby application, now we can.

### **Efficiency: more sites per developer, with faster onboarding**

We're _far_ more efficient. We're now able to manage many more sites with fewer developers. With the help of Upsun, we've standardized on all these things related to local development, so we can give a developer who's never touched a site access to the repository, they clone it down, start up Lando, run through the script, and have a working, exact clone of the Upsun site on their local machine. They’re able to support other sites, too, even if they haven't seen them before.

### **Lower cost, more value**

The main thing it boils down to is this: when we purchase an account from Upsun, we're able to have the hosting environment _and_ the database environment together on a single bill. With local servers through our IT department, we had a LAMP stack: Linux, Apache, MySQL, PHP. The MySQL support charges for our internal service were quite expensive because it's a one-off from what they normally support, so it costs them more. A lot of our reduction in cost revolves around the fact that we're bundling database hosting with Upsun, and we can get the database services at a significantly lower cost than we can internally.

Most of our sites have seen a 30% decrease in their annual hosting costs with Upsun.

It's been helpful to show our user community that they're getting a lot of value from a cloud-based hosting vendor like Upsun. We can honestly say to them, ‘These are the benefits that you're getting.’ And most of our websites cost less than they did on our local hardware.

## **Digital transformation that meets stringent higher-ed requirements**

After 25-plus years of the university’s organic website growth, Bailey takes great pride in his team’s accomplishments. The hundreds of websites: completely standardized on the backend and close to that (as close as Drupal and WordPress can be) on the frontend.

Today, the MU Marketing and Communications has grown from a two-person dev shop to a 16-member group that includes Drupal and WordPress developers, a backend team, designers, and UX/UI specialists. Working in an agency model, they’re no longer herding websites, but are analyzing how the sites are meeting audience and departmental needs and what improvements should be made moving forward. From a technology perspective, team conversations are getting started to develop a headless or hybrid strategy.

Reinforcing the university’s brand has become a core component of the team’s mission, supporting the larger goals of Mizzou’s value in the higher-ed community and increasing student recruitment and retention. In just a few months, the team will completely oversee all the websites for Mizzou’s 13 main Colleges and Schools, implementing theme and brand standards on every site.

“Our goal was always to get to the point where we could help our content managers take a website and easily manage their own content without us having to be involved,” explains Bailey. To that end, Mizzou content managers can now take self-paced training—created by Bailey’s web developers—to better understand how the university’s Drupal and WordPress environments work. How to more quickly and efficiently set up new websites. And how to grow their technology skills and knowledge to be part of the extended team’s continuous improvement process.

> “We wouldn’t have been able to dedicate our time to the many internal client requests without Upsun capabilities, infrastructure management, and their technical team supporting our backend. That has saved us both time and budget.”
> 
> **Kevin Bailey**

### [UNICEF Switzerland and Liechtenstein joined us | Upsun](https://upsun.com/blog/unicef-switzerland-and-liechtenstein/)

# UNICEF Switzerland and Liechtenstein moves to Upsun

Challenge: To eliminate limited, time-consuming testing processes that impeded development workflow

Solution: Adopt Upsun to gain the flexibility to test and deploy new services faster

Stack: Drupal

Results:

-   60% reduction in costs
-   Ability to scale during emergencies
-   Improved donor and fundraising experiences

---

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

## **Pioneer in nonprofit digital transformation moves to Upsun, gains flexibility, drives innovation**

For more than 70 years, the United Nations Children’s Fund, or UNICEF, has been committed to children's rights throughout the world. Today, more than 12,000 employees in 150-plus countries worldwide work diligently to advocate for children and to provide support and services for education, health, nutrition, and hygiene. UNICEF also campaigns for refugees and against recruiting children into military service. All of the organization’s efforts are financed entirely by voluntary contributions from governments and private donors.

Numerous national committees represent UNICEF on a global scale, acting as independent nonprofit organizations that educate the public on a local level about UNICEF's sustainable development goals and collect donations for both national and global UNICEF projects. One of these committees is UNICEF Switzerland and Liechtenstein, founded in Zurich in 2018. As an independent non-governmental organization, it’s one of UNICEF’s 33 national committees.

Manfred Ruf, the head of information technology at UNICEF Switzerland and Liechtenstein, has been working with the organization for nearly 15 years. His responsibilities include IT infrastructure maintenance and ensuring the security and operability of unicef.ch. He’s also responsible for the continuous development of communication systems and the donation portal. In recent years, Ruf repeatedly encountered setbacks in his development workflow due to a lack of flexibility in testing processes—until he migrated from his old hosting provider to Upsun.

## **Creating more efficient ways to work**

Ruf's goal has been to replace outdated systems with modern technologies to create agile workflows that can help manage the organization’s IT infrastructure more efficiently. UNICEF Switzerland and Liechtenstein uses Drupal for web development and is supported by the expert Drupal team at Swiss-based MD Systems and its subsidiary Kampaweb, both Upsun partners.

Part of the organization’s digital transformation was a long-needed overhaul of the outdated unicef.ch website, last updated in 2013. With swift, ever-evolving technology advancements and the official November 2021 end of support for Drupal 7, a timely transition to Drupal 8 was needed. Upsun provided the necessary flexibility to the organization’s testing process.

Prior to adopting Upsun, UNICEF Switzerland and Liechtenstein was hosted on Nine, the leading cloud provider in Switzerland; a sandbox was used for testing purposes. Even though there hadn’t been major problems with the old solution, Ruf encountered obstacles during the transition from Drupal 7 to Drupal 8. And creating a testing environment was limited and time consuming, Ruf explains.

"Eventually MD Systems asked us if we wanted to change our hosting provider. They said Upsun would make it much easier to create test environments and copy entire web pages, so we could proceed faster. In general, we trust our agency to recommend the best possible solutions."

## **A compelling combination: cost effective, reliable, and GDPR-compliant**

Since UNICEF Switzerland joined forces with Liechtenstein in September 2018, an important criterion for any tool used by the organization has been its conformity with the European General Data Protection Regulation (GDPR); Liechtenstein—unlike Switzerland—is subject to European data regulations. Ruf quickly learned that Upsun not only complies with the GDPR, but also enforces strict security standards in general.

Although Ruf normally tests and compares three to five different solutions, he says that the Upsun price/performance ratio was unbeatable, which led to a quickly made decision.

"The cost was a major reason why we decided to go with Upsun. It is far less costly than our previous provider, and we actually decided relatively fast that we wanted to change," Ruf says. "And I have to say we’re very satisfied. We didn't have any failures or loss of speed."

## **Less complexity, more productivity**

#### **60% Reduction in costs**

UNICEF Switzerland and Liechtenstein has been with Upsun since 2018, and Ruf says he's more than satisfied. He emphasizes that the organization has benefited from numerous Upsun services and that he’s happy to have made the switch.

"Even though we didn't have any serious issues before using Upsun, everything was more complicated," Ruf explains. "Especially when it came to building test environments. I had to call MD Systems, and they had to copy all the content. So it took a long time to test something new.”

> Today, I can easily create a clone of my current system, and it's fast. We’re much more flexible.
> 
> **Manfred Ruf**  
> Head of Information Technology  
> UNICEF Switzerland and Liechtenstein

## **New pages go live faster, can be scaled at any time**

One of the most important technical criterion for Ruf is to retain flexibility in providing new services. Fast and smooth deployments are often critical factors for the organization. Emergency situations, where quick action is required, are not uncommon.

"If, for example, public fundraising reaches out to us in the morning with a request for the creation of a certain page that has to go live in the afternoon, I can do it the same day,” explains Ruf. “Prior to Upsun, it would take me half a day or even an entire day."

The newly won scalability that UNICEF Switzerland and Liechtenstein gained through Upsun has become indispensable for the organization today. Ruf also praises Upsun for its easy usability and customer support.

> If you ever need anything or want to change something, there's always someone to support you quickly. Unlike other platforms, Upsun is much less bureaucratic.
> 
> **Manfred Ruf**

## **Enabling the adaptation to modern technologies**

Currently, UNICEF Switzerland and Liechtenstein is working with MD Systems on a complete revision of its current donation and fundraising processes. The cloud-based CRM service Salesforce will soon replace the old system to enhance the future fundraising experience for donors and UNICEF. Upsun will play a significant role in the transition to Salesforce.

"Everything about payment transactions and the payment status is now being completely revised," Ruf says. "It's a huge project."

Even though Salesforce has been offering a custom solution for nonprofit and charitable organizations for years, not many nonprofits in Europe are using the solution. UNICEF Switzerland and Liechtenstein is now considered to be at the forefront of digitization in the nonprofit sector. Ever since the project started, Ruf has been attending a large number of industry events, presenting the new venture to other organizations. "And I also like to mention our good experiences with Upsun," he says.

Upsun provides UNICEF Switzerland and Liechtenstein with test environments and the necessary flexibility to move the project forward efficiently. The revised donation and fundraising processes are scheduled to go live in March 2020.

"Especially in the context of testing, we use Upsun a lot," Ruf says. "We build test environments with Salesforce integration and test processes quickly and easily. The flexibility helps us enormously."

## **An optimistic look into the future with Upsun**

Ruf explains that UNICEF Switzerland and Liechtenstein realizes benefits from Upsun in terms of productivity, speed, and cost. "Costs have decreased by more than 60%," Ruf says and shares that the organization has also started to use Upsun to host another children’s aid website.

> Everything has become easier and, above all, faster. The handling of Upsun is professional, there are no noticeable failures, and the good price-performance ratio is, of course, very important in the nonprofit sector. The cooperation is simply great and has no downside.
> 
> **Manfred Ruf**

UNICEF bases its commitment on the principles of tolerance, mutual understanding, solidarity, and peace between peoples. The children’s relief organization opposes any kind of discrimination, is politically and denominationally independent, and works to improve the living conditions for children in developing countries. Learn more about UNICEF and how you can make a donation.

### [Global Drupal delivery made simple](https://upsun.com/blog/aten-design-group-global-drupal-delivery/)

# Global, multilingual, and scalable websites for mission-driven organizations

Challenge: Aten Design Group was tasked with building a multilingual, multi-region Drupal site for a mission-driven client. Aten needed one standardized, production-like review workflow for a multilingual, multi-region Drupal program, where every branch spins up a live environment stakeholders can open, so reviews move faster and releases stay predictable.

Solution: Aten adopted Upsun to standardize one workflow. Every branch gets a live environment, allowing teams and clients to review real sites instead of screenshots, and move faster together.

Stack: Drupal, GitOps

Results:

-   One repeatable workflow for global delivery
-   Faster reviews with live, shareable URLs
-   More predictable releases with production-like testing

---

## **Complex coordination slowed reviews**

Aten Design Group builds websites for nonprofits, education, and government. Clients like Health Care Without Harm publish content across languages, regions, and time zones, so teams need to see real changes quickly and give clear feedback.

Travis Tomka, Senior Developer, explained: “Aten is a full-service strategy, design, and development agency. We focus on higher ed, government, and mission-driven organizations like Health Care Without Harm." Work often involves distributed teams, regional content owners, and tight timelines. Standardizing how work is built and reviewed keeps everyone aligned.

For Aten’s client’s global, multilingual scope, the priority was to consolidate onto one Git-based workflow where each branch automatically creates a live, production-like environment, so editors and regional owners review real changes in context, cut repetition, and keep development, testing, and production aligned.

##### **What Aten needed:**

-   A single way to build and review across regions and languages
-   Fewer manual steps in setup and deployment
-   Live previews that non-technical stakeholders could open and understand

## **One workflow on Upsun**

Upsun simplifies how Aten builds and scales Drupal sites for international clients. With Upsun, the team follows one consistent process that reduces handoffs and guesswork.

Day-to-day control matters on busy projects. Tomka is direct: "We have control over all of the resources in the environment, and we customize them exactly as we need them at a really granular level. Our clients have access to everything, too." When content spikes or a region expects a surge, the team tunes resources and keeps work moving without changing how people collaborate.

##### How work flows now

-   Each branch spins up a live environment that mirrors production.
-   Teams share a link, see the change in context, and give feedback right away.
-   Approvals move faster because everyone is reviewing the same thing.

With production-like environments, editors validate copy and layout in place. Developers avoid translating screenshots into assumptions. Project leads get clearer timelines because feedback cycles are shorter and focused.

## **Multi-region publishing made simple**

Health Care Without Harm serves audiences in the Americas, Europe, and Asia. Some content is shared globally, much of it is regional, and each market needs a site that feels local. Aten set up the project so content and look adjust based on the active domain. As Tomka explains, "We used the Domain Access module so the site can switch the color palette and the content based on the active domain."

This keeps shared assets consistent while giving regional teams room to tailor pages for language and local needs. Because each branch has a live environment, editors check translations, imagery, and layout in a space that behaves like production. If something needs to change, the team updates the branch and shares a fresh link. Decisions happen faster because everyone can see the same thing at the same time.

The model reduces risk, too. Less manual coordination means fewer chances for configuration drift and last-minute surprises. A change that works in a review environment is more likely to work after merge because it has already run on a close copy of production.

## **Continuous delivery with clear reviews**

Upsun turned a complex process into a steady rhythm: build, preview, review, ship. Automatic environments keep developers confident and client teams involved at every step. Reviews are not blocked by staging windows. A link is created with the environment, shared with the right people, and the team moves on with clear feedback.

Consistent environments and shared access keep everyone aligned during reviews, from the client's internal developers to Aten's team and project stakeholders. Fast feedback loops reduce rework and protect timelines. After launch, new ideas can be explored in a branch and reviewed by regional owners without interrupting day-to-day operations.

## **Results at a glance**

-   Simplified management: Spin up review environments from Git with the same setup used in production
-   Faster delivery: Live preview links speed up QA and client sign-off
-   Unified workflow: One path from development to production across languages and regions
-   Reliable rollouts: Validate changes in production-like environments before release
-   Better collaboration: Share a link and review together, no more back-and-forth screenshots

## **Looking ahead**

Aten is applying this approach to new Drupal projects and reusing what works. Regional owners get clear review paths. Developers get solid guardrails. Project leads get predictable schedules. Upsun helps the agency focus on what matters most: reaching global audiences with clear, accessible experiences that reflect their mission and deliver results.

### [Qombo hits 3,000+ RPS on Upsun with zero downtime](https://upsun.com/blog/qombo-fintech-upsun/)

# Qombo launches bank‑grade verification at 3,000+ RPS with Upsun

Challenge: A fixed regulatory deadline, bank-grade reliability expectations, and a lean team. Qombo needed to launch an EU-sovereign verification API capable of handling unpredictable spikes, without hiring DevOps or pausing product work. They also required audited controls, encryption, and EU data residency to expedite clearing bank compliance reviews.

Solution: Upsun provided an EU‑hosted application platform with the required compliance and security, Git‑native deployments, environments‑as‑code, automated scaling, and a co‑validated zero‑downtime deployment flow. Qombo built and shipped from a single repo; Upsun handled the platform, security posture, backups, and observability.

Stack: Fintech

Results:

Reliability, velocity, credibility

-   Sustained 3,000+ requests/second at launch with zero downtime.
-   0 DevOps hires required; founders focused on product and customer onboarding.
-   EU sovereignty on OVHcloud, accelerating bank due diligence and compliance reviews.
-   Faster iteration cycles with safe, repeatable zero‑downtime releases.

---

_**A lean, product-driven fintech ships continuously, without the infrastructure overhead.**_

**Qombo** is a Paris-based fintech that provides an API for IBAN and beneficiary-name verification to banks and payment providers across the EU. Its buyers, banks, and regulated payment providers expect 24/7 availability, low latency, and audited controls.

Built by two founders, Qombo set out to prove that a lean team could deliver bank‑grade reliability from day one. The commercial plan hinged on meeting a hard go‑live date for early banking partners while keeping the core team intentionally small.

On the technical side, Qombo runs a Node.js API and a Next.js web app, with Redis for caching. Data persists in both MongoDB and PostgreSQL, and encryption at rest is handled via Vault KMS, a stack chosen for speed, operational simplicity, and bank-grade resilience.

### **From DIY risk to operational bottleneck**

Demand was lumpy and high-stakes; a launch cohort could drive traffic surges of thousands of requests per second with no warm-up window. Every deployment risked interrupting payment‑adjacent workflows, and any outage would erode trust with compliance‑sensitive buyers.

That growth curve exposed an operational truth: DIY infrastructure would dilute focus and force a DevOps hire before revenue. Qombo needed a platform that met compliance, regulation, and EU sovereignty expectations, scaled automatically, and made releases operationally invisible, so product velocity wouldn’t slow under operational load.

### **Why Upsun: compliance, no‑ops, and a partner mindset**

Upsun matched the brief on three fronts. First, compliance posture and EU hosting let Qombo lead with credibility in banking conversations. Second, a no‑ops model, Git‑based workflows, automated pipelines, managed backups, and security hardening meant the team could keep headcount lean. Third, partnership: Ahead of launch, Upsun worked directly with Qombo to validate a zero-downtime rollout approach tailored to a high-throughput API.

> "We really wanted to work with OVH behind Upsun, our clients are all Europeans and are very happy with this.", - **Arthur Legourd, CEO and Co-founder, Qombo**

### **Implementation on Upsun**

Qombo's stateless services and data layer were modeled as code on Upsun, with environments branching from Git. Production ran on OVHcloud in the EU; autoscaling absorbed spikes while guardrails enforced safe deploys. The application layer is Node.js with a Next.js web app; Redis handles caching for hot paths. Data services combine MongoDB for document workloads and PostgreSQL for relational needs, with Vault KMS providing encryption at rest. Together, Qombo and Upsun employed a blue-green deployment style to ensure changes were shipped without interrupting live traffic. Observability and alerts were tuned to surface only what mattered during the first critical weeks.

### **Impact: continuous delivery without downtime**

Within the first release window, Qombo sustained over 3,000 RPS with zero downtime, proving that a two-person team could meet bank-grade expectations without a DevOps function. Deployments became a background task: small, frequent, and uneventful. The credibility of EU sovereignty shortened buyer reviews; the absence of infrastructure toil accelerated roadmap work.

> “The most important thing for us was to have a reliable partner doing all the DevOps and infrastructure for us. Not having to hire a person specifically for DevOps is critical.” **\- Arthur Legourd, CEO and Co‑founder, Qombo.**

With the platform layer handled, Qombo’s founders now spend their cycles on customer feedback and product improvements, not fire drills. Zero‑downtime releases turned into a habit, reinforcing confidence with every change.

### **What’s next: scaling calmly across EU banking**

Qombo plans to expand coverage across more European banks and adjacent verification flows while maintaining an intentionally small team.

> "We want to keep a small team and keep building, not hiring. DevOps is strategic for us because it saves money and keeps us focused on the product.", **\- Arthur Legourd, CEO and Co-founder, Qombo**. 

With Upsun as the operational backbone, scaling is a planning exercise, not a hiring plan.

For fintech teams wrestling with EU compliance, unpredictable traffic, and limited DevOps capacity, Qombo’s story shows that the right managed platform does more than keep systems running; it turns infrastructure risk into product velocity, zero-downtime releases, and the confidence to scale with customers.

### [How Symphony3 standardizes council delivery | Upsun](https://upsun.com/blog/symphony3-standardizes-digital-delivery-councils/)

# How Symphony3 standardizes digital delivery for 40+ councils across Australia and New Zealand

Challenge:

Symphony3, a digital solutions agency, delivers integrated digital services for local government councils across Australia and New Zealand. It provides 3 core services: Digital solutions, Integration solutions via its SmartGlue platform, and AI solutions via its Beetrix AI platform.  
  
Each council requires secure, accessible digital solutions, across websites, webforms, emergency dashboards and more.  
  
However, managing these as bespoke individual projects created massive infrastructure overhead. Slow deployment cycles and manual server configurations were becoming a bottleneck, limiting the agency’s ability to scale and respond quickly when councils needed urgent digital updates.

Solution:

Symphony3 consolidated its entire local government digital solutions and delivery model on Upsun, replacing time-consuming manual server management with an automated, code-driven workflow.  
  
This enabled a standardized, repeatable delivery model: council websites and digital services are built on consistent templates, meaning a new council can go from signed contract to live infrastructure in a fraction of the time previously required.  
  
The digital infrastructure on Upsun was integrated with Symphony3’s wider delivery model (integration and AI), connecting council websites and forms to core back-end systems and automated workflows.  
  
Symphony3 primarily deploys on AWS, leveraging its security certifications and infrastructure reliability to meet the data residency and compliance requirements expected by local government. For risk-conscious council CEOs and CTOs, this matters as it removes the unknowns of bespoke infrastructure and replaces them with a proven, enterprise-grade delivery model.

Results:

-   **Scalable platform operations**: Automation enables a lean engineering team to efficiently manage and deploy applications across 40+ unique council environments.
-   **Hundreds of thousands in savings per annum**: Automated workflows for Ballina Shire eliminated 5,000 hours of manual handling, delivering ROI in just five weeks.
-   **Reliability during high-demand events**: Rapidly deployable emergency dashboards provide a single source of truth during fires and floods, pulling real-time data from trusted sources with minimal manual intervention.
-   **Unified backend integration**: Digital applications running on Upsun connect directly to Symphony3's SmartGlue integration platform. This architecture enables secure synchronization with critical council backend systems, including ERP, finance, asset management, document management, and much more.
-   **AI plug-ins**: Councils using Symphony3’s SmartGlue deployment can plug-in Beetrix-AI to deliver AI driven services. This includes AI Infringement Agents, AI PDF to Digital forms Creators, AI Heritage Agents, and more.

---

### **Moving beyond the bottleneck of manual deployments**

Local councils face a unique digital pressure: they must deliver integrated digital services, enterprise-grade security and 24/7/365 availability with limited internal resources. For Symphony3, the challenge was managing this at scale. Before adopting Upsun, every new council project risked becoming an operational burden.

The friction wasn't just in the initial build; it was in the toil of maintenance. Manual server configurations and fragmented workflows meant that launching a new service or patching an existing one took focus away from what really mattered: the citizen experience.

> _"Symphony3 needed a platform that could eliminate infrastructure overhead, make integration into core systems easier to maintain, and let one developer do the work of many, without sacrificing reliability or security." – Philip Joseph, Head of Digital Solutions, Symphony3._

### A repeatable delivery model built for local government

Symphony3's pivot was an architecture change, not just a hosting swap. They needed a platform that would enable scalable, repeatable, and integrated digital services. They leveraged Upsun to create a repeatable delivery model.

By defining infrastructure as code, Symphony3 can now spin up a new council environment, complete with the necessary security certifications and configurations, in a fraction of the time.

This approach allows the agency to offer "out-of-the-box" integrated digital services that feel bespoke to the citizen, and plug directly into enterprise systems, all while being managed through a unified, high-efficiency pipeline.

### **Websites built for councils, delivered at pace**

Symphony3 has delivered modern, accessible websites for councils across Australia and New Zealand, each built to help residents find information and complete transactions online without needing to call.

For the City of Greater Bendigo, a seven-year-old website was replaced with a modern integrated, AI-enabled digital platform delivering services at three to five times better cost efficiency.

Golden Plains Shire Council saw the benefits extend well beyond the website itself. Online forms now integrate directly with core council systems, eliminating manual processing. Staff were fully trained and equipped with tools that let them design and publish content without relying on developers. With reusable code, designs, and forms developed across Symphony3's council network, Golden Plains avoided the cost of building from scratch.

When Lismore City Council's previous website provider ceased operations, Symphony3 moved quickly to ensure continuity of service, delivering 3 smaller register/applications within a tight timeframe and preventing any disruption to the council's digital presence during the transition.

### **From webforms to emergency preparation**

The true test of this standardized model is the emergency dashboard. In moments of crisis, such as bushfires or flooding, council websites see massive traffic spikes as residents look for a single source of truth.

On Upsun, these dashboards pull live data from third-party emergency services (like the Country Fire Authority (CFA)) and scale automatically to handle the surge. Residents can access real-time information such as live mapping showing road closures, live updates pulled directly from council social media pages, and critical information from trusted emergency sources, all in one place.

Because the infrastructure is pre-configured and proven, council staff don't have to worry about server health during a crisis; they can focus entirely on communicating critical information to their community.

> _"The emergency dashboard is a strong example of what is possible... the same speed, reliability, and scalability applies to every website and digital service delivered on the platform." – Philip Joseph, Head of Digital Solutions, Symphony3._

### **Real-world impact: hundreds of thousands of dollars saved per year**

The results of this modernization are evident in the Ballina Shire Council project. Symphony3 designed and built digital forms and payment registries that automated work previously done by hand.

That automation eliminated roughly 5,000 hours of manual data handling per year.

The project paid for itself in just 5 weeks and now saves the council hundreds of thousands of dollars each year.

The outcome reflects the combination of the two: Symphony3 built the integration and automation that delivered the savings, and Upsun provided the platform that allowed it to be built quickly and run reliably. With Upsun handling the plumbing (automated updates, scaling, and compliance), Symphony3 has reclaimed hundreds of hours previously spent on server maintenance.

### **A blueprint for public sector modernization**

The journey of Symphony3 proves that digital transformation in local government doesn't have to be slow or resource-intensive. By choosing a platform that prioritizes standardization and developer autonomy, agencies can deliver higher-quality services to more citizens, more quickly.

> _"Using Upsun, Symphony3 has strengthened its ability to deliver high-quality digital outcomes at scale, reducing DevOps overhead and redirecting hours toward building better solutions for councils." - Philip Joseph, Head of Digital Solutions, Symphony3._

### **About Symphony3**

Symphony3 is a digital solutions company established in 2011 and dedicated to local government. Over more than a decade, Symphony3 has delivered more than 120 local government projects across Australia and New Zealand, building a platform trusted by over 40 council clients today.

Symphony3's three core solution areas, digital, integration, and AI, drive the way Symphony3 partners with councils to deliver simple, connected customer experiences that meet the evolving needs and expectations of communities.

### [Open Social: SaaS for custom communities | Upsun](https://upsun.com/blog/open-social-saas-solution/)

# Open Social: a SaaS solution for custom communities at scale

Stack: Drupal

---

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

In 2016, Open Social announced our partnership with Upsun. This partnersOpen Social is a Software-as-a-Service hip has enabled us to create a simple and secure way to deploy new online community platforms for our clients (and keep those communities running without a hitch!).

It’s possible that even if you’re an Open Social client, you may not be aware of the fact that your community is actually running on Upsun. On the other hand, you may be a Upsun user already, but weren’t aware that there were businesses built to a large extent on top of their API.

Either way, our collaboration with Upsun has enabled us to maintain thousands of community sites, and we thought you might be interested in how it all works.

## **What is Open Social?**

For those who are unfamiliar, Open Social is a Software-as-a-Service (SaaS) online community solution. This means that we set up community platforms for clients, including company intranets and knowledge bases for governmental organizations, as well as e-learning platforms for NGOs and others. You can very quickly receive an out-of-the-box online community, and then as soon as it’s deployed, you can customize the site in a number of ways to suit your organization—from adding branding and selecting a color palette to uploading custom content and changing its layout.

## **But how does Open Social work?**

SaaS products like Open Social can get tricky: how you choose to deliver a piece of software to clients can often introduce limitations on what the software can (and can’t) do when they finally get it.

You can choose to provide clients with their own isolated instance, and that comes with a lot of benefits. Their sites can be customized completely, from their look and features to scaling to meet traffic demands, but that approach does have downsides. If you're successful enough to set up hundreds of clients with their own instances, what’s the best way to ensure regular updates and consistent security across all of them? You’d need to build tooling to manage it, and that investment could run up the already considerable operating costs of the instances themselves.

Alternatively, you could very well decide on a more shared approach. In this case, individual clients really only have a slice of the whole product in the cloud, rather than their own instance. This can be helpful in initializing what they see and keeping every client up to date very easily, since everyone’s sharing the same data. But without true isolation, the software they get is at least in some way dependent on that shared data, as well as the health and security of the larger ecosystem. And an individual client’s site becomes that much more difficult to scale and customize.

Trying to get the best of these options without their respective setbacks is what led to our current model using Upsun. At the most basic level, each community on Open Social is a Drupal site, and each site’s code exists on its own Upsun project. To manage this model across all of our clients’ communities, we built a tool called Multiverse. Multiverse wraps around and leverages the Upsun public API to manage both individual and larger groups of projects, keeping all of our communities updating regularly in the background.

With this model of one project per community, with a larger API at our disposal, we do get the best parts of those two options for offering a SaaS product. If you sign up for Open Social, you’ll get a Upsun project that’s completely isolated from anything else. No other community site affects yours, and your site can be scaled up, scaled down, and customized however you need it to be, at any time. Retaining this ability to customize is essential for the very idea of a community. We can then initialize and create new communities quickly from a common template using the Upsun API, and then continue updating the whole fleet—that is, all of the communities we oversee—in the background from then on.

## **Multiverse: focus on building communities, not platforms**

With the development of Multiverse, we’ve automated the entire process of initializing and deploying sites for individual communities. “Multiverse controls just about everything,” says Open Social Senior Developer Ronald te Brake. “Multiverse receives the site and domain name from the customer success manager and then talks to Upsun using the API. It can say, ‘Okay, I need a new environment in the German Region, the European Region, or the US region.’ And then Upsun will start creating that environment. And once that’s done, Upsun will send a signal to Multiverse, so we know the site has been created. Multiverse can also say, for example, ‘I want the site name to change,’ so it can also update the community using the API.”

All of these things can be done through the Upsun API, which enables our team to manage nearly every aspect of an account and the communities hosted with us. te Brake shares, “It’s really good at opening up all the necessary configurations for us to create, manage, and maintain websites. The API allows you to abstract it a step up, so you can make changes to multiple projects at the same time.”

Instead of relying solely on Upsun’s management console to manage individual projects, Multiverse provides the interface to all communities, opening up considerable fleet management capabilities for us.

_Multiple online communities are hosted on Upsun and managed by Open Social through Multiverse._

Multiverse works because of our consistent model shared by every community on Open Social. Since every community is a Drupal site on a Upsun project, we can very easily initialize new communities with a well-tested template and extensions through Multiverse. Each community will want a specific domain, which just becomes another endpoint called through Multiverse. “You can do everything you need to through the dashboard as well, te Brake explains. "But it's more just manual labor. The end-goal of Multiverse is to make sure we can just about automate everything."

So what does the customer get from Open Social working with a tool like Multiverse sitting on top of Upsun—besides the trade-off between isolation and being a part of our large-scale community monitoring and security practices?

FIrst of all, Multiverse enables Open Social to anticipate the external integrations communities commonly need, making them part of the initialization and maintenance process tied to their accounts. Stripe credentials get added to the accounts and the Multiverse dashboard, so everything that our developers and account managers need to know about one community is totally available.

As a result, Open Social clients don’t have to ever worry about hosting. Client site managers don’t have to log in to the hosting platform themselves. “It’s only developers logging in,” says te Brake, “And that’s why we’d rather have better APIs and a better developer experience.” This is exactly what Open Social gets from Upsun: a trusted partner that understands the needs of developers. “The fact that Upsun opens up the API means that it gives us a lot of opportunities that aren’t directly visible to customers. Users don’t notice anything in the entire process because there’s a partner that does this for us and takes away any potential problems,” says te Brake.

Another interesting side effect of this relationship is the kinds of communities we can initialize, including some that open up new opportunities for both Open Social and our clients. Since each community is a Drupal site, it’s possible through Multiverse to set clients up with a multisite solution: where a client’s project is actually multiple Drupal installations sharing the same codebase.

This solution is very useful for large NGOs that regularly run different projects or campaigns, both internally and externally, and need a standardized way to bring stakeholders together online. If a client needs a number of separate (but interoperable) communities, Open Social can create a custom community template that lets us nearly instantly deploy a new community and make it live. Ronald te Brake explains, “We have a template—a shared set of features that has been combined—and you can use that to easily install a new environment with the same configurations.”

## **API helps deliver a seamless customer experience**

In the end, the Upsun API removed a lot of the limitations we would have encountered early when designing Open Social. It wasn’t as necessary for us to weigh the trade-offs between developing a single tenant (one installation per client) or multitenant (shared resources between all clients) model for our product. Instead, we could get the best of both models by providing isolated instances for each of our clients that are initialized and managed as a part of a larger ecosystem of communities with Multiverse. This approach enables us to provide secure and dependable sites for our clients—all while allowing them to customize those communities as they grow and evolve.

### **Related content**

-   Find out how to start your own online community with Open Social
-   See a similar example, and review the Admiral example codebase
-   Check out the Upsun API documentation

_Adriaan Odendaal’s experience spans a spectrum of creative disciplines—from design and copywriting to web design/development, marketing, multimedia, animation, and screenwriting._

### [SportRx hits peak performance with PaaS | Upsun](https://upsun.com/blog/sportrx-hits-peak-performance-with-paas/)

# SportRx hits peak performance with Upsun

Challenge: To find a scalable solution, including modern development and automated deployments, to help meet a 40% annual growth goal

Solution: A secure, scalable, agile solution, with triple redundancy and high memory to support ecommerce needs on Magento

Stack: magento

Results:

-   80% fewer website support requests due to problems with the website
-   Average time to install weekly software updates dropped from an hour to 15 minutes, a 75% decrease

---

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

Pedaling up a mountain trail. Slaloming down a ski slope. Sprinting across the finish line. You'll never spot a SportRx customer standing still. By equipping its perpetually in-motion patrons with customized, high-end prescription sports eyewear, SportRx has seen its growth set an equally blistering pace: 40 percent yearly over the past four years.

But one thing at SportRx was stuck at a standstill: their cloud infrastructure. “Our infrastructure was very static,” says SportRx Director of Technology Saaed Fattahi. “We had two dedicated web servers and one dedicated database server hosted by a vendor. No redundancy. If traffic went up, we couldn't upgrade our servers very easily; it could take up to a week. We were feeling some pains.”

Needing a scalable cloud solution that could keep stride with its accelerating web traffic, SportRx asked Upsun to help them put their best foot forward. “Scaling is no longer an issue,” says Fattahi. “Our Upsun environment easily and automatically scales out to meet the demands of the incoming web traffic, and it’s triple-redundant to protect us against hardware failures.”

## **Searching for high performance in heavy traffic**

Every SportRx sale is a tightly orchestrated online process. Customers choose their eyeglasses on the SportRx website with assistance from a trained optician (who’s just as much of a sports junkie as any SportRx customer). Each customer order and prescription is then transmitted to a lens manufacturing laboratory through an XML interface. The laboratory fills the order and ships it to the customer.

“Because our product is so configurable,” explains Fattahi, “our site is pretty customized. We’re constantly working to improve the site, making it easier for people to place orders. The key to our business is having a robust infrastructure that ensures our website is always performing well, regardless of the amount of traffic.”

> Our Upsun environment easily and automatically scales out to meet the demands of the incoming web traffic, and it’s triple-redundant to protect us against hardware failures.
> 
> **Saaed Fattahi**  
> Director of Technology  
> SportRX

A third-party vendor handles all SportRx website development, with SportRx managing product development duties in-house. As website traffic grew, SportRx found themselves throwing more and more man-hours into site management duties.

## **Fighting the grind**

When SportRx realized its growth wasn’t slowing down anytime soon, the company decided it was time to make a significant investment in their technology infrastructure. In October 2019, they took the first step of hiring Fattahi to oversee the company’s backend infrastructure, analytics, and reporting.

Fattahi realized when he came onboard that the company’s steady growth was in danger of being throttled by their archaic cloud infrastructure. “Site performance has a direct impact on conversion rates,” says Fattahi. “SportRx had been working on the software end of things to speed up page loads. But the infrastructure kept slowing things down. The site was constantly grinding to a halt anytime a crawler came through or the caches filled up.”

Even if SportRx could overcome its infrastructure liabilities to create an enticing ecommerce experience for customers, that success would only lead to more site visitors. And Fattahi knew that the site had very little ability to scale to meet demand. Win or lose, the infrastructure was going to cost SportRx business. “I made the recommendation to management that it was time to overhaul it,” Fattahi recalls.

## **“It sounded so much easier than the way we were doing things”**

“My first thought was to design and build our own cloud infrastructure on Amazon Web Services, so we could auto-scale and stuff like that,” says Fattahi. “But then we worried about having to do our own support and monitoring without really having the necessary technical expertise in-house.”

So Fattahi began asking around about other solutions. The CEO of SportRx’s development agency mentioned the success their agency had experienced partnering with Upsun. Fattahi struck up a conversation with Upsun and liked what he heard.

“What stood out from our initial talks were things like the triple redundancy of the environment; we could stop worrying about servers and data centers going down,” Fattahi shared. “I liked hearing about the ability to scale out both purposefully and when traffic demanded it. I also liked the integration with Git and the ability to automatically push updates to the production and staging sites. It sounded so much easier than the manual way we were doing things with our previous cloud vendor.”

## **Seeing is believing**

When SportRx migrated to Upsun, Fattahi watched in satisfaction as each action item from his conversations came to fruition.

“Compared to our previous cloud infrastructure, our Upsun environment has been very stable and performant,” says Fattahi. “We spend much less time dealing with performance and caching issues and more time on end-user features that make the shopping experience better for our customers.”

SportRx CEO Dan Bruton leads his bespectacled team in a cheer celebrating their rapid growth.

Beyond Upsun capabilities and performance, Fattahi was impressed by how attentive Upsun customer support was to his needs. “Our previous vendor was very reactive. It was always on us to notice if the site was slow and to ask them to look into it. But Upsun is very proactive. I remember an incident shortly after we went live when a Google crawler slowed down the site, and Upsun automatically upscaled us to compensate.”

Fattahi has also been eager to tap into the deep Magento expertise that Upsun brings to the table. “Upsun has really looked over how we’re doing things and how things are configured. They’ve suggested a bunch of changes—such as changes to Fastly to thwart unwanted crawlers from affecting performance—that ended up really stabilizing the site.”

> We spend much less time dealing with performance and caching issues and more time on end-user features that make the shopping experience better for our customers.
> 
> **Saaed Fattahi**  
> Director of Technology  
> SportRX

## **Systems are a go**

With a strong start to the partnership, Fattahi is looking to inject Upsun capabilities into additional SportRx systems. “As we grow—and operational efficiency becomes increasingly important—our footprint on Upsun might get larger,” Fattahi says. “We have a lot of systems running in the background for such things as order fulfillment, inventory management, CRM, and analytics. Those could be things that move to Upsun at some point.”

As eyeglass wearers continue to turn to SportRx to equip them for biking, skiing, and running, SportRx will continue to turn to Upsun to equip them for scaling, optimization, and performance.

### [Olympique de Marseille scales projects seamlessly | Upsun](https://upsun.com/blog/olympique-de-marseille/)

# Olympique de Marseille supports a growing fanbase with new projects built on Upsun

Challenge: To simultaneously build, test, deploy, and scale 2 critical applications in just a few months, using a variety of programming languages and frameworks

Solution: Build both applications with Upsun, creating individual dev environments with staging that perfectly replicates production—streamlining development, simplifying deployment, and ensuring scalability

Stack: PHP, Python, JavaScript

Results:

-   Generate 3 repositories to eliminate challenges with simultaneous deployment
-   Simplify monitoring and troubleshooting for OM Connect with Blackfire observability
-   Improve ease and speed of deployment
-   Successfully manage sudden traffic surges (100-200x increase in visitors) without impacting the fan experience

---

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

Olympique de Marseille (OM) is a professional football club in Ligue 1, the elite French football league. Founded in 1899, the club now holds nearly 30 titles across its league, France, and all of Europe. Its loyal fanbase of 25 million considers Marseille an integral part of their lives.

Due to the popularity and success of the club, Marseille’s digital team manages about 30 diverse applications. With internal sites for operations along with fan-facing applications to manage digital entry, VIP stadium experiences, and more, the development team at Marseille certainly stays busy. 

Yet, they recognize that every programming language has a technical limit, and every digital need requires a unique solution. So Marseille’s developers approach each project with curiosity. They can code in any language required for the best results: PHP, Python, JavaScript, TypeScript, and more. 

With so many sites and applications, choosing the right managed hosting provider for each project is critical, too. So, when Head of Digital Jessy Hanzo saw his colleagues' success using Upsun, he was inspired to explore.

## **Navigating Upsun as a new user**

Marseille’s core website, OM.fr, has been with Upsun since 2019. So when Jessy joined OM in January 2022, he quickly discovered what his developers loved about it.

> “I learned how to use Upsun myself, and it was very easy for me and my team,”

recalls Jessy.

> “The support that we had was very good.” 

Jessy manages a team of developers and project managers at Marseille, dealing in both functional and technical topics across the club. He’s responsible for selecting the best approach, the right solutions, and the ideal contractors and teams for all of Marseille’s digital products. 

As he gained familiarity with Upsun, Jessy grew excited about using it for future initiatives. His first project? Changing the database management system for OM.fr.

## **The push to accommodate live sports data tracking**

Jessy worried that Marseille’s main website, OM.fr, lacked the database support required for the elite club’s robust data tracking and storage needs.

Working with Upsun to identify the right solution, he selected MongoDB—and Jessy’s team prepared to shift a mountain of data on the backend. Typically, database migration isn’t simple, but Jessy felt confident.

> “One of the main advantages of Upsun is the ability to customize products,”

says Jessy.

> “It was very easy to move to MongoDB with Upsun, whereas it can be very difficult with other services, requiring multiple agreement updates and other complexities.”

Thanks to MongoDB, OM.fr can support powerful data tracking tools. For example, Stats Perform generates live statistical updates for every league, championship, and match. With that amount and specificity of data, noSQL tech like MongoDB is essential for optimal performance.

And as the club’s technology needs continue to grow, Jessy knows he’ll have no trouble integrating legacy systems with new frameworks and tools. He remarks,

> “With Upsun, it’s very easy to add more services and to scale.”

## **New projects demand an efficient approach** 

At the start of 2024, Jessy’s team began to scope and design two new key initiatives:

-   OM Connect, a product uniting Marseille fans in a digital landscape
-   Top Bar, a data initiative to create a unified, comprehensive view of the customer journey by injecting script in the top navigation bar across all Marseille websites 

Building on the success of OM.fr, Jessy knew he wanted to build and deploy both projects with Upsun.

Initially, OM Connect and Top Bar used the same repository and shared dev environments. But this quickly proved problematic. Deploying updates for both projects simultaneously led to delays and frustration.

So Jessy consulted the Upsun team. Together, they created an effective solution to give each project its own environment and a third repository for the Olympique de Marseille design system. Since then, the team has streamlined development and improved performance in these initiatives.

> “With separate environments and GitHub Actions, it’s easy for us to deploy very quickly just by pushing some code,”

says Jessy. 

And when issues do arise, Blackfire observability makes it easy to identify and resolve any challenges. 

> “When there’s an error, I need to see how many times the error occurs and understand where it comes from, and just looking at the logs isn’t enough—it’s not sufficient,”

Jessy explains.

> “So it’s really nice to have Blackfire because before, it was a nightmare to dive into issues.”

## **Support, speed, and scalability drive continued success for Marseille**

Testing projects with a new PaaS can be complex, with many unknowns. But for Jessy, working with a team that truly cares about its customers makes a big difference.

> “I'm very satisfied with the support at Upsun,”

Jessy explains.

> “It's good to know that the support team can respond very quickly because at Olympique de Marseille, we have a lot of peaks in traffic. For example, when a football match starts, traffic to the website can increase by 100-200x. So we need the ability to accommodate and answer our customers very quickly.”

With volatile traffic demands, speed and scalability are top priorities for Marseille. They’re also the main reasons Jessy would recommend Upsun to others:

> “If there’s a strong need to deploy different websites with scalability and the ability to deploy very quickly, of course, I’ll recommend Upsun.”

### [Thinkbean: Building customized solutions | Upsun](https://upsun.com/blog/web-dev-agency-thinkbean/)

# Web dev agency Thinkbean to the rescue

Stack: Symfony, Drupal, node.js

---

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

When clients are at the ends of the road (and their wits), with no solutions in sight, they call Boston-area-based Web dev agency, Thinkbean, LLC. A deeply experienced, Drupal-only dev shop, Thinkbean developers apply their extensive expertise to build the customized solutions clients require, when their current vendors’ skill sets have been exhausted. The Thinkbean team stands proud knowing a client has never needed to bring in larger agencies to reach their project’s business goals.

## **Reduce provider costs, gain more value and flexibility**

Upsun enables Thinkbean’s developers to apply the same processes and infrastructure to all clients—regardless of the size of their organizations. This approach drives consistency, optimizes workflow, and keeps customer costs down.

But it wasn’t always this way. Restrictions with their previous provider’s hosting processes and infrastructure impeded Thinkbean’s ability to realize these efficiencies. To better serve current clients (including several major healthcare organizations), the Thinkbean team began to seriously consider other partners/providers. So, they set out the following criteria to guide their evaluation process:

-   Flexible pricing relative to website requirements and usage
-   Value of services
-   Modern features, like CI, VCS, and multiple environments
-   Unlimited GitHub integration
-   Project/environment API
-   Ability to automate integration configuration
-   Quality support
-   Symfony and NodeJS support

“Our former provider didn’t seem to care about smaller shops or sites, or how their decisions impacted agencies like Thinkbean,” mused Mike Milano, Thinkbean’s director of engineering. “After doing our due diligence, Upsun received all the highest marks, in all of our considerations,” says Milano. “And Upsun continues to provide the best solutions for an agency like ours.

Let me give you an example from a technical perspective: the GitHub integration to the Upsun webhook. The webhook integration sets up webhooks on each of our projects. So, when an event happens on Upsun, it pings our agency application. Then, we pull in the data and have a central place to see what's going on with all site deployments. That integration thing Upsun has is just beautiful.”

Thinkbean’s Agency Portal—an internal app for managing client, project, and environmental data—also takes advantage of Upsun integration capabilities. Health checks and tasks—including backups, Drupal security checks, SSL expiration checks, redeployments for certificate renewals, and configuration for log transports to Elasticsearch—are all automated. So, the team can focus their time on creative thinking and solution building.

> From a business point of view, Upsun has a lower cost of entry for a higher standard of base-level service. For example, we could offer one of our clients (a leading healthcare organization) a low cost of entry, and we gain access to all the tools we want. To match Platform’s service offering, the cost from our previous vendor would be ~300% more, which would have translated into a reduction in services or work arounds to keep costs in line with project requirements. Choosing Platform was a no-brainer.
> 
> **Glenn Hodgkinson**  
> Co-founder  
> Thinkbean

### **So,**

“Don't it always seem to go, that you don't know what you’ve got ‘til it’s gone.” Classic Joni Mitchell. But in Thinkbean’s case, it was quite the opposite. “We didn’t know what we’d been missing until, well, we found out what we’d been missing.” Milano says. Thinkbean’s onboarding with Upsun, guided by a team of senior engineers communicating through a dedicated Slack channel, delivered the concise information and levels of support Milano was looking for.

“I was never handed off to different tiers of folks; it's just night and day from the support that we had before,” Milano explains. “In the several years we’ve had projects with Upsun, it’s uncommon that a question isn’t resolved quickly through the Slack channel. That’s been huge for us. Technical documentation is clear, concise, and easy to find. Simply put, support with Upsun has been second to none.”

## **Reported real-world results**

-   Technical support resolutions reduced, in most cases, from days to minutes.
-   Dramatically improved DevOps efficiency and stability, with superior build capabilities available to all projects.
-   Ability to provision as many environments as are needed for QA or prototyping.
-   Increased automation, with access to project/environment data and actions made available from the CLI and libraries.
-   Greater flexibility to offer clients comparable package options, with substantial savings.
-   More value to our business than competitive offerings.

### **Speedier development and approvals, happier clients**

Working with larger clients usually means more organizational complexity and multiple stakeholder reviewers and approvers—often creating project bottlenecks. For Thinkbean, developing with Upsun has streamlined that previously cumbersome process. Now, they have the ability to create multiple environments to test and QA new features, develop those features in parallel, and then, merge them into their master environment.

Find out more about how to reap Upsun agency partner benefits.

### [Happy Coding sped up Hôpital Fribourgeois by 90% with Upsun](https://upsun.com/blog/hospital-backend-modernization/)

# Hôpital Fribourgeois modernization: how Happy Coding cut backend wait times by 90% with Upsun

Challenge: Happy Coding was responsible for a massive UX/UI redesign for Hôpital Fribourgeois (HFR) to modernize its digital presence. However, the agency faced a major roadblock: a legacy hosting provider. The existing infrastructure offered poor performance, sluggish support, and a lack of transparency. Happy Coding saw that hospital editors faced 30-second delays when updating content, while their own development team struggled with "black box" environments that hampered their ability to deliver the project.

Solution: Happy Coding migrated the HFR platform to Upsun, enabling the agency to leverage a flexible, developer-first cloud application platform and regain control of its infrastructure. They utilized the robust Upsun command-line interface (CLI) and automated workflows to bypass previous operational bottlenecks. The agency executed the migration seamlessly. It took just one week of preparation and a mere two hours to switch over.

Stack: migration, application modernization

Results:

-   **90% performance gain:** Content editing time dropped from 30 seconds to under 3 seconds, significantly improving editor productivity.
-   **2-hour migration:** A complex infrastructure switch was completed in just two hours with zero critical downtime.
-   **DevOps autonomy:** The Happy Coding team gained full independence and now manages tasks internally without relying on external support tickets.
-   **Rapid support:** They moved from slow escalation queues to responsive, human-centric support that actively aids project success.

---

### **A digital facelift needs a strong foundation**

When Hôpital Fribourgeois (HFR) engaged Happy Coding to execute an ambitious UX/UI modernisation, the agency knew the stakes were high. For this leading public hospital network in the canton of Fribourg, Switzerland, a website is more than a brochure. It is a critical access point for patients, staff, and partners.

The goal for Happy Coding was clear: create a scalable, intuitive, and high-performance digital platform. However, the agency realised that while their visual redesign promised a better patient experience, the underlying legacy infrastructure was failing to support the hospital's operational needs. Happy Coding knew that a beautiful frontend means little if the backend is unusable for the staff who manage it.

### **When infrastructure slows down care**

While Happy Coding focused on delivering a cutting-edge design, they continually ran into the limitations of the existing hosting provider. The friction points were not just technical. They were operational and costly.

The most immediate pain point was backend performance. Hospital staff, responsible for keeping critical health information up to date, faced excruciating delays. Saving a simple form or updating a page took up to 30 seconds. This latency turned routine content management into a tedious, time-consuming chore.

For the engineering team, the frustration stemmed from a lack of transparency and control. Olivier Ritlewski, Senior Digital Consultant and Partner at Happy Coding, described the previous environment as opaque. "We had issues where the production server was actually pointing to staging environments without transparency," he recalls.

Worse, support was a bottleneck. Simple infrastructure tasks required submitting tickets to the hosting provider and waiting for their engineers to execute them. 

> "We lost a lot of time trying to escalate issues," says Ritlewski. "We have the knowledge to fix things, but we didn't have the power/access." 

The legacy provider’s model forced the agency to rely on expensive, slow external support for tasks they could have handled in minutes with the right tools.

### **Regaining control with Upsun**

Happy Coding needed a platform that matched their agility. They chose Upsun for its developer-centric ethos and "NoOps" capabilities that empower agencies to manage infrastructure as code.

The decision was driven by Ritlewski’s previous success with the platform and a desire for reliability. Unlike the "black box" of the legacy provider, Upsun offered transparency and autonomy. The Upsun platform allowed the agency to define the entire infrastructure, including routes, services, and dependencies, in a single configuration file. This meant Happy Coding could instantly replicate production environments. It ensured that what they tested was exactly what they deployed.

> The migration process highlighted the platform's efficiency. "It took just one week of preparation," Ritlewski notes. "The actual switch took about two hours. It was really quick."

Crucially, Upsun provided a sales and support experience that respected the agency's expertise. Instead of generic emails, the Upsun team provided professional, tailored presentations that helped Happy Coding validate the switch to HFR stakeholders. "The salesperson was highly responsive and adapted to the client's needs, which was really helpful," Ritlewski adds.

### **Speed, autonomy, and peace of mind**

The impact of the migration was immediate and tangible for both the agency and the hospital.

**Unlocking editor productivity:** The most dramatic improvement was in backend performance. The 30-second wait times that plagued the hospital's editorial team vanished. "Now it’s maybe three seconds," says Ritlewski. This 90% reduction in latency transformed the editor experience from "very painful" to fluid and efficient. It allows staff to focus on communication rather than waiting for page loads to complete.

> "The 30-second wait times that plagued the hospital's editorial team vanished. Now it’s maybe three seconds." - Olivier Ritlewski, Senior Digital Consultant and Partner, Happy Coding

**Empowered engineering:** For Happy Coding, the shift to Upsun meant reclaiming their autonomy. The agency no longer needs to wait for a support ticket to clear cache, manage variables, or scale resources. "We can do a lot of things on our own now," Ritlewski explains. "It simplified DevOps by eliminating that overhead reliance on external engineers."

**Cost-effective scalability:** The move also addressed budget inefficiencies. The bundled services from the previous provider were expensive and often unnecessary for the client's specific needs. This allows the budget to be reallocated toward feature development and innovation rather than dormant hosting fees.

**Human support:** Perhaps most importantly, the anxiety of "going it alone" is gone. "With some competitors, if you have an issue, there is no person to call," Ritlewski observes. With Upsun, Happy Coding has direct access to expert support that acts as a partner rather than a gatekeeper.

> "The migration team was really happy, and that is the ultimate test. If you are looking to modernise, you need to try Upsun. You gain total confidence in the resilience and availability of your platforms." - Olivier Ritlewski, Senior Digital Consultant and Partner, Happy Coding

For digital agencies and enterprise teams, the infrastructure you choose can either be a bottleneck or a catalyst. Upsun empowers you to stop wrestling with legacy hosting limitations and start delivering faster, more reliable digital experiences. By providing full DevOps autonomy, transparent pricing, and performance that delights end-users, Upsun helps you build trust with your clients and keeps your engineering team happy.

### [How Goodflair hits 8-hour reimbursement | Upsun](https://upsun.com/blog/goodflair-hits-8-hour-reimbursement-targets/)

# Insurance at speed: How Goodflair hits 8-hour reimbursement targets with Upsun

Challenge:

Goodflair co-founders Christophe Mas and Jérôme Brisseau launched the company in 2022 to fix a major problem: nearly half of pet owners avoid the vet because it costs too much. They built their reputation on a single, difficult promise: paying back claims in an average of 8 hours.  
  
To hit that goal, they rely on two critical engines: a WordPress storefront and a custom Symfony CRM that handles the business operations. But as the company scaled, their original cloud provider, a massive generalist, became a bottleneck. At a giant host, the platform is just one of a hundred products; it lacked the specialized support and sharp expertise needed to handle sensitive pet health data and complex technical requirements.

Solution:

Goodflair moved 100% of its applications to Upsun to gain finer scalability, tighter security, and expert support. By adopting Upsun’s Git-driven workflow, every code change automatically creates an isolated preview environment.  
  
These environments act as production-perfect clones where the team can test new features, member journeys, or pricing updates against real data without risking the live site. By defining their entire infrastructure as code, Goodflair offloaded server complexity to the platform, freeing their internal team to focus entirely on insurance innovation.

Stack: WordPress, Symfony

Results:

-   Radical velocity: Shorter delivery cycles and faster shipping of new insurance features.
-   Production-perfect testing: Eliminated "unpleasant surprises" by using isolated preview environments for every branch.
-   Operational peace of mind: Achieved stable response times and high security for sensitive health data.
-   0% infrastructure toil: Freed up engineering bandwidth to maintain a #1 Trustpilot ranking and focus on member care.

---

## **Bridging the gap between technology and human care**

While Goodflair offers a fully digital experience, the back office is run by qualified Veterinary Technicians who review every claim. For Christophe Mas, the infrastructure must support these human experts without becoming a distraction.

> "The CRM is the operational heart of Goodflair," Christophe explains. "It handles all business workflows, manages connections with our third-party partners, and operates with a high level of security. Ultimately, it is what makes our promise of ultra-fast reimbursement a reality."

### **Why Upsun was the right fit**

The move to Upsun was about getting three things right: scaling, security, and expertise. Generalist cloud providers often lack the deep platform knowledge required to move as fast as a growing startup.

> "We needed finer scalability, a robust and secure infrastructure we handle health data, that is non-negotiable and above all, genuinely expert support," says Christophe. 

Upsun’s "NoOps" model allowed them to scale their Symfony CRM alongside WordPress in a centralized, predictable environment without managing the underlying plumbing.

### **Removing the fear of production risk**

The biggest barrier to rapid delivery is the fear of breaking the site. Before Upsun, Goodflair found testing to be a tedious manual process where results rarely matched what would actually happen in production.

Goodflair fixed this by making preview environments a natural reflex. 

> "Today, in a few clicks, we create a preview environment that is a faithful replica of production same configuration, same services, same data," says Christophe. "Each environment is fully isolated tests cannot impact production, and data remains protected. For a company that handles health data, that is far from a minor detail."

### **Scaling without the operational overhead**

By moving to a dedicated application platform, Goodflair has created shorter delivery cycles and a calmer work environment. Stability is a trust issue; a single outage could delay a reimbursement and break a customer promise.

> "PaaS, by nature, frees engineering teams from low-value infrastructure tasks," Christophe notes. "We ship faster and with greater confidence because environments are reproducible and consistent. Automatic scaling means we no longer have to question capacity at every release."

### **Advice for technical leaders**

The Goodflair team encourages other CTOs to focus on the product rather than the infrastructure. By offloading the "Ops" to a partner that understands high-stakes platforms, teams can maintain their velocity as they grow.

> "Moving to PaaS is a structural choice that frees up engineering bandwidth for what truly matters: the product," Christophe concludes. "With Upsun in particular, you also get genuinely expert and responsive support. I recommend it to any CTO who wants to build fast and build well, without drowning in ops."

### **About Goodflair**

Goodflair is a French insurtech providing transparent and ultra-fast pet insurance. Based in France, they combine a digital-first experience with human veterinary expertise. They are currently ranked #1 on Trustpilot among French pet insurance providers.

### [Kurier accelerates development | Upsun](https://upsun.com/blog/austrian-publishing-giant-kurier-accelerates-development/)

# Kurier accelerates development & restores work/life balance

Stack: Drupal

---

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

Dominating the Austrian publishing landscape for the last 60 years, Vienna-based Kurier Group delivers one of the country’s largest daily tabloid newspapers. An online publishing pioneer, Kurier’s complementary mega website drives ad sales and energizes readers by offering 200 new articles a day.

Keeping the 5 million unique Kurier.at visitors in the know about the latest news around the globe: a monumental responsibility for Adam Zielinski, Kurier Digital CTO. One that used to tether him to his laptop—virtually around the clock. When Zielinski went out to dinner with his family, his laptop occupied an unwelcome seat at the table.

## **A laser focus on product, \*not\* on DevOps**

Historically, Kurier’s dev team split their time between DevOps and development; the latter got the short end of the stick. The team handled a mix of major issues and mundane tasks—from system outages to updating SSL certificates. None of these delivered tangible value to the company.

Highly motivated to make a change that would free their dev team to focus on product, Zielinski selected Upsun as their platform-as-a-service (PaaS) provider.

> It might take a good DevOps team member 100 minutes to manually set up a new environment, including a new database and web server and all that belongs to it, including Elasticsearch and configuration. With Upsun, it takes a minute, and no one has to do anything; it’s completely automated. We push a YAML file that defines we want a database, and two minutes later, we have a database. It can't get better than that. Our developer productivity has increased 25 percent.
> 
> **Adam Zielinski**  
> CTO  
> Kurier Digital

## **Speeding internal approvals gets features to readers—faster**

The ultimate outcome of gaining dev efficiencies: stakeholder and customer happiness. One example is Kurier’s branch workflow. With its old process, each developer had an instance, and only one active feature branch was allowed per developer. On occasion, this lack of branches meant developers would need to juggle features and fixes, swapping between different versions on the same instance. While that approach was generally acceptable when dealing with different code versions, it often led to challenging, time-consuming issues when varying database schemas were used between versions.

The Upsun feature-branch model enables the Kurier dev team to have three times as many throw-away branches in development as staff. To experiment with a new markup, a new component, a new workflow, or a new CSS, the front-end team simply pushes the branch and activates the environment in Upsun. Approvers, like on-the-go editors, can test the home page or new features from their smartphones while they’re out in the field scooping stories—a key feature for Zielinski’s team, who can password-protect prototypes and get feedback quickly (from internal stakeholders and external reviewers). Says Zielinski, “I would honestly never do a project of any magnitude without this capability. It has simplified project management. People can focus on their real work and not worry about the technology behind it. And it’s helped accelerate our development and feedback cycles five-fold.”

## **Kurier’s Upsun advantage by the numbers**

## **Upsun features Kurier loves**

-   **Remove the need for in-house operations.** Redirect focus to writing code and building features that generate reader and stakeholder value.
-   **Feature branches.** Create a responsive, mobile-first site, with cool markup and a nice CSS—and have it live within minutes.
-   **Back-end cluster reliability.** Move from on-prem, DIY set up of Elasticsearch and database to Upsun environment, which follows best practices; no outages since.

## **Process improvements yield cost savings**

Instant gratification—_we want it, and we want it now_—isn’t new when it comes to expectations of technology. In Kurier’s previous process, their deployments were just a Git pull on the servers, making deployment time zero. “Except of course,” Zielinski explains, “when things went south; then, it all exploded.” It may be counter-intuitive, but in those days, the team actually deployed to production more often, but 80 percent of those deployments were devoted to bug fixes rather than to cool, new features.

> With Upsun, we know our system is stable. Today, we’re not deploying to live as often, but we’re deploying many more feature branches, with more people working on them\_—\_instead of spending time on fixes. In fact, we have five times as many deployments per person. It’s the difference between successful and meaningful deployments versus housekeeping. Thanks to improvements like these, our overall costs have decreased by around 66 percent. That is massive.
> 
> **Adam Zielinski**  
> CTO  
> Kurier Digital

## **Performance instills confidence within the team and beyond**

_Timing is everything_ cannot be more applicable than in the business of delivering news. Making information available to readers in near real time? The prime directive.

In their old system, building the Kurier.at home page took 30 – 60 seconds. Editorial cycles dictated that the page be refreshed every minute. The site wasn’t exactly reliable, either, going offline on a regular, yet unpredictable schedule every week. For staff giving a press conference or reporting out the latest results of a presidential election, which drew peak traffic, these outages were “an embarrassment,“ explained Zielinski. He felt compelled to bring his laptop with him wherever he went, even after work hours, in case something went awry; it often did.

After adopting Upsun, Kurier can rebuild an uncached landing page in one or two seconds. And uptime is nearly 100 percent.

Now, when Zielinski goes on his annual skiing vacation, he leaves his laptop at home. In his absence, his team continues to develop feature branches with stakeholders. The editorial staff? Happy campers. On the rare occasion something fails, Kurier can look to the Upsun team for 24x7 support. “Honestly, I think it's part of my job to create an environment where people don't need me. Upsun helps me accomplish just that,” muses Zielinski.

### [Oliver Sweeney: Elevating luxury e-commerce | Upsun](https://upsun.com/blog/oliver-sweeney-website-revamp-with-magento-cloud/)

# Oliver Sweeney website revamp with Magento Cloud

Stack: magento

---

_Note: This case study was initially published under the Platform.sh brand. It has been republished (updated) to reflect our new name, Upsun. All results and insights remain unchanged_

When your company sells luxury items, you want your website to offer that same exclusive, stunning digital experience for your customers too. That was the mission Oliver Sweeney, a men’s luxury lifestyle brand for shoes and accessories, had set themselves.

>   
> "We needed a platform that we could easily scale up if required, and customize to our brand" says Alex Barbier, Digital Marketing Director, Oliver Sweeney

Faced with an old platform that was unable to keep pace with frequent, new offers and promotions, Oliver Sweeney looked for a more powerful and stable platform and it is no surprise that they turned to Magento, the leading open-source eCommerce platform. With Magento’s Enterprise Cloud Edition, powered by Upsun, they found it to be flexible and highly-scalable.

Having upgraded their platform, Oliver Sweeney could refresh their website numerous times every day should they need to for any new offers and promotions. This is particularly useful to capture their fashion conscious customers’ interest in critical sales periods.

Read their full story on the Magento website.

## Press Releases

### [Our mission to reduce carbon emissions | Upsun](https://upsun.com/blog/mission-to-reduce-carbon-emissions/)

# Platform.sh’s mission to reduce carbon emissions

_This article was initially published under the Platform.sh brand. As this is a press release, we have retained the Platform.sh name for historical accuracy and citation consistency._

TL; DR: Platform.sh leads the cloud industry by highlighting and reducing the sector’s role in carbon emissions and environmental impact. Formed in 2015, Platform.sh provides users with an unified platform to build, run, and scale their web applications efficiently with fully automated infrastructure solutions. As cloud usage soars, the company has formed initiatives to limit energy use and its carbon footprint by optimizing infrastructure and leveraging server density. Platform.sh conveys a message of hope and environmental awareness on this Earth Day and beyond.

Read the article in its entirety at Hostingadvice.com.

## **About Platform.sh**

Platform.sh is a cloud-based web application hosting platform, a leader in the management of fleets of websites and applications. Its innovative deployment platform allows teams in charge of eCommerce sites, media sites, innovative and high-traffic applications to focus their efforts on developing and improving their applications, without having to worry about infrastructure issues (scalability, continuous deployment, maintenance, security, 24/7 monitoring, etc.). Platform.sh is available in Europe, the United States and Asia, through global partnerships with AWS, Google, Azure, Orange and OVHcloud.

The company, winner of the European Commission's H2020 program, recently recognized by Numeum as part of the Top 250 for its international growth, member of the French Tech 120 and Gaia-X and certified "Great Place to Work", has its head office in Paris (France) and San Francisco and counts among its customers prestigious brands such as the Financial Times, Gap, Unity3D, Adobe Magento, Orange, Hachette, The British Council.

**For more information, please contact:**  
CCgroup for Platform.sh  
Ryan O’Leary / Matthew Denby (UK)  
T: +44 7890 049769  
E: platform.sh@ccgrouppr.com

### [Up to 80% more website traffic for ecommerce apps | Upsun](https://upsun.com/blog/ecommerce-websites-holiday-season-traffic/)

# Up to 80% more website traffic for ecommerce applications

_This article was initially published under the Platform.sh brand. As this is a press release, we have retained the Platform.sh name for historical accuracy and citation consistency._

**Paris/San Francisco Tuesday 13th December 2022** - Platform.sh, a unified, secure, enterprise-grade platform for building, running and scaling web applications, has today revealed data outlining website traffic of ecommerce websites during the holiday shopping season. Across one of the biggest retail events of the calendar year, ecommerce websites had to handle up to 80% more website traffic than they would on any previous week or month in 2022, with the 12,000 websites that run on Platform.sh throughout Europe, the US and APAC receiving two billion visits on the day of Black Friday alone.

Despite the cost of living crisis predicted to curb shoppers' enthusiasm, the early holiday deals associated with the month of November still attracted many website visitors. Cyber Monday saw an increase with ecommerce website visits up 50% compared to an average Monday in 2022. And it doesn’t seem to be quietening down for online retailers with the holidays period in full swing. Website traffic for the first week of December was up 24% with over one billion website visits per day in this week compared to the 2022 average.

For ecommerce companies, these seasonal peaks in demand pose a major challenge, as the short, sharp spikes in traffic and associated transactions place a heavy burden on a system designed for much lower numbers. In addition to marketing teams working to make sure promotions are adjusted in real time, developer teams are under huge pressure to ensure information is accurate and website performance is optimal. As a result, ecommerce dev teams deployed 10% more on Black Friday than on any other sector’s website according to Platform.sh’ data.

_“November and December are busy months for online retailers with overall website traffic considerably higher than on an average day or week in previous months,”_ **said Fred Plais, CEO at Platform.sh**. _“The heightened user demand comes with a sensitivity to things going wrong but for a fast moving company during one of the biggest retail periods of the calendar year you have to be flexible and agile to any potential changes. That’s why at Platform.sh we provide a no code freeze policy to enable dev teams to deploy and make website tweaks at any time.”_

**Notes to editors**

**Methodology** The data used for this story is based on a sample of 12,000 websites that are run on Platform.sh across Europe, the US and APAC.

**About**

Platform.sh is a unified, secure, enterprise-grade platform for building, running and scaling web applications. Founded in 2015, the company is headquartered in Paris and San Francisco. Platform.sh employs over 400 people across 39 countries and is available in Europe, the United States and Asia, through global partnerships with AWS, GCP, Azure and OVHcloud.

A member of the FrenchTech 120 and Gaia-X, Platform.sh recently included in the FT1000 list of fastest growing European companies. Offering a 100% remote working environment the company is a certified "Great Place to Work" and counts among its customers prestigious brands such as Adobe Magento, Gap, Nestle, Orange, The British Council, The Financial Times and Unicef.

### [CTI Group achievesour Partner Program Diamond-tier Status | Upsun](https://upsun.com/blog/cti-group-diamond-status/)

# CTI Group leads the pack, becoming first UK agency to achieve Platform.sh Partner Program Diamond-tier Status

_This article was initially published under the Platform.sh brand. As this is a press release, we have retained the Platform.sh name for historical accuracy and citation consistency._

_Leading UK-based agency CTI Group becomes the first to achieve Platform.sh Partner Program Diamond-tier status in the United Kingdom._

_August 16, 2023, France_ - We are proud to announce Platform.sh partner, the CTI Group, a pioneering force in the UK's digital agency landscape, has secured their position as the first UK agency network to achieve Platform.sh Partner Program Diamond-tier status.

As a Platform.sh Partner Program Diamond-tier partner, the CTI Group joins an exclusive league of technology leaders and innovators at the forefront of revolutionizing the digital landscape. The partnership is a testament to CTI’s exceptional capabilities in architecting, developing, and maintaining web applications with unparalleled efficiency and scalability.

"We are delighted to be recognized in this elite, Diamond partnership tier. Our collaboration with Platform.sh allows us to deliver flexible experiences and a variety of digital solutions to our clients who use different technologies or want more compatibility," said CTI Growth and Partnerships Director, Kirstie Buchanan. “Platform.sh supports many common programming languages and frameworks, including Drupal, Symfony, React, PHP, among others, enabling us to offer diversified solution options to our clients.”

**The CTI Group's achievement as a Platform.sh Partner Program Diamond-tier partner further cements its position as a leading force within the UK’s agency landscape.**

“We are thrilled to be awarded Diamond partner status and look forward to continuing to strengthen our partnership with Platform.sh as a leading PaaS provider," said CTI Director of Hosting, Tom Ashworth. "Platform.sh is an excellent solution for hosting large, open-source-based systems while also providing clients with robust development and deployment workflows that can be provided at any scale.“

The agency's innovative approach, coupled with the industry-leading Platform-as-a-Service from Platform.sh, opens limitless possibilities for businesses seeking to strive for distinction in the dynamic world of digital transformation.

“Our long-term partnership with the CTI Group has just reached a new level, and we’re excited about collaborating even more closely moving forward," said Platform.sh Senior Director of Partnerships, Chantal Pastorek. "As we head toward 2024 and beyond, we trust the CTI Group’s expert teams will continue to leverage Platform.sh infrastructure and tools to efficiently develop and deliver unique, flexible solutions that meet client challenges, day in and day out.”

For more information about the CTI Group's groundbreaking services and its partnership with Platform.sh, please visit the CTI Group official website, or read about their Platform.sh Partner Program Diamond-tier announcement here.

Want to join the Platform.sh Partner Program, or are you looking for an agency partner to help you innovate?

**About CTI Group:** The CTI Group is a UK-based digital agency network that specializes in crafting exceptional digital experiences for clients across various industries. With a focus on innovation, technical expertise, and client satisfaction, CTI Group has earned a reputation as a pioneering force in the digital landscape.

**About Platform.sh:** Platform.sh is an innovative cloud hosting and development platform that empowers businesses to build, deploy, and scale web applications with unparalleled efficiency. With a focus on modernizing development workflows and optimizing digital experiences, Platform.sh is at the forefront of driving innovation in the digital realm.

### [Shopware and Upsun Partner to Strengthen European eCommerce](https://upsun.com/blog/shopware-upsun-european-ecommerce-partnership/)

# Shopware and Upsun expand strategic partnership to accelerate European eCommerce innovation and secure digital sovereignty

_**French and German leaders join forces in strategic partnership to bring flexibility and reliability to the European eCommerce market.**_

After three years of successful collaboration, Shopware, the German-based European leader in open-source eCommerce, and Upsun, the French-based leading European Cloud Application Platform, are announcing a strategic partnership.

Building on early success, with already 45 joint customers and growing, Shopware and Upsun are deepening their collaboration in 2026 and beyond. Together, they aim to address the multi-trillion-dollar European eCommerce market, combining the flexibility of open source with the power of an open cloud application platform.

This partnership delivers a unique European alternative to closed SaaS ecommerce ecosystems, empowering merchants to:

-   Retain full control over their data ownership
-   Deploy on sovereign European cloud infrastructures of their choice
-   Customize freely through a powerful, extensible software framework
-   Avoid vendor lock-in
-   Offer developers a best-in-class experience
-   Leverage AI-assisted development for faster innovation

As the leading eCommerce platform provider among Germany’s largest merchants, Shopware views the transition to the Application Cloud model as a major growth driver, enhancing both customer satisfaction and competitiveness.

“We’ve been working successfully with Upsun for quite some time, achieving great progress together,” said Alexey Pronin, General Manager EMEA, Shopware. “We see tremendous potential in continuing this collaboration and further combining the strengths of open-source innovation and Upsun’s powerful cloud capabilities to drive sustainable growth for European merchants.”

“Digital sovereignty is not declared, it is built through cooperation and trust. Together with Shopware, we are giving European merchants a flexible, sovereign alternative that combines open source with an open cloud application platform.” said Fred Plais, CEO and Co-Founder of Upsun (formerly Platform.sh) “On Upsun, you retain control of your data, deploy on European cloud regions of your choice, avoid lock-in, and ship faster with predictable security and uptime. This Franco-German partnership is how Europe scales innovation by uniting talent around reliability, sustainability, and independence.”

As the B2B eCommerce market continues to expand rapidly, the need for European, sovereign, and competitive cloud options has never been greater. This alliance between leading German and French innovators marks an exciting milestone for Europe’s digital future.

* * *

_**About Upsun**_

_Upsun (formerly known as Platform.sh) is the analyst-recognized cloud application platform that humans and robots love. Employing more than 290 Upsunners across 40+ nationalities in its 100% remote and B Corporation™ certified, ESG-led organization, with its headquarters in Paris._

_Since 2015, Upsun has provided speed, simplicity, scale, standardization, security, and sustainability to over 6,000 enterprise clients and 16,000 developers worldwide. Building strong partnerships with top open source providers and leading cloud providers, including AWS, Google Cloud, Azure, IBM, and OVHcloud. Among its notable clients are prestigious brands such as Adobe, Pinterest, The University of Missouri, The YMCA, and UNICEF._

_As an early supporter of the EuroStack Initiative Foundation e.V. Upsun empowers software editors to build and run their applications on European infrastructures (OVH as of today) without compromise on performance or extra effort._

* * *

_**About Shopware**_

_Shopware delivers advanced B2C and B2B commerce solutions, empowering global organizations with the performance, agility, and scalability needed to compete at the highest level. Built on the robust security of open-source technology and architected with an API-first approach, the platform combines ready-to-deploy capabilities with the freedom to customize, extend, and innovate at speed. Shopware supports all deployment models—SaaS, PaaS, and self-hosted—giving businesses full flexibility and control over their infrastructure to align with strategic priorities._

_More than 50,000 companies worldwide trust Shopware to power their ecommerce operations. Industry analysts, including Gartner, Forrester, IDC, and Paradigm B2B, consistently recognize Shopware as a key player in digital commerce. With its modular infrastructure, strong partner ecosystem, and over 6,000 extensions available in the Shopware store, the platform provides the resilience and adaptability needed to respond to evolving market demands._

### [Platform.sh Proudly Announces B Corp Certification |  Upsun](https://upsun.com/blog/b-corp-announcement/)

# Platform.sh Proudly Announces B Corp Certification

_This article was initially published under the Platform.sh brand. As this is a press release, we have retained the Platform.sh name for historical accuracy and citation consistency._

_Platform.sh, a leading Cloud Application Platform, is proud to announce that it is now a Certified B Corporation™ (B Corp™). A global community of for-profit leaders pledging to use business as a force for good._

This certification, awarded by B Labs, reflects its commitment to upholding rigorous standards of social and environmental performance, accountability, and transparency. By joining the ranks of Certified B Corporations™, the company is proud to be part of a global community of businesses that prioritize using their operations as a force for good.

The B Corporation certification is granted to organizations that show a sincere commitment to sustainability and social responsibility. Platform.sh earned an overall score of 96.9, significantly surpassing the median score of 50.9 for typical businesses that complete the assessment.

This news is echoed in the recent announcement that Platform.sh received double gold recognition for sustainability achievements from EcoVadis and Greenly in 2024. The certification includes all product offerings by Platform.sh. Including its latest platform offering, Upsun, which offers a Greener Region Discount for customers when choosing a greener data center to deploy their applications.

“For us at Platform.sh, this recognition is not just a badge; it embodies our dedication to enhancing the developer experience while also making a positive impact on society and the environment. The certification process involved a thorough assessment of our impact on our workers, our diversity and inclusion, community, environment, and customers, and we are grateful for the opportunity to reflect on our practices.” **\- Caroline Leroy Chief People Officer, Platform.sh**

“Our new status as a Certified B Corporation™ positions Platform.sh as a responsible choice within the cloud sector, particularly for clients who prioritize ethical business practices. By achieving this certification, we hope to align our operations with the growing demand for corporate accountability. We recognize that more businesses are seeking partners who share their values around sustainability and social impact, and we are honored to be among them.

This certification underscores our commitment to a triple bottom-line approach, which balances people, planet, and profit. We understand that this resonates with a diverse audience, including developers, businesses, and customers who are increasingly aware of how their choices impact the world. As companies navigate their cloud strategies, we believe that an emphasis on ethical practices and sustainable operations is essential in decision-making.” **\- Fred Plais, Founder and CEO, Platform.sh**

"Platform.sh’s B Corp certification is a powerful recognition of their commitment to sustainability, transparency, and ethical business practices. Revaia is proud to support Platform.sh as they demonstrate how the cloud industry can balance profit with purpose, proving that tech innovation can drive both business success and positive impact.” **\- Bettina Denis, Head of Sustainability, Revaia**

“Platform.sh's achievement of B Corp certification is a significant milestone that underscores its constant dedication to ESG best practices. We are proud to support visionary companies like Platform.sh, which lead by example, demonstrating that success in tech can and should go hand in hand with responsible, purpose-driven innovation." **\- Valérie Gombart, Co-Founder and CEO Hi inov Dentressangle**

* * *

**Platform.sh**

Platform.sh is a unified, secure, enterprise-grade Cloud Application Platform founded in 2015 and headquartered in Paris and San Francisco. Employing more than 300 Platformers across 43 nationalities and available in Europe, North America and APAC through global partnerships with AWS, Google Cloud, Azure, Orange and OVHcloud. A member of the FrenchTech 120 since 2019 and recently awarded B Corporation™ certification. Platform.sh is a certified Great Place to Work with inclusivity and diversity at its core and is a 100% remote working organization. It counts among its customers prestigious brands such as Adobe, Gap, The British Council, The Financial Times, and UNICEF.

### [Platform.sh and Blackfire.io unite | Upsun](https://upsun.com/blog/joining-forces-with-blackfire/)

# Platform.sh and Blackfire.io unite to enhance observability

_This article was initially published under the Platform.sh brand. As this is a press release, we have retained the Platform.sh name for historical accuracy and citation consistency._

**Blackfire.io is the first fully integrated Application Performance Monitoring (APM) and performance profiling suite that helps apps run faster, and makes development teams smarter, with an intelligent recommendation engine**

**San Francisco, May 25, 2021**\--Platform.sh today has announced its intent to acquire Blackfire SAS, a privately held company headquartered in Paris, France. Blackfire is the only fully integrated application performance profiling, testing, monitoring, and optimization suite for web sites and applications. The Blackfire team, led by founder and CEO Fabien Potencier, creator of Symfony–the leading PHP web application framework–will join Platform.sh. Potencier will join the Platform.sh executive team.

Blackfire brings two key technologies to Platform.sh:

-   Blackfire Profiler enables developers to pinpoint performance bottlenecks within their applications with robust tracing and call graphs, decreasing problem resolution time, and increasing developer productivity.
-   Blackfire Monitoring then continuously monitors application performance and alerts developers and devops teams to issues that may arise in production, and suggests areas to troubleshoot. Blackfire.io’s recommendation engine identifies areas for improvement in all PHP and Python applications, including common frameworks like Drupal, WordPress, Magento, and Django, and is extensible with custom tests written for business use cases.

Blackfire works integrally with the Platform.sh workflow. Website fleet owners can see an overview of the health of all their live sites and apps at a glance, identify best practices, and focus efforts on improvement of user experience. Instant cloning of production apps to development environments enables teams to use Blackfire Profiler to assess the performance of their code before they go live. Because Platform.sh natively manages every change to code and configuration with Git, an auditable revision control system, teams can pinpoint exactly where performance-affecting changes were introduced in moments, implement testing techniques and validate iterations against their custom performance budget.

Website and app users expect speed. In fact, 53% of users will abandon a site that takes more than three seconds to load. To deliver on ecommerce sales goals, audience growth KPIs, or SEO value, site owners must deliver consistently fast experiences and respond to market changes. The fast-paced evolution of web technologies increases the complexity for teams to build and maintain applications. Platform.sh removes the burden of infrastructure management while supporting all latest technologies, and helps teams implement automated quality assurance best practices. By joining forces with Blackfire, the tight integration of technologies offer unprecedented visibility in vital application and infrastructure metrics. Businesses will no longer be let in the dark when creating and deploying new features and applications. And that experience is delivered out-of-the-box. Teams can focus on what matters in the moment and plan for continuous improvement. At scale: whether one app or hundreds, Platform.sh and Blackfire give teams observability into the performance of all of their applications, so the quality of user experience can be maintained, and continuously improved, even as new apps are added to the fleet, or traffic ebbs and flows.

Platform.sh will continue to support Blackfire Profiler and Blackfire Monitoring customers regardless of where their websites and applications run. Blackfire will also become available with zero installation or configuration directly within Platform.sh.

> “With this acquisition Platform.sh furthers our vision that organizations should focus on building meaningful digital applications and experiences with relevant business outcomes, instead of managing infrastructure. With the addition of Blackfire to Platform.sh our customers can continuously track the performance of their entire website fleet, and discover areas to improve their end users’ experience. We are also delighted to work closely with Fabien and his team. Fabien’s track record as an open-source leader and an entrepreneur speaks for itself. We believe that his unique insights on the web industry will be highly valuable to steer the company towards even greater customer satisfaction.” _–Fred Plais, CEO, Platform.sh_

> “We’re thrilled to join forces with Platform.sh. We have collaborated and shared a vision for years: to focus on building their value, businesses need a unified platform that seamlessly brings their ideas to life. Platform.sh offers a robust technology for teams to work on applications from development to production, through continuous integration and staging, and back. Blackfire.io gives them the observability they need at each step of this lifecycle, to identify and fix performance issues as early as possible.” _–Fabien Potencier, CEO, Blackfire.io_

> “Building quality software is hard. Blackfire has been helping CCM Benchmark Group (www.journaldunet.com, www.linternaute.com) for years, in every step of the devops cycle, first with Blackfire Profiler and today with Blackfire Monitoring. Since day 1, Platform.sh and Blackfire have been built with the same goal in mind: optimize every step of web engineering. Tomorrow I'm sure they will help developers and companies to build high quality software that scales.” _\-Xavier Leune, VP Engineering, Groupe Figaro/CCM Benchmark_

### **About Platform.sh**

Platform.sh is the end-to-end PaaS that enables organizations to build, run, and scale websites and apps in the languages and frameworks they need to innovate. We've created the leading web platform that scales as organizations grow. Whether building a single site or deploying and managing a fleet of applications worldwide, Platform.sh takes care of hosting, management, and DevOps, so businesses can focus on development with our included tools, APIs and workflows. Founded in Paris in 2015 by Frederic Plais, Damien Tournoud, and Ori Pekelman, Platform.sh is trusted by more than 5000 organizations globally to create the best digital experiences.

### **About Blackfire.io**

Blackfire.io is the code observability SaaS that enables businesses to improve the performance of their web applications. We’ve created the reference solution on the PHP market for organizations which have high stakes in delivering optimal user experiences to their customer base, and now enter the Python and Golang markets. From development to production, Blackfire.io offers detailed and intelligent insights that let teams prevent, and proactively fix issues. Founded in Paris in 2018 by Fabien Potencier and Grégory Pascal, Blackfire.io is trusted by more than 1500 organizations globally to scale the best digital experiences.

### **Media contacts**

Worldwide: Ed Zitron ed@ezpr.com

France: Pierre Gatey pierre@agenceraoul.com

### [Stephane Kasriel joins Upsun Board to support the future of AI-assisted development | Upsun](https://upsun.com/blog/stephane-kasriel-joins-upsun-board/)

# Upsun names Meta’s fundamental AI Research team executive Stephane Kasriel to Board

**Paris/San Francisco — 21 April 2026** — Upsun (formerly Platform.sh), the cloud application platform that helps organizations build, deploy, and scale modern applications, today announced the appointment of **Stephane Kasriel** to its Board of Directors.

Kasriel brings more than two decades of experience building and scaling global technology platforms. He previously served as CEO of Upwork and now leads FAIR Foundations at Meta Superintelligence Labs. Throughout his career, he has helped companies navigate major shifts in how technology platforms are built, operated, and scaled.

His appointment comes as AI-assisted coding rapidly reshapes software development, accelerating development cycles and increasing the need for automated, secure, and production-grade infrastructure.

### **Software development is accelerating  with AI**

AI coding assistants accelerate software development. Developers can generate, test, and iterate on code faster than ever before. But this new speed  also introduces new challenges.

Agentic workflows need to move to the cloud much earlier in the development cycle to foster collaboration and infrastructure must support rapid experimentation, automated environments, and reliable production deployments. Without the right foundation, velocity quickly turns into complexity, and introduces new risks and inefficiency.

Upsun has spent more than a decade building a cloud application platform designed to solve exactly that problem.

> “Stephane joins Upsun at a pivotal moment,” said Frédéric Plais, CEO and Chairman of Upsun. “Software is being rebuilt with AI at its core. At Upsun, we are redesigning the infrastructure to adapt to that shift and enable software development teams to orchestrate agents in the cloud and reliably deploy to the cloud. Stephane’s deep AI expertise along with his experience scaling global platforms and navigating strategic inflection points will be instrumental to Upsun’s future.”

Kasriel added, "AI-assisted coding changes the velocity and structure of software development. Upsun is uniquely positioned to provide the secure, automated, production-grade infrastructure that this new paradigm requires. I'm excited to help the team amplify that advantage."

### **Strengthening the board with global platform leadership**

Kasriel has spent more than two decades helping technology companies scale through major platform shifts. As CEO of Upwork, he led the company through rapid global expansion, and at Meta, he now works on foundational AI technologies shaping the future of intelligent systems.

He joins the Upsun Board with the perspective of a global operator who has led platform innovation, international growth, and large-scale product organizations through periods of significant and rapid technological change.

> "Having a former CEO who has operated at a global scale and comes with deep AI expertise is incredibly valuable given Upsun’s roadmap,” said Plais. "Stephane brings both strategic depth and pragmatic execution insight, exactly what we need as we accelerate."

### **Supporting Upsun's next phase of growth**

Founded in 2015, Upsun has spent the past decade building a platform that helps organizations deploy and run applications with speed, simplicity, and reliability. 

As AI becomes central to software development, Upsun's roadmap focuses on providing the agentic-enabled infrastructure needed to build, deploy, and scale modern applications and AI projects safely in production.

As Upsun continues to scale, the company is preparing for its next phase of corporate development, which may include strategic acquisitions, capital structure optimization, liquidity pathways for early investors, and long-term strategic optionality. Kasriel's experience navigating large-scale organizational growth and corporate evolution will provide valuable guidance as Upsun builds toward its long-term ambition.

> "Upsun has built a technically exceptional platform and a strong foundation," said Kasriel. "The opportunity ahead, to become the infrastructure backbone of AI-assisted software, is significant. I'm looking forward to contributing to that journey."

### [Fabien Potencier appointed as CTO | Upsun](https://upsun.com/blog/fabien-potencier-appointed-as-cto/)

# Platform.sh appoints Fabien Potencier as Chief Technology Officer, succeeding co-founder Damien Tournoud

_This article was initially published under the Platform.sh brand. As this is a press release, we have retained the Platform.sh name for historical accuracy and citation consistency._

_Platform.sh appoints open source pioneer Fabien Potencier as Chief Technology Officer to scale developer-first innovation and accelerate enterprise growth globally_

**Paris/San Francisco, 14 May 2025** - Platform.sh, the unified, secure cloud platform built for enterprise-scale digital innovation, today announces the appointment of Fabien Potencier as Chief Technology Officer (CTO). He succeeds Damien Tournoud, company co-founder, who is stepping away from day-to-day operations to embark on a new entrepreneurial journey. Damien will continue to serve as an active member of Platform.sh’s strategic product and engineering committee.

This transition marks an important milestone in the Platform.sh journey as a fast-scaling cloud leader with over 300 employees across the globe and an annual recurring revenue (ARR) of €50 million.

## **A legacy of technical vision**

Together with Frédéric Plais and Ori Pekelman, Damien co-founded Platform.sh in 2015 following their experience building Drupal Commerce at Commerce Guys. Driven by the belief that infrastructure should adapt to the needs of applications—not the other way around—they pioneered a fundamentally new approach to cloud hosting.

Damien’s product vision, technical intuition and relentless innovation shaped the foundation of the Platform.sh product and helped transform it into a global solution adopted by more than 17,000 developers and 7,000 organizations worldwide.

## **A natural successor with deep developer roots**

Joining Platform.sh in 2021, Fabien Potencier has held multiple leadership roles, including Chief Product Officer and Chief Developer Advocacy Officer. As CTO, he brings decades of experience and a profound connection to the developer community.

A successful serial entrepreneur, Fabien is best known as the creator of Symfony—one of the world’s most widely used and influential open source frameworks—and the founder of Blackfire.io, a performance monitoring and optimization solution acquired by Platform.sh in 2021. Recognized globally for his technical rigor, product vision, and deep empathy for developers, Fabien will lead the company’s technical direction—focusing on long-term innovation and customer-centric product excellence.

“Damien laid the groundwork for a product that is both robust and innovative, guided by a clear vision and technical excellence,” said Fabien Potencier. “It’s an honor to build on that legacy and ensure continuity and stability through this transition.”

“After fifteen incredible years, it’s time for me to pass the torch,” said Damien Tournoud. “I’m extremely proud of what we’ve achieved together. With Fabien’s leadership, technical vision, and intimate knowledge of our product, I’m confident Platform.sh is in the best hands to continue its momentum.”

* * *

_**About Platform.sh**_

Platform.sh is a unified, secure, enterprise-grade Cloud Application Platform founded in 2015 and headquartered in Paris and San Francisco. Employing more than 300 Platformers across 43 nationalities and available in Europe, North America and APAC through global partnerships with AWS, Google Cloud, Azure, Orange and OVHcloud.

A member of the FrenchTech 120 since 2019, recently awarded B Corporation™ certification, and a certified Great Place to Work with inclusivity and diversity at its core, it is a 100% remote working organization. It counts among its customers prestigious brands such as Adobe, Gap, The British Council, The Financial Times, and UNICEF.

### [Platform.sh renews partnership with Adobe | Upsun](https://upsun.com/blog/renewing-partnership-with-adobe-commerce/)

# Platform.sh renews partnership with Adobe

_This article was initially published under the Platform.sh brand. As this is a press release, we have retained the Platform.sh name for historical accuracy and citation consistency._

**Paris/San Francisco, Wednesday 6th April 2022** - Platform.sh, a unified, secure, enterprise-grade platform for building, running and scaling web applications, and Adobe, today announced a renewed 5-year agreement for Adobe Commerce to leverage the Platform.sh Platform as a Service (PaaS). Adobe Commerce helps brands build and deliver personalized, multichannel commerce experiences from a single platform. As part of the agreement, Platform.sh has become a Premier Partner in the Adobe Exchange Partner Program. Platform.sh’s new Premier Partner status builds on a long-standing relationship with Adobe.

With consumers changing the way they shop, brands need solutions that make it easy to deliver real-time personalized shopping experiences to meet customer demands. The extension of the partnership continues the evolution of Commerce at Adobe, enabling customers to easily build, run, and scale an end-to-end commerce experience in the cloud. The Platform.sh infrastructure management for Adobe Commerce Managed Services and Cloud Pro streamlines the developer experience and deployment velocity while optimising cloud performance and infrastructure efficiency. By focusing on efficiencies Platform.sh is helping Adobe reduce its carbon footprint across the eCommerce platform.

_“It's an honour to extend our partnership with Adobe for another five years,”_ **said Fred Plais, CEO and Co-founder at Platform.sh.** _“We are committed in supporting Adobe Commerce to have an even brighter future, with a reinforced focus on making the management of the eCommerce product effortless, with an enhanced developer experience and a lower carbon footprint.”_

_“We’re pleased to renew our partnership with Platform.sh and view them as a key partner to enabling the success of our customers with more agility and faster deployment of commerce experiences,”_ **added Loni Stark, VP of Strategy and Product at Adobe.** _“We look forward to the next phase of our partnership, where together we will make continuous improvements to our platform and help merchants and brands grow their businesses and better serve their clients.”_

**ENDS**

## **Notes to editors**

### **About Platform.sh**

Platform.sh is a cloud-based web application hosting platform, a leader in the management of fleets of websites and applications. Its innovative deployment platform allows teams in charge of eCommerce sites, media sites, innovative and high-traffic applications to focus their efforts on developing and improving their applications, without having to worry about infrastructure issues (scalability, continuous deployment, maintenance, security, 24/7 monitoring, etc.). Platform.sh is available in Europe, the United States and Asia, through global partnerships with AWS, Google, Azure, Orange and OVHcloud.

The company, winner of the European Commission's H2020 program, recently recognized by Numeum as part of the Top 250 for its international growth, member of the French Tech 120 and Gaia-X and certified "Great Place to Work", has its head office in Paris (France) and San Francisco and counts among its customers prestigious brands such as the Financial Times, Gap, Unity3D, Adobe Magento, Orange, Hachette, The British Council.

**For more information, please contact:**  
CCgroup for Platform.sh  
Ryan O’Leary / Matthew Denby (UK)  
T: +44 7890 049769  
E: platform.sh@ccgrouppr.com

### [Platform.sh reveals Upsun a new PaaS offering | Upsun](https://upsun.com/blog/revealing-upsun-a-new-paas-offering/)

# Platform.sh reveals Upsun. A new PaaS offering designed to support the growth of startups and scaleups

_This article was initially published under the Platform.sh brand. As this is a press release, we have retained the Platform.sh name for historical accuracy and citation consistency._

-   _Founded in 2015 and a leading Platform-as-a-Service player, Platform.sh has more than 7,000 customers and is used by more than 17,000 active developers worldwide._
-   _Upsun, its new PaaS offering, provides automated DevOps tools and managed cloud services to empower startups and scaleups to build, deploy, and scale their applications and data backends with simplicity and flexibility._
-   _Based on proven foundations, Upsun combines security, compliance, and reliability to support startups and scaleups as they consolidate and expand._

**Paris and San Francisco, 3rd April 2024** - Platform.sh, a major Platform-as-a-Service player, today announced the launch of Upsun, its new offering designed to provide startups and digital teams within larger groups who adopt the code and agile methods belonging to startups with a self-service, highly flexible, and scalable platform. The aim is to simplify the application lifecycle— from development to deployment and iteration—by providing development teams with the tooling to describe and flexibly compose the infrastructure, optimize code, efficiently use resources, and easily resolve issues.

From the outset, startups face various challenges, from designing their products and recruiting talent to managing their finances. Time and resource constraints can hamper their growth and their ability to scale and innovate. Today, where efficiency is paramount, is the perfect time for startups to consider leveraging Upsun and enable their development teams to focus on building features and improving their business—rather than spending considerable time managing engineering platforms and cloud infrastructures.

With Upsun, startups can grow and implement a large variety of cloud projects. Upsun is a good fit for decoupled architecture, headless projects and data or AI-rich applications.

_“For seven months, we’ve had the opportunity to beta-test Upsun and have been blown away by how easy it is to use, given the complexity it can handle. The platform provides the perfect tools for start-ups like Witty Works, a platform to meet the resource demands of custom code, microservices, and AI-rich projects. We have been able to improve our performance and automate the deployment of our applications without the need to recruit a dedicated DevOps team. This flexibility has enabled us to concentrate our resources on our core technology,”_ said Lukas Kahwe Smith, co-founder and CTO of Witty Works, a Zurich based startup delivering an application improving inclusive language within diverse companies.

Upsun is committed to supporting its customers’ efforts to reduce their carbon footprints. Through this new offer, Platform.sh is providing a 3% discount on resource usage when deploying to a low-carbon region. The company is currently offering this incentive in five regions (France, Sweden, Canada, the United States and Switzerland), enabling it to respond effectively to the needs of startups in terms of sustainability, data localization, and compliance.

**Only pay for the resources you use** Upsun’s pricing model is transparent, flexible and consumption-based. This approach enables startups to pay only for what they use and scale step-by-step while managing their budgets more effectively.

Platform.sh is supporting the growth and acceleration of startups with a special promotional offer when they adopt Upsun. With a 50% discount on their first year contract, this initiative aims to make startup adoption more accessible. The offer is reserved exclusively for Upsun subscribers and is subject to specific eligibility criteria.

_“The launch of Upsun marks a new era in our commitment to innovation, durability, and growth for startups. We are convinced that this new offering will provide them with the resources they need to expand and prosper in an ever-changing environment,”_ says Fred Plais, CEO and co-founder of Platform.sh.

Beyond startups, Upsun is designed for any organization with an innovative application project that requires development teams to quickly build, deploy, and scale their applications.

Upsun is live and available now—to bring your new project to Upsun see more details here.

### [Welcoming Ori Pekelman and Fabien Potencier as CSO and CPO | Upsun](https://upsun.com/blog/management-team-ori-pekelman-fabien-potencier/)

# Welcoming Ori Pekelman and Fabien Potencier as CSO and CPO

_This article was initially published under the Platform.sh brand. As this is a press release, we have retained the Platform.sh name for historical accuracy and citation consistency._

-   _A major player in European cloud, created in 2015 with presence in Europe and the United States, Platform.sh is entering a new growth stage._
-   _With a team of more than 300 employees and 150 more to be added in 2022, Platform.sh is developing and consolidating its management team. Ori Pekelman, co-founder and previously Chief Product Officer (CPO), passes the torch to Fabien Potencier and becomes Chief Strategy Officer (CSO)._
-   _In 2021, Platform.sh acquired Fabien Potencier’s company Blackfire.io to consolidate its position as a leading platform for the management of web app fleets—making this move a logical next step._

**PARIS, France, 1st February 2022 –** the end-to-end PaaS that enables organizations to build, run, and scale websites and apps in the languages and frameworks they need to innovate—today announced two strategic appointments: Ori Pekelman, co-founder of the scale-up, is appointed to the newly created position of Chief Strategy Officer and Fabien Potencier joins the management team as Chief Product Officer, following Platform.sh’s acquisition of Blackfire.io in 2021.

Platform.sh offers a unique and innovative deployment platform that allows teams in charge of eCommerce sites, media sites, high traffic web-applications and API backends, to focus their efforts on the development and improvement of their applications, without having to worry about infrastructure issues.

Accessible in Europe, the United States and in Asia thanks to international partnerships with AWS, Google, Azure, Orange and OVHcloud, Platform.sh is a member of the French Tech 120 for the second year in a row, and is part of the European cloud alliance Gaia-X.

With a 30-year+ career in the startup world, polyglot developer and open source activist, Ori Pekelman is co-founder of Platform.sh where he was VP Marketing then Chief Product Officer. He is now heading up the new team dedicated to the strategy of the French scale-up with the objective of fully embodying the long-term vision of the company and promoting its growth at scale.

To do this, he will guarantee the external development of the company through a dedicated acquisition policy while defining the implementation of strategic partnerships. The new strategy team will have as its priority the continuation of the fundamental work of reducing the environmental impact of the cloud. It will also continue its mission to achieve full gender parity at all levels and in all roles within the company.

The new team is looking to recruit for roles such as M&A Analyst, Environmental Impact Manager and Public Affairs Officer.

A key developer on GitHub (in the world-top-10 for 5 years, and even world number 1 in 2017) and successful serial entrepreneur, Fabien Potencier continually searches for new ways to accelerate digital projects. It is with this goal in mind that he first co-founded Sensio, which later became SensioLabs. To best respond to customers' issues (e.g. the creation and maintenance of websites and applications, replace recurring tasks for developers, etc.), in 2005 they developed Symfony, the open source framework that now underpins nearly 8% of websites worldwide.

In 2015, Fabien Potencier once again embarked on an entrepreneurial adventure and founded Blackfire.io. The company is the only fully integrated APM (Application Performance Management) tool offering profiling, testing, monitoring and optimization of the performance of applications and websites. Blackfire.io joined Platform.sh in May 2021.

As the new CPO at Platform.sh, Fabien Potencier will be responsible for supporting the growth of the company, as well as optimizing the solutions and the performance of services offered. At the same time, Fabien Potencier will retain his role as CEO of Symfony.

“In carrying out the spin-off of Commerce Guys with Platform.sh back in 2014, we wanted to respond to a major problem in our ecosystem. Since then, we have demonstrated the value of our know-how but above all the need to simplify cloud infrastructures. In seven years and thanks to a global team of more than 300 people, we have successfully accomplished our international development. We look forward to taking up new challenges and leaving our mark on our ecosystem,” says Ori Pekelman, co-founder and CSO at Platform.sh.

“With Platform.sh, we’ve always shared a common philosophy and vision: to facilitate the daily lives of digital professionals by providing them with a unified digital infrastructure, based on innovation and collaboration. I am very happy to join a human team with an international dimension and to bring my expertise and know-how to a growing ecosystem,” explains Fabien Potencier, CPO at Platform.sh.

“Like any rapidly accelerating scale-up, each stage of growth has been an opportunity for Platform.sh to rethink itself. And today, we are entering a new era. By revitalizing the management team, we are taking advantage of everyone's strengths and skills to stimulate our development. Ori, my business partner since Commerce Guys, has a thorough knowledge of the company and our ecosystem. He embodies the future of society. Fabien, recognized for his part in the creation of Symfony, one of the most visible open source projects in the world, and for his unequalled expertise in the development of web projects, will make it possible to direct the company towards an even greater customer experience,” adds Frédéric Plais, CEO and co-founder of Platform.sh.

## **About Platform.sh**

Platform.sh is a cloud-based web application hosting platform, a leader in the management of fleets of websites and applications. Its innovative deployment platform allows teams in charge of eCommerce sites, media sites, innovative and high-traffic applications to focus their efforts on developing and improving their applications, without having to worry about infrastructure issues (scalability, continuous deployment, maintenance, security, 24/7 monitoring, etc.). Platform.sh is available in Europe, the United States and Asia, through global partnerships with AWS, Google, Azure, Orange and OVHcloud.

The company, winner of the European Commission's H2020 program, recently recognized by Numeum as part of the Top 250 for its international growth, member of the French Tech 120 and Gaia-X and certified "Great Place to Work", has its head office in Paris (France) and San Francisco and counts among its customers prestigious brands such as the Financial Times, Gap, Unity3D, Adobe Magento, Orange, Hachette, The British Council.

**For more information, please contact:**  
CCgroup for Platform.sh  
Ryan O’Leary / Matthew Denby (UK)  
T: +44 7890 049769  
E: platform.sh@ccgrouppr.com

### [Nigel Kersten joins Platform.sh as Chief Product Officer (CPO) | Upsun](https://upsun.com/blog/nigel-kersten-joins-as-cpo/)

# Nigel Kersten joins Platform.sh as Chief Product Officer (CPO)

_This article was initially published under the Platform.sh brand. As this is a press release, we have retained the Platform.sh name for historical accuracy and citation consistency._

_With over 25 years of experience in tech and over a decade serving in product and engineering executive roles in international B2B start-ups, Nigel Kersten will bring to Platform.sh his expertise in product strategy, DevOps, and platform engineering to develop and grow the Upsun offering. This recruitment is part of the company's strategy to accelerate its growth and position itself as a global player in the field of cloud application platforms for managing websites and applications._

Platform.sh - a leading Cloud Application Platform - today announced the appointment of Nigel Kersten as Chief Product Officer to lead product strategy and execution across the portfolio, leveraging his expertise in platform engineering, DevOps, and open-source, with a particular focus on Upsun, the company's latest offering.

**Dynamic DevOps leader with a passion for revolutionizing infrastructure management and driving impactful transformations**

Nigel Kersten is an internationally recognized expert in DevOps, Platform Engineering, and fast-flow product delivery. He is one of the original founders of the award-winning State of DevOps Report that introduced 'DORA metrics' to the world and elevated the state of software delivery across the industry. He served as the primary co-author of the report for 11 years, pioneering best practices for modernizing complex IT environments through DevOps and platform engineering.

After building an industry-leading, open-source, infrastructure-as-code platform in the SRE organization at Google, Nigel joined Puppet, an open-source DevOps pioneer, as an early-stage employee and Head of Product. Over the next 12 years, he served in various technical leadership roles, from CTO to VP of Engineering to Field CTO. He drove product strategy and strategic customer relationships until a successful exit via acquisition.

In May 2024, Nigel joined Platform.sh as CPO to lead product strategy, design, and ecosystem development, leveraging his extensive experience in open source, platform development, and leading high-performance product teams to optimize and evolve the company's capabilities to support its continued growth and strengthen its market position.

This appointment is part of the Platform.sh strategy to consolidate its position as the leading cloud application platform and to optimize the company's new PaaS offering, Upsun. This latest service simplifies the cloud for developers, making it easy to turn code into robust, production-ready cloud applications with seamless collaboration across the entire software delivery lifecycle.

_"I am delighted to be joining Platform.sh at such a pivotal time to help grow our already industry-leading multi-cloud and multi-stack capabilities into the leading cloud application platform. With initiatives like Upsun, we aim to transform the way businesses develop and deploy applications of all kinds, offering them both flexibility and control."_ explains Nigel Kersten

_"We're thrilled to welcome Nigel to our leadership team as Chief Product Officer. With his deep industry expertise and passion for innovation, Nigel is uniquely positioned to drive our product vision forward and help us deliver greater value to our customers. His commitment to excellence and user-centric design aligns perfectly with our goals, and we're excited for the impact he will make."_ Frédéric Plais, CEO and co-founder of Platform.sh, is delighted.

* * *

_**About Platform.sh**_

Platform.sh is a unified, secure, enterprise-grade Cloud Application Platform founded in 2015 and headquartered in Paris and San Francisco. Employing more than 300 Platformers across 43 nationalities and available in Europe, North America and APAC through global partnerships with AWS, Google Cloud, Azure, Orange and OVHcloud.

A member of the FrenchTech 120 since 2019, recently awarded B Corporation™ certification, and a certified Great Place to Work with inclusivity and diversity at its core, it is a 100% remote working organization. It counts among its customers prestigious brands such as Adobe, Gap, The British Council, The Financial Times, and UNICEF.

### [Platform.sh and Pimcore Forge a Technology Partnership | Upsun](https://upsun.com/blog/technology-partnership-with-pimcore/)

# Platform.sh and Pimcore Forge a Transformative Technology Partnership

_This article was initially published under the Platform.sh brand. As this is a press release, we have retained the Platform.sh name for historical accuracy and citation consistency._

_Pimcore and Platform.sh join forces, merging data management and PaaS expertise to redefine digital efficiency and scalability._

Platform.sh and Pimcore have joined forces in an unprecedented collaboration, heralding a new era of technological advancement. This groundbreaking partnership brings together the cutting-edge cloud hosting solutions of Platform.sh and Pimcore's innovative digital experience platform, promising transformative outcomes for businesses worldwide.

Through this alliance, businesses can harness the power of Platform.sh and its robust cloud infrastructure, seamlessly integrated with Pimcore's dynamic digital experience platform. The synergy between these two industry leaders empowers organizations to streamline their development processes, accelerate time-to-market, and deliver unparalleled digital experiences to their customers.

By leveraging Platform.sh a scalable and reliable cloud hosting environment alongside Pimcore's comprehensive suite of digital experience tools, businesses can unlock new levels of agility, scalability, and efficiency. This collaboration signifies a significant step forward in the realm of digital transformation, providing businesses with the tools they need to thrive in today's competitive landscape.

Stay tuned for further updates as Platform.sh and Pimcore continue to redefine the boundaries of technological innovation and drive unprecedented value for businesses worldwide.

### **About Pimcore**

Pimcore is an analyst-ranked IT company that provides innovative data and experience management solutions. The company was founded in 2013 and is headquartered in Salzburg, Austria. More than 110,000 customers, including Fortune 100 companies such as Pepsi, Sony, and Audi, already rely on Pimcore. The Pimcore Platform aggregates, enriches, and manages enterprise data, providing customers with up-to-date, consistent, and personalized experiences. Its Digital Asset Management (DAM), Product Information Management (PIM), Master Data Management (MDM), Digital Experience Management (DXP/CMS), and Digital Commerce modules are recognized by analysts such as Gartner and Forrester. The consolidated platform provides companies with a "trusted view" of information (products, assets, and customers) to eliminate data silos, optimize operational efficiency, improve customer experience, and minimize IT costs.

### [Platform.sh launches new public region in Zurich | Upsun](https://upsun.com/blog/launching-new-public-region-zurich/)

# Platform.sh launches new public region in Zurich

_This article was initially published under the Platform.sh brand. As this is a press release, we have retained the Platform.sh name for historical accuracy and citation consistency._

_The Platform.sh PaaS seeks to empower customers to meet sustainability, data localisation and compliance requirements with the launch of their new Switzerland region_

**Paris, 1st February 2024** - Platform.sh, a unified, secure, enterprise-grade platform for building, running and scaling web applications, today announces the availability of their new public region. Platform.sh is now available out of the Google Cloud region in Zurich, Switzerland, making it easier for customers to choose the right option to meet their sustainability, data localisation and compliance needs.

The new region availability has been launched in response to increasing demand from Swiss businesses that want to ensure their data is held locally, and from businesses with an international footprint with needs in Switzerland. Zurich is recognised as a leading European city for technological innovation, particularly in financial services, and is host to a number of global tech giants.

In late 2023, Switzerland updated its data protection rules. revFADP, or the revised Swiss Federal Act on Data Protection, aims to align the country’s data protection rules with the GDPR. Those storing and processing data of Swiss citizens will need to meet the requirements of this new law, and easier data localisation will be key.

Switzerland’s leadership in sustainable energy makes it an attractive data location for any business looking to reduce its carbon footprint. Adding Switzerland as a region, with its use of low-carbon and renewable energy sources, means Platform.sh now offers greener options in seven regions across five countries. With more businesses required to report their environmental impact under the EU Corporate Sustainability Reporting Directive (CSRD)—and many more expected to do so by 2026—Platform.sh offers a simple way to make a difference in this increasingly important area.

As a cloud-agnostic Platform-as-a-Service (PaaS), Platform.sh makes it simple to choose between regions to meet sustainability and compliance requirements.

Mathieu Strauch, Senior Enterprise Account Executive, Platform.sh: “Global businesses need to comply with a complex web of regional data privacy and security laws. Local businesses want to strive to keep their customers’ data easily accessible. Both are best served by being able to choose where their data is stored. Platform.sh enables this choice by offering services out of a growing number of datacenter regions, allowing businesses to comply with data sovereignty laws while efficiently serving their customers’ needs. Expanding our multi-cloud reach into Zurich means our customers can deploy globally and comply locally.”

### [ Platform.sh placed in 2024 Gartner® Magic Quadrant™ | Upsun](https://upsun.com/blog/gartner-magic-quadrant/)

# Platform.sh placed in 2024 Gartner® Magic Quadrant™ for Cloud Application Platforms

_This article was initially published under the Platform.sh brand. As this is a press release, we have retained the Platform.sh name for historical accuracy and citation consistency._

_08 November 2024 – Platform.sh, a leading Cloud Application Platform, is proud to announce that Gartner has positioned it as a Niche Player in the Magic Quadrant for Cloud Application Platforms. 1_

Magic Quadrant reports are a culmination of rigorous, fact-based research in specific markets, providing a wide-angle view of the relative positions of providers in markets where growth is high and provider differentiation is distinct.

Gartner defines cloud application platforms as those that provide managed application runtime environments for applications and integrated capabilities to manage the life cycle of an application or application component. They typically enable distributed application deployments and support cloud-style operations — such as elasticity, multitenancy and self-service — without requiring infrastructure provisioning or container management.

Platform.sh is pleased to receive this recognition, we believe it serves as a testament to our unwavering commitment to excellence and innovation. This commitment ensures that Platform.sh will continue to provide the best solutions for its customers, making you feel confident and secure in its capabilities.

“We believe the inclusion of Platform.sh in the Gartner Magic Quadrant for Cloud Application Platforms demonstrates our commitment to providing robust cloud migration, multi-provider variety, and enterprise-grade capabilities to customers of all sizes while placing a key focus on ethical practices and sustainable operations, whether modernizing legacy systems or launching new applications.” - **Fred Plais, Founder and CEO, Platform.sh**

As a developer-centric, API-first, full-stack cloud application platform trusted by Fortune 500s and startups worldwide for its robust, secure, and compliant multi-cloud service, Platform.sh excels in cloud migration and offers businesses a painless, flexible, lift-and-shift experience. They empower organizations to modernize sustainably and efficiently while maintaining governance and cost control.

We feel this evaluation and recognition from Gartner further emphasizes the cloud application platform’s strengths as a polyglot backend framework, and support for enterprise-grade security, effortless compliance, and comprehensive SLAs. And we believe it also underscores the company’s mission and vision of delivering boutique-level attention to customers of all sizes, inspiring confidence in our future endeavors.

View a complimentary copy of the Magic Quadrant report to learn more about Platform.sh strengths and cautions, among other provider offerings, at this link.

_1\. Source: Gartner, “Magic Quadrant for Cloud Application Platforms,” Tigran Egiazarov, 4 November 2024._

Gartner does not endorse any vendor, product or service depicted in our research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose. GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally, and MAGIC QUADRANT is a registered trademark of Gartner, Inc. and/or its affiliates and are used herein with permission. All rights reserved.

* * *

_**About Platform.sh**_

Platform.sh is a unified, secure, enterprise-grade Cloud Application Platform founded in 2015 and headquartered in Paris and San Francisco. Employing more than 300 Platformers across 43 nationalities and available in Europe, North America and APAC through global partnerships with AWS, Google Cloud, Azure, Orange and OVHcloud.

A member of the FrenchTech 120 since 2019 and recently awarded B Corporation™ certification. Platform.sh is a certified Great Place to Work with inclusivity and diversity at its core and is a 100% remote working organization. It counts among its customers prestigious brands such as Adobe, Gap, The British Council, The Financial Times, and UNICEF.

### [Platform.sh receives double gold recognition for sustainability | Upsun](https://upsun.com/blog/double-gold-sustainability-certification/)

# Platform.sh receives double gold recognition for sustainability achievements

_This article was initially published under the Platform.sh brand. As this is a press release, we have retained the Platform.sh name for historical accuracy and citation consistency._

_Platform.sh, a leading Platform-as-a-Service (PaaS) provider, has obtained two prestigious gold medals awarded by_ _EcoVadis_ _and_ _Greenly__, solidifying its commitment to sustainability and corporate social responsibility._

## **Commitment to accountability through yearly carbon audits**

EcoVadis and Greenly, independent rating agencies specializing in corporate social responsibility assessments, have recognized the sustainability commitments and performance of Platform.sh.

Both rating agencies awarded the PaaS provider a gold medal, ranking Platform.sh among the top 5% (95th percentile) across all companies in all industries assessed by EcoVadis and Greenly.

Greenly reported that Platform.sh achieved a remarkable 6% reduction in its 2023 C02eq emissions audit compared to 2022. This significant decrease in absolute emissions is a testament to the company's dedication to combating climate change and reducing its environmental impact.

Both the assessment processes were rigorous, taking into account set quantified targets for reducing emissions, and the impact of action plans, employee training, and complying with SBTi standards.

The EcoVadis assessment also includes a global evaluation of the company's sustainability management system across four themes: Environment, Labor & Human Rights, Ethics, and Sustainable Procurement.

## **Commitment to transparency towards its customers**

Along with its commitments to sustainability Platform.sh also strives for carbon auditing transparency. In May 2024, Platform.sh achieved the first step towards this goal by sending each of its customers their 2023 CO2eq cloud carbon footprint report based on the emissions generated by their applications hosted with the PaaS provider.

**"The Platform.sh carbon footprint report enables customers to better understand their environmental impact. It's a step towards making informed decisions that align with sustainability goals, whether for internal benchmarking or for reporting in compliance with environmental, social, and governance criteria." - Fred Plais, CEO, Platform.sh**

Each carbon footprint report details an organization's annual CO2eq emissions based on its activities. Platform.sh customers can utilize these statements to track their cloud emissions for the European Union's Corporate Sustainability Reporting Directive (CSRD) or similar carbon disclosure requirements and to make greener and more informed deployment decisions.

**"Typically, a full carbon footprint report covers Scopes 1, 2, and 3. The statement we provide is one part of an organizations' Scope 3 disclosures. Scope 3 emissions are those based on activities from sources not owned or controlled by an organization (e.g., renting cloud instances, airline flights)." - Sabri Helal, Product Manager, Platform.sh**

## **Aiming for a sustainable digital future**

The PaaS providers' success in carbon emissions reduction is due to its unique location-based approach to hosting applications in the cloud. Through optimized server density, Platform.sh reduces CPU usage by up to 12 times compared to traditional hosting methods. Additionally, Platform.sh offers location-based hosting options, allowing customers to select regions powered by low-carbon grids and receive a 3% resource usage discount on its latest PaaS, Upsun. By implementing these initiatives Platform.sh further minimizes their environmental impact and helps their customers make greener choices.

By prioritizing sustainability and corporate social responsibility, Platform.sh is driving positive change within the industry and paving the way for a more sustainable digital future.

* * *

EcoVadis

EcoVadis is the global standard for business sustainability ratings. The EcoVadis assessment evaluates 21 sustainability criteria across four core themes: Environment, Labor & Human Rights, Ethics and Sustainable Procurement. More than 125,000 companies globally have been rated by EcoVadis.

EcoVadis’ business sustainability ratings are based on international sustainability standards such as the Ten Principles of the UN Global Compact, the International Labour Organization (ILO) conventions, the Global Reporting Initiative (GRI) standards and the ISO 26000 standard. The ratings provide an evidenced-based analysis on performance and an actionable roadmap for continuous improvement.

Greenly

Founded in October 2019 by Alexis Normand (CEO, former VP of Healthcare at Withings, HEC, Sciences Po, formerly at the Boston offices of Withings and Techstars), Mathieu Vergeville (CTO, X-Telecom, former data scientist at Withings) and Arnaud Delubac (CMO, Essec-Centrale, INSEE, formerly in charge of digital communication in the office of the French Prime Minister), Offspend SAS launched Greenly in January 2020 as the world’s first carbon accounting platform with almost 1,000 corporate clients in France, the UK and the US. The climate tech allows all enterprises, regardless of their size or sector of activity, to contribute to the fight against climate change, starting by simply tracking their CO2 emissions. Once a report is completed, Greenly helps them develop a roadmap to help them align themselves to a Net Zero Contributor Initiative. Greenly obtained the B-Corp label in September 2022, putting their solution at the disposal of society.

Platform.sh

Platform.sh is a unified, secure, enterprise-grade platform for building, running and scaling web applications. Founded in 2015, the company is headquartered in Paris and San Francisco. Platform.sh employs more than 310 Platformers, 43 nationalities, and is available in Europe, the United States and Asia, through global partnerships with AWS, GCP, Azure and OVHcloud.

A member of the FrenchTech 120 and Gaia-X, Platform.sh was recently included in the FT1000 list of fastest growing European companies. Offering a 100% remote working environment the company is a certified "Great Place to Work" with inclusivity and diversity at its core. It counts among its customers prestigious brands such as Adobe Magento, Gap, Nestlé, Orange, The British Council, The Financial Times and Unicef.

### [Unleashed Technologies - Partner Diamond-tier Status | Upsun](https://upsun.com/blog/unleashed-technologies-achieves-diamond-partner-status/)

# Unleashed Technologies achieves Platform.sh Partner Program Diamond-tier Status

_This article was initially published under the Platform.sh brand. As this is a press release, we have retained the Platform.sh name for historical accuracy and citation consistency._

_January 18, 2024, Paris, France_ - We are proud to announce United States based Platform.sh partner, Unleashed Technologies, an industry-leading digital strategy, custom software and web development company, has achieved Platform.sh Partner Program Diamond-tier status.

This recognition is a testament to Unleashed Technologies' expertise and success in leveraging the capabilities of Platform.sh to deliver exceptional results for their clients. As a Diamond tier partner, Unleashed Technologies will receive a range of benefits including program member discounts and referrals, technical training and certifications, collaboration with Agency Partner Team managers, and the opportunity to generate recurring revenue streams.

Unleashed Technologies has worked closely with Platform.sh for the past year, and quickly ascended to Platinum status. Their commitment and dedication to the platform has enabled countless migrations of sites seamlessly to the cloud from physical servers.

**This achievement places Unleashed Technologies among a select group of agencies globally who have achieved Diamond-tier partner status with Platform.sh.**

With sites hosted and powered by Platform.sh, Unleashed Technologies' clients benefit from gold-plated 24/7 cloud hosting support at reasonable pricing, ensuring fast and responsive service while proactively preventing site outages.

**“At Unleashed, we’re committed to providing our clients with top-tier custom software development, enterprise websites, and leading edge eCommerce solutions. Making sure we continue to offer industry-leading hosting to our clients is part of our commitment to quality. Partnering with Platform.sh was an obvious choice and achieving Diamond Tier Status and being the first digital agency in the US to do so is a testament to the hard work our teams have put in together on behalf of Unleashed clients.” - Muhammad Hutasuhut, CEO**

Unleashed Technologies' success in achieving Diamond-tier partner status is a result of meeting the rigorous qualifications set by Platform.sh. These qualifications include annual revenue thresholds and a net-new business threshold, as well as technical qualifications, such as the number of certified developers and completion of all annual trainings.

**"We are thrilled to have Unleashed Technologies as a Diamond tier partner. Their commitment to excellence and expertise in leveraging our platform is commendable. And we look forward to growing our successful partnership so Unleashed Technologies can continue to provide excellent experiences for their clients." - Platform.sh Senior Director of Partnerships, Chantal Pastorek**

Unleashed Technologies' attainment of Diamond-tier partner status with Platform.sh signifies their industry leadership and ability to deliver exceptional results for their clients. With a strong focus on technical expertise and customer satisfaction, Unleashed Technologies is well-positioned for continued success as a Platform.sh Agency Partner Program Diamond-tier trusted partner.

For more information about Unleashed Technologies’ end-to-end services and its partnership with Platform.sh, please visit the Unleashed Technologies' official website. Want to join the Platform.sh Partner Program, or are you looking for an agency partner to help you innovate?

* * *

**About Unleashed Technologies**: Unleashed Technologies provides enterprise and e-commerce websites, custom software development, digital strategy, and data structuring services for the Generative AI era. Since 2007, Unleashed has been committed to solving the most pressing business challenges using modern technology and custom development expertise. Our Mission is to deliver client-centric, digital solutions by leveraging our expertise in open-source technologies and cross-platform integrations.

### [Reducing collective carbon emissions from cloud activities | Upsun](https://upsun.com/blog/reduce-carbon-emissions-from-cloud-activities/)

# Reducing collective carbon emissions from cloud activities

_This article was initially published under the Platform.sh brand. As this is a press release, we have retained the Platform.sh name for historical accuracy and citation consistency._

**Paris/San Francisco, 17th March 2022** - Platform.sh, a unified, secure, enterprise-grade platform for building, running and scaling web applications, has worked with Greenly to calculate its carbon emissions to provide a clear picture to its customers.

Climate change is real. The IT sector is estimated to be responsible for 4% of the global GES emissions, a bigger impact than the airline industry already, and it is growing much faster. Platform.sh is committed to reducing its impact on the environment, alongside its customers, as a signatory to the Climate Act.

Platform.sh limits environmental impact by reducing its hardware and energy usage, then optimising its respective emissions and offsetting what is leftover.

**Platform.sh reduces energy use by:**

-   Application Performance Monitoring—optimising individual apps performance means **using fewer resources to run the same workloads.**
-   Increasing server density—servers are often under-utilised and under-optimised, with anything between 60-80% of their capacity going to waste. **Platform.sh uses proprietary technology to increase density up to 12 times** and cut energy usage up to 10x.
-   Rightsizing and scaling—No more overprovisioning. Platform.sh works with businesses to understand their needs today and allow them to grow fast and responsibly.

**Platform.sh optimises infrastructure to reduce emissions by:**

-   Supporting multiple cloud providers—**optimising infrastructure providers** offer different advantages, including better Power Usage Effectiveness. Customers can choose the cloud providers that offer the most benefits, where it matters.
-   Using the right location—**data center location can make a huge difference to CO₂e emissions.** For example, a datacenter in Sweden, using renewable energy, emits ten times less CO₂e per kWh than one powered by coal-generated electricity in Germany.

The rise of cloud services and cloud hosting makes it easy to forget about certain carbon costs—but any business aiming to reduce emissions must understand its complete carbon footprint. To enable this, Platform.sh is improving its environmental impact model and opening it to its customers, allowing them to take impactful action.

_“We have a responsibility to not just be a sustainable business, but to ensure everything we do enables our customers to be sustainable too—they need to be able to understand their impact to either reduce it or offset it,” said Fred Plais, CEO, Platform.sh. “In the past it was common to improve performance by “throwing more metal” at it—that is, to use more and better hardware. This approach is fundamentally flawed, solving nothing in the long run, and contributing to environmental damage.”_

Platform.sh is accelerating its efforts for the decarbonization and the environmental transition of the economy thanks to the France 2030 public investment plan. This funding helps us to continue our R&D in order to further reduce the environmental impact of our activities and those of our users

## **About Platform.sh**

Platform.sh is a cloud-based web application hosting platform, a leader in the management of fleets of websites and applications. Its innovative deployment platform allows teams in charge of eCommerce sites, media sites, innovative and high-traffic applications to focus their efforts on developing and improving their applications, without having to worry about infrastructure issues (scalability, continuous deployment, maintenance, security, 24/7 monitoring, etc.). Platform.sh is available in Europe, the United States and Asia, through global partnerships with AWS, Google, Azure, Orange and OVHcloud.

The company, winner of the European Commission's H2020 program, recently recognized by Numeum as part of the Top 250 for its international growth, member of the French Tech 120 and Gaia-X and certified "Great Place to Work", has its head office in Paris (France) and San Francisco and counts among its customers prestigious brands such as the Financial Times, Gap, Unity3D, Adobe Magento, Orange, Hachette, The British Council.

**For more information, please contact:**  
CCgroup for Platform.sh  
Ryan O’Leary / Matthew Denby (UK)  
T: +44 7890 049769  
E: platform.sh@ccgrouppr.com

### [App management for Orange Business Services | Upsun](https://upsun.com/blog/app-management-solution-for-6000-orange-business-services/)

# App management for Orange Business Services’ SMB customers

_This article was initially published under the Platform.sh brand. As this is a press release, we have retained the Platform.sh name for historical accuracy and citation consistency._

As result of the partnership, Orange Business Services’ thousands of SMB customers (including hotels, craftsmen, consulting, health providers) and hundreds of web agency partners will benefit from simplified site management, a superior developer experience, and improved total cost of ownership for their digital presence.

**Paris, July 29, 2019 –** Platform.sh, the Idea-to-Cloud Application Platform that simplifies could infrastructure, today announced an extension to the company’s partnership with Orange Cloud for Business through a significant, new contract to migrate and manage more than 6,000 WordPress, Joomla, Prestashop, and Drupal sites onto the Platform.sh Platform-as-a-Service (PaaS). The partnership aims to streamline the current web hosting offering, which supports thousands of subscribers using websites on a shared hosting infrastructure, the majority of which will be upgraded to full, standalone projects on the Platform.sh PaaS.

“Our primary goal is to help enterprises leverage the power of the cloud to deliver a stellar customer experience,” said Orange Cloud for Business CEO Stefan Kanis. “With this new offering, our customers can utilize advanced PaaS functionality to boost developer productivity and deliver business-critical apps and services at scale—all of this on a local cloud and at a lower overall cost. As a result, our customers can increase revenue while achieving core business objectives, including accelerating their digital transformation initiatives.”

This significant new contract comes three years after the companies announced Platform.sh availability on Orange Business Services’ public cloud. This new step enables Orange to relaunch its Flexible Web Publisher offering as an advanced, container-based ‘CMS as a Service’ (CMSaaS).

Platform.sh provides Orange with governance and management tools for their growing fleet of customer websites and applications within a single platform, entirely managed and secure. The Platform.sh solution includes automated updates of the CMS software, automated backups, a unique instant-cloning system for testing application changes, and the ability to integrate with the Orange Flexible Web Publisher product to provide customers with a seamless user experience.

“We’re very pleased to extend the scope of the partnership with Orange Business Services’ Cloud entity. For three years, our teams have worked effectively together, and this new project is getting some very strong traction in the enterprise market. It will also allow us to help smaller businesses benefit from the huge productivity and performance improvements, and the significant cost savings Platform.sh provides” said Fred Plais, Platform.sh CEO and co-founder. “From now on, Platform.sh will support Orange on both sides of the spectrum—from SMBs to large enterprises.”

Find out more about Platform.sh for Orange Business Services: https://cloud.orange-business.com/hebergement-web/

## **About Platform.sh**

Platform.sh enables teams to develop and deliver web applications at scale, with an end-to-end Platform-as-a-Service. With Platform.sh, organizations can focus 100 percent of their time on building amazing experiences–and zero time managing infrastructure. With headquarters in San Francisco and Paris, Platform.sh serves more than 5,000 clients and their 65,000+ developers worldwide. Customers like Unity, The Economist, Kaplan, CFL, Reiss, Pinterest, and The British Council rely on Platform.sh to launch, scale, and manage their fleets of websites and applications.

## **Press contact: EZPR**

Ed Zitron ed@ezpr.com +1 (347) 844-2149

### [Insights on how digital businesses should approach sustainability | Upsun](https://upsun.com/blog/expert-insights-on-business-sustainability/)

# Insights on how digital businesses should approach sustainability in 2024

_This article was initially published under the Platform.sh brand. As this is a press release, we have retained the Platform.sh name for historical accuracy and citation consistency._

_How can digital companies be more progressive to drive better sustainability practices in their business and beyond in 2024? Leah Goldfarb and Gerhard Andrey explore this topic and more in an insightful conversation on what business sustainability should look like in 2024._

To be progressive in your business practices in 2024 it’s not enough to focus only on the tools your organization develops. You also need to focus on its ecological, social, and economic impact. Leah Goldfarb, Platform.sh Environmental Impact Officer, and Gerhard Andrey, Co-Founder of Liip and National Councillor for the Swiss Green Party, delved into the critical topic of sustainability in digital businesses today. Their impactful conversation illuminated the pressing need for environmentally responsible practices within the tech industry and provided actionable insights for companies striving to make a positive impact in 2024.

## **The digital sustainability challenge**

Their discussion began with a sobering assessment of the current state of digital sustainability. Leah Goldfarb emphasized the urgency of addressing environmental impacts, noting, "The tech industry is a significant contributor to global emissions, and it's our responsibility to mitigate this." This sentiment was echoed by Gerhard Andrey, who highlighted that the digital sector's rapid growth necessitates a proactive approach to sustainability: "We can't afford to wait. The time to act is now."

## **Key strategies for sustainable growth**

The discussion soon transitioned into practical strategies for digital businesses to adopt. Both speakers emphasized the importance of measuring and understanding one's carbon footprint. "You can't manage what you don't measure," Leah pointed out, advocating for comprehensive environmental impact assessments. Gerhard added that transparency is key, "Openly sharing your sustainability metrics builds trust and drives industry-wide change."

Leah elaborated on the Platform.sh approach, which includes optimizing cloud infrastructure to reduce energy consumption and investing in data centers run on renewable energy. "Efficiency and innovation go hand in hand," she stated, highlighting the company's commitment to minimizing its ecological footprint while maintaining high performance.

## **Collaborative efforts and community engagement**

A recurring theme in the discussion was the power of collaboration. Gerhard stressed the importance of partnerships, both within the industry and with external stakeholders. "By working together, we can accelerate the transition to a sustainable digital future," he asserted. Leah concurred, emphasizing that collective action amplifies individual efforts, leading to a more substantial and lasting impact.

## **Looking ahead: the future of digital sustainability**

As the conversation drew to a close, both Leah and Gerhard expressed optimism about the future. Leah noted that growing awareness and technological advancements are paving the way for more sustainable practices. "We're seeing a cultural shift towards sustainability, and it's inspiring," she said. Gerhard echoed this sentiment, adding that policy changes and increased accountability will drive further progress: "The regulatory landscape is evolving, and it's pushing businesses to prioritize sustainability."

## **Join the journey**

The insights shared by Leah Goldfarb and Gerhard Andrey serve as a compelling call to action for digital businesses. The path to sustainability is challenging but achievable, and the rewards extend beyond environmental benefits to include enhanced brand reputation and customer loyalty. Platform.sh and Liip are committed to leading by example and invite you to explore their sustainability initiatives further. Together, as an industry, we can build a more sustainable digital future.

To learn more about the innovative approaches towards sustainability and their contributions to the digital landscape, visit Platform.sh and Liip.

### [Navigating 2025: top cybersecurity trends and AI's role in defense | Upsun](https://upsun.com/blog/key-cybersecurity-trends-for-2025/)

# Navigating 2025: top cybersecurity trends and AI's role in defense

_This article was initially published under the Platform.sh brand. As this is a press release, we have retained the Platform.sh name for historical accuracy and citation consistency._

**Paris/San Francisco 15 January 2025** - Organizations must adapt swiftly to stay ahead as cyber threats evolve. Joey Stanford, VP of Data Protection and Compliance at Platform.sh, a unified, secure, enterprise-grade Platform-as-a-Service (PaaS) for building, running, and scaling web applications, highlights the top cybersecurity trends for 2025, offering insights into the opportunities and challenges organizations face in securing their digital environments.

## **1\. The rise of AI in cybersecurity**

Artificial intelligence is reshaping the cybersecurity landscape with its ability to detect threats, automate responses, and provide 24/7 monitoring. However, its adoption is not without drawbacks. While AI enables rapid threat detection and response, adversarial AI tactics, such as deepfake creation and automated phishing, present new challenges. Additionally, high implementation costs and the risk of biased or flawed AI decision-making require careful consideration.

## **2\. Adoption of cybersecurity mesh architecture (CSMA)**

A more flexible, scalable framework is gaining traction. This framework enables seamless integration of security tools across diverse environments, providing organizations with enhanced adaptability in an increasingly complex threat landscape.

### **Key characteristics of cybersecurity mesh include:**

-   Decentralization: Instead of relying on a single centralized security solution, mesh systems distribute various security functions across the network, allowing them to function independently and communicate with each other.
-   Policy-driven security: Mesh architectures use policy definitions to determine which security tools can interact with or monitor different parts of the network.
-   Scalability: They are designed to scale horizontally by adding more nodes (or instances) into a system, making it easier for organizations to adapt their defense strategy as they grow.
-   Flexibility: Cybersecurity mesh enables organizations to combine various security functions from different vendors into a unified framework.

### **Importance:**

-   Enhanced threat detection and response: Decentralized network security can better detect and respond to threats that originate in multiple locations.
-   Better performance and scalability: The distributed nature of a cybersecurity mesh architecture allows for more efficient processing, which translates to faster incident response times and the ability to scale as needed.
-   Reduced complexity: Mesh architectures combine various functions into a single system, simplifying network security management by reducing the number of tools an organization needs to manage.
-   Improved user experience: By distributing security functions across the network, mesh architecture can help prevent slowdowns caused by overloading centralized security solutions.

## **3\. Stricter regulations and compliance demands**

Governments worldwide are tightening regulations, particularly around data breaches and ransomware. Staying compliant will require organizations to adapt to new laws and standards proactively as well as maturing supply chain security.

## **4\. Growth of Zero Trust security models**

Continuous verification of users and devices will dominate security strategies, reinforcing the need for organizations to assume no implicit trust in their networks. Continued adoption of passkeys over multifactor authentication.

## **5\. Expanding cybersecurity skills gap**

Demand for cybersecurity professionals continues to outpace supply. Organizations must invest in training and development to bridge this gap and ensure robust security defenses.

In reflecting on the year ahead, Joey Stanford said, “Cybersecurity in 2025 is poised at a pivotal juncture where the transformative potential of artificial intelligence (AI) offers unprecedented opportunities to bolster defenses against evolving threats, while simultaneously amplifying existing risks. As organizations embark on their digital transformation journey, it is paramount that they not only welcome this innovation with open arms but also cultivate a proactive mindset towards its inherent complexities.

To successfully navigate this landscape in the years ahead, cybersecurity strategies must go beyond mere defense mechanisms to incorporate strategic approaches that seamlessly integrate AI-driven technologies. By doing so, organizations can harness the full power of these tools without compromising their foundational security principles. This balanced approach will be crucial in defining the success of cybersecurity initiatives in 2025 and paving the way for a safer digital future.” Balancing the advantages and limitations of emerging technologies, particularly AI, will be crucial for organizations aiming to strengthen their cybersecurity posture in 2025. Understanding these trends is key to building resilient strategies against evolving threats.

* * *

_**About Platform.sh**_

Platform.sh is a unified, secure, enterprise-grade Cloud Application Platform founded in 2015 and headquartered in Paris and San Francisco. Employing more than 300 Platformers across 43 nationalities and available in Europe, North America and APAC through global partnerships with AWS, Google Cloud, Azure, Orange and OVHcloud.

A member of the FrenchTech 120 since 2019, recently awarded B Corporation™ certification, and a certified Great Place to Work with inclusivity and diversity at its core, it is a 100% remote working organization. It counts among its customers prestigious brands such as Adobe, Gap, The British Council, The Financial Times, and UNICEF.

### [Announcing a Greener Region Discount offering | Upsun](https://upsun.com/blog/announcing-greener-region-discount/)

# A First for the Cloud Industry — Platform.sh announces a Greener Region Discount offering

_This article was initially published under the Platform.sh brand. As this is a press release, we have retained the Platform.sh name for historical accuracy and citation consistency._

_**By offering a resource-usage discount when customers deploy to eligible greener data centers, Platform.sh expands its strategy to help customers reduce their carbon emissions.**_

_**Paris/San Francisco, 28 February 2024**_ - Platform.sh, a unified, secure, enterprise-grade platform for building, running and scaling web applications, today announced a first within the cloud industry: a 3% Greener Region Discount for customers when choosing a greener data center to deploy their applications on Upsun, the new PaaS from Platform.sh to be launched in April.

Despite its name, cloud computing is a very “grounded” activity, relying on physical data centers and servers, which accounts for approximately 3% of the electric power consumption in the world. Depending on physical location, the carbon intensity of these data centers varies drastically: it can be up to 30 times more intensive depending on whether the electricity primarily comes from coal and gas or from lower-carbon sources of electricity like hydro, solar, wind or nuclear.

This announcement confirms Platform.sh’s commitment to support developers and organizations who seek to deploy projects in regions generating less carbon. The Greener Region Discount is a financial incentive (fully funded by Platform.sh) built to align with customer financial and ESG interests. To incentivize users to reduce their carbon footprint the company will now offer a 3% discount on resource usage when selecting a greener region on Upsun.

Data centers that consume electricity that is less than 100 gCO₂eq/kWh are categorized as eligible. Based on this criteria, Platform.sh offers six incentive-eligible data center regions within five countries (France, Sweden, Switzerland, Canada and the U.S.) across four cloud providers (Azure, AWS, GCP and OVH) that are eligible under this incentive.

**“With Upsun, we are offering our most efficient cloud orchestration, providing better alignment between cost optimization and carbon footprint. With the Greener Region Discount, we aim to contribute to making a real impact by bearing the cost of this incentive, thereby empowering our users to reduce their carbon footprint in the cloud while staying cost-efficient. This cements our commitment to decrease the effects of our activity on the environment, one step at a time, ” said Fred Plais, co-founder and CEO, Platform.sh.**

Ensuring it provides the most up-to-date and accurate numbers to inform users to make the greenest choice possible without impacting performance, Platform.sh updates the carbon intensities for its regions using Electricity Maps data.

Leah Goldfarb, Environmental Impact Officer at Platform.sh: “Using a location-based approach, we display the underlying carbon intensity (in gCO₂eq/kWh) of the electrical grid supplying the individual data center. For our typical client, this is more accurately aggregated over a full 12-month period. As the grid carbon intensity fluctuates based on the day, time of day of the measurement and due to usage impacting the source of that energy, we will base our data on an annual 12-month average per year provided by Electricity Maps. This gives us a more accurate estimation of our clients’ usage and aligns with how our carbon audit is calculated.”

Upsun is currently in Open Beta, and the **Greener Region Discount** is available for all Open Beta users as of today. Upsun is set to be launched in April 2024.

### [Leah Goldfarb joins us as Environmental Impact Officer | Upsun](https://upsun.com/blog/leah-goldfarb-environmental-impact-officer/)

# Leah Goldfarb joins us as Environmental Impact Officer

_This article was initially published under the Platform.sh brand. As this is a press release, we have retained the Platform.sh name for historical accuracy and citation consistency._

**Paris/San Francisco, September 7th 2022** - Platform.sh, a unified, secure, enterprise-grade platform for building, running and scaling web applications, today announced the appointment of Leah Goldfarb as Environmental Impact Officer. In what is the first hire of its kind for the PaaS industry, Goldfarb will oversee the company’s greener web hosting strategy as Platform.sh looks to further reduce the digital carbon footprint of its large enterprise clients.

Holding a PhD in Atmospheric Science, Goldfarb has spent two decades working in environmental science and policy. Prior to joining Platform.sh, Goldfarb served as Senior Science Officer at the Technical Support Unit of the Intergovernmental Panel on Climate Change (IPCC) Working Group I, and before that as a Science Officer at the International Science Council, liaising with the United Nations around sustainable development. This appointment is a signal of intent by Platform.sh to offer responsible website scaling and fleet management and become a more sustainable business.

Due to the server density provided by Platform.sh, businesses of all sizes can reduce their carbon emissions. Platform.sh uses proprietary technology to increase density up to 12 times and cut energy usage up to 10 times. Data center location can also make a huge difference to CO₂ emissions. Through Platform.sh’s API, developers of companies such as Nestlé can access environmental information to see which regions use less CO₂, meaning they can make more informed greener decisions and help improve their company’s digital carbon footprint.

Goldfarb’s initial focus at Platform.sh will be on measurement and then continued optimization: currently Platform.sh is looking to measure the impact of its clients’ carbon emissions and to optimize deployments and further improve application performance monitoring.

_“Working in climate science and policy, I was writing reports for decision makers who didn’t always do enough with the scientific information provided. I joined Platform.sh because the company and I have the same shared goal, to have a positive impact on the environment”, said **Leah Goldfarb**, Environmental Impact Officer at Platform.sh. “While the ITC sector is estimated to be responsible for 4% of the global greenhouse gases emissions, it is also in a unique place to make a difference when it comes to the planet due to its forward-thinking approach and scale. At Platform.sh, we want to play our part in contributing to reduced emissions by curbing companies' emissions and helping them be more carbon conscious.”_

**About Platform.sh** Platform.sh is a unified, secure, enterprise-grade platform for building, running and scaling web applications. Founded in 2015, the company is headquartered in Paris and San Francisco. Platform.sh employs 340 people across 36 countries and is available in Europe, the United States and Asia, through global partnerships with AWS, GCP, Azure, Orange and OVHcloud. A member of the FrenchTech 120 and Gaia-X, Platform.sh was recently included in the FT1000 list of fastest growing European companies. Offering a 100% remote working environment the company is a certified "Great Place to Work" and counts among its customers prestigious brands such as Adobe Magento, Gap, Nestlé, Orange, The British Council, The Financial Times and Unicef.

**For more information, please contact:** CCgroup for Platform.sh Ryan O’Leary / Matthew Denby (UK) T: +44 7890 049769 E: platform.sh@ccgrouppr.com

### [Platform.sh Secures $140 million in Series D Funding | Upsun](https://upsun.com/blog/securing-series-d-financing/)

# Platform.sh Secures $140 million in Series D Funding

_This article was initially published under the Platform.sh brand. As this is a press release, we have retained the Platform.sh name for historical accuracy and citation consistency._

-   _Revaia, Digital+ Partners and Morgan Stanley Expansion Capital lead the round._
-   _Investment will allow the leading enterprise grade PaaS for websites and web apps to cement its market position across its key regions (North America, Europe and Asia) through team expansion as well as accelerated product development both organically and inorganically._

**Paris and San Francisco, 21st June 2022**: Platform.sh, a unified, secure, enterprise-grade platform for building, running and scaling web applications, today announced it has raised $140 million in Series D funding. The round was led by Munich-based Digital+Partners, San Francisco-based Morgan Stanley Expansion Capital, and Paris-based Revaia, alongside existing investors BGV, Eurazeo, Hiinov, and Partech, all re-investing.

The funds will allow Platform.sh to build on its leading position in Europe, the US and Asia, recruiting new employees worldwide to meet its expansion goals. Building on the successful acquisition of Blackfire in May 2021 that helped the company to strengthen its offering in application performance management, Platform.sh intends to use part of the proceeds to fund future acquisitions to accelerate its organic product roll out.

Platform.sh has found global success by removing the pain associated with building websites or web applications. Digital teams face a large array of choices when building, deploying and managing web applications, from selecting which system to use in the backend to deciding what framework and language to code in. To solve this complexity, Platform.sh offers companies an end-to-end platform that helps build, host, and scale a fleet of web sites and web applications while removing the need for IT and cloud operations.

Using Platform.sh, websites and web applications can be built by distributed development teams, including external agencies, in different languages and using different frameworks, enabling smooth collaboration. Powerful automation significantly improves productivity and generates massive cost savings on cloud expenditure. Businesses of all sizes can also reduce their carbon emissions thanks to the unmatched server density provided by Platform.sh, with the company's commitment to sustainable hosting leading it to engage in the B Corp certification process. As a result, Platform.sh’s responsible cloud platform and fleet management strategy has been adopted by large organizations worldwide such as Adobe, Nestlé, but also for smaller digital teams like Gault et Millau, Unicef, University of Missouri and many more.

Founded in 2015 and member of the FrenchTech 120 for a third year in a row, Platform.sh currently employs 340 people across 36 countries and generates north of $40m in annual recurring revenue. Its commitment to a 100% remote workforce has made it one of the hottest tech companies to work for. This funding round demonstrates the success of both Platform.sh and the growing French tech ecosystem.

_“When we launched Platform.sh, we wanted to build a very powerful cloud platform that simplifies the cloud experience for web developers, making sure they spend time on developing and zero time on cloud infrastructure,”_ said **Fred Plais, CEO and Co-Founder of Platform.sh**. _“Our approach has quickly inspired global corporations to manage thousands of websites and applications efficiently and securely to help them make informed, greener decisions when hosting web apps. This latest round of funding will support us as we invest in third-party technology acquisition and continue to innovate.”_

_"We are honoured to partner with Platform.sh and support their mission to help companies implement automated cloud infrastructure, while reducing the environmental impact of their digital operations,”_ said **Morgan Kessous, Partner at Revaia**. _“The company screens as a leader in the DevOps and PaaS markets, and unlocks tremendous value for its customers as it provides developers a platform to deploy both safer and faster. We also share with Platform.sh's team the conviction that Green Hosting is the next frontier in cloud infrastructure, and we are very enthusiastic to back a company with the highest levels of ambition and ethics.”_

_“We have been following Platform.sh’s journey for several years and are delighted to support Fred and his excellent team to become the global category leader for managing fleets of websites,”_ said **Julian Mattes, Partner at Digital+ Partners**. _“The war for developer talent and the increasing complexity of DevOps tooling drives the strong demand in the website infrastructure market. We feel a strong connection to the team, the vision, and the values of Platform.sh to enable organizations to focus 100% of their time on building amazing experiences.”_

_“The website is core to the brand and customer experience, and as such, uptime, cross-functional collaboration, and rapid iteration is table stakes,”_ said **Pete Chung, Partner at Morgan Stanley Expansion Capital**. _“Fred and the team at Platform.sh have built the market-leading platform to tackle these issues head-on and we look forward to partnering with the Company in its next phase of growth,”_

Platform.sh was advised by KeyBanc Capital Markets, Gide and White & Case. New investors were advised by White & Case.

**About Platform.sh**

Platform.sh is a unified, secure, enterprise-grade platform for building, running and scaling web applications. Founded in 2015, the company is headquartered in Paris and San Francisco. Platform.sh employs 340 people across 36 countries and is available in Europe, the United States and Asia, through global partnerships with AWS, GCP, Azure and OVHcloud.

A member of the FrenchTech 120 and Gaia-X, Platform.sh was recently included in the FT1000 list of fastest growing European companies. Offering a 100% remote working environment the company is a certified "Great Place to Work" and counts among its customers prestigious brands such as Adobe Magento, Gap, Nestle, Orange, The British Council, The Financial Times and Unicef.

**For more information, please contact:**

CCgroup for Platform.sh Ryan O’Leary / Matthew Denby (UK) T: +44 7890 049769 E: platform.sh@ccgrouppr.com

**About Revaia**

Based in the core of Europe, with our roots in two of the continent’s financial and technology powerhouses – Paris and Berlin – Revaia is pan-European at heart. We invest in European growth-stage companies with global ambitions and sustainable leadership. We are a young, complementary, and diverse team with entrepreneurial and private equity backgrounds. We build bridges between growth and public markets. We are sparring partners for entrepreneurs who are working to transform our world for the better. Our team has already invested in companies that are doing just that, like Aircall, Algolia, Deepki, Epsor, Frontify, GetAccept, etc. For more information please visit: https://revaia.com/

**About Digital + Partners**

Based in Frankfurt, Munich and London, Digital+ Partners is a leading technology growth equity investor focused on DACH and European technology companies with over $800 million assets under management. Digital+ Partners aims to support ambitious entrepreneurs build global technology leaders, providing them with strategic advice and long-term financial support to help them define and execute their growth plans. Digital+ Partners focuses exclusively on B2B technology companies and leverages a deep corporate network to help portfolio companies access new markets and build new partnerships. For more information please visit: www.dplus.partners

**About Morgan Stanley Expansion Capital** Morgan Stanley Expansion Capital is the growth-focused private investment platform within Morgan Stanley Investment Management. Morgan Stanley Expansion Capital targets growth equity and credit investments within technology, healthcare, consumer, digital media and other high-growth sectors. For over three decades, Morgan Stanley Expansion Capital has successfully pursued growth investment opportunities and has completed investments in over 200 companies, leveraging the global brand and network of Morgan Stanley. For further information about Morgan Stanley Expansion Capital, please visit www.morganstanley.com/im/expansioncapital.

### [We join forces with Welcome to the Jungle | Upsun](https://upsun.com/blog/joining-forces-with-welcome-to-the-jungle/)

# Platform.sh and Welcome to the Jungle join forces to support the European developer ecosystem through the return of dotConferences

_This article was initially published under the Platform.sh brand. As this is a press release, we have retained the Platform.sh name for historical accuracy and citation consistency._

-   _After 39 editions since 2012, with over 24,000 participants and a forced 4-year hiatus post-Covid, dotConferences are making a grand comeback in June 2024._
-   _By providing a platform for the world's top developers, both entities aim to reposition Paris as a major hub in the international tech scene._
-   _Under the independent leadership of Nessrine Berrama, dotConferences plans to organize three major events this year focused on the latest technological revolutions: Javascript, Python, and AI._

**In Paris, on February 06, 2024** - Platform.sh - a unified, secure, enterprise-grade platform for building, running and scaling web applications and Welcome to the Jungle\- a French specialist in employer branding and recruitment - are joining forces to help relaunch dotConferences. This initiative aims to revive globally renowned conferences and strengthen Paris's position as a key tech hub. The idea is to provide a reassuring perspective on the future of developer professions through top-notch speakers and premium content.

Two tech leaders lend their support to dotConferences The post-COVID period led to the suspension of physical events, and their resumption is taking longer than anticipated. Recognizing the impact of the current crisis and the absence of vibrant tech events, Platform.sh and Welcome to the Jungle aim to breathe new life into dotConferences to restore dynamism to the pan-European tech ecosystem.

Indeed, when these two players emerged to respectively streamline developers' daily lives and enhance recruitment, dotConferences served as an endless source of inspiration for the entire ecosystem. These events catalyzed community engagement through high-quality content shared by an unparalleled assembly of guests (experts, leaders, mentors, etc.), thus fueling sectoral growth and contributing to the rise of numerous players.

Today, faced with a profound paradigm shift due to the crisis and the constant emergence of new technologies, developers increasingly feel the need to understand industry developments and the evolution of their profession. In the midst of an uncertain period, the ecosystem eagerly anticipates the return of qualitative conferences where expertise and reassurance intertwine. By participating in the revival of these conferences that have profoundly influenced the French tech ecosystem, Platform.sh and Welcome to the Jungle aim to provide participants with an enlightened vision of their future.

**At the forefront of innovation to enhance the skills of European developers** Returning in 2024, dotConferences aims to support European developers in acquiring essential skills to maintain their competitiveness in the race for innovation. This will be achieved through a new series of conferences focusing on the latest revolutionary technologies within various sectors. These events aim to give a global scope to tech thought leaders and contribute to the repositioning of Paris as an international platform for expertise and innovation.

dotConferences will structure the content of its events by exploring diverse technological topics and giving increased prominence to the diversity of programming languages. The spotlight will be on Javascript, Python, and artificial intelligence in 2024.

Simultaneously, the entity aims to internationalize its conferences by expanding into other European tech hubs and fostering the development of international B2B partnerships.

_"The dotConferences have always been the must-attend event for technology enthusiasts. After this forced hiatus, we are delighted to relaunch this event that has left a lasting mark on the industry and are eager to once again bring together the best international experts, contributing to the prominence of the European tech ecosystem,"_ explains Nessrine Berrama, CEO of dotConferences.

_"As an associate partner of these events, Welcome to the Jungle is proud to support their revival. These conferences have always been a source of inspiration and learning for industry professionals. With their return, we hope to bring the entire community the inspiration they have given us,"_ emphasizes Alice Hagger, Vice President Brand & Creative at Welcome to the Jungle.

_"We are pleased to partner with Welcome to the Jungle to contribute to the return of dotConferences to the international tech scene. These events have a long and successful history, and we are determined to elevate them to new heights, focusing on innovation and technical excellence,"_ rejoice Frédéric Plais, co-founder and CEO of Platform.sh, Ori Pekelman, co-founder and Chief Strategy Officer of Platform.sh.

* * *

**About dotConferences**

dotConferences is a series of high-level events for developers in Europe. Since 2012, 39 conferences have been organized in Paris, bringing together over 24,000 participants and showcasing the most popular programming languages and technologies such as Javascript, Python, CSS, Artificial Intelligence, Security, and many more.

The mission of dotConferences is to help developers enhance their skills by inviting technical thought leaders from around the world to speak in the most prestigious venues that cities have to offer.

**About Welcome to the Jungle**

Welcome to the Jungle is a workplace expert, providing innovative solutions to companies to develop their employer brand and strengthen their attractiveness. The company also offers inspiring experiences and content that provide both workers and companies with the tools to redefine the rules of work

### [Navigating data sovereignty through complexity | Upsun](https://upsun.com/blog/navigating-data-sovereignty-through-complexity/)

# Navigating data sovereignty through complexity

_This article was initially published under the Platform.sh brand. As this is a press release, we have retained the Platform.sh name for historical accuracy and citation consistency._

Navigating data sovereignty through complexity

https://www.information-age.com/navigating-data-sovereignty-through-complexity-123496315/

## **About Platform.sh**

Platform.sh enables teams to develop and deliver web applications at scale, with an end-to-end Platform-as-a-Service. With Platform.sh, organizations can focus 100 percent of their time on building amazing experiences–and zero time managing infrastructure. With headquarters in San Francisco and Paris, Platform.sh serves more than 5,000 clients and their 65,000+ developers worldwide. Customers like Unity, The Economist, Kaplan, CFL, Reiss, Pinterest, and The British Council rely on Platform.sh to launch, scale, and manage their fleets of websites and applications.

### [Easy experimenting with Apache Kafka | Upsun](https://upsun.com/blog/experiment-with-apache-kafka/)

# Easy experimenting with Apache Kafka

_This article was initially published under the Platform.sh brand. As this is a press release, we have retained the Platform.sh name for historical accuracy and citation consistency._

The Next Web covers the launch of Kafka on Platform.sh.

https://thenextweb.com/dd/2019/06/12/this-site-makes-it-ridiculously-easy-to-experiment-with-apache-kafka/

## **About Platform.sh**

Platform.sh enables teams to develop and deliver web applications at scale, with an end-to-end Platform-as-a-Service. With Platform.sh, organizations can focus 100 percent of their time on building amazing experiences–and zero time managing infrastructure. With headquarters in San Francisco and Paris, Platform.sh serves more than 5,000 clients and their 65,000+ developers worldwide. Customers like Unity, The Economist, Kaplan, CFL, Reiss, Pinterest, and The British Council rely on Platform.sh to launch, scale, and manage their fleets of websites and applications.

### [Black Friday reinforces itself as the biggest week in ecommerce | Upsun](https://upsun.com/blog/black-friday-is-biggest-week-in-ecommerce/)

# Black Friday reinforces itself as the biggest week in ecommerce

_This article was initially published under the Platform.sh brand. As this is a press release, we have retained the Platform.sh name for historical accuracy and citation consistency._

_**Paris/San Francisco, 17 December 2024**_ - Platform.sh, a unified, secure, enterprise-grade Platform-as-a-Service (PaaS) for building, running, and scaling web applications, revealed data1 from its platform outlining website traffic of ecommerce websites during the 2024 Black Friday and Cyber Monday shopping season.

Platform.sh data revealed that on Black Friday 2024, customer ecommerce websites demonstrated remarkable resilience. They managed to handle a surge of up to 65% in website traffic when compared to any other Friday in 2024, including a 14% traffic increase compared to Black Friday in 2023. Cyber Monday is another significant shopping day that saw a 39% increase in ecommerce website traffic compared to an average Monday in 2024, and a 13% traffic increase compared to Cyber Monday 2023.

The trend continues for online retailers as the holiday period drives into full swing, with ecommerce traffic for the first week of December 2024 seeing an increase of 16% with over 11 million website visits in this week compared to the week post Black Friday in 2023. Just over 12,000 ecommerce websites running on Platform.sh throughout Europe, the U.S. and APAC received just under two billion visits on Black Friday alone–showcasing that online and in-person shopping has stabilized post-pandemic times.

Despite the cost of living and inflation rising across the U.S., UK, and EU, the discounts associated with Black Friday and Cyber Monday still attracted many shoppers and visitors to online retail. Adobe reported a significant growth in U.S. online sales on Black Friday, with $10.8 billion in online sales on Black Friday 2024, up from $9.8 billion in 2023, painting a promising picture for the future of ecommerce.

### [Process and performance improvement in private cloud | Upsun](https://upsun.com/blog/investigating-process-performance-improvement-private-cloud/)

# Process and performance improvement in private cloud

_This article was initially published under the Platform.sh brand. As this is a press release, we have retained the Platform.sh name for historical accuracy and citation consistency._

Investigating process and performance improvement in private cloud

https://www.computerweekly.com/feature/Investigating-process-and-performance-improvement-in-private-cloud

## **About Platform.sh**

Platform.sh enables teams to develop and deliver web applications at scale, with an end-to-end Platform-as-a-Service. With Platform.sh, organizations can focus 100 percent of their time on building amazing experiences–and zero time managing infrastructure. With headquarters in San Francisco and Paris, Platform.sh serves more than 5,000 clients and their 65,000+ developers worldwide. Customers like Unity, The Economist, Kaplan, CFL, Reiss, Pinterest, and The British Council rely on Platform.sh to launch, scale, and manage their fleets of websites and applications.

### [ How cloud services spending will impact the hosting industry | Upsun](https://upsun.com/blog/spike-in-cloud-services-spending-impacts-hosting-industry/)

# How cloud services spending will impact the hosting industry

_This article was initially published under the Platform.sh brand. As this is a press release, we have retained the Platform.sh name for historical accuracy and citation consistency._

Platform.sh CEO and Co-Founder Fred Plais and others weigh in on the effects of increased spending on the hosting industry. Read the article at HostingAdvice.com.

## **About Platform.sh**

Platform.sh is a cloud-based web application hosting platform, a leader in the management of fleets of websites and applications. Its innovative deployment platform allows teams in charge of eCommerce sites, media sites, innovative and high-traffic applications to focus their efforts on developing and improving their applications, without having to worry about infrastructure issues (scalability, continuous deployment, maintenance, security, 24/7 monitoring, etc.). Platform.sh is available in Europe, the United States and Asia, through global partnerships with AWS, Google, Azure, Orange and OVHcloud.

The company, winner of the European Commission's H2020 program, recently recognized by Numeum as part of the Top 250 for its international growth, member of the French Tech 120 and Gaia-X and certified "Great Place to Work", has its head office in Paris (France) and San Francisco and counts among its customers prestigious brands such as the Financial Times, Gap, Unity3D, Adobe Magento, Orange, Hachette, The British Council.

**For more information, please contact:**  
CCgroup for Platform.sh  
Ryan O’Leary / Matthew Denby (UK)  
T: +44 7890 049769  
E: platform.sh@ccgrouppr.com

### [Platform.sh evolves into Upsun | Upsun](https://upsun.com/blog/platformsh-evolves-into-upsun/)

# Platform.sh evolves into Upsun, the cloud application platform built for humans and robots

_Formerly Platform.sh, Upsun builds on proven foundations of reliability, compliance, and sustainability while introducing new capabilities to power AI-assisted development and enterprise-scale modernization._

**23 September 2025, San Francisco and Paris -** Platform.sh, the trusted cloud application platform used by more than 6,000 enterprises and 16,000 developers worldwide, today announced its evolution into Upsun. This strategic evolution reflects the company's future-ready focus to assist enterprises in accelerating digital transformation with AI at the forefront.

> “The transition from Platform.sh to Upsun symbolizes our significant evolution as a company. Our growth over the last decade required a brand that captures our commitment to global reach, exceptional service, and continuous innovation. As enterprises expand the use of AI in software development, Upsun will provide the AI support they need to increase productivity and deployment velocity, and help companies manage risk–all while ensuring application quality from development to production and beyond,” said Fred Plais, CEO and Co-Founder of Upsun (formerly Platform.sh)

**Trusted foundations, expanded capabilities**

For a decade, multicloud flexibility, built-in security, and compliance have been cornerstones of Platform.sh. Providing organizations with the ability to manage complexity,  optimize cost, maintain compliance, and ensure performance across regions and providers such as AWS, Azure, Google Cloud, IBM Cloud, and OVHcloud.

Platform.sh has set the standard for environmentally responsible cloud operations, and Upsun continues this commitment with its multicloud location-based approach and carbon intensity transparency. It also offers its users a greener-region incentive to deploy to low-carbon data regions. These trusted foundations that defined Platform.sh remain at the core as the company evolves into Upsun. 

Upsun is the company's strategic expansion into modern application lifecycle management, accelerating AI-assisted development and AI-augmented workflows. Giving enterprises the tools to keep pace with the rapid adoption of AI, unlocking new opportunities for innovation.

**Full steam ahead on accelerating the software delivery lifecycle**

As enterprises accelerate their adoption of AI, Upsun supports human developers, AI agents, and coding assistants. It provides a robust and intelligent environment for modern software development without the need for costly overhead and complicated infrastructure management:

-   Multi-runtime compatibility: a single, consistent platform for Python, Node.js, Java, .NET, Go, PHP and more enables teams to choose the best language for each service, accelerating delivery and reducing operational overhead.
-   Upsun streamlines day-to-day operations with GitOps workflows, Continuous Delivery by default, fully managed services, and built-in observability, cutting developer toil, and speeding incident response.
-   Risk is contained with Isolated Preview Environments that mirror production, observability guardrails, automated backups and comprehensive access control, safely and securely enabling rapid innovation.
-   Onboarding is accelerated by AI-generated Configuration supported by a comprehensive CLI and a VSCode extension. 
-   Upsun’s MCP server and API give AI agents a secure, auditable way to invoke platform tools and run runbooks, and enables direct developer interaction from their preferred LLM-enabled IDE (Claude Code, Github Copilot, etc)

Upsun empowers teams to build and deploy AI-enabled and non-AI applications with confidence.

> “The move to Upsun recognises how far we have come. Developers get speed, simplicity, and scalability. Enterprises get standardization, security, and sustainability. With our shared values, we’re building a company that’s not just future-ready, but future-defining. This brand evolution sets the stage for everything we are building next,” said Nigel Kersten, CPO at Upsun (formerly Platform.sh)

**Reliability and continuity with momentum**

With a refreshed look, Upsun continues the Platform.sh commitment to ensuring enterprise reliability, building customer trust, and striving towards ESG leadership. Customers can expect the same high level of service, now with enhanced capabilities designed for the next decade of digital transformation.

> "As Upsun, we look forward to continuing our journey of growth and innovation, ensuring our clients can confidently navigate the complexities of modern digital transformation," said Fabien Potencier, CTO of Upsun (formerly Platform.sh).

### [2023 new plans and pricing update | Upsun](https://upsun.com/blog/new-plans-and-pricing-update/)

# 2023 new plans and pricing update

_This article was initially published under the Platform.sh brand. As this is a press release, we have retained the Platform.sh name for historical accuracy and citation consistency._

While building Platform.sh and our product, value, and quality are central to every decision we make. Over the last 7 years, our product has evolved greatly adding many features and functionalities that specifically address both value and quality - at the best possible price. However, we are not immune to the current economic conditions and inflation. The environment keeps evolving around us and providers have significantly raised our costs, especially in the last year. Therefore, to keep providing the same value and quality offering, we will adjust our prices from January 1st, 2023. Our philosophy when revamping the pricing was to offer a reasonable increase of roughly 10% on average across all our plans (in each tier) while keeping them simple and predictable.

We are also announcing the introduction of new plans in January 2023 which many of our customers have been waiting for - including high memory options and an Essential plan. The Essential plan is a new entry-level production plan introducing a lower-cost alternative for smaller workloads to provide our clients with greater choice and cost efficiency. Meanwhile, the new high-memory plans will allow those customers in need of additional memory to simply purchase the increased memory their application needs, with no need to upgrade to a larger plan unnecessarily. These are just an example of the developments we have made for our offering and the innovations we will continue to make going forward into 2023.

### [Sylius Cloud powered by Platform.sh | Upsun](https://upsun.com/blog/introducing-sylius-cloud/)

# Build, run, and scale your ecommerce applications with Sylius Cloud powered by Platform.sh

_This article was initially published under the Platform.sh brand. As this is a press release, we have retained the Platform.sh name for historical accuracy and citation consistency._

_Platform.sh and Sylius, the open source, headless ecommerce platform, have joined forces to create an innovative new offering—Sylius Cloud powered by Platform.sh._

Platform.sh and Sylius have joined forces to create a brand new innovative offering, Sylius Cloud powered by Platform.sh—a simplified way to manage complex infrastructure, customize the platform, and scale effortlessly as the business grows.

Sylius is an open-source eCommerce framework based on Symfony, tailored for mid-market and enterprise brands that require custom solutions. Renowned for its developer-friendly environment, Sylius enables the creation of diverse shopping experiences for both B2C and B2B eCommerce. It excels in supporting the most demanding business models. Sylius also comes with ready-to-use plugins, known as Sylius Plus, which can accelerate implementation time by 40%.

This strategic partnership brings together the cutting-edge cloud hosting solutions of Platform.sh and the modern,developer-centric approach to the professional development of Sylius. Creating a dynamic solution for mid-market and enterprise organizations that need custom solutions.

Sylius Cloud powered by Platform.sh offers an excellent solution for every Sylius user—a developer working on a pet project, agencies requiring multiple environments during the project development process, or merchants operating on a serious enterprise scale.

Find out how easy the deployment of Sylius Cloud powered by Platform.sh could be with our quick start guide on how to create a new project and environment in Platform.sh.

Sylius Cloud powered by Platform.sh is a perfect match for businesses and individuals looking for flexibility and scalability in cloud computing without compromising on the unique needs of their ecommerce stores and control over the data or source code.

Stay tuned for more updates as Platform.sh and Sylius continue to redefine the boundaries of technological innovation and drive unprecedented value for businesses worldwide.

### [How to measure the success of a PaaS strategy | Upsun](https://upsun.com/blog/measure-success-of-paas-strategy/)

# How to measure the success of a PaaS strategy

_This article was initially published under the Platform.sh brand. As this is a press release, we have retained the Platform.sh name for historical accuracy and citation consistency._

How to measure the success of a PaaS strategy

https://www.techradar.com/uk/news/how-to-measure-the-success-of-a-paas-strategy

## **About Platform.sh**

Platform.sh enables teams to develop and deliver web applications at scale, with an end-to-end Platform-as-a-Service. With Platform.sh, organizations can focus 100 percent of their time on building amazing experiences–and zero time managing infrastructure. With headquarters in San Francisco and Paris, Platform.sh serves more than 5,000 clients and their 65,000+ developers worldwide. Customers like Unity, The Economist, Kaplan, CFL, Reiss, Pinterest, and The British Council rely on Platform.sh to launch, scale, and manage their fleets of websites and applications.

### [Platform.sh Unlocks C/D With an End-to-End Platform | Upsun](https://upsun.com/blog/interview-hostingadvice/)

# Platform.sh Unlocks C/D With an End-to-End Platform

_This article was initially published under the Platform.sh brand. As this is a press release, we have retained the Platform.sh name for historical accuracy and citation consistency._

TL; DR: Platform.sh introduces a reliable way to safely deploy updates created in a cloned production environment by removing any fears about breaking your website or application in the middle of a critical traffic spike. The company’s multi-cloud platform streamlines infrastructure configuration and management to simple YAML files, enabling developers and startups to more easily launch and scale containerized or headless applications. Vice President of Marketing Chris Yates shared his own experiences using Platform.sh and how the user-focused company continuously aims to simplify development and delivery. Share

Read the article in its entirety at Hostingadvice.com.

## **About Platform.sh**

Platform.sh enables teams to develop and deliver web applications at scale, with an end-to-end Platform-as-a-Service. With Platform.sh, organizations can focus 100 percent of their time on building amazing experiences–and zero time managing infrastructure. With headquarters in San Francisco and Paris, Platform.sh serves more than 5,000 clients and their 65,000+ developers worldwide. Customers like Unity, The Economist, Kaplan, CFL, Reiss, Pinterest, and The British Council rely on Platform.sh to launch, scale, and manage their fleets of websites and applications.

### [Platform.sh certified by the Great Place to Work Institute | Upsun](https://upsun.com/blog/we-are-named-great-place-to-work/)

# Platform.sh certified by the Great Place to Work Institute

_This article was initially published under the Platform.sh brand. As this is a press release, we have retained the Platform.sh name for historical accuracy and citation consistency._

**San Francisco, July 1, 2019 -** Platform.sh is thrilled to announce that has been certified by the Great Place To Work(r) Institute for 2019.

-   Read more about the Platform.sh experience from the Great Place to Work(r) Institute
-   Find out about Platform.sh
-   Work at Platform.sh

## **About Platform.sh**

Platform.sh enables teams to develop and deliver web applications at scale, with an end-to-end Platform-as-a-Service. With Platform.sh, organizations can focus 100 percent of their time on building amazing experiences–and zero time managing infrastructure. With headquarters in San Francisco and Paris, Platform.sh serves more than 5,000 clients and their 65,000+ developers worldwide. Customers like Unity, The Economist, Kaplan, CFL, Reiss, Pinterest, and The British Council rely on Platform.sh to launch, scale, and manage their fleets of websites and applications.

## Trust Center

### [Trust Center - Cloud Web Security | Upsun](https://upsun.com/trust-center)

# Upsun Trust Center

Upsun, the cloud PaaS to develop, deploy, and securely host websites and web apps, provides the cloud web security, flexibility, and control you need to build innovative digital experiences. Trust is at the core of everything we do earned through our transparency and our unwavering commitment to protecting and responsibly handling your data.

Trust Center

Trust Center - Cloud Web Security | Upsun

Learn about cloud web security at Upsun, the PaaS that provides flexibility, control, and data protection needed to build innovative digital experiences.

### Privacy

At our Trust Center, you’ll find clear information about how we manage and protect your data. Our privacy practices are built to give you control, ensure compliance, and uphold the highest standards of integrity.

### Security

Upsun lets you deliver amazing online experiences, and helps to keep your site safe, secure, and available—24x7. Now you can navigate through changing requirements and updates as we work to protect your applications from cyber attacks.

### Reliability

Upsun.com, with its up to 99.99% uptime SLA, auto-scaling architecture, automated backups, and available DDoS protection, will keep your site online when it matters most.

### Legal

Easily access legal information and documentation to find answers to your questions about our Terms of Service, intellectual property, and other key policies.

### Sustainability

At Upsun, sustainability is built on accountability, continuous improvement, and transparency. We embed ESG considerations across our business, from how we design our platform to how we measure and manage our environmental impact.

## Compliance certifications and standards

We adhere to key industry certifications and standards to ensure high levels of security, reliability, and operational integrity. Our compliance reflects our commitment to transparency, data protection, and continuous improvement. In addition to mandatory requirements, we voluntarily align with recognized sustainability and governance frameworks.

### PCI Level 1

### HIPAA

### SOC 2 - Type 2

### IBM Cloud for Financial Services validation

### ISO 27001

### B Corp

### Ecovadis

### United Nations Global Compact

## IaaS provider partners

Learn more about our partner certifications.

- AWS
- OVHcloud
- Google Cloud
- Microsoft Azure
- IBM Cloud

### [Cloud Data Privacy | Upsun Trust Center](https://upsun.com/trust-center/privacy)

# Privacy

At Upsun, supporting our customers as they navigate global privacy requirements is built into how we operate. We understand that protecting personal data is not just a responsibility, it’s a shared commitment. Our services are designed with data protection and privacy in mind, offering robust technical and organizational measures to help you meet your regulatory obligations with confidence.

Privacy

Cloud Data Privacy | Upsun Trust Center

Learn about cloud data privacy at Upsun, the PaaS that cares about its customers and strives to be good, transparent custodians of their important data.

## Documentation

## Trust

### Information security frameworks

[SOC2](/trust-center/security/soc2/), [PCI](/trust-center/security/pci/), ISO27001

### HIPAA

Learn about Upsun's [HIPAA-compliant cloud hosting](/trust-center/privacy/hipaa/)

## Personal data processing

## Compliance

### What steps has Upsun taken to comply with different data protection laws (GDPR, CCPA/CPRA, PIPEDA, APA, HIPAA)?

We operate a comprehensive Data Protection program that applies to all subsidiaries processing personal data. Our program establishes essential business requirements covering transparency, security, data governance, privacy by design, and third‑party supplier management.

To support this, we have dedicated security and risk teams made up of qualified subject matter experts. A privacy by design approach is embedded into our change management processes, ensuring that all new services and changes to existing processes are subject to appropriate review and that risks are addressed on time.

Our personnel play a key role in protecting data. All employees, including contractors, are subject to confidentiality obligations under their contracts. In addition, they receive mandatory data protection training upon hire and on an annual basis thereafter. This training enables staff to identify and manage security and data protection risks in day‑to‑day operations as well as during the design and development of products, systems, and processes.

When transferring personal data outside the European Economic Area, we generally rely on the EU Standard Contractual Clauses (SCCs) where no adequacy decision exists. Data transfers between our group entities are further governed by an intragroup data sharing agreement, which incorporates the EU SCCs and requires implementation of consistent data protection and information security measures across all our entities.

Oversight of these activities is provided by our appointed Data Protection Officer, who ensures compliance with data protection obligations and promotes best practices across the organization.

### What is your role under data protection laws?

We act as a data processor or sub-processor on behalf of our customers (or equivalent roles defined differently). This means we only process personal data in accordance with our customers' instructions and applicable data protection regulations.  We do not access or use customer data for our own purposes, and processing is strictly limited to fulfilling our role as a processor or sub-processor.

We are a Controller for the overall PaaS service and our Infrastructure Control Plane when we use information to establish and operate regions, provision services, networks, account management and billing. Please see our Privacy Notice for more information.

### Where is data stored and hosted?

Customer data is stored in highly secure data centers hosted by leading providers such as AWS and Azure,GCP. We offer region-specific storage (e.g., EU-only).

If you create a project in a specific region, data from that project never leaves your chosen region unless you intentionally request an additional dedicated cluster in a different location.

Data leaves this storage only when you initiate a backup (to a location where the region itself is) or during disaster recovery backups (which use the same storage principle).

### What subprocessors do you use?

We maintain a current list of subprocessors, including the services they provide and their geographic locations. Customers receive advance notice of changes and may object in accordance with the terms of our DPA.

### What happens to customer data when the engagement ends?

Upon termination, all data is securely deleted in accordance with our documented retention and deletion policies, unless otherwise agreed in writing.

### What type of personal data processing do you perform?

Upsun provides the project environment and stores the customer content as part of its service offering. The categories of personal data processed by Upsun are determined solely by the customer and are dependent on the data that the Customer uploads, transmits, or otherwise makes available on or through the services. Upsun does not determine the nature, scope, or purpose of the data uploaded by the Customer.

As a Platform as a Service provider, we process personal data primarily in support of our customers' applications. This includes:

-   Hosting and storing personal data within customer-deployed applications
-   Enabling secure transmission of data between systems
-   Logging and monitoring for operational and security purposes 
-   Supporting customer requests and debugging issues.

### Do you adhere to any information security frameworks?

Yes, We undergo an annual ISO 27001, SOC 2 Type ΙΙ and PCI DSS Level audit over Security, Privacy, and Availability.

Upsun is also US Data Privacy Framework self-certified. Our DPF Notice is available here.

### Does Upsun have a due diligence process when utilising the services of third party suppliers that process, store or transmit personal data?

We have established a Supplier Management Team to conduct thorough due diligence on all suppliers. Prior to engagement, suppliers undergo both data protection and information security assessments to ensure compliance with our standards. Where appropriate, we enter into Data Processing Agreements with suppliers, and we require them to cascade equivalent obligations to their own third‑party suppliers.

### How do you handle data breaches?

We maintain a comprehensive Incident Response Plan that complies with applicable data protection requirements. In the event of a personal data breach, our internal response team follows a structured protocol to contain the incident, investigate its root cause, assess potential impacts, and carry out any required notifications. Following resolution, we conduct post‑incident reviews to capture lessons learned and implement corrective measures to help prevent recurrence.

### What Technical and Organizational measures Upsun implements to protect personal data?

We implement technical and organizational measures to support compliance with data protection laws, as those measures described in our DPA, and our security page.

### How does Upsun help customers meet their data protection obligations?

We help our customers address compliance challenges every day by securing the underlying platform and infrastructure. This allows customers to focus on developing and managing their applications, while maintaining responsibility for application-level data protection and user access controls.

We enable customers to select the geographic region (such as a specific country or multi-region area) for storing application data at rest. This ensures that data remains within the desired jurisdiction, helping our customers meet legal and regulatory requirements.

For customers interested in running HIPAA projects, please see our information about HIPAA compliance

### [Security | Upsun Trust Center](https://upsun.com/trust-center/security)

# Security

Upsun lets you deliver amazing digital experiences, while helping to keep your site safe and secure with top-tier cloud security governance. We remove the headache of security updates and allow you to focus on developing world-class applications. Now you can navigate through changing requirements and updates as we work to protect your applications from cyberattacks.

Security

Security | Upsun Trust Center

Cloud security governance is taken seriously on Upsun. Navigate through changing requirements and updates as we protect you from cyberattacks.

### Data security

We work to ensure our products and services maintain compliance with several standards related to data privacy and security in order to help our customers secure their services and meet their own security and compliance requirements.

### Security assurance plan

This document describes the provisions in terms of information system security that Upsun undertakes to implement to meet the customer's security requirements.

## Client Security Guidance

Ensuring a service provider meets your security and compliance requirements can be difficult. To help make our customers' lives a little easier, we’ve gathered answers to some of the most common security and compliance questions below.

### [Reliability | Upsun Trust Center](https://upsun.com/trust-center/reliability)

# Reliability

Over 5,000 organizations work with Upsun, and they can all rely on a foundation of cloud security standards and vital security practices that work seamlessly to protect their personal information and sensitive data at scale.

Reliability

Reliability | Upsun Trust Center

Organizations that work with Upsun can depend on a bedrock of vital cloud security standards and practices that work seamlessly to protect personal data.

## Confidentiality

### Certifications

Upsun is compliant with major security, privacy, and information security frameworks. We undergo an annual  ISO 27001, SOC 2 Type ΙΙ and PCI DSS Level audit over Security, Privacy, and Availability for our regions hosted on Amazon Web Services, Microsoft Azure, and Google Cloud Platform.

### Encryption

All customer application data in transit is encrypted by default. Plus, we only access data internally for support reasons at the customer’s request, or to fix or prevent an outage. We also maintain a list of Upsun  employees with access to customer data, which is reviewed monthly.

## Integrity

### Automatic backups

Automatic backups can be set up on customer projects to prevent data loss.

### Internal logging and monitoring

We log and monitor access and are alerted when potential threats to our containment model have been discovered.

### Automatic updates

Upsun regularly updates its container images for the latest security updates from upstream providers. Don't worry, these updates aren't pushed automatically. Instead, the latest available version of every requested container is loaded on each deploy to a given environment. So, after a deployment, you are always guaranteed to run the latest version of a container.

### Access control and audits

We automate and centralize our access control management and apply the principle of least privilege. Additionally, we audit our own access control lists monthly as a safeguard.

## Availability

### Up to 99.99% uptime

We understand even the slightest outage can have an incredible impact on business. Upsun  provides everything you need to keep your applications and websites up and running through the use of our effective automated support system, backups, byte-for-byte clones of production environments, and an optional SLA of up to 99.99% uptime, so you can consistently give your audience the best digital experience possible, without sacrificing security.

### Auto-scaling and DDos protection

Developers can leverage our built-in reverse proxy cache, TLS encryption on all connections, and optional Distributed Denial of Service prevention. And our orchestration system can automatically increase the resources of your production environment in minutes, so your apps and sites remain available even under the most stressful of traffic surges.

### [Legal Information | Upsun Trust Center](https://upsun.com/trust-center/legal)

# Legal

Everything you need on our service terms, ethics, and other legal policies and documentation.

Legal

Legal Information | Upsun Trust Center

Everything about service terms, policies, intellectual property, accessibility, environmental statement, and abuse and transparency reports on Upsun

## Terms of service

## Other

### [Data Security - Trust Center | Upsun](https://upsun.com/trust-center/security/data-security/)

# Data Security

Upsun lets you deliver amazing digital experiences, while keeping your site safe, secure, and available—24x7. Now you can navigate through changing requirements and updates as you’re protected against cyberattacks.

Data Security - Trust Center | Upsun

Data security and governance is taken seriously at Upsun. We’re compliant with the many data regulations including European GDPR, German BDSG, and more.

## Data privacy in today's world

Upsun takes data security and governance seriously. We've demonstrated our commitment to data security by undergoing an annual ISO27001, SOC 2 Type 2 examination over Security, Privacy and Availability, and by achieving PCI DSS Level 1 compliance for our platform hosted on Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). When you use Upsun, you can:

Know that your security comes first in everything we do. We promptly notify you if we detect a breach of security. And we will never sell your data.

Control what happens to your data. You can access it or take it out at any time.

Know where your data is stored and rely on it being available when you need it. You define where your data is stored. We operate our service from multiple data centers with strong security practices that are independently validated by third-party auditors.

Be confident knowing that customer data is not used for advertising. You own your data. We don't process your data for advertising purposes.

Be reassured that our regular infrastructure vulnerability scans and penetration tests will keep our service secure.

## We keep your data private and safe

### Cryptography and user security

All of our sites adhere to our cryptographic controls policy, which mandates the use of strong, industry-standard cryptographic measures. These measures include TLS for data in transit, encrypted disks, and support for 2FA.

### Auto-redundant architecture

Our Dedicated offering comes with automated triple redundancy for every element of your stack, as well as automated full-cluster backups.

### Security updates and stack management

Upsun provides security updates for every element of the stack as soon as they’re available—without service interruption.

### Permissions and access management

Retain tight control and governance over user access via fine-grained, per-environment permissions.

### Project and data isolation

Each project runs in isolation, with the most minimal network surface possible. Every service is network isolated from other services.

### Global managed CDN

Upsun makes it easier to integrate your application with a CDN versus configuring all the CDN/cloud bits yourself.

## Security updates and stack management

We keep your services secure, so your team can focus on building cool stuff. Upsun takes over the activities needed to manage the stack and perform infrastructure security updates saving you time, frustration, and money. So you can focus your efforts on building and maintaining world-class applications.

### Instant and global updates

No more outdated software and libraries. Our seamless infrastructure rollouts enable you to stay current with all the latest versions. Updating your application is simply a lightning-fast redeploy away. Do it manually or automate it to fit your change windows.

### New releases as they go stable

We follow a strict testing procedure for every release of new versions of runtimes and stack components.

### Git-driven architecture

Every change to your infrastructure configuration is versioned and auditable, so you can have peace of mind.

### Immutable architecture

Every application is deployed to a read-only file system. Any software install or change to the application is through a secure and auditable process.

### Rigorous security incident procedures

Should an infrastructure security incident occur, our dedicated security teams will provide 24/7 coverage. Engineers will be assigned and they will determine the root cause and mitigate the issue by executing our stringent incident-management process to resolution.

### 24/7 incident coverage

Should an issue arise, we have dedicated teams to provide 24/7 coverage regarding outages, configuration matters, security issues, and so on. We have drilled procedures in place so that when an alert comes in, everyone knows what to do to ensure its prompt resolution.

## Project data and isolation

Create multiple, byte-for-byte clones of production—securely and in isolation. You can clone your environments endlessly to meet your development workflows and know that these environments are isolated from all others—even your own. If your data needs to stay in a specific geographic region, you can specify where you want that to be.

### Secrets management

Limit the secrets available on a specific environment, and override each value with a test value for non-production environments.

### Geographic and project isolation

Every project is fully isolated from others. You can specify which region to host your project in, and we'll ensure that your data stays within that region.

## Permissions and access management

Safeguard confidentiality, integrity, and availability. Retain complete control and governance of your application, while giving full flexibility to your developers to build, test, and deploy new features quickly.

### Permissions per environment

Let developers freely and fearlessly create and work on test environments without worrying about changing or seeing production.

### Principle of least privilege

Permissions are set at minimum level and are managed through a central directory for terminations and audits.

### Goodbye passwords

SSH access is restricted to Public Key authentication only, ensuring only those who are supposed to log in, can.

### Reduced attack surface

Our fully automated, reproducible build chain creates microcontainers, with no extraneous packages. This helps reduce the attack surface by having only what is strictly needed for your app and nothing else.

### Two-factor authentication

Any dashboard login can be enforced through a second authentication method.

## Hardened kernel and services

We run hardened Linux Kernels. All deployed packages come from signed internal repositories. We perform internal detection, logging, and alerting of any process or activity that attempts to break our infrastructure containment model.

Upsun provides a modern, secure infrastructure to provide you with peace of mind. We lock down access to the extent possible, while allowing you to specify your services and routes.

### Rootless operations

Operations are performed without using root and are fully automated. All operations are logged.

### Restrictive firewall

Our infrastructure employs both security groups and iptables firewalls. Only HTTP/S and SSH are allowed in. Services run in full network isolation. You specify the routes your application needs.

### Restricted access

SSH access is controlled per environment. All users are unprivileged.

### Read-only filesystem

When deployed on Upsun, user code is read-only so no unwanted changes can be made.

## Multitier, secure, global managed CDN

Performance, security, and protection. We work with you to apply the best caching strategy to optimize your application performance, uptime, and costs—without compromising security. Our Enterprise offering gives you a solid foundation of vital security measures to protect your customers' personal information and other sensitive data.

### DDoS mitigation

The CDN provides Distributed Denial of Service prevention.

### Modern features

Your developers will love our additional modern features, like a built-in reverse proxy cache and TLS encryption on all connections.

### 99.99% uptime guarantee

This extends to the worldwide cache layer, so you can consistently deliver the best digital experience to your audiences.

## Trust Center Documents

### [Hipaa Compliance | Upsun](https://upsun.com/trust-center/privacy/hipaa/)

Please refer to our Compliance Guidance page for an overview of our HIPAA-compliant cloud hosting and overall compliance program, including security & compensating controls, and a general allocation of responsibility.

### **Overview**

Upsun provides a Platform as a Service (PaaS) solution that our customers may use for applications requiring HIPAA compliance. All HIPAA workloads will run on the US-4 region.

Upsun has SOC 2 Type 2 and PCI certifications. As a part of those third-party audits, we have been audited on overlapping HIPAA controls. Independent third-party audits provide an external examination of the controls we have implemented on our infrastructure and operations and ensure Upsun’s commitment to complying with information security standards and industry best practices.

**Please note that there is no certification recognized by the US Department of Health & Human Services for HIPAA compliance. Thus, complying with HIPAA is a shared responsibility between the customer and Platform.sh.**

### **Responsibility**

Customers who want to run healthcare workloads on Platform.sh must agree to the following:

-   The Customer must sign a Business Associate Agreement with Platform.sh.
-   The Customer implements the relevant controls contained in the Upsun HIPAA Shared Responsibility Matrix (Excel). This document provides guidance on shared responsibilities required to achieve HIPAA compliance.
-   The Customer is solely responsible for any of its applications’ security.
-   The Customer must run HIPAA workloads on the HIPAA designated region and is responsible for managing access to all environments that are included in the HIPAA designated region.
-   The Customer must use Fastly WAF or a Upsun-approved equivalent HIPAA-compliant WAF.
-   The Customer will perform, at a minimum on an annual basis, penetration testing and vulnerability scanning against their projects in accordance with industry standards, and will remediate findings in an expedited manner.
-   The Customer need to redeploy applications regularly to be able to pick up patches.

While Upsun provides a secure and compliant infrastructure for HIPAA projects, the customer is responsible for ensuring that the environment and applications that they host on Upsun are properly configured and secured according to HIPAA requirements. Failure to do so results in a non-compliant customer environment.

Customers can contact their Upsun Account Manager to request a Business Associate Agreement or for more information regarding our HIPAA offering.

### [ISO 27001 compliance and certification | Upsun](https://upsun.com/trust-center/security/iso27001/)

ISO/IEC 27001:2022 is the world's leading standard for Information Security Management Systems (ISMS). It provides a systematic framework for managing and protecting sensitive information assets through comprehensive security controls and risk management processes.

Upsun has achieved accredited ISO 27001:2022 certification, demonstrating our commitment to maintaining the highest standards of information security. This globally recognised certification validates that we have implemented robust security controls to protect customer data and ensure service reliability. It reflects our dedication to continuous improvement and our proactive approach to maintaining trust and compliance in an evolving digital landscape.

Our certification was independently verified by Risk3sixty, an accredited third-party auditor, confirming that our security management processes meet the rigorous requirements of ISO 27001:2022.

**Resources**

To access the Upsun ISO 27001:2022 certification, visit the links below:

-   Risk3sixty ISO Certificate Directory
-   IAF CertSearch

### [Responsible Disclosure Program | Upsun](https://upsun.com/trust-center/security/responsible-disclosure/)

Upsun is a Platform-as-a-Service where customers can host their applications and make them available to the world without worrying about the "how". 

At Upsun, we take the security of our platform seriously. We appreciate the work of security researchers and welcome responsible disclosure that helps us protect our customers and our infrastructure.

This Vulnerability Disclosure Program (VDP) is not a public bug bounty program

### Program Overview

Our goal is to give security researchers a clear, simple and safe way to report vulnerabilities affecting Upsun or Blackfire.  
This program allows you to responsibly disclose potential vulnerabilities without fear of legal consequences, provided you follow our guidelines.

### Program Guidelines

When testing or reporting, you must:

-   Avoid affecting our users, systems or data. No service disruption, no degradation, no privacy violations
-   Only test using your own accounts, or accounts where you have explicit permission
-   Use our official reporting channel (security.txt)
-   Keep all findings confidential for 90 days or until we complete remediation
-   Coordinate any public disclosure with us

If you follow these rules, we commit to:

-   Providing you with Safe Harbor protections
-   Working with you to validate and remediate legitimate issues
-   High-quality, high-impact submissions may lead to an invitation to our private HackerOne program

### Program Scope

#### In scope

The following assets operated directly by Upsun, Platform.sh or Blackfire:

-   \*.upsun.com (one subdomain level)
-   \*.platform.sh (one subdomain level)
-   Blackfire dashboards and the Blackfire agent  
     

If the domain contains more than one subdomain level, it is almost certainly a customer application and out of scope.

Examples:

-   eu.platformsh.site  in scope
-   foo.eu.platformsh.site out of scope (customer)

#### Out of scope

The following are always out of scope:

##### **1\. Customer applications**

Upsun operates as a PaaS where customers can host their applications and leverage our tooling to enhance their productivity.

According to our shared responsibility model, customers are responsible for the security of their applications so customer applications will always be out of scope for the purpose of this program.

##### **2\. Third-party platforms we use**

Examples include:

-   Drift
-   Stripe
-   Slack
-   Zendesk
-   Disqus
-   Google Tag Manager
-   fonts.googleapis.com
-   cdn.jsdelivr.net  
     

Research against those vendors should be reported directly to them.

##### **3\. Core Ineligible Findings**

Including but not limited to:

-   Reports without a demonstrated real-world security impact
-   Missing headers (X-Frame-Options, CSP, etc.)
-   SPF/DMARC/DKIM configuration issues
-   TLS/SSH configuration or cipher suite “weaknesses”
-   Clickjacking without an actual exploit
-   Version disclosures, outdated libraries without exploitation
-   Low-impact CSRF (non-sensitive actions), self-XSS
-   Rate limiting tests or noisy scanning
-   DoS, DDoS, or any volume-based testing
-   Social engineering, phishing, physical security issues  
     

Full reference: _HackerOne Core Ineligible Findings_

**We do not process these reports and they will never result in a reward or invitation.**

### **Report Structure**

When submitting a report, please include:

1.  **Summary**  
    Clear explanation of the issue  
     
2.  **Steps to Reproduce / PoC**  
    Enough detail to validate the vulnerability  
     
3.  **Impact**  
    Real-world impact demonstrating how security properties can be meaningfully compromised  
     

Please do not include real data samples such as PII, cardholder data or other sensitive information. Provide only the information needed for validation.

We strongly discourage the excessive or uncritical use of LLMs to generate reports.

Low-effort AI-generated reports will be rejected immediately and will not result in an invitation to our private program.

If you use an LLM, ensure the content is accurate, concise and validated manually

### How to submit

Please submit all reports through the contact listed in our security.txt file:

Before reporting, double-check:

-   The asset is in scope
-   The vulnerability has real security impact
-   You can provide a clear PoC
-   It is not covered under the out-of-scope section above

Low-impact or purely theoretical issues will not be accepted.

### **Private Bug Bounty Program** 

We maintain a private bug bounty program on HackerOne.  
It is invitation-only and focused on impactful vulnerabilities.

If you believe your expertise could be valuable, feel free to include your HackerOne username  
Researchers who demonstrate strong signal, quality and impact may receive an invitation.

We appreciate the time and effort researchers invest in helping us secure Upsun.

Your responsible disclosure helps protect our users, our platform, and the broader ecosystem.

### [Anti-Bribery Policy | Upsun](https://upsun.com/trust-center/legal/anti-bribery-policy/)

## 1.Purpose

Upsun (‘the Company’) is committed to responsible corporate conduct and full compliance with anti-corruption laws, including the UK Bribery Act, the French Sapin II Law, and the U.S. FCPA. The company upholds a strong anti-corruption culture, prohibiting all forms of bribery or corrupt payments by employees or representatives.

## 2\. Bribery

2.1. Bribery (Offering or Promising):

-   Involves offering or promising money or other benefits.
-   Intended to cause someone to perform their duties improperly or reward them for doing so.
-   Acceptance of such an advantage can itself be considered improper. The offer doesn’t need to be accepted or acted upon; the intent alone is sufficient.

2.2. Bribery (Requesting or Receiving):

-   Occurs when someone requests or agrees to receive a benefit.
-   The benefit is meant to influence them to misbehave, or they anticipate it and act accordingly.
-   The act of accepting such a benefit may itself be improper conduct.

2.3. Bribery of a Foreign Official:

-   Involves offering or promising a benefit to influence a foreign official.
-   Done with the intent of gaining business or a business advantage.
-   Only allowed if the official is legally permitted or required to be influenced by such benefits.

## 3\. Consequences of bribery

3.1. For employees, contractors, or other collaborators of the Company, failure to comply with this Policy and other laws may result in:

3.1.1. disciplinary action, which may include dismissal;   
3.1.2. criminal penalties; and   
3.1.3. fines.

3.2. For the Company, any breach of this Policy by any employee, contractor, collaborator, or other business associate may result in:

3.2.1. The Company being deemed to be in violation of law and potentially subject to fines; and

3.2.2. the Company suffering negative publicity and further associated damage as a result of such breach.

## 4\. Responsibility for Compliance and Scope of Policy

4.1. This Policy applies to all employees, agents, contractors, subcontractors, consultants, business partners, and any other parties (including individuals, partnerships, and corporate bodies) associated with the Company or any of its subsidiaries.

4.2. It is the responsibility of all of the above-mentioned parties to ensure that bribery is prevented, detected, and reported. All such reports should be made in accordance with the Company’s Complaint Policy or as otherwise stated in this Policy, as appropriate.

4.3. No party described in section 4.1 may:

4.3.1. Give or offer money or anything of value to someone (directly or through someone else) on the Company’s behalf if the goal is to make them do something improperly, reward them for doing so, or if accepting it would be considered improper.

4.3.2. Ask for or agree to accept money or anything of value from someone if it's meant to make you do something improperly, if accepting it would be considered improper, or if you plan to act improperly because you expect to receive it.

4.4. Parties described in section 4.1 must:

4.4.1. be aware and alert at all times of all bribery risks as described in this Policy, and in particular, as set out in section 9 below;

4.4.2. exercise due diligence at all times when dealing with third-parties on behalf of the Company; and

4.4.3. report any and all concerns relating to bribery to their direct Manager or, in the case of non-employees, their normal point of contact within the Company, or otherwise in accordance with the Company’s Complaint Policy.

## 5\. Facilitation Payments

5.1. A facilitation payment is defined as a small payment made to officials in order to ensure or speed up the performance of routine or necessary functions.

5.2. Facilitation payments constitute bribes and may not be made at any time irrespective of prevailing business customs in certain territories.

## 6\. Gifts and Hospitality

6.1. Gifts and hospitality remain a legitimate part of conducting business.

6.2.Gifts and hospitality can, when excessive, constitute a bribe and/or a conflict of interest. Care and due diligence should be exercised at all times when giving or receiving any form of gift or hospitality on behalf of the Company.

6.3. The following general principles apply:

6.3.1. Gifts and hospitality may neither be given nor received as rewards, inducements, or encouragement for preferential treatment (including influence a business decision) or inappropriate or dishonest conduct.

6.3.2. Cash should be neither given nor received as a gift under any circumstances.

6.3.3. Gifts and hospitality to or from relevant parties should be generally avoided at the time of contracts being tendered or awarded.

6.3.4. The value of any gift or hospitality, whether given or received, should match the situation and not be unusually high or generous compared to what’s normal in our industry.

6.3.5. Some gifts that normally break this Policy may be accepted if refusing them would cause serious or cultural offense. In such cases, the Company will donate the gifts to charity.

6.3.6. All gifts and hospitality, whether given or received, must be recorded in writing by the Company.

## 7\. Partisan Donations

7.1. The Company doesn’t make political donations or support parties, candidates, or campaigns—directly or indirectly—without written approval from the Compliance Officer or General Counsel.

## 8\. Due Diligence and Risks

8.1. The following issues should be considered with care in any and all transactions, dealings with officials, and other business matters concerning third parties:

8.1.1. territorial risks, particularly the prevalence of bribery and corruption in a particular country;

8.1.2. cross-border payments, particularly those involving territories falling under section 8.1.1.;

8.1.3. requests for cash payment, payment through intermediaries or other unusual methods of payment;

8.1.4. activities requiring the Company and/or any associated party to obtain permits or other forms of official authorization;

8.1.5. transactions involving the import or export of goods.

## 9\. Point of Contact

9.1   The Chief People Officer and Chief Financial Officer are responsible for enforcing this Anti-Bribery Policy. If you have any questions about bribery-related issues, they are your main contacts.

9.2  The Chief People Officer can help with questions about workplace ethics, and the Chief Financial Officer can answer questions about financial matters and compliance. Employees are encouraged to talk to them to help maintain high ethical standards.

### [DMCA Takedown Policy | Upsun](https://upsun.com/trust-center/legal/dmca/)

## **Introduction**

Upsun provides a Platform-as-a-Service (PaaS) that allows users to deploy, manage, and operate applications and services using our infrastructure. Upsun respects intellectual property rights and complies with the Digital Millennium Copyright Act (DMCA). In accordance with the DMCA,  we have implemented this policy to address claims of copyright infringement related to content hosted or transmitted through our platform. This policy explains how copyright owners can report alleged infringements and how users can respond with a counter-notice if they believe the removal was a mistake or misidentification.

The DMCA is a U.S. law that provides a process for copyright holders to request the removal of infringing content from websites and internet services. It also protects service providers like Upsun from liability when they promptly respond to valid takedown requests and provide users with an opportunity to respond.

Just as we require users to respect others' rights, we respect the rights of users to challenge takedown notices and assert their own lawful use of content (such as through fair use, parody, commentary, or other exceptions).

We believe the DMCA process should balance the rights of creators and users, and we commit to handling takedown and counter-notice claims transparently and fairly.

## **What Is the DMCA Process?**

The DMCA process includes three key parts:

1\. A copyright owner (or authorized agent) submits a written takedown notice if they believe their work has been used without permission.

2\. The service provider (like Upsun) reviews the request and, if not manifestly abusive disables access to the content or removes it.

3\. The affected user has the right to submit a counter-notice if they believe the takedown was made in error or their use is protected by law.

If the copyright owner does not initiate legal action within 10 business days after receiving a counter-notice, the service provider may restore the suspended content.

## **Our Principles Regarding DMCA Takedowns**

 We follow the requirements of the DMCA and comply with complete and not manifestly abusive takedown notices.

We notify users when their content is suspended or removed due to a takedown request.

We give users the opportunity to respond with a counter-notice.

We may share takedown notices and counter-notices publicly for transparency (e.g., via Lumen Database).

We may reject notices that are incomplete, overly broad, or appear to misuse the DMCA process.

## **How to Submit a DMCA Takedown Notice**

If you believe content hosted on upsun.com infringes your copyright, you must submit a notice that includes all of the following:

1\. Identification of the copyrighted work you claim has been infringed (or a list).

2\. Identification of the allegedly infringing material, including URLs or descriptions to locate it.

3\. Your contact information – full name, address, phone number, and email.

4\. The following two statements:

-    “I have a good faith belief that the use of the material in the manner complained of is not authorized by the copyright owner, its agent, or the law.”
-   “I swear, under penalty of perjury, that the information in this notification is accurate and that I am the copyright owner or am authorized to act on behalf of the owner.”

5\. Your physical or electronic signature.

Send your complete notice to our designated agent: 

Platform.sh Operations and Security Team  
Platform.sh SAS doing business as Upsun  
22 rue de Palestro  
Paris,  75002   
France  
Email: abuse@upsun.com

Information on our designated agent can also be found here : https://dmca.copyright.gov/dmca/search.html 

Please note that incomplete notices may be ignored. 

## **What Happens After We Receive a Notice?**

If the notice is complete and not manifestly abusive, we will remove or disable access to the User’s project containing the identified infringing content.

We will notify the user who posted the content and give them a chance to respond.

If a counter-notification is submitted, and you do not file legal action within 10 business days, we may restore the content.

## **Submitting a Counter-Notification**

If you believe content was removed in error, you may submit a counter-notice including:

1\. Identification of the content and its location prior to removal.

2\. A statement under penalty of perjury that you believe the removal was a mistake or misidentification.

3\. Your full name, address, and phone number, and a statement that you consent to the jurisdiction of the U.S. Federal District Court in your district (or any district where Upsun may be found if outside the U.S.).

4\. A statement that you will accept service of process from the original complainant or their agent.

5\. Your physical or electronic signature.

Send the counter-notice to the same designated agent listed above.

## **Repeat Infringer Policy**

We may suspend or terminate accounts of users who are repeat infringers, in accordance with the DMCA.

## **Abuse of the DMCA**

The DMCA is a legal process. Submitting false claims or misusing the process can have serious legal consequences, including potential damages and attorney’s fees under 17 U.S.C. § 512(f). Please consider seeking legal advice before submitting a takedown or counter-notice.

## **Questions?**

We’re committed to a fair, lawful, and transparent DMCA process. If you have questions about how it works or how to submit a request, contact us at legal@upsun.com.

### [Data Collection Information | Upsun](https://upsun.com/trust-center/security/data-collection/)

Information about data privacy, including our Record of Processing Activities, can be found at our Privacy page.

### **Application logs**

Application logs are those generated by the host application or application server (such as PHP-FPM). These logs are immutable to Customers to prevent tampering. They are also secured behind key-based SSH so that only the Customer and our relevant teams have access.

### **System logs**

Upsun records routine system logs. We do not access Customer-specific system logs or the customer environment unless one of the following situations applies:

1.  we are requested to do so by the Customer,
2.  to fix a problem or outage,
3.  to prevent an outage, or
4.  to comply with a legal obligation.

### **Access logs**

There are two main types of access logs: Web and SSH.

#### Web access logs

Application access logs are immutable to Customers to prevent tampering. These logs are secured behind key-based SSH so that only the Customer and our relevant teams have access.

#### SSH access logs

SSH access logs are securely stored in our infrastructure and aren’t accessible to Customers. These logs can be accessed by Upsun support personnel as part of an audit, if requested.

Access by Customers and Upsun support personnel to customer environments is logged. However, to protect Customer privacy, we only log the connection itself, not what was done during the session.

### [Cookie Notice | Upsun](https://upsun.com/trust-center/privacy/cookie-notice/)

Cookies are small data files stored on your computer or mobile device. They help us personalize your experience and make your future visits to our site easier. We use both first-party cookies (set by us) and third-party cookies (set by trusted partners). Third-party cookies may be used to build a profile of your interests and display relevant ads on other websites. When you visit our site, cookies may be downloaded to your device. You can choose to:

-   Accept all cookies
-   Accept only certain types
-   Reject all cookies.

Examples of Cookies we use:

**UTM Tags and How We Use Them**

UTM (Urchin Tracking Module) tags are not the same as cookies. Instead, they are parameters added to the end of a URL to help track the effectiveness of marketing campaigns. These tags allow us to see which specific links or campaigns brought users to our site.

UTM data is visible in tools like Google Analytics and Marketo. It helps us understand how users are finding our website and which marketing efforts are performing best. This information is collected in aggregate and does not identify you personally.

As part of this tracking, non-identifiable information such as the traffic source, medium, campaign name, and click ID may be stored in your browser's local storage. This helps us analyze and improve our marketing efforts so we can better serve you and our audience.

You can change your cookies preferences on your web browser control or in our dashboard.

### [Vulnerability scanning and penetration testing | Upsun](https://upsun.com/trust-center/security/penetration-testing/)

Upsun understands the need for application owners to ensure the integrity, and standards compliance, of their applications. Because there could be adverse impacts to other clients which would violate our terms of service, we only permit certain types of tests.

Currently, we do not offer the possibility to activate/deactivate the Intrusion Prevention System (IPS) on demand. On Upsun’s side, there is no automatic IP or range blocking. Blocking IP’s (or not) is usually left to the appreciation of the on-call engineer based on the specific circumstances.

### **Approved Activities**

-   Vulnerability scanning of your web application. You are free to perform this as often as required without approval from Upsun.
-   Web application penetration tests that don’t result in high network load. You are free to perform this as often as required without approval from Upsun.
-   Application level load testing that don’t result in high network load. If the load test may result in the application to be down, we ask to open an urgent ticket as a courtesy 30 to 60 minutes before the load test begins. Typically application level load tests will trigger one or many NodePing alerts. Knowing that a load test is in progress will allow the on-call engineer to immediately snooze alerts.

### **Approved Activities by Prior Arrangement**

-   For Dedicated customers, we do permit infrastructure penetration testing (but not load testing) by prior arrangement. This requires special advanced preparation. You must submit a support ticket request a minimum of **three (3) weeks** in advance for us to coordinate this on your behalf.

### **Prohibited Activities**

-   Vulnerability scanning of web applications which you do not own.
-   Denial of Service tests and any other type of load testing which results in heavy network load.
-   Social engineering tests of Upsun services including falsely representing yourself as a Upsun employee.
-   Infrastructure penetration tests for non-Dedicated customers. This includes SSH and database testing.

### **Rate Limits**

-   Please limit scans to a maximum of 20 Mb per second and 50 requests per second to prevent triggering denial of service bans.

### **Troubleshooting**

If your vulnerability scanning suggests there may be an issue with Upsun's service, please ensure your container is updated and retest. If the problem remains, please contact support.

### [Data Location Information | Upsun](https://upsun.com/trust-center/security/data-location/)

### **When project data leaves a region**

If you create a project in a specific region, data from that project never leaves your chosen region unless you intentionally request an additional dedicated cluster in a different location.

Technically, each region has separate data storage. Data leaves this storage only when you initiate a backup (to a location where the region itself is) or during disaster recovery backups (which use the same storage principle).

### **Backups**

Backups stay in the same region as the project itself.

### **Access logs**

Access logs (such as web and SSH logs) are sent outside of the region to a collection point inside the EU. This is done to ensure that logs are available should the region be affected by availability or integrity issues. Upsun also uses the logs for security analysis.

### [Encryption | Upsun](https://upsun.com/trust-center/security/encryption/)

### **Data in transit**

Data in transit between the World and Upsun always encrypted as all of the sites and tools which Upsun supports and maintains require TLS or SSH to access. This includes the Upsun Console, Accounts site, git repositories, documentation, and help desk.

Data in transit between the world and customer applications is encrypted by default. Only SSH and HTTPS connections are generally accepted, with HTTP requests redirected to HTTPS. Users may opt-out of that redirect and accept HTTP requests via `routes.yaml` configuration, although that isn’t recommended. By default HTTPS connections use an automatically generated Let’s Encrypt certificate or users may provide their own TLS certificate.

Data in transit on Upsun controlled networks (for example, between the application and a database) may or may not be encrypted, but is nonetheless protected by private networking rules.

### **Data at rest**

All application data is encrypted at rest by default using encrypted ephemeral storage (typically using an AES-256 block cipher). Some Dedicated Gen 2 clusters and the `FR-3` region do not have full encryption at rest.

If you have specific audit requirements surrounding data at rest encryption, please contact support.

### [Strong customer authentication | Upsun](https://upsun.com/trust-center/security/sca/)

In accordance with Article 14(1) of the Commission Delegated Regulation (EU) 2018/389, Upsun has implemented strong customer authentication (SCA) for customers using payment methods from the EU.

The article states:

> _Payment service providers shall apply strong customer authentication when a payer creates, amends, or initiates for the first time, a series of recurring transactions with the same amount and with the same payee._

SCA is part of the Revised Payment Services Directive, acting as a regulatory requirement to reduce fraud and to make online transactions more secure.

The law went into effect September 14, 2019, and European card holders have been required since October 1, 2019 to authenticate recurring payments with their payment institutions.

### [Data Access Information | Upsun](https://upsun.com/trust-center/security/data-access/)

We ensure Customer data is protected by limiting internal access and preventing unauthorized access by implementing security measures such as encryption of data in transport and at rest. We only access data internally for support reasons at the Customer’s request, or to fix or prevent an outage. Additionally, we maintain a list of Upsun employees with access to customer data, which is reviewed monthly.

### **Data Disclosure**

We do not disclose Customer data to third parties unless legally obligated to do so under certain circumstances such as a law enforcement request.

### [Data Breach Notifications | Upsun](https://upsun.com/trust-center/security/data-breach-notifications/)

If a data breach occurs, we will execute a breach notification and response process in accordance with our Data Breach Policy.

As part of this process, we will prepare a data breach notification with as much detail as possible, such as the nature of the data breach, possible consequences, and the measures we are taking to deal with the breach.

You can have an email address other than the one connected to your Account be notified of a data breach. Make sure that the “Security Contact” field in your Account Settings has the email address you want to receive data breach notifications.

Once the data breach notification is ready and approved internally, in accordance with our Data Breach Policy, we will open a Zendesk ticket against the project that was affected by the breach and send the notification. Additionally, we will send the notification to the Security Contact email address, if provided.

### [Data Privacy Framework Notice | Upsun](https://upsun.com/trust-center/privacy/data-privacy-framework-notice/)

Platform.sh Inc. doing business as Upsun and Blackfire.io Inc., comply with the EU-U.S. Data Privacy Framework, UK Extension to the EU-US Data Privacy Framework, and the Swiss-U.S. Data Privacy Framework (collectively, the "**Data Privacy Framework**") as set forth by the U.S. Department of Commerce regarding the collection, use, and retention of personal data transferred from the European Union, and Switzerland, as applicable, to the United States in reliance on the Data Privacy Framework. Platform.sh Inc. has certified to the Department of Commerce that it adheres to the Data Privacy Framework Principles with respect to such data. If there is any conflict between the terms in this notice and the Data Privacy Framework Principles, the Data Privacy Framework Principles shall govern.

In compliance with the Data Privacy Framework, Platform.sh Inc. commits to resolve Data Privacy Framework Principles-related complaints about our collection and use of your personal information. EU, UK and Swiss individuals with inquiries or complaints regarding our handling of personal data received in reliance on the Data Privacy Framework should first contact Platform.sh Inc. at dpo@platform.sh with the subject "Data Privacy Framework". In compliance with the Data Privacy Framework, Platform.sh Inc. commits to refer unresolved complaints concerning our handling of personal data received in reliance on the Data Privacy Framework to the panel established by the EU Data Protection Authorities (DPAs), the UK Information Commissioner’s Office and the Swiss Federal Data Protection and Information Commissioner with regard to your unresolved complaint concerning our handling of your Personal Data.

If neither Platform.sh Inc.  nor the relevant panel can resolve your complaint, you may be able to invoke binding arbitration, in accordance with the Data Privacy Framework requirements, through the Data Privacy Framework Panel. For more information on this option, see Annex I of the Principles.

Platform.sh Inc. is responsible for the personal data that we receive under the Data Privacy Framework, including where we transfer such personal data to a third party acting as our agent. Please be aware that we may be required to disclose personal data that we receive under the Data Privacy Framework in response to lawful requests by public authorities, including to meet national security or law enforcement requirements. The Federal Trade Commission has jurisdiction over Platform.sh' Inc. compliance with the Data Privacy Framework. To learn more about the Data Privacy Framework program, and to view our certification, please visit the U.S. Department of Commerce's website here.

### [Law Enforcement Requests Guidelines | Upsun](https://upsun.com/trust-center/legal/law-enforcement-requests-guidelines/)

These guidelines are for law enforcement and government representatives (“Authorities”) seeking access to customer account information or personal data. They do not apply to requests from customers, their end-users, or other third parties.

## **Scope & Approach**

Upsun provides a global Platform as a Service (PaaS) in the cloud. If Authorities seek customer account data or personal data, they must follow legal procedures. Upsun only discloses personal data if required by law and after careful review. Overbroad or unjustified requests may be limited or challenged.

## **Submitting a Request**

1.Send an email to dpo@upsun.com with the subject line “Attention: Government & Law Enforcement Information Request.”

2.Alternate Submission: Requests by mail or in person should be sent to:  
22 Rue de Palestro, 75002 Paris, France.  
(Note: Mail requests take longer and submitting this way does not waive jurisdiction or service objections.)

## **Requirements for Requests**

A valid request must:

-   Be sent from an official government domain (except for mail/in-person).
-   Include enforceable legal authority (e.g., subpoena, court order, or search warrant).
-   Provide the requester’s name and contact details.
-   Clearly specify the records or data sought.
-   Supply enough detail (e.g., an account identifier) to identify the customer’s account, but only as needed.
-   Define the time period for which data is requested.

Upsun responds only to requests compliant with its Terms of Service, Privacy Policy, and applicable laws. Depending on jurisdiction, further legal process (like MLAT or letter rogatory) may be required.

## **Customer Notification**

Upsun will usually inform customers if authorities request their data unless prohibited by law. If Authorities wish to restrict customer notification, they should provide a court order or legal authority preventing Upsun from informing the customer.

If a request reveals a Terms of Service violation, Upsun may act to prevent abuse, potentially alerting the customer. To delay such action, Authorities must explicitly direct Upsun not to take action until after data production and investigation are complete.

## **Emergencies & Child Safety**

Upsun may disclose data without standard process if necessary to prevent imminent harm or serious injury, as allowed by law. All such requests are evaluated case by case. Upsun also reports child exploitation or missing children to Authorities and cooperates fully per applicable laws.

## **Data Preservation**

Authorities may request preservation of existing data for up to 90 days (unless the law requires a longer period) except where there are system limitations from our side. Preservation requests must meet these guidelines and may be subject to user notification unless barred by law or court order.

## **Cost and Timing**

Upsun may seek reimbursement for costs incurred by unusual or burdensome requests but not for emergencies or child safety matters.

Upsun aims to respond within two business weeks. Complex cases may take longer. If an urgent response is necessary, Authorities should justify that.

## **Changes**

These guidelines are reviewed periodically and may change at Upsun’s discretion.

### [Service specific terms | Upsun](https://upsun.com/trust-center/legal/service-specific-terms/)

Capitalized terms not defined in these UPSUN Service Specific Terms have the meaning given to them in the Terms of Services.

These UPSUN Service Specific Terms apply to Customers subscribing to or using the services or features listed below.

## **1\. Definitions**

1.1. “**Organization**” is a structured entity created by Customer in Customer Account to group Customer’s Projects for managing resources, access, and billing.

Organizations can be either fixed (“**Fixed Organization**”) or flexible (“**Flexible Organization**”) at Customer’s election:

1.1.1. Fixed Organization will include Project(s) operating with fixed billing plans including predetermined resource limits;

1.1.2. Flexible Organization will include Project(s) with flexible resource allocation.

## **2\. Uptime**

### 2.1. Uptime available to all Customers 

Upsun will make commercially reasonable efforts to make sure the uptime of the hosting infrastructure of Customer’s Projects on production environment reaches or exceeds 99.5% monthly. The best efforts uptime commitment mentioned above does not apply to development and test environments and is exclusive of all interruptions for maintenance purposes and incidents caused by Customer Projects (e.g. Project that exceeds the allocated resources, contains a programming error, failure to apply updates) and/or caused by failure of TLS certificates provided by Customer.

### 2.2. Advanced or Premium uptime Service Level Agreement (“SLA”) add-on

2.2.1. Advanced or Premium uptime SLAs add-ons can only be subscribed to for Projects under a Flexible Organization. Projects under a Fixed Organization can benefit from Advanced or Premium uptime SLAs under the Enterprise or Elite tier.

2.2.2. Definitions 

-   **“Monthly Uptime Percentage”** means the percentage derived by subtracting from 100 the percentage of Service Unavailability minutes during the month. 
-   **“Service Credit”** means a percentage of the Subscription Fee to be credited to Customer if Upsun fails to meet the Service Level agreed in 1.2.2 below. Service Credit is calculated based on the monthly Subscription Fee due for the environment in production suffering from the Service Unavailability status, as defined below. 
-   **“Service Levels”** means the service levels set out in 2.2.3.3. below.
-   **“Service Unavailability”** means the unavailability of the hosting infrastructure of Customer’s Projects on production environment, due either to errors or failures in the hosting stack or lack of network connectivity to the Internet. 

2.2.3. Advanced or Premium uptime SLA and Service Credits

2.2.3.1. Advanced or Premium uptime SLAs requires the subscription to the “Premium” or “Advanced” Support add-on.

2.2.3.2. Uptime SLAs are contracted at Project level. Minimum subscription term is twelve (12) months. 

2.2.3.3. Upsun will provide the following service level agreements:

2.2.4. Service Level exclusions

2.2.4.1. The Service Levels identified above do not apply to any Service Unavailability, suspension or termination of the Services caused by any of the following: 

2.2.4.1.1. Factors outside of the reasonable control of or not directly imputable to Upsun, including but not limited to any force majeure event listed in this Agreement, internet access, or related problems beyond the software and server instances directly maintained by Upsun; 

2.2.4.1.2. Problems resulting from any act or omission of Customer, including errant or problematic application code deployed into an environment; 

2.2.4.1.3. Issues resulting from Customer’s equipment, software or other technology and/or third party equipment, software or other technology (other than third-party equipment directly maintained by Upsun); 

2.2.4.1.4. Issues that affect non production environments (e.g.development and/or staging environments, etc);.

2.2.4.1.5. Services that are not essential to the uptime of the hosting infrastructure of the Project in production environment (e.g. Console, CLI, APIs for the control plane, user authentication, etc);

2.2.4.1.6. Issues that result from any act or omission of the Upsun support team at the request of Customer (e.g. downtime caused by the refusal of Customer to increase the resources allocation on a Customer Project);

2.2.4.1.7. Issues arising from suspension and/or termination of Customer’s right to use the Services in accordance with this Agreement;

2.2.4.1.8. Customer-caused unavailability such as missing content, errors caused by Customer code or application configuration errors, or usage capacity in excess of the Customer purchased amount;

2.2.4.1.9. Service Unavailability due to maintenance operations. Upsun reserves the right to interrupt part or all of the Services to perform a technical intervention for the purpose of ensuring the proper operation of the Services, and the safety and stability of the infrastructure behind the Services. Upsun will make commercially reasonable efforts to limit the occurrence and duration of the interruption and, where feasible, will publish notifications of upcoming scheduled maintenance operations on https://status.upsun.com/ at least 5 calendar days ahead of the maintenance date. Customer can also subscribe to updates and be notified by email on upcoming and ongoing maintenance operations.

2.2.4.2.When factors causing the Service Unavailability status cannot be clearly imputed to Upsun, Upsun may, on a case-by-case basis and in its sole discretion, grant Service Credits. 

2.2.4.3. Unavailability of some specific features or functions within a Project in production, while others remain available, will not constitute Service Unavailable status, so long as the affected features or functions are not, in the aggregate, material to the Project or the Services as a whole. 

2.2.5. Service Credits

2.2.5.1. Customer’s sole and exclusive remedy for any Service Unavailability, non-performance, or other failure by Upsun to provide Services is the receipt of a Service Credit. 

2.2.5.2. Service Credits will only be applied against outstanding invoice or future Subscription Fees due and will not entitle Customer to a refund or other payment; except that in the event that Customer is entitled to a Service Credit on termination of the Agreement, Upsun will refund Customer in the amount of the Service Credit within thirty (30) days of a request by the Customer to do so.

2.2.5.3. Should Upsun fail to provide Monthly Uptime Percentage of at least 97% for three (3) successive calendar months, Customer may terminate this Agreement immediately on notice to Upsun and receive a cash refund in the amount of the current Subscription Term’s prepaid Fees proportionate to the unexpired portion of the Term.

2.2.5.4. To receive a Service Credit, Customer must submit a claim by opening a support ticket prior to the end of the second month after which the incident occurred and must include: 

-   The words “Service Credit Request” in the subject line; 
-   The dates and times of each Service Unavailable incident being claimed; 
-   The affected Service Project ID; 
-   The request logs that document the errors and corroborate the claimed outage (any confidential or sensitive information in these logs should be removed or replaced with asterisks). 

2.2.5.5. If the Monthly Uptime Percentage of such a request is confirmed by Upsun and is less than the Service Level, Upsun will issue the Service Credit within one month following the month in which the request is confirmed. Failure to provide the request and other information as required above will disqualify Service Credit eligibility. 

## **3\. Support** 

### 3.1. Support available to all Customers

3.1.1. Standard support will be provided through an online service desk and on public forums.

3.1.2. Standard support does not include specific answer time commitment, but Upsun will make commercially reasonable efforts to answer Urgent (P1) tickets within 4 hours (24\*7\*365).

### 3.2. Advanced or Premium support add-ons

3.2.1. Advanced or Premium uptime SLAs add-ons can only be subscribed to by Flexible Organization. Fixed Organization can benefit from Premium or Advanced support under the Enterprise or Elite tier.

3.2.2. Advanced or Premium support is contracted at the Organization level. Minimum subscription term is twelve (12) months. 

3.2.3. Support tickets will be addressed 24/7/365 in order of the priority level and support tier.

3.2.4. Response times: Support tickets will be addressed according to the response times for the relevant support tier as set forth in the table below:

3.2.5. Regular Support Hours are as follows: from 00:00 UTC to 23:59 UTC Monday to Friday.

3.3. Procedures 

3.3.1. Login. Users will be granted access to the support ticketing and issue management system (“Support Portal”). 

3.3.2. Initiation of Support Tickets and Ticket Workflows. Tickets are initiated by the Users through the Support Portal and must be submitted separately for each Project and/or issue. They should include: 

3.3.2.1. Description of the issue or request, including identification of Supported Modules;

3.3.2.2. Description of the desired state or outcome;

3.3.2.3. Steps necessary to demonstrate or reproduce the issue;

3.3.2.4. Initial Indication of Priority Level (see descriptions of P1 Urgent, P2 High, P3 Normal in 2.4.1. below) 

3.3.3. Ticket status. Through the Support Portal, Upsun will provide updates on investigation progress and any change of status. Statuses include: 

3.3.3.1. New. Tickets not yet reviewed. 

3.3.3.2. Open. Analysis in process. 

3.3.3.3. Pending. Tickets that are awaiting feedback or other progress from Customer based on information required, or recommendations made, by Upsun. 

3.3.3.4. Scheduled / On Hold: Events that are requested or scheduled to be executed within the next 72 hours will be marked with this status and will be actioned at the requested time. 

3.3.3.5. Solved. Tickets that have reached a conclusion either through resolution of the issue or determination that no further work is warranted. 

3.4. Priority Level

3.4.1. Priority levels are defined as follows: 

3.4.1.1. Priority 1 Urgent (P1) - P1 is a catastrophic production problem that severely impacts the Customer’s production systems, or because of which Customer’s production systems are down or not functioning, or that results in a loss of production data and no workaround exists. Upsun will make continuous efforts, with appropriate escalation to senior management, to provide a resolution. 

3.4.1.2. Priority 2 High (P2) - P2 is a problem in which the Customer’s system is functioning but in a reduced capacity, or the problem is causing significant impact to portions of business operations and productivity, or the software is exposed to potential loss or interruption of service. Upsun will make continuous efforts to provide a resolution. 

3.4.1.3. Priority 3 Normal (P3) - P3 is a medium- to low-impact problem that involves partial and/or non-critical loss of functionality, or that impairs some operations but allows the Customer’s operations to continue to function. Problems for which there is limited or no loss of functionality or impact to the Customer’s operation and for which there is an easy workaround qualify as P3. Upsun will use reasonable efforts to provide a resolution in time for the next minor release of the software.

3.4.1.4. Blackfire support tickets will be treated as Priority 3 Normal (P3) tickets.

3.4.2. Customer acknowledges that response targets for the relevant support tier as per sections 3.1 and 3.2 above are response targets only and not resolution targets. Upsun sets no target and makes no guarantee or representation to the Customer regarding resolution times of support tickets.

3.5. Included services

3.5.1. Support is available for all Customer environments hosted on Upsun (production, staging and development environments) (see exclusions in Section 2.6, below). P1 Tickets are only applicable to live, production environments. Support is only available for repeat or systemic issues or errors.

3.5.2. Support includes the following: 

3.5.2.1. Response. Upsun will respond to and make commercially reasonable efforts towards resolving submitted support tickets. Responses will be addressed within the timeframes and allowances corresponding to the Customer’s purchased support level. 

3.5.2.2. Post-Issue Analysis. For Advanced and Premium support services, Upsun will use commercially- reasonable efforts to provide post issue analysis upon request following the conclusion of Upsun specified Priority 1 (“P1”) tickets only. Customers must request this within 14 calendar days of the ticket being closed, via an update to the original Priority 1 ticket. Customers will be provided a written summary of no more than 500 words in an attachment to the original ticket. Code samples, when included, are not counted towards such limits. The summary will include, as applicable, an explanation of the circumstances, change, or context that caused the issue, or business practices that resolved the issue, and recommendations for prevention of future instances. Depth of analysis is at the discretion of Upsun. No additional efforts on the issue will be undertaken. 

3.6. Excluded services

3.6.1. Except as expressly agreed in writing by Upsun, the following are excluded from Support: 

3.6.1.1. Support excluded for Non-Production, Development or Preview environments, or other functionalities. Staging environments, “sandbox” Projects, and other sites related to the development of a production Project are not eligible for P1 Support. 

3.6.1.2. No support to end-users of Customer’s application. Support for end-users of Customer’s applications hosted on Upsun will be provided exclusively by Customer. 

3.6.1.3. Training and Consulting. Support related to the application implementation, standard usage, and project consulting is not provided unless specifically ordered by Customer. 

3.6.1.4. Hardware, operating system, third-party software, databases, and networks. No support relating to installation, configuration, use, maintenance, or functionality of non-Service hardware, operating systems, third-party software, databases networks, or other enabling technologies is provided.

## **4\. Advanced User Management add-on.**

4.1. Advanced User Management add-ons can only be subscribed to by Flexible Organization.

4.2. Advanced User Management is contracted at the Organization level. Minimum subscription term is thirty (30) days.

### [Cloud Compliance | Upsun](https://upsun.com/trust-center/security/compliance-guidance/)

### **Overview**

Upsun provides a Platform as a Service (PaaS) solution and has many customers that require us to maintain various cloud compliance certifications. These certifications contain requirements to ensure certain measures are implemented to meet industry standards. Some requirements are the responsibility of the host, some are the responsibility of the application developer, and others are a shared responsibility.

Basic compliance questions can be handled by our support team via a ticket. For more advanced questions, including help with an audit, please contact your Upsun Account Manager.

### **Security & Compensating Controls**

-   For a list of security measures, please see our Data Security page.
-   Customer environments are deployed in a read-only instance, segregated with GRE tunnels and encrypted using TLS, which often permits compensating controls to be claimed for several PCI requirements.
-   Because customers can use our PaaS in a variety of ways, the best approach with auditors is to focus on “What do I (the customer) control/configure, and how is it managed in a compliant manner?”
-   The OVHcloud region (FR-3) is currently excluded from our ISO 27001, PCI, and SOC 2 certifications
-   HIPAA and TX-RAMP workloads are strictly run on our `US-4` region.

### **Responsibility**

Upsun and customers often have shared responsibility for ensuring an up-to-date and secure environment. The customer is responsible for achieving and maintaining their own certifications and compliance.

The following is a general allocation of responsibilities between Upsun and the customer. For more guidance on responsibility for specific certification requirements, refer to the relevant documentation (such as PCI Compliance) to access the relevant shared responsibility matrix.

Upsun is responsible for:

-   **Physical and Environmental controls**: We use third-party hosting and thus these requirements are passed through to those providers (such as AWS).
-   **Patch Management**: Upsun is responsible for patching and fixing underlying system software, management software, and environment images.
-   **Configuration Management**: Upsun maintains the configuration of its infrastructure and devices.
-   **Awareness and Training**: Upsun trains its own employees in secure software development and management.
-   **Capacity Management**: Upsun is responsible for capacity management of the infrastructure, such as server allocation and bandwidth management.
-   **Access Control**: Upsun is responsible for providing access control mechanisms to customers and for vetting all Upsun personnel access.
-   **Backups**: Upsun is responsible for backing up the infrastructure and management components of the system. On Dedicated Gen 2, Upsun also backs up application code and databases on behalf of customers.
-   **Managed CDN and web application firewall (WAF)**: If a customer’s plan includes a managed CDN and/or a managed WAF, Upsun is responsible for setting up and maintaining the included measures. See more details about each at their respective documentation pages.

Customers are responsible for:

-   **Patch Management**: Customers are responsible for maintaining and patching application code uploaded to Upsun.com, either written by them or by a third-party.
-   **Configuration Management**: Customers are responsible for the secure configuration of their application, including Upsun configuration and routes managed through YAML files.
-   **Awareness and Training**: Customers are responsible for training their own employees and users on secure software practices.
-   **Capacity Management**: Customers are responsible for ensuring their application containers have sufficient resources for their selected tasks.
-   **Access Control**: Customers are responsible for effectively leveraging available access control mechanisms, including proper access control settings, secrets management, SSH key management, and the use of two-factor authentication.
-   **Backups**: On Upsun, Professional customers are responsible for all application and database backups.
-   **CDN and web application firewall (WAF)**: If a customer’s plan does _not_ include a managed CDN or managed WAF, the customer is responsible for setting up and maintaining such measures.

### [Security updates | Upsun](https://upsun.com/trust-center/security/updates/)

**The Upsun Rule:** Update Early, Update Often

Upsun periodically updates its container images to incorporate the latest security updates from upstream providers (PHP, Ruby, MariaDB, etc.). While updates are not always applied immediately, they are generally implemented soon after a security vulnerability is identified and a corresponding fix is released.

However, these updates aren’t automatically propagated to individual projects as that would involve potential customer downtime. Instead, the latest available version of every requested container is loaded on each deploy to a given environment. After a deploy you are always guaranteed to be running the latest Upsun-provided version of a container.

If you are using Upsun-provided Let’s Encrypt TLS certificates, your site is automatically redeployed approximately once every two months to ensure it always has an up to date certificate. That also ensures your container versions are up to date at the same time.

### [Data Deletion Information | Upsun](https://upsun.com/trust-center/security/data-deletion/)

Data deletion is handled via our backend providers. When a volume is released back to the provider, the provider performs a wipe on the data in accordance with NIST 800-88. This wipe is done immediately before reuse.

All projects, except those hosted on FR-3, utilize encrypted volumes. The encryption key is destroyed when the volume is released back to the provider, which adds another layer of protection.

### **Media destruction**

Media destruction is handled via our backend providers. When the provider decommissions media it undergoes destruction as outlined in NIST 800-88.

### [Subprocessor list | Upsun](https://upsun.com/trust-center/privacy/subprocessor-list/)

At Upsun, we rely on a group of trusted third-party providers (“subprocessors”) to support the delivery, operation, and security of our services. These subprocessors may process personal data  as part of our sevices. 

* * *

### **Our Subprocessors**

### Change Notification

We are committed to keeping our customers informed. Customers will receive advance notice of any intended changes to our subprocessor list, in accordance with our DPA.

### [PCI Compliance | Upsun](https://upsun.com/trust-center/security/pci/)

Refer to our Compliance Guidance for an overview of our PCI-compliant program, including security & compensating controls, and a general allocation of responsibility.

### **Overview**

Payment Card Industry (PCI) Data Security Standards (DSS) is a set of network security and business best practice guidelines that establish a “minimum security standard” to protect payment card information. While Upsun doesn’t handle credit cards, many of our customers do.

Upsun undergoes an annual third-party audit to maintain PCI DSS recertification. Note that the FR-1 and FR-3 regions are excluded from our PCI certification.

Note: Cardholder processing activity is discouraged. Please use a third-party processor.

### **Responsibility**

Customers who want to run PCI workloads on Upsun must agree to and implement the measures contained in the Upsun PCI Responsibility Matrix (Excel). This document provides guidance on shared responsibilities to achieve PCI DSS compliance using PCI DSS v4.0.1 as a reference.

While Upsun provides a secure and PCI compliant infrastructure, the customer is responsible for ensuring that the environment and applications that they host on Upsun are properly configured and secured according to PCI requirements. Failure to do so will result in a non-compliant customer environment.

Our most current PCI DSS report can be obtained by submitting a support ticket.

### [Transparency and Abuse Reports | Upsun](https://upsun.com/trust-center/legal/transparency/)

In accordance with the EU Digital Services Act Package, French law, and the European Data Protection Board’s requirements and recommendations, Upsun provides two reports on an annual basis outlining governmental authority requests and abuse reports received during that year. The contents of those reports are listed below, and can also be downloaded as a PDF.

### **Available reports**

### [EU DPA - DPA in the Cloud | Upsun](https://upsun.com/trust-center/privacy/dpa/)

## **1\. Introduction**

This Data Processing Agreement, including its Exhibits (this **“DPA**”), supplements the Upsun Terms of Services or any other written contract in place (the ‘**Agreemen**t’) between You (the ‘**Custome**r’) and Upsun (“**Upsun”**) in connection with the Services to reflect the parties’ agreement with regard to the Processing of Personal Data.

## **2\. Definitions**

“**Data Protection Laws**” means laws and regulations relating to privacy and/or data protection, applicable to the processing of personal data under the Agreement, including without limitation, to the extent applicable, the General Data Protection Regulation (EU) 2016/679 ("**GDPR**"), the UK General Data Protection Regulation (“**UK GDPR**”),  the Swiss Federal Data Protection Act and its implementing regulations (“**Swiss FADP**”) the California Consumer Privacy Act, Cal. Civ. Code § 1798.100 et seq. (“**CCPA**”), the California Privacy Rights and Enforcement Act of 2020, and/or any applicable analogous legislation in any jurisdiction. 

“**Personal Data Breach**” means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, Personal Data transmitted, stored, or otherwise Processed.

“**Subprocessor**” means an Upsun affiliate and/or any other third party engaged by Upsun to Process Personal Data.

**“Standard Contractual Clauses**” means the standard contractual clauses annexed to the EU Commission decision EU 2021/914 of 4 June 2021 as regards the introduction of an alternative set of standard contractual clauses for the transfer of personal data to third countries ( as updated from time to time).

**“Data Controller”** (or Controller), **“Data Processor”** (or Processor) **“Data Subject”**, **“Personal Data”**, **“Processing”**, all have the meanings given to those terms in Data Protection Laws (and related terms such as **“Process”** and **“Processed”** shall have corresponding meanings).

Capitalized terms not defined herein shall have the meaning ascribed to them in the Agreement. 

## **3\. Processing Instructions**

3.1 Customer shall ensure that the use of the Services and its instructions comply with Data Protection Laws applicable to the Processing of Personal Data, and will not cause Upsun to be in breach of Data Protection Laws. 

3.2 Customer is solely responsible for the accuracy, quality, and legality of (i) Personal Data provided to Upsun by or on behalf of Customer, (ii) the means by which Customer acquired the Personal Data, and (iii) the instructions it provides to Upsun. 

3.3 Upsun shall Process Personal Data (i) for the purposes set forth in the Agreement, (ii) in accordance with the terms and conditions set forth in this DPA and any other documented instructions provided by Customer from time to time, and (iii) in compliance with Data Protection Laws.

3.4 The parties acknowledge and agree that Upsun is a Processor of Personal Data under Data Protection Laws (or a subprocessor as may be applicable) and the Customer is a Controller or a Processor. If Customer is a Processor, Customer represents and warrants that its instructions and actions with respect to the Personal Data, including appointing Upsun as a subprocessor, have been and are authorized by the relevant Controller.  Upsun shall not sell, retain, use or disclose any Personal Data provided by Customer pursuant to the Agreement except as necessary for performing the Services or otherwise as set forth in the Agreement or as permitted by applicable Data Protection Laws.

3.5 The subject matter, nature, purpose and duration of this Processing, as well as the types of Personal Data collected and categories of Data Subjects, are described in Exhibit A to this DPA.

3.6 Following completion of the Services, Upsun shall delete the Personal Data, except as required to be retained by applicable law. The provisions of this DPA survive the termination or expiration of the Agreement for so long as Upsun Processes Personal Data.

## **4\. Upsun Personnel and Subprocessors**

4.1 Upsun shall ensure the reliability of its employees who access Personal Data, and have signed agreements requiring them to keep Personal Data confidential.

4.2 Upsun may use Subprocessors to fulfil its contractual obligations to Customer under the Agreement. Customer consents to Upsun’s use of Subprocessors for such purposes. A current list of Upsun’s Subprocessors is available at https://upsun.com/trust-center/privacy/subprocessor-list/ and may be updated by Upsun from time to time. 

4.3 Upsun shall notify Customer if it adds any new Subprocessor (notification may be via email, by notification on an online portal of our Services, or by other reasonable means) at least fifteen (15) days prior to allowing such Subprocessor to Process Personal Data. Customer may object in writing to Upsun’s appointment of a new Subprocessor within five (5) calendar days of such notice, provided that such objection is based on substantial rational grounds relating to data protection or documented evidence of non-compliance with applicable Data Protection Laws . If the parties are unable to reach a mutually agreeable resolution to Customer objection to a new Subprocessor, as sole and exclusive remedy, Customer may terminate the specific Service or portion of Service that cannot be provided without the objected-to Subprocessor, and Upsun will refund any prepaid, unused fees for the terminated portion of the applicable subscription term for the affected Service. 

4.4 Upsun shall enter into a written agreement that imposes similar obligations on its Subprocessors as are imposed on Upsun under this DPA.

4.5 Upsun shall be liable to Customer for the acts and omissions of its Subprocessors to the same extent that Upsun would itself be liable under the this DPA had it conducted such acts or omissions.

## **5\. Assistance and Audits**

5.1  Upsun shall, taking into account the nature of the Processing and the information available to it, and provided that Customer does not otherwise have access to the relevant information, provide Customer with reasonable cooperation and assistance, where necessary, for Customer to: 

i. comply with its obligations under Data Protection Laws, including responding to              Data Subject requests; If Upsun receives a request from a Data Subject in relation to the Data Subject’s Personal Data processed under this DPA, Upsun will notify Customer and will advise the Data Subject to submit the request to Customer;

ii. conduct a data protection impact assessment;

iii. cooperate with and/or participate in a consultation with any supervisory authority, where necessary and legally required.

5.2 Upsun, upon request, shall (i) supply a summary copy of its audit report(s) to Customer, so Customer can verify Upsun’s compliance with the audit standards against which it has been assessed, to the extent applicable this DPA and (ii) allow Customer or its authorized representative to conduct an audit of Upsun data processing practices to demonstrate compliance with its obligations under this DPA, provided that such audit shall be communicated to Upsun 30 days in advance, shall not be unreasonably disruptive to Upsun’s business and shall occur no more than once per twelve (12) month period during the term of the Agreement, unless otherwise required by a supervisory authority or in connection with a Personal Data Breach. The Customer shall be responsible for the costs of any such audit.

## **6\. Transfers or Personal Data** 

6.1 Customer authorizes Upsun or its Subprocessor to Process Personal Data outside the European Economic Area to the extent required for the provision of Services in a country that may not have the same level of protection as the applicable Data Protection Laws.

6.2 Upsun shall take all steps necessary to comply with relevant Data Protection Laws regarding transfers of Personal Data to third countries including entering into Standard Contractual Clauses (or other approved transfer mechanism) with the importing entity.

## **7\. Security**

7.1 Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of Processing, as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, Upsun shall maintain appropriate technical and organizational measures to ensure a level of security appropriate to the risk of Processing Personal Data, including at a minimum those outlined in Exhibit B. 

## **8\. Security Breach Notification.** 

8.1 Upsun shall notify Customer without undue delay after becoming aware of a Personal Data Breach by Upsun or its Subprocessors, providing Customer with sufficient information (insofar as such information is within Upsun’s possession). Upsun shall make commercially reasonable efforts to assist in the investigation, mitigation and remediation of such a Personal Data Breach. Customer acknowledges that Upsun providing notification of a Personal Data Breach is not an acknowledgment of fault or liability.

9. **Order of Precedence**  
9.1 This DPA supplements the Agreement. The general conditions declared applicable in the Agreement are equally applicable to this DPA. However, if the Agreement is in direct conflict with this DPA, the provisions of this DPA shall prevail. The provisions of this DPA apply to any Processing of Personal Data by Upsun in relation to the Agreement.

## **Exhibit A**

Details of Processing   
_**Nature and Purpose of Processing**_: The overall purpose of Upsun’s processing of Personal Data is to provide the Services described in the Agreement. Processing necessary to achieve the stated purposes may include data entry, hosting, storage, structuring, transmission, and deletion. 

_**Duration of Processing**_: For the duration of the Agreement.

_**Categories of Data Subjects**_: The Data Subjects may include Customer’s employees, customers and end-users, or any other individual whose personal data Customer uploads to or makes available to Upsun in connection with the Services.

_**Type of Personal Data**_: Upsun provides the project environment and stores the Customer Content (as defined in the Agreement) as part of its service offering. The categories of Personal Data processed by Upsun are determined solely by the Customer and are dependent on the data that the Customer uploads, transmits, or otherwise makes available on or through the Services. Upsun does not determine the nature, scope, or purpose of the data uploaded by the Customer and disclaims any responsibility for ensuring that such data falls within the categories described herein.  
 

## **Exhibit B**

Technical and Organizational Measures 

**Workforce Security Management**

-   Permanent employees, temporary employees, and sub-contractors of Upsun have signed confidentiality and non-disclosure agreements (or are individually bound by equivalent confidentiality obligations) upon employment or appointment.
-   Security policies and individuals' responsibilities for good information security practices are communicated to all relevant personnel and agents upon the start of employment and at other appropriate times (for example once a year).
-   Personnel are informed of information security risks associated with travel and working from remote locations.

**Workstation & Device Protection**

-   Personnel are not authorised to use non-company computers (i.e. computers not owned/leased and operated by Upsun), unless technical security policies implemented by Upsun protect the processing of Upsun and customer Personal Data on non-company computers.
-   All laptop and desktop computers have security policies enforced, which ensure encryption, AV protection, OS updates, as well as the possibility of remotely disconnecting a device from the network, locking the device or performing a full data wipe, to ensure data integrity and combat leaking information in case of a security incident.
-   Passwords granting access to computers, applications and accounts are not hard coded into any computer or file or transmitted in clear text.
-   Upsun reduces password usage by enforcing Single Sign-On (SSO) wherever possible. When passwords are necessary, personnel are advised to use a password manager to generate and store strong, unique passwords.
-   Hard disks in laptop and desktop computers are subject to a multiple overwrite process before disposal.  Other media potentially containing data are disabled/destroyed or otherwise sufficiently formatted or overwritten to prevent unauthorised data access.
-   Where a specific laptop or desktop computer is issued to personnel, data on this computer's hard drive is erased before this computer is issued to any subsequent user.
-   Personnel are instructed to immediately report thefts and other losses of devices/media containing company information (including laptops).  Any loss/theft of such devices/media is followed with the necessary actions to prevent unauthorised network access (e.g., by removal from Active Directory) and unauthorised disclosure of information (e.g., by executing 'remote kill' commands).
-   All company-managed devices run endpoint protection software with real-time threat detection and response capabilities.

**Network and System Access Management**

-   Access to the web application is managed through Okta, our enterprise-grade identity and access management platform. All user authentication flows are directed through Okta’s secure infrastructure, ensuring that credentials are never handled directly by the application.
-   This integration leverages Single Sign-On (SSO) based on industry-standard protocols, including SAML 2.0, OAuth 2.0, and OpenID Connect, to provide a seamless and secure authentication experience.
-   Documented procedures and access policies are established and communicated to request, approve, administer, and review user IDs (also known as "system accounts" or "accounts") and passwords for network and applications access.
-   Access requests for application/data access are approved at least by the requestor's supervisor or the application/data owner.  Approved access is assigned individually to a person in accordance with that person's approved job/position responsibilities and considerations regarding segregation of duties.
-   Passwords are automatically set to expire after a limited period and contain a minimum of 12 characters that are not easily guessed.  Accounts granting access to networks and applications are automatically locked out after a predefined number of unsuccessful logon attempts, and such lockouts are investigated before reactivating accounts and/or resetting passwords. Additionally this requires in-person verification with security personnel to confirm identity, before access is restored.  Network and application settings are maintained to keep concurrent logon connections to a minimum.  Security settings are enabled so as to prevent re-use of the last 24 passwords.
-   Default user IDs and passwords are disabled or changed from their initial values to prevent abuse of default system administrator accounts and features.  Workstation administrative passwords are changed at least once per year.
-   Accounts granting access to the network and to applications are regularly reviewed to detect and disable/remove inactive user IDs.  User IDs of terminated personnel are disabled on the day of termination.  User master files for network and application access are reconciled to lists of departing/departed personnel periodically to ensure unrequired system access has been removed promptly.
-   System access rights (of collaboration / document management systems as well as file servers storing information) are reviewed at least once per year in liaison with application/data owners to validate that all users' system access permissions are commensurate with approved position responsibilities

**Backup and Disaster Recovery Operations**

-   Contingency and disaster recovery plans covering critical applications/document repositories are documented, updated, and tested/evaluated on an annual basis.
-   Up-to-date anti-virus software is installed on all workstations connecting to Upsun’s network.  The anti-virus software is configured to identify and remove, disable, or quarantine computer viruses automatically, and receives automatic updates to ensure this capability is maintained on an ongoing basis.

**Change Management**

-   Formal change management procedures are documented, communicated and adhered to for the development and maintenance of custom-built computer applications, to ensure sufficient review and approval of software code and system configuration changes and to segregate the ability to modify computer programs and move these into production.  Critical applications have separate environments (and appropriately configured access rights) for development/training/testing/QA and production.

**Other Security Controls**

-   System administrator and “super-user” privileges to computers and application/system management software are limited to a small number of qualified and authorised personnel, in accordance with their approved job responsibilities.
-   Log files recording critical security and system administrator activities (including creation of new users, password resets, changes of access rights, clearance of audit logs) are maintained and independently reviewed on a regular basis.
-   Remote network access capabilities are provided in a controlled and secure manner to ensure that remote network access only occurs for approved business purposes and by authorised personnel only.
-   Employees are informed that highly confidential data transmissions must be subject to additional data protection measures as Upsun makes available, (e.g., encryption of e-mail).

### [Vendor Sustainability & Ethics Charter ](https://upsun.com/trust-center/legal/vendor-sustainability-charter/)

## **Purpose**

At Upsun we are committed to upholding high standards of ethical conduct, environmental responsibility, and human rights. This charter outlines our expectations for all vendors and partners to align with these values in their operations, ensuring a responsible and sustainable supply chain.

## **Scope**

We encourage vendors and partners to read this document and uphold these principles as essential conditions for conducting sustainable business with Upsun.  
  
 

## 1\. Labor Practices and Human Rights 

We endeavour our vendors to promote and protect the rights of workers as follows:

-   **Fair Working Conditions**  
    Vendors must comply with all applicable labour laws, providing fair wages, reasonable working hours, and appropriate benefits. This includes adherence to local laws and international standards regarding overtime and compensation.
-   **Health and Safety**  
    Vendors must maintain a healthy and safe work environment for all employees. This includes implementing safety protocols, providing appropriate training, and ensuring access to necessary personal protective equipment.
-   **Anti-Discrimination and Anti-Harassment**  
    We expect vendors to foster inclusive work environments free from discrimination and harassment. This includes ensuring that no individual is discriminated against based on race, gender, age, religion, sexual orientation, or any other legally protected characteristic.
-   **Freedom of Association**  
    Vendors must respect the rights of workers to form and join trade unions and to bargain collectively without fear of retaliation.
-   **No Forced or Child Labor**  
    Vendors are strictly prohibited from using forced labor, including bonded or involuntary labor. The use of child labor is also strictly forbidden in compliance with international child labor standards.  
      
     

## 2\. Environmental Responsibility

We endeavour our vendors to contribute to the protection of the environment and pursue sustainability in their operations:

-   **Energy Efficiency and GHG Emissions**  
    Vendors must track and work towards reducing their energy consumption and greenhouse gas emissions. We encourage the use of renewable energy and participation in initiatives that promote energy efficiency.
-   **Waste Management and Reduction**  
    Vendors must implement effective waste reduction strategies, promote recycling, and ensure the proper disposal of hazardous materials. A reduction in overall waste, especially plastic and non-recyclable materials, is expected.
-   **Sustainable Sourcing**  
    Vendors must strive to procure materials from sustainable sources. This includes working with suppliers who practice responsible environmental management, with the aim of reducing the environmental footprint across the supply chain.
-   **Biodiversity and Ecosystem Preservation**  
    Vendors must ensure that their operations do not harm biodiversity and local ecosystems. Efforts should be made to preserve natural habitats and contribute to restoration projects where possible.

## 3\. Commitment to Collaboration

Sustainability and ethical practices are a shared responsibility. Upsun is committed to working collaboratively with vendors to improve labour standards and environmental performance. We encourage vendors to dialogue and share best practices that contribute to mutual improvement and innovation in these areas.

### [Terms of Service for Upsun Services purchased via a Marketplace or Reseller](https://upsun.com/trust-center/legal/tos-marketplace-and-reseller/)

These Terms of Service for Upsun Services ordered via a Marketplace or Reseller (the “Terms of Service”) set forth the terms and conditions governing the Customer’s (as defined below) subscription to and use of the Upsun Services when procured by Customer through a Marketplace or Reseller (as defined below).  

Customer’s order of Upsun Services listed or made available through a Marketplace or Customer’s order of Upsun Services through a Reseller constitutes Customer’s acceptance of these Terms of Service and their entry into this Agreement (as defined below). 

The “Effective Date” of this Agreement is (i) the date upon which Customer accepts a private offer or purchases publicly-listed Upsun Services via the applicable Marketplace; or (ii) the effective date of a Reseller Order Form. 

## **1\. Definitions and interpretation**

1.1. Capitalised terms used but not defined in these Terms of Service shall have the meaning given to them in the Service Specific Terms or any other document incorporated by reference into the Agreement. 

1.2. In these Terms of Service:

-   “**Agreement**” means these Terms of Service, the Service Specific Terms, any applicable Marketplace Order Form, and any documents referred to therein.
-   “**Acceptable Use Policy**” means the acceptable use policy available at https://upsun.com/trust-center/legal/aup/.
-   “**Account**” means a Customer account on the Platform. 
-   “**Affiliates**” means an entity that controls, is controlled by, or is under common control with a Party, where “control” means control of more than fifty percent (50%) of the voting shares of such entity.
-   “**Beta Feature(s**)” means any beta or pre-release features still undergoing testing that are not generally available.
-   “**Confidential Information**” means: (i) any non-public technical or business information of a Party, including without limitation, any information relating to a Party’s techniques, algorithms, know-how, current and future products and services, research, engineering, designs, financial information, procurement requirements, manufacturing, customers, business forecasts and marketing plans; and (ii) any other information that is designated as “confidential” or that should reasonably be understood by the receiving Party to be Confidential Information. Confidential Information will not include any information that (i) is or becomes generally known to the public through no fault or breach of this Agreement; (ii) the receiving Party can demonstrate was rightfully in its possession at the time of disclosure, without an obligation of confidentiality; (iii) is independently developed by the receiving Party without the use of or access to the disclosing Party's Confidential Information; or (iv) the receiving Party rightfully obtains from a third party not under a duty of confidentiality and without restriction on use or disclosure.
-   “**Console**” means the web administration console in Customer’s Account through which Customer manages its Projects. 
-   “**Content**” means all information and content relating to a Customer’s Projects, including without limitation related data files, written text, software or program source code, pictures, music, audio or video files, or other images or materials.
-   “**Fees**” means the fees set out in the Order Form.
-   “**Customer**” means the Customer entity set forth in an Order Form. 
-   “**Data Processing Agreement**” or “**DPA**” means the data processing agreement at https://upsun.com/trust-center/privacy/dpa/.
-   “**Documentation**” means the documentation at https://docs.upsun.com/
-   “**Managed Services**” means third-party services, components, or tools which are provided to Customer by Upsun as a managed service.
-   “**Marketplace**” means the Amazon Web Services Marketplace and the Microsoft Azure Marketplace through which Upsun makes the Services available for subscription by Customer. 
-   “**Marketplace Order Form**”means, as applicable, (i) Upsun’s public listing on a Marketplace or (ii) a private offer and any related ordering, pricing, or transaction terms accepted by Customer through a Marketplace.
-   “**Order Form**” means a Marketplace Order Form or a Reseller Order Form, as the case may be. 
-   “**Organization**” is a structured entity created by Customer in Customer Account to group Customer’s Projects for managing resources, access, and billing.
-   “**Party**” means the Customer or Upsun, collectively the “Parties”.
-   “**Platform**” means the Upsun PaaS-Platform-as-a-Service.
-   “**Privacy Notice**” means the privacy notice available at https://upsun.com/trust-center/privacy/privacy-notice/.
-   “**Projects**” means Customer applications, data and related services developed and/or hosted on the Platform. 
-   “**Representatives**” means the Users, employees, agents, legal affiliates, consultants, or professional advisors of a Party.
-   **“Reseller”** means a third party authorized by Upsun to resell the Upsun Services.For the avoidance of doubt, where an Upsun customer accesses or uses the Services pursuant to a subscription purchased by an OEM Partner or Agency Partner of Upsun, customer’s access to and use of such Services shall be governed by the applicable agreement between customer and such partner, and not by these Terms of Service.
-   “**Reseller Order Form**” means an order document executed between a Reseller and Upsun for the subscription of the Services.  
-   “**Services**” means the provision of the Platform to help Customer develop, deploy, host, monitor, and maintain its Projects and related services. 
-   “**Service Specific Terms**” means the service-specific additional terms available at https://upsun.com/trust-center/legal/service-specific-terms/ 
-   “**Third Party Services**” means all third party tools and websites accessed through the Platform or used by the Customer with the Platform but excluding Managed Services.
-   “**Upsun**” or “**Upsun Contracting Entity**” is the Upsun entity identified in the Order Form.
-   “**User(s**)” means any individual accessing or using the Services on behalf of Customer.

## **2\. Orders** 

### 2.1. Orders via a Marketplace 

2.1.1. Where Customer has ordered Services via a Marketplace, Customer agrees to pay the Fees through its account with such Marketplace provider and any refund to which Customer is entitled under the Agreement may be provided in the form of a credit back to Customer's account with such Marketplace provider. 

2.1.2. Orders for Services placed through a Marketplace,  including multi-year subscriptions, are non-cancellable except as expressly set forth in these Terms of Service.

### 2.2. Orders via a Reseller

2.2.1. If Customer orders  Services through a Reseller, Customer shall enter into a separate agreement directly with such Reseller governing the applicable commercial terms, including pricing, invoicing, and payment obligations. Upsun is not a party to, and shall not be bound by, any agreement between Customer and a Reseller, nor shall any such agreement modify or supersede this Agreement. Customer acknowledges that Reseller acts independently from Upsun, and Upsun shall have no liability or responsibility for any acts, omissions, representations, warranties, or obligations of the Reseller.

2.2.2. Upsun’s obligation to provide the Services is conditional upon Reseller’s payment of all applicable Fees owed to Upsun for such Services. Subject to the foregoing Upsun shall remain responsible solely for providing the Services in accordance with this Agreement. 

2.2.3. Any refund to which Customer is entitled in connection with the Services may be provided in the form of a credit to Reseller. 

2.2.4. Orders for Services placed through a Reseller, including multi-year subscriptions, are non-cancellable except as expressly set forth in these Terms of Service.

## **3\. Provision of the Services**

3.1. Upsun will provide the Services ordered by Customer in accordance with this Agreement. 

3.2. The Services ordered by Customer may come with resources and usage limits. Usage in excess of the contracted scope and/or capacity may be allowed and billed as used.

## **4\. Data protection**

4.1 Each Party shall comply with the Data Processing Agreement.

4.2 Upsun may collect personal data from Customer’s Users and/or employees, consultants, directors, or agents in connection with the Services. The Privacy Notice describes how Upsun collects, uses, and discloses such personal data.

## **5\. Security**

5.1. Upsun will maintain the technical and organizational security measures set out in the DPA. 

5.2. Security and backups are a shared responsibility between Upsun and Customer, as further described in the Documentation. Customer is solely responsible for the security of any Project Customer deploys on the Platform. Upsun will regularly schedule automated backups of Customer production environments, as further described in the Documentation. Upsun may notify Customer of security vulnerabilities relating to elements under Customer’s control and responsibility (e.g., application code, configuration of application, and routes managed through YAML files), but has no obligation to review or advise Customer of any security vulnerabilities. Customer must patch any notified vulnerabilities as soon as possible. Failure to do so may result in the immediate suspension of Customer Projects, at Upsun’s sole discretion. Upsun is not responsible for any vulnerabilities relating to elements under Customer’s control.

5.3. Upsun may provide templates and code examples in the Documentation, public repositories, and support interactions. It will make reasonable efforts to make sure these examples respect secure coding standards, but example code may not be ready for production settings. It is the Customer responsibility to make sure any application code Customer runs is up to date and secure, even when originally provided by Upsun.

## **6\. Beta Features**

6.1. Upsun may allow Customer to try certain Beta Features. Beta Features are provided for evaluation purposes and are not intended for production use. Beta Features do not come with any uptime commitment or support obligation. Any Beta Features may be modified, removed, or discontinued, or made generally available to all Upsun customers for production use (including for a fee) at Upsun’s sole discretion and without any liability to Customer. All Beta Features are provided "AS IS,'' without warranty or representation of any kind. Notwithstanding section 19 Liability, Upsun’s liability for any damage arising out of or in connection with any Beta Feature is excluded in its entirety, including any obligation or liability with respect to Customer Content, except to the extent liability cannot be excluded or limited under applicable law. Customer assumes all risks associated with Customer use of a Beta Feature.

## **7\. Third-party services and Managed Services**

7.1. Upsun may provide Customer with direct access to, integrations, or connections with, Third Party Services. Upsun is not responsible for evaluating such Third Party Services. Access to Third Party Services is “as is” and “as available,” without any warranties or representations of any kind and without any endorsement. Upsun shall have no liability for any harm or damages related to Customer’s use of optional Third Party Services. In the event that Customer or any Customer User consents to a third-party integration, Customer shall be deemed as agreeing to the passage of data to the third-party integration partner for the purposes agreed upon between Customer and Upsun.

7.2. Upsun will make reasonable efforts to maintain integration with Third Party Services and Managed Services. However, Upsun cannot guarantee the continued availability of any integrated or managed features and may cease to provide these without entitling Customer to any refund, credit, or other compensation, if for example and without limitation, the provider of a third-party service, tool, or component ceases to make its service, tool, or component available for integration with the Services in a manner acceptable to Upsun or changes the terms of the third-party services in a manner that no longer allows Upsun to provide said integration feature. 

## **8\. Changes to the Services**

8.1. Upsun reserves the right to modify, add, or remove portions and/or functionality of the Services on a temporary or permanent basis, without liability to Customer. Except where an urgent change is required for security reasons, Upsun will notify Customer ahead of any material change by displaying a prominent notice within the Platform and/or by sending Customer an email. Except for changes that are implemented by Upsun for legal, regulatory or security reasons, if and to the extent a change introduced by Upsun has a material adverse effect on Customer’s use of the Services, Customer may, as its sole and exclusive remedy, terminate any active subscription and obtain a pro-rata refund of any prepaid and unused Fees. Customer’s failure to exercise its right to terminate and request a pro-rata refund within thirty (30) days from the day the change is released by Upsun will be deemed to be Customer’s acceptance of the revised Services.  When the Customer purchases through a Reseller, Customer must request that the Reseller exercises this right to terminate on its behalf. Failure to do so shall be deemed acceptance of the revised Services. Any refund will be made to the Reseller. 

## **9\. Customer’s obligations**

9.1. Customer must comply, and shall ensure that its Users comply, with the Acceptable Use Policy, applicable laws, and this Agreement.

9.2. Customer will ensure that its Users’ login details are kept confidential, are individual, and are not shared between several individuals. 

9.3. Customer is liable for its Users’ acts and omissions as if they were acts and omissions of Customer. Customer will notify Upsun immediately and terminate the relevant User(s)’s access to the Services should Customer become aware of (i) any breach of this Agreement by a User or (ii) any possible misuse of a User’s login details.

9.4. Customer is solely responsible for the use and submission of Content. Customer must make sure such Content is validly licensed to Customer for the intended use and Customer is solely liable for complying with any third-party intellectual property rights or licenses over any software or programs included in its Content.  If Customer’s Projects developed or hosted on the Platform allow for third parties (including but not limited to end users of the Customer’s applications) to publish, transmit, or host Content, Customer is solely responsible for any Content that breaches this Agreement or applicable law. 

9.5. Customer agrees to immediately remove any Content that breaches this Agreement upon first request of Upsun or upon becoming aware of any such breach. 

## **10\. Customer Affiliates**

10.1. Customer may enter into this Agreement on behalf of itself and Affiliates and may enable Affiliates to use the Services under Customer’s Account. Customer will remain liable for all obligations under our Agreement and any act or omission of any Affiliates will be deemed to be an act or omission of Customer. Any claim under this Agreement will be brought by or against Customer and not the Affiliate.  

## **11\. Fees, billing, and payment**

11.1. This section 11 shall not apply where Customer has ordered Services via a Reseller.

11.2. Orders via a Marketplace

11.2.1. Customer will pay the Fees as set out in the Marketplace Order Form. Bills will be issued through the Marketplace on behalf of Upsun and Customer’s payment of Fees to the Marketplace will be deemed to be Upsun’s receipt of the same. 

11.2.2. If Customer wishes to dispute a payment, it must provide written notice of the dispute to Upsun promptly, and in any event no later than fifteen (15) days from the payment date. Initiating a chargeback or requesting a reversal through a bank or credit card provider does not relieve Customer of its obligation to notify Upsun directly. Customer and Upsun shall work together in good faith and without undue delay to resolve the dispute. 

11.2.3. Any amount payable under this Agreement that is not paid when due will accrue interest at the interest rate applied by the European Central Bank to its main refinancing operation plus 10%, from the due date until paid, and (ii) a minimum fixed sum of EUR/USD 40 by way of compensation for recovery costs to Upsun for every invoice paid late. In the event Upsun brings a legal action for collection or hires an agent or authorized representative of collections due to overdue amounts, Customer will reimburse Upsun for all costs and expenses related to such collection, including but not limited to Upsun attorneys’ fees, court costs, and any other related collection enforcement fees.

11.2.4. All Fees are exclusive of tax. Customer must pay all taxes and duties assessed in connection with this Agreement, including any sales, use, value-added, withholding, and other taxes and duties.  In the event tax is required by law to be withheld from the Fees, Upsun may gross up the invoice such that after the deduction of withholding tax, the original Fees are received in full by Upsun. In the event that any withholding taxes are paid by Customer, Customer shall provide Upsun with a valid withholding tax receipt in Upsun’s name and all information reasonably required by Upsun within thirty (30) days following the payment. 

11.2.5. If Customer requires a purchase order or purchase order number it must provide that purchase order number to Upsun upon acceptance of the Marketplace Order Form.  Terms and conditions on any Customer purchase order are expressly excluded and shall be null and void. 

## **12\. Changes to prices**

12.1. Unless expressly stated otherwise in an Order Form, Upsun may change the Fees at any time. When Services are ordered by Customer via a Marketplace, Upsun must notify Customer of the change not less than thirty (30) days prior to the change taking effect. When Services are ordered by Customer via a Reseller, Upsun must notify the Reseller and the Customer of the change not less than thirty (30) days prior to the change taking effect.

12.2. If Customer objects to the updated prices, Customer (or the Reseller on behalf of the Customer) can terminate its subscription as its sole and exclusive remedy.

## **13\. Representations and warranty**

13.1. When Platform.sh SAS doing business as Upsun, Platform.sh Ltd trading as Upsun, Platform.sh Canada Sub Ltd doing business as Upsun Canada Sub, or Platform.sh Pty Ltd trading as Upsun is the Upsun Contracting Entity:

13.1.1. Upsun warrants that the Services will conform in all material respects with the Service Specific Terms and Documentation when used in accordance with this Agreement. In the event of a breach of the foregoing warranty, Upsun’s sole obligation, and Customer’s sole and exclusive remedy shall be for Upsun to (i) issue a Service Credit to Customer in accordance with the subscribed service level agreement (where applicable), (ii) correct any failure(s) of the Services to conform in all material respects with the Service Specific Terms and Documentation, or (iii) re-perform the Services at no additional cost to Customer or Reseller. 

13.1.2. This warranty will not apply if the error or non-conformity was caused by: (i) Customer’s breach of the Acceptable Use Policy, (ii) incidents caused by Customer’s Projects (e.g. Project that exceeds the allocated resources, contains a programming error, failure to apply updates) and/or caused by failure of TLS certificates provided by Customer, (iii) any services or hardware of Customer or any Third Party Services or Managed Services used by Customer. 

13.1.3. No implied warranty. Except as expressly provided in this Agreement and to the fullest extent permitted by applicable law, the Services are provided on an “as-is” and “as available” basis, and neither Party makes any warranties of any kind, whether express, implied, statutory, or otherwise, and all implied warranties, including the implied warranties of merchantability and fitness for a particular purpose are hereby excluded.

13.2. When Platform.sh Inc doing business as Upsun is the Upsun Contracting Entity, the Services (including but not limited to products, functionalities, and information) are provided on an "AS IS" and "AS AVAILABLE" basis. TO THE FULLEST EXTENT PERMITTED BY LAW AND EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, UPSUN HEREBY DISCLAIMS TO CUSTOMER OR TO ANY OTHER PERSON, INCLUDING ANY OF CUSTOMER’S USERS, ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, IMPLIED WARRANTIES OF MERCHANTABILITY, AND FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT. EXCEPT AS OTHERWISE EXPRESSLY SET FORTH HEREIN, UPSUN DOES NOT WARRANT THAT THE SERVICES, PRODUCTS, FUNCTIONALITY, DOCUMENTATION, OR INFORMATION, AS APPLICABLE, WILL MEET CUSTOMER’S REQUIREMENTS, OR BE UNINTERRUPTED OR ERROR-FREE, AND IT DOES NOT MAKE ANY REPRESENTATION REGARDING RESULTS OR USE IN TERMS OF CORRECTNESS, ACCURACY, RELIABILITY, OR RISK OF INJURY.

## **14\. Intellectual Property**

14.1. Upsun, and where applicable its licensors, are the sole and exclusive owners of all right, title, and interest in and to the Services. 

14.2. Upsun hereby grants Customer a limited in time, worldwide, royalty-free, non-transferable, non-assignable, non-sublicensable, and non-exclusive right to use the Services as permitted by this Agreement and subject to the usage restrictions in the Acceptable Use Policy, Service Specific Terms, and Documentation. 

14.3. Customer may not, and shall procure that Users, or others within Customer’s control do not copy, republish, reverse engineer, decompile, disassemble, or otherwise attempt to discover the source code or underlying ideas or algorithms of the Services; modify, translate, or create derivative works based on the Services; rent, lease, distribute, sell, resell, assign, or otherwise transfer intellectual property rights of the Services; use the Services for time-sharing or service bureau purposes, or otherwise for the benefit of a third party; or remove any trademark or proprietary notices from the Services. 

14.5. Customer, and where applicable, Customer licensors, are and will remain the sole and exclusive owners of all rights and title to and interest in the Content. Customer hereby grants to Upsun a non-exclusive, transferable, sub-licensable, royalty-free, worldwide license to host, reproduce, distribute, use, publicly perform, publicly display, and digitally perform the Content only as necessary to provide the Services. 

14.6. Upsun may state publicly that Customer is an Upsun customer by displaying Customer’s name and logo in online or offline promotional materials, or on Upsun websites.

14.7. The Services provide Customer with ways to share feedback with Upsun. Customer has no obligation to provide feedback. However, if Customer submits feedback, Customer acknowledges that such feedback is free from any confidentiality restriction and Customer hereby grants Upsun a fully-paid, royalty-free, perpetual, irrevocable, worldwide, non-exclusive, and fully sublicensable right and license to use, reproduce, perform, display, distribute, adapt, modify, translate, create derivative works of, and otherwise commercially exploit such feedback. The foregoing grant of rights is made without any duty to account to Customer or Customer Users for the use of such feedback. No feedback will be considered Customer Confidential Information, and nothing in this Agreement limits Upsun’s right to independently use, develop, evaluate, or market products or services, whether incorporating feedback or otherwise.

14.8. Any open-source software available through the Services is provided as-is and is not subject to the terms and conditions of this Agreement. Each item of open-source software is licensed under the end-user license that accompanies it.

## **15\. Confidentiality**

15.1 Each Party will, during the term of this Agreement and for a period of three (3) years after its termination or expiry, maintain in confidence all Confidential Information of the other Party and will not use such Confidential Information for any purpose, except as expressly permitted herein. 

15.2. Each Party will limit the disclosure of such Confidential Information to those of its Representatives who need to access such Confidential Information and are subject to binding use and disclosure restrictions at least as protective as those set forth herein. The receiving Party will be liable for any act or omission of such Representatives that, if taken by the receiving Party, would constitute a breach of this Agreement. The receiving Party will notify the disclosing Party of any actual or suspected breach of this Confidentiality section.

15.3. The receiving Party may make disclosures to the limited extent required by law or court order, provided the receiving Party uses reasonable efforts to limit disclosure and to obtain confidential treatment or a protective order and allows the disclosing Party to participate in the proceedings (to the extent legally permitted). 

15.4. In the event of a breach or threatened breach of this section by either Party, the other Party shall be entitled to seek preliminary and permanent injunctive relief (in addition to monetary damages and other remedies at law) to enforce the provisions hereof and shall be entitled to recover attorneys’ fees incurred in connection therewith. Notwithstanding the foregoing, the remedies in this section shall in no way be considered the exclusive remedies of a breach of this section by either Party.

## **16\. Indemnification**

16.1. Upsun hereby agrees to defend, indemnify, and hold Customer harmless from and against any and all liabilities, losses, damages, or expenses incurred by Customer arising out of or relating to any claim, suit, action or proceeding by a third party alleging that Customer’s use of the Services in compliance with the terms of this Agreement infringes upon such third party’s intellectual property rights. Upsun indemnification obligation does not apply to the extent the third-party claim arises out of or relates to (i) Customer breach of the Agreement, including the Acceptable Use Policy or Documentation, (ii) Customer Content, (iii) the use of the Services in connection with materials, including third-party materials, not provided by Upsun, and (iv) Beta Features, or free trials.

16.2. Customer hereby agrees to defend, indemnify, and hold harmless Upsun and Affiliates against all claims, settlements, procedures, expenses, damages, or suits (including attorneys’ fees and expenses) resulting from Customer Content and Customer’s use of the Services in breach of the Acceptable Use Policy or this Agreement.

16.3. The above indemnification obligations are subject to the following: (i) the indemnified Party will promptly inform the indemnifying Party of the applicable claim, (ii) the indemnifying Party will have sole control of the defense and all related settlement negotiations with respect to the claim, provided the Indemnifying Party may not settle the claim unless it unconditionally releases the indemnified Party of all liability or such settlement receives the indemnified Party prior approval, and (iii) the indemnified Party will, to the necessary extent and upon request of the indemnifying Party, fully cooperate to the claim investigation, defense, and trial. 

## **17\. Liability**

17.1. When Platform.sh Inc doing business as Upsun is the Upsun Contracting Entity, the liability of the Parties is as follows:

17.1.1. IN NO EVENT SHALL UPSUN OR ITS SUBCONTRACTORS, LICENSORS, AFFILIATES, OR SUBSIDIARIES, AND THEIR RESPECTIVE OFFICERS, DIRECTORS, EMPLOYEES, AND AGENTS BE LIABLE TO CUSTOMER OR TO ANY THIRD PARTY, INCLUDING ANY END USER, FOR ANY CONSEQUENTIAL, INDIRECT, SPECIAL, PUNITIVE, EXEMPLARY, OR INCIDENTAL DAMAGES OR LOSSES, INCLUDING WITHOUT LIMITATION, LOSS OF BUSINESS PROFITS, BUSINESS INTERRUPTION, GOODWILL OR SAVINGS, LOSS OR CORRUPTION OF DATA, DATA FILES, OR PROGRAMS, OR OTHER PECUNIARY LOSS ARISING OUT OF THE USE OF OR INABILITY TO USE THE SERVICES OR IN CONNECTION WITH THIS AGREEMENT, EVEN IF CUSTOMER OR UPSUN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. IN NO EVENT WILL UPSUN AGGREGATE LIABILITY TO CUSTOMER OR ANY THIRD PARTY, INCLUDING ANY END USER, FROM ALL CAUSES OF ACTION AND THEORIES OF LIABILITY, EXCEED THE ACTUAL AMOUNT OF FEES DURING THE TWELVE (12) MONTHS IMMEDIATELY PRECEDING THE DATE THE LIABILITY AROSE. SUCH FOREGOING EXCLUSIONS, LIMITATIONS OF LIABILITY, AND REMEDIES WILL APPLY, TO THE FULLEST EXTENT PERMITTED BY LAW, IN ALL ACTIONS OF ANY KIND, WHETHER BASED ON CONTRACT, TORT, OR ANY OTHER LEGAL OR EQUITABLE THEORY.

17.1.2 EACH EXCLUSION AND LIMITATION IS INTENDED TO BE SEPARATELY ENFORCEABLE, WITHOUT REGARD TO THE OTHER EXCLUSIONS AND LIMITATIONS, AND WITHOUT REGARD TO WHETHER ANY OTHER REMEDY UNDER THIS AGREEMENT FAILS OF ITS ESSENTIAL PURPOSE.

17.2. When Platform.sh SAS doing business as Upsun, Platform.sh Ltd trading as Upsun, Platform.sh Canada Sub Ltd doing business as Upsun Canada Sub, or Platform.sh Pty Ltd trading as Upsun is the Upsun Contracting Entity, liability of the Parties is as follows:

17.2.1. Upsun will not be liable to the Customer for any indirect, punitive, exemplary, special or consequential damages, including without limitation loss of profit, revenue, business interruption, procurement of substitute products or services, or other pecuniary loss arising out of the use or inability to use the Services, even if such Customer has been advised as to the possibility of such damages.

17.2.2. In no event will the aggregate liability of Upsun arising out of or related to this Agreement exceed the actual amount of Fees during the twelve (12) months immediately preceding the date the liability arose. 

17.2.3 The limitation set forth in section 17.2.2 will not apply (i) in the event of gross negligence or willful misconduct and matters for which liability cannot be excluded under applicable law, and (ii) to the indemnification obligations under section 16 “Indemnification”. 

17.2.4. The exclusions and limitations of liability in this section 17.2. apply to the fullest extent permitted by law, in all actions of any kind, whether based on contract, tort or any other legal or equitable theory.

17.3. When Customer ordered Services through a Reseller, amounts paid by the Reseller to Upsun for Services ordered on behalf Customer shall be deemed to be fees paid by Customer hereunder for the purposes of section Liability. 

## **18\. Suspension**

18.1. Upsun may immediately suspend Customer’s access to Customer Account and/or suspend Customer Project(s):

18.1.1. If Customer or any User(s) breaches the Acceptable Use Policy or applicable law or as reasonably deemed necessary by Upsun to prevent any harm to the Platform, to Upsun’s customers, or to the underlying infrastructure, or

18.1.2. Upon request of the Reseller when Customer ordered Services via a Reseller.

18.2. Upsun may suspend Customer access to Customer Account and/or suspend Customer Project(s) eight (8) days from written notice to Customer or Reseller if:

18.2.1. Customer fails to pay any amounts due under the Marketplace Order Form or Reseller fails to pay any amounts due under the Reseller Order Form; and/or  

18.2.2. Customer fails to provide any document or information reasonably requested by Upsun and necessary for the billing of the Services.

18.3.Suspension will be lifted when the circumstances giving rise to the suspension have been resolved. Suspension does not relieve Customer or the Reseller from its payment obligations or prevent Upsun from exercising any right to terminate this Agreement under section 21 below. 

## **19\. Term and Termination**

19.1. This Agreement takes effect when Customer agrees to these Terms of Service and will continue until expiry of the Order Form or terminated in accordance with this section.

19.2. For Services ordered under a fixed-term Order Form, deletion of Customer Projects or Organizations shall not terminate the applicable Order Form or relieve Customer or Reseller of its payment obligations. 

19.3 Unless otherwise expressly stated on the Order Form, auto-renewal is excluded. Customer and, if applicable, Reseller is responsible for ensuring that any renewal or replacement Order Form is executed prior to expiration of the applicable Subscription Term in order to avoid interruption of the Services. Upsun shall not be liable for any suspension, unavailability, or loss of access or Content resulting from Customer’s or Reseller’s failure to timely renew or replace an expired Order Form. 

19.4. Either Party may terminate this Agreement immediately on written notice to the other if the other Party is in breach of the Agreement and fails to cure that breach within thirty (30) days of receipt of written notice of the breach and a request to do so.

19.5. Upsun may terminate this Agreement:

19.5.1. immediately on written notice to Customer, if Customer’s use of the Services breaches the Acceptable Use Policy or applicable law; or 

19.5.2. with eight (8) days prior written notice to Customer or Reseller if Customer or Reseller fails to pay any amount due to Upsun under the Marketplace Order Form or the  Reseller Order Form.

19.6. Upon termination or expiry of this Agreement, Customer rights and access to the Services will be terminated, and Upsun will delete all Customer Projects and Content without undue delay, unless otherwise required by applicable law or as reasonably necessary for the establishment, exercise, or defense of legal claims. It is Customer’s sole responsibility to carry out any action necessary for the conservation or transfer of its Content. 

19.7. All sections of this Agreement, which, by their nature, extend beyond termination of this Agreement,  shall survive the expiration or termination of this Agreement to the fullest extent necessary for their enforcement and for the protection of the Party in whose favor they operate, including, without limitation, accrued rights to payment, confidentiality obligations, warranty disclaimers, and limitations of liability.

## **20\. Force Majeure**

20.1. Except for payment obligations of amounts due under this Agreement, neither Party will be responsible for failure or delay of performance if caused by: an act of war, hostility, terrorism, riot; strike or sabotage; an act of God, like epidemic, fire, or floods; energy crisis or electrical, internet, or telecommunication outage that is not caused by the obligated Party; government restrictions or embargoes; or other event outside the reasonable control of the obligated Party. Such failure or delay will not be deemed to constitute a breach of this Agreement, but such obligation will remain in full force and effect, and will be performed or satisfied as soon as reasonably practicable after the termination of the circumstances causing such failure or delay, provided that if such Party is prevented or delayed from performing for more than sixty (60) days, the other Party may terminate this Agreement upon fifteen (15) days’ prior written notice. Each Party will use reasonable efforts to mitigate the effect of a force majeure event.

## **21\. Export control**

21.1. Customer represents and warrants that Customer is not a restricted party (e.g., individual or entity that has been denied import or export privileges) and will comply with all applicable export control laws, regulations, and trade sanctions, including those emitted by the United Nation Security Council (UNSC), the US Government, the European Union or its Member States, the UK Government, the Government of Canada, and the Government of Australia. Customer further represents and warrants that: (i) Customer will not directly or indirectly use or allow Users to use the Services in a prohibited country (e.g., Cuba, Iran, North Korea, South Sudan, and Syria) or engage in any export or re-export activity with any entity or individual who Customer knows or has reason to know is engaging in the design, development, or production of nuclear, chemical, or biological weapons, or missile technology, and (ii) none of Customer, Customer’s affiliates, nor any of Customer’s directors, officers, employees, and none of the Users of the Service is a sanctioned person.

## **22\. Anti-bribery** 

22.1. Each Party shall comply with applicable laws concerning anti-bribery and anti-corruption, which may include the US Foreign Corrupt Practices Act of 1977, the French law of December 9, 2016 on transparency, the fight against corruption and the modernisation of economic life, known as "Sapin 2," and the UK Bribery Act 2010.

## **23\. Non-consumer service**

23.1. The Services are not designed primarily for personal, family, or household use, but rather are designed for purposes which are inside Customer’s trade, business, craft, or profession. As such, and to the fullest extent allowed by applicable law, Customer understands and agrees that this Agreement is primarily deemed to be entered into between two professionals. Nonetheless, if Customer qualifies as a consumer under applicable law, and applicable law provides consumers with consumer-specific, statutory and non-waivable rights, then any such statutory provision will prevail over any conflicting terms of this Agreement. 

23.2. If Customer is a UK or European Union resident: by agreeing to these Terms of Service, Customer consents to the immediate performance of this Agreement and acknowledges that it will lose its right of withdrawal from the Agreement once the ordered Services have been made available to Customer by Upsun.

## **24\. Notices**

24.1. Notices concerning the day-to-day operation of this Agreement shall be sent to:

24.1.1. Upsun via email through the Upsun support portal; and 

24.1.2. Customer by posting notices within the Platform or by email to the Customer Account owner listed in the Customer Account.

24.2. All other notices must be sent by email to the Customer Account owner and to legal@upsun.com, unless applicable law requires notice to be provided by an express courier (with confirmation) in which case notices shall be sent to the Upsun Contracting Entity address listed in section 2 or to the Customer’s billing address listed in the Customer Account.

24.3. The Parties may use emails to satisfy written notice or consent requirements under this Agreement. 

## **25\. Changes to this Agreement**

25.1. Upsun may, in its sole discretion, modify these Terms of Service or the Service Specific Terms from time to time. When Upsun makes a material change to these documents, Upsun will provide Customer and if applicable the Reseller with prominent notice of that change by displaying prominent notice within the Platform and/or by sending Customer and Reseller an email. To the extent any material change introduced by Upsun is materially less favorable to the Customer than the original term, Customer may, as its sole and exclusive remedy, terminate this Agreement or request that Reseller terminate the Reseller Order Form and obtain a pro-rata refund of any prepaid and unused Fees. Customer’s failure to terminate or request that the Reseller terminate this Agreement and request a pro-rata refund within thirty (30) days from the day Customer is informed about the change will be deemed acceptance of the revised terms.

## **26\. Governing law and jurisdiction**

26.1. The Parties undertake to take all steps to reach a mutual agreement to any dispute arising in relation to the validity, interpretation, or fulfillment of this Agreement.

26.2. When Platform.sh SAS doing business as Upsun is the Upsun Contracting Entity, the Parties agree that this Agreement will be governed by and construed under the laws of France, without regard to conflict of law principles. The United Nations Convention for the International Sale of Goods shall not apply. The Parties agree that all disputes and any claims arising out of or in connection with this Agreement and its subject matter shall be exclusively settled by the Commercial court of Paris or any court of competent jurisdiction in Paris (France).

26.3. When Platform.sh Ltd trading as Upsun is the Upsun Contracting Entity, the Parties agree that this Agreement will be governed by and construed under the laws of England and Wales, without regard to conflict of law principles. The United Nations Convention for the International Sale of Goods shall not apply. The courts of London (England) shall have exclusive jurisdiction to hear any dispute, claim, or controversy arising out of or relating to this Agreement or the breach, termination, enforcement, interpretation or validity thereof.

26.4. When Platform.sh Pty Ltd trading as Upsun is the Upsun Contracting Entity, the Parties agree that this Agreement shall be governed by the laws of New South Wales, Australia. The United Nations Convention for the International Sale of Goods shall not apply. The courts of Sydney, New South Wales (Australia) shall have exclusive jurisdiction to hear any dispute, claim, or controversy arising out of or relating to this Agreement or the breach, termination, enforcement, interpretation or validity thereof.

26.5. When Platform.sh Canada Sub Ltd doing business as Upsun Canada Sub is the Upsun Contracting Entity, the Parties agree that this Agreement will be governed by and construed under the laws of British Columbia (Canada) and the federal laws of Canada applicable therein, without regard to conflict of law principles. The United Nations Convention for the International Sale of Goods shall not apply. The courts of Vancouver, British Columbia (Canada) shall have exclusive jurisdiction to hear any dispute, claim, or controversy arising out of or relating to this Agreement or the breach, termination, enforcement, interpretation or validity thereof.

26.6. When Platform.sh Inc doing business as Upsun is the Upsun Contracting Entity, the Parties agree that this Agreement will be governed by and construed under the laws of the State of California, applicable to contracts between residents of that State and executed in and to be performed in that State, without regard to conflict of law principles. The United Nations Convention for the International Sale of Goods shall not apply. The courts of Los Angeles, California shall have exclusive jurisdiction to hear any dispute, claim, or controversy arising out of or relating to this Agreement or the breach, termination, enforcement, interpretation or validity thereof.

## **27\. Miscellaneous**

27.1. This Agreement is in English. Any translations produced in other languages are for convenience only. The English language version of this Agreement shall be controlling in all respects and shall prevail in the event of any inconsistencies with translated versions.

27.2. Except where expressly provided herein, no failure or delay by either Party in exercising any right or remedy under this Agreement will constitute a waiver of that right or remedy or any other right or remedy. 

27.3. The Parties to this Agreement are independent contractors. There is no relationship of agency, partnership, joint venture, employment, or franchise between the Parties. Neither Party nor its employees has the authority to bind or commit the other Party in any way or to incur any obligation on its behalf.

27.4. If a court of competent jurisdiction finds any provision of this Agreement invalid or unenforceable, that provision of the Agreement will be amended to achieve as nearly as possible the intent of the Parties, and the remainder of this Agreement will remain in full force and effect.

27.5. This Agreement shall constitute the entire agreement and understanding between Customer and Upsun and govern Customer’s use of the Services, superseding any prior or contemporaneous agreements, communications, and proposals, whether oral or written, between Customer and Upsun.

27.6. Neither Party may assign this Agreement without the prior written consent of the other Party, except that either Party may assign this Agreement without the prior written consent of the other Party, (i) to any of its Affiliates, (ii) in connection with a corporate reorganization, merger or consolidation of its business, or (iii) pursuant to the sale of all or substantially all of its assets. Notwithstanding the foregoing, for the purposes of verification and registration, if a Party assigns this Agreement in accordance with (i)-(iii) above, it will provide the other Party with prompt written notice and will together with its assignee provide and/or execute such additional documents and take such other actions as reasonably required by the other Party to register the assignment. 

27.7. Except as expressly set out herein, there are no third-party beneficiaries under this Agreement.

### [Index Egapro | Upsun](https://upsun.com/trust-center/ega-pro/)

Every year, Upsun calculates the Index Egapro, the mandatory French Index for professional equality between women and men.

## Results by year

## Detailed sub-results, 2025

**Global score: 81/100**

-   **Gender pay gap indicator:** 29
-   **Individual Increase Rate Variance between women and men:** 35
-   **High remuneration indicator:** 5
-   **Percentage of female employees who received an increase within one year of their return from maternity leave:** Not calculable

The score obtained is calculated over the reference period from January 1, 2025, to December 31, 2025.

### [EU Data Act Addendum](https://upsun.com/trust-center/legal/eu-data-act-addendum/)

This EU Data Act Addendum supplements either (i) the Terms of Services available at https://upsun.com/trust-center/legal/tos/ or (ii)  the written agreement entered into between Customer and Upsun, if any, collectively the “Agreement”.  It applies to  Upsun and Eligible Customers as defined below.

Capitalized terms not defined in this EU Data Act Addendum have the meaning given to them in the Agreement. 

## **1\. Definitions**

“**Deletion Request**” means the process whereby Customer requests the deletion of its Content.

“**Destination Provider**” means any other PaaS or IaaS provider chosen by Customer to replace Upsun as provider of PaaS or hosting services.

“**Eligible Customer**” (or “**Customer**” as used in this Data Act Addendum) refers to a customer with a registered address in the European Union or any customer to whom the EU Data Act is otherwise applicable. It does not include customers with a registered address in the UK, Norway or Switzerland.

“**EU Data Act**” means Regulation (EU) 2023/2854 of the European Parliament and the European Council dated December 13, 2023 regarding harmonized requirements for fair data access and fair data usage and to amend Regulation (EU) 2017/2394 and Directive (EU) 2020/1828.

“**Exportable Data**” means Customer Content and other exportable digital assets.

“**Switching**” means the process whereby Customer switches from using the Upsun Platform to the services of another provider or to an on-premises hosting infrastructure.

## **2\. Applicability and Scope**

2.1. This EU Data Act Addendum governs Switching or Deletion Requests made by Customer pursuant to the EU Data Act. 

2.2. In the event of any conflict between the terms of this EU Data Act Addendum and the Agreement, the terms of this EU Data Act Addendum will prevail solely with respect to the subject matter herein.

## **3\. Switching or Deletion process**

**3.1. Switching or Deletion Request notice.** Customer shall have the right to request either the switching or the complete deletion of their Exportable Data at any time, upon 2 months’ written notice to Upsun. Such requests must be formally submitted by completing the Switching or Deletion Request Form, located at https://upsun.com/trust-center/legal/eu-data-act-switching-request/, and transmitting the completed form to Upsun’s support team.

**3.2. Transitional Period**. Customer shall retrieve Exportable Data and migrate Exportable Data on another provider’s service within thirty (30) days from expiry of the notice period set forth above. Except that Customer may request, by written request to Upsun no less than eight (8) days prior to the beginning of the Transitional Period, the extension of the Transitional Period as Customer considers appropriate, provided that any such extension must be proportionate to the complexity of and amount of Exportable Data to be retrieved. There shall be no Transitional Period for a Deletion Request.

**3.3. Data Retrieval Period.** Customer will retain access to the Upsun Platform for data retrieval purposes for the longest of 30 days after expiry or the Transitional Period or until Customer notifies Upsun in writing of successful completion of switching.  There shall be no Data Retrieval Period for a Deletion Request.

## **4\. Continuity of Services during the Switching or Deletion process**

4.1.Throughout any Switching or Deletion process initiated by Customer pursuant to this Addendum, Upsun will act with due care and use commercially reasonable efforts to:

4.1.1. make all Exportable Data available to Customer in commonly-used, machine-readable, and interoperable formats, and shall provide access via standard export tools, APIs, or interfaces as further set forth in the data register available under https://developer.upsun.com/docs/registry;

4.1.2. provide clear information to Customer regarding export methods and known risk to business continuity during the switching process under https://developer.upsun.com/docs/core-concepts/common-tasks/exporting

4.1.3. maintain full operation of the Platform and uninterrupted access to the Platform and Customer Content, subject to the terms of the Agreement;

4.1.4. maintain the uptime commitments and support levels set forth in the applicable Service Specific Terms or as otherwise agreed in the Agreement; and 

4.1.5. maintain its then-current technical and organizational security measures, controls and standards.

## **5\. Assistance during Switching**

5.1. Upsun shall support the Customer’s exit strategy by providing commercially reasonable assistance to the Customer or to a third party designated by the Customer, and shall cooperate in good faith to facilitate the effective migration and export of Customer Data to a Destination Provider or to an on-premises infrastructure.

5.2. Such assistance shall primarily consist of guidance from Upsun Support teams enabling Customer or the third party mandated by Customer to perform self-service migration and data export using the tools, APIs, and documentation made available by Upsun. For the avoidance of doubt, Customer shall be solely responsible for exporting and verifying the completeness, accuracy, integrity, and successful migration of all Exportable Data it intends to switch to a third-party provider and for for the import and implementation of Exportable Data in its own systems or in the systems of the Destination Provider.

5.3. Unless otherwise expressly agreed in writing between the Parties, migration execution services (including direct data transfer to a third-party provider, or reconfiguration of environments) are not included within the standard assistance obligations under this Addendum. However, Upsun may provide advanced migration assistance or professional services, subject to separate agreement and applicable additional fees.

## **6\. Termination of the Agreement and consequences of Termination**

6.1 Services and the corresponding Agreement shall be considered to be terminated and Upsun will notify Customer of the termination upon  (i)  expiry of the Data Deletion Request, or, in the event of a Switching Request (ii) when Customer notifies Upsun in writing of the successful completion of switching or, if later, 30 days after expiry of the Transitional Period, (in each case the “**Effective Date of Termination**”).

6.2. Where a Switching or Deletion Request applies only to a portion of the Projects governed by an existing Agreement, the Parties shall negotiate in good faith and execute a written amendment or addendum to the Agreement to reflect the reduced scope of Services and applicable fees. 

## **7\. Data Deletion.** 

7.1. Upon the Effective Date of Termination, Upsun will delete Exportable Data subject to the Deletion or Switching Request, except for any Exportable Data which Upsun is obligated to store under EU or national laws.

## **8\. Fees**

### **8.1. Continuity of Service Fees**

8.1.1. Customer shall remain responsible for payment of all recurring fees, usage-based charges, spend commitment and any other applicable amounts under the Agreement until the Effective Date of Termination as set forth in 6.1 above.

### **8.2. Early Termination penalty** 

8.2.1. Customer shall, upon the Effective Date of Termination, be released from payment of recurring service fees or minimum spend commitments that would otherwise have become due for the remaining portion of the Agreement.

8.2.2. Notwithstanding the foregoing, Customer shall be required to pay an early termination penalty fee, consisting of the following components:

(i) **Total Discounted Amount**: The sum of all discounts applied under the Agreement,  if any, from the Agreement’s inception up to the Early Termination Date.

(ii) **Base Fee:** 30% of the undiscounted contract amount from the Early Termination Date until the end of the original term of the  Agreement.

(iii) **Customisation Fee** (if applicable): The full, undiscounted contractually-agreed fee for bespoke development, configuration, integration, or other technical or functional tailoring of the services specifically for the Customer.

8.2.3. The early termination penalty shall become due and payable upon the Effective Date of Termination.

### [EU  Data Act disclosure on switching provider](https://upsun.com/trust-center/legal/eu-data-act-switching-provider/)

## **Introduction** 

In compliance with articles 26 and 28 of the EU Data Act (Regulation (EU) 2023/2854), this disclosure:

1.  outlines the methods and procedures for Upsun customers to switch to another service provider or migrate data to their own on-premises infrastructure, and 
2.  provides information on the jurisdiction governing the Upsun Platform and the protective measures against international governmental access to customer content.

## **1\. Available Switching & Porting Methods**

### **1.1. Self-Service Portability.**

Customers can access and export data through the following mechanisms:

-   **Management API**: Upsun exposes a comprehensive REST API covering the full lifecycle of organizations, projects, environments, deployments, and configuration. The API is documented via OpenAPI specifications and publicly available at: https://docs.upsun.com/api/ 
-   **Command Line Interface (CLI)**: The Upsun CLI provides programmatic access to platform resources and allows customers to retrieve configuration, metadata, logs, and environment information using API-backed commands: https://docs.upsun.com/administration/cli.html 
-   **Git Repository Access**: Application source code and configuration stored on Upsun is accessible via Git. Customers can retrieve the full repository history using standard Git operations.
-   **Service-Level Data Export**: Persistent services (such as databases or other stateful services) can export their stored data using standard service-specific tools and formats. Documentation for exporting data is available at:  https://docs.upsun.com/learn/tutorials/exporting.html 

### **1.2. Data Transport**

Exportable data may be transferred by customers using common secure methods including:

-   Secure download via HTTPS and SSH
-   Secure file transfer protocols (sFTP)
-   Git repository synchronization

## **2\. Data Formats & Interoperability Specifications**

Upsun enables data portability using widely-adopted open formats and protocols.

### **2.1. Exportable Data Categories**

Customer data that can be exported includes, but is not limited to:

-   Application source code and configuration files repositories
-   Persistent service data and stored files
-   Project, organization, and environment metadata
-   Logs
-   Backups
-   Environment variables and routing configuration

A full inventory of data categories is maintained in the Upsun Data Register, available at: https://developer.upsun.com/docs/registry

### **2.2. Technical Formats**

Exported data may be retrieved in commonly used technical formats including:

-   Git repositories (source code and history)
-   JSON (API responses and configuration metadata)
-   YAML (application and infrastructure configuration)
-   SQL dumps or database-native export formats for relational databases
-   CSV or text formats for certain logs and datasets
-   Binary archives for backups

These formats are widely supported by common development tools and cloud environments.

### **2.3. Standards Compliance**

Upsun relies on widely adopted open standards and protocols, including:

-   Git distributed version control system
-   REST APIs documented using the OpenAPI specification
-   Standard database export formats for supported database engines
-   HTTPS for secure data transport

## **3\. Technical Restrictions & Known Limitations**

While Upsun supports customer data portability, certain technical characteristics of cloud-native platforms may affect migration workflows.

### **3.1. Volume Limits**

Upsun does not impose platform-specific restrictions on the volume of customer data that can be exported. However, exports may be subject to:

-   network bandwidth limitations
-   resource constraints of the originating environment
-   service-specific export mechanisms

### **3.2. Transformation Requirements**

Some exported data may require reconfiguration before being used in another environment. Examples include:

-   environment-specific configuration values
-   infrastructure definitions referencing Upsun-specific services
-   deployment configuration files tailored to Upsun’s build and runtime model

### **3.4. Compatibility**

Upsun supports widely adopted open formats and standards to maximize portability. However:

-   infrastructure definitions written for Upsun may require adaptation when deployed on other cloud providers
-   service configuration may need adjustment depending on the destination platform’s capabilities
-   some operational metadata used internally by Upsun is platform-specific and may not be applicable in external environments

These limitations are typical for platform-as-a-service environments and do not prevent customers from exporting their application data and code.

## **4.  Continuity and Support**

-   **Uptime and Support Levels:** Throughout the switching process, Upsun will maintain full service operation and data access  and the uptime and support level as detailed in the Service Specific Terms or as agreed upon in the customer contract.
-   **Assistance:** The Upsun support team provides commercially reasonable assistance, focusing on guiding the customer with self-serve migration and data export using Upsun-provided tools. Migration services are not included; however, advanced migration assistance is available upon request for an additional fee. 

## **5\. The Switching Process & Timeline**

Customers who fall within the scope of the EU Data Act can inform Upsun of their request to switch providers or delete data at any time, provided they give two months' notice. This can be done by filling out the switching request form, available at https://upsun.com/trust-center/legal/eu-data-act-switching-request/, and submitting it to Upsun's support team.

The switching process is subject to the notification and timelines set out below:

-   **Notice Period:** 2 months
-   **Transition Period:** 30 days, extendable once by customer upon written notice to Upsun’s support team. 
-   **Data Retrieval period**: 30 days
-   **Data Erasure**:  Upsun may permanently delete Projects subject to the switching or data deletion request upon confirmation of successful completion of switching from the customer or upon expiry of the data deletion request notice period.

Note: Transition Period and Data Retrieval Period will be waived in case of data deletion request.

##  **6. Financial Terms** 

-   **Continuity of Service Fees:** Upsun maintains full service operation and data access throughout the switching process (including the Data Retrieval Period). The customer is responsible for and must pay all recurring fees and charges for Upsun services until the switching process is successfully completed or data is erased.
-   **Early Termination Penalties:**  Customers who fall within the scope of the EU Data Act will be exempt from payment of recurring service fees or spend commitments otherwise due for the remainder of their contract term, following successful completion of the switching process or data erasure.

However, an early termination penalty fee will apply, consisting of the following components:

(i) **Total Discounted Amount**: The sum of all discounts, if any,  applied from the contract's inception up to the early termination date.

(ii) **Base Fee**: 30% of the remaining undiscounted contract amount from the early termination date until the end of the original contract term.

(iii) **Customisation Fee** (if applicable): The full, undiscounted contractually-agreed fee for bespoke development, configuration, integration, or other technical or functional tailoring of the services specifically for the customer.

For the avoidance of doubt, customers who do not fall within the scope of the EU Data Act  are not subject to the early termination penalty set forth above but remain responsible for the payment of all recurring service fees or spend commitments for the remainder of their contract term.

## **7\. Infrastructure Jurisdiction**

-   The ICT Infrastructure is subject to the laws of the country where the ICT Infrastructure is located. Customers determine the location of the ICT Infrastructure when electing a hosting region for their project: https://docs.upsun.com/development/regions.html.
-   Sub-Processor locations: https://upsun.com/trust-center/privacy/subprocessor-list/.

## **8\. Security Measures and  Protection Against International Governmental Access**

-   **Security Measures:** Security measures described in the relevant security and privacy sections in our Trust Center shall apply throughout the duration of the contract  and the switching process.
-   **Law Enforcement Requests**. Upsun will usually inform customers if authorities request their data unless prohibited by law. If Law Enforcement Authorities wish to restrict customer notification, they should provide a court order or legal authority preventing Upsun from informing the customer.

### [Acceptable Use Policy | Upsun](https://upsun.com/trust-center/legal/aup/)

## **1\. Scope and definitions**

1.1. This Acceptable Use Policy applies to the use of the Upsun and/or Blackfire Services by any authorized User of the Services.

1.2. In this Acceptable Use Policy:

1.2.1. “**You**” refers to you as a Customer or as an individual authorized to use the Services by the Upsun Customer. 

1.2.2. “**Upsun Site**” refers to Platform.sh, Upsun and Blackfire commercial websites, Services, API, Documentation (as defined in the Agreement) and other online resources made available by Upsun, but excluding Customer sites which are subdomains under eu.platform.sh, .us.platform.sh, .platformsh.site, .upsun.app, and .upsunapp.com.

1.2.3. Other capitalized terms have the meaning stated in the applicable agreement between the Customer and Upsun (the “Agreement”). 

##  **2. Prohibited Users**

2.1. You are not allowed to use the Services if You are (i) under the age of majority in your state, province, or country of residence, or 16 years of age, whichever is greater, or if You are (ii) located in a sanctioned country or are yourself a sanctioned person, i.e. if You are listed in any sanctions-related list of designated persons maintained by the Office of Foreign Assets Control of the U.S. Department of the Treasury, the U.S. Department of State, the United Nations Security Council, the European Union, any European Union member state, the UK Government, under Canada's SEMA and JVCFOA acts, or Australia's Department of Foreign Affairs and Trade or are a person owned or controlled by any such person. 

## **3\. Compliance with applicable laws and regulations** 

3.1. At all times, Your use of and access to the Services must be in compliance with any applicable local, state, national, and international law or regulation, including, but not limited to, all applicable data protection laws and regulations, and all applicable export control laws and regulations.

## **4\. Respect of Upsun Intellectual Property**

4.1. You are not allowed to copy, republish, reverse-engineer, decompile, disassemble, or otherwise attempt to discover the source code or underlying ideas or algorithms of the Services; modify, translate, or create derivative works based on the Services; rent, lease, distribute, sell, resell, assign, or otherwise transfer intellectual property rights of the Services; use the Services for time-sharing or service bureau purposes or otherwise for the benefit of a third party; remove any trademark or proprietary notices from the Services. 

## **5\. Prohibited Content**

5.1. You may not use the Services to store, transmit, display, or process Content that is, or that Upsun may determine in its sole discretion, to be or constitute:  

5.1.1. unlawful, offensive, threatening, harmful, libelous, malicious, defamatory, pornographic, obscene, racist, infringing, or otherwise objectionable; 

5.1.2. an infringement of any patent, trademark, copyright, trade secret, or other proprietary right of a third party, and Content;

5.1.3. not wholly owned by or validly licensed to You; 

5.1.4. fraud;

5.1.5. violation of a third party's privacy; 

5.1.6. breach of the Agreement; 

5.1.7. false expression or implication that Your Content is sponsored or endorsed by Upsun;

5.1.8. a promotion or facilitation of illegal gambling, illegal export;

5.1.9. a discrimination based on race, sex, religion, nationality, disability, sexual orientation, age, or otherwise; 

5.1.10. viruses, unauthorized data, malware, trojan horses, spyware, worms, or other harmful or corrupted components. 

5.2. You acknowledge that Upsun does not have the capacity or the obligation to intervene directly on the Content and as such, You are solely responsible and liable for reviewing the Content and to immediately remove any Content that breaches this Acceptable Use Policy upon first request of Upsun or upon becoming aware of any such breach. 

## **6\. Prohibited activities and actions** 

6.1. You agree not to use the Services:

6.1.1. in high-risk activities, where their use or failure could reasonably be expected to lead to death, personal injury, or environmental or property damage (such as, but not limited to, the creation or operation of any military, nuclear-engineering, aviation- and/or automotive-engineering purposes or software applications related thereto or in connection with any software application that is used in connection with monitoring or assessing human health or as a life support system);

6.1.2. for the purpose of exploiting, harming, or attempting to exploit or harm minors in any way by exposing them to inappropriate content, asking for personally identifiable information, or otherwise;

6.1.3. to transmit, or procure the sending of, any unsolicited advertising or promotional material, including any “junk mail”,“chain letter,” or “spam,” or any other similar unsolicited solicitation;

6.1.4. to offer or disseminate fraudulent goods, services, promotions, make-money-fast schemes, ponzi and pyramid schemes;

6.1.5. to impersonate, or collect of personally identifying or other information about other Upsun customers or their users’ use of information obtained from or through the Services, for the purpose of direct marketing, spamming, unsolicited contacting, phishing, or pharming

6.1.6. to infringe or violate the intellectual property rights or proprietary rights, rights of publicity or privacy, or other rights of any third party;

6.1.7. to advertise or sell firearms or accessories or parts that convert firearms as defined by “Category A – Prohibited Firearms” under the European Directive (EU) 2021/555. Upsun may accord, at its sole discretion, specific explicit waivers for sites falling under this category, but that exclusively target business-to-business or government buyers;

6.1.8. in any way that is harmful, fraudulent, deceptive, threatening, abusive, harassing, tortious, defamatory, vulgar, obscene, libelous, or unlawful;

6.1.9. to impersonate or attempt to impersonate Upsun, an Upsun employee, another user, or any other person or entity (including, without limitation, by using e-mail addresses or screen names associated with any of the foregoing);

6.1.10 to knowingly engage in any other conduct that restricts or inhibits anyone’s use of the Upsun Site or Services, or which, as determined by us, may harm  Upsun, the Upsun Site or Services, users of the Upsun Site or Services or expose them to liability.

6.2. Additionally, You agree not to:

6.2.1. use Your site or mobile applications or any technological device or process in any manner that You know or reasonably should know could disable, overburden, damage, or impair the Upsun Site or interfere with any other party’s use of the  Upsun Site, Upsun mobile applications, or Services, including their ability to engage in real-time activities through the same;

6.2.2. use any robot, spider, or other automatic device, process, or means to access the Upsun Site or any of its content or any Services in a fashion that may result in excessive resource use or disruption or interruption of the Service; 

6.2.3. use any manual process to monitor or copy any of the material on the Upsun Site or any other content of Upsun or for any other unauthorized purpose without Upsun prior written consent;

6.2.4. use any device, software, or routine that knowingly interferes with the proper working of the Upsun Site or the provision of the Services;

6.2.5. introduce any viruses, trojan horses, worms, logic bombs, or other material which is malicious or technologically harmful;

6.2.6. attempt to gain unauthorized access to, or knowingly interfere with, damage or disrupt any parts of the Upsun Site, the infrastructure on which the Upsun Site or Services are stored, or any server, computer, or database connected to the Upsun Site or Services, or perform any of these actions from the Service;

6.2.7. attack the Upsun Site or the Services via a denial-of-service attack or a distributed denial-of-service attack,  or perform any of these actions from the Service; 

6.2.8. interfere with, modify, disrupt, or disable features or functionality of Upsun, including without limitation any such mechanism used to restrict or control the functionality, or defeat, avoid, bypass, remove, deactivate, or otherwise circumvent any software protection or monitoring mechanisms of the Services;

6.2.9. use the Services for intense computational calculation, for instance, but not limited to, cryptomining, movie or video transcoding, real-time computer vision (except with Upsun prior written consent);

6.2.10. use the Services as a traffic relay, connection-proxying, Tor exit node, or as a service with intention of anonymizing traffic;

6.2.11. use the Services to monitor, scan, or crawl servers, hosts, websites and/or their contents (except with Upsun prior written consent); 

6.2.12. otherwise knowingly interfere with the proper working of the Upsun Site or the proper provision of the Services.

## **7\. Protection of reputation**

7.1. Neither You or Upsun will take any action or make any statement which is intended to, or would reasonably be expected to, harm the other Party's reputation, or which would reasonably be expected to lead to unwanted or unfavorable publicity to the other Party.  

7.2. The foregoing provision on protection of reputation shall not apply to (a) compliance with any legal process, subpoena, or applicable law, rule, or regulation, (b) statements in response to authorized inquiry from a court, regulatory body, or law enforcement agency, or (c) disclosure of security incidents or data breaches as required by applicable law or industry standards. 

7.3. Upsun does not actively monitor Your Content. However, if You become involved in highly controversial activities, if Your Content includes highly controversial material, or if You take part in highly controversial events that may reasonably be expected to cause significant harm to Upsun reputation, Upsun reserves the right to take any preventive or corrective actions it deems appropriate, as further detailed in section Enforcement of this Acceptable Use Policy below.

## **8\. Reporting Violations of this Policy**

8.1. If You become aware of any violation of this Acceptable Use Policy, you will immediately notify Upsun and stop or remedy the violation. To report any violation of this Acceptable Use Policy, please contact abuse@upsun.com.

## **9\. Changes to this Acceptable Use Policy**

9.1. Upsun may change this Acceptable Use Policy from time to time at its sole discretion. In accordance with Upsun Terms or Services, You will be notified of any material change, and Your continued use of the Services after a material change will constitute Your consent to such change. If You don’t agree to the revised Acceptable Use Policy, Your sole and exclusive remedy is to stop using the Services.

## **10\. Enforcement of this Acceptable Use Policy** 

10.1. Upsun reserves the right, but shall be under no obligation, to review Your Content, Your Account, and Your use of the Services for fraud and abuse prevention, and for the purpose of monitoring Your compliance with this Acceptable Use Policy, and may, at its sole discretion, engage third parties for identity verification and abuse reporting.

10.2. If You use the Services in a way that Upsun reasonably believes violates or may violate this Acceptable Use Policy, Upsun may, at its sole discretion, take any preventive or responsive action it deems appropriate, such as:

10.2.1. reaching out to You and asking You to promptly and validly demonstrate that You are not a Prohibited User, or that Your Content and activities and actions are not violating this Acceptable Use Policy,

10.2.2. issuing a formal written warning outlining the specific violation and requesting immediate compliance with this Acceptable Use Policy,

10.2.3. temporarily suspending Your Account and/or Project until the violation is remedied or issue is resolved, or 

10.2.4. terminating Your Account and/or permanently deleting Your Project.  

10.3. The above-listed preventive and responsive actions are without limitation and without prejudice to other rights and remedies available to Upsun under the applicable agreement between You and Upsun, at law or in equity. Upsun reserves the right to  initiate legal proceedings against You and to report any activity that violates any applicable law or regulation to the appropriate law enforcement officials, regulators, or other appropriate third parties.

### [Professional Services Supplemental Terms Upsun](https://upsun.com/trust-center/legal/professional-services-terms/)

These Professional Services Supplemental Terms apply to Customers ordering Professional Services from Upsun under a Statement of Work.

Capitalized terms not defined in these Professional Services Supplemental Terms have the meaning given to them in (i) the Statement of Work, (ii) the Platform Terms or (iii) in any other document incorporated by reference therein.

## **1\. Definitions** 

-   “**Deliverables**” means all documents, work products, and other materials prepared by or on behalf of Upsun in the course of performing the Services, and excluding general or technical documentation on the Upsun core PaaS offering available to all Upsun customers. 
-   **“Fees”** means the fees set out in the relevant Statement of Work.
-   “**Personnel**” means all Upsun personnel involved in the performance of  the Professional Services ordered by Customer.
-   **“Platform Terms”** shall have the meaning given to it in the Statement of Work. 
-   **“Professional Services”** means all advisory, technical, implementation, and migration services, as distinct from Upsun’s core PaaS offering, provided under the relevant SOW. These services may include, but are not limited to, initial onboarding, setup and go-live assistance, training and knowledge transfer on the Upsun core PaaS offering, data or application migration services, and application monitoring, performance review and maintenance services. Professional Services, however, expressly excludes support services, which are provided as part of the core PaaS offering.
-   **“Statement of Work”** or **"SOW"** means any Statement of Work entered into by the Parties that describes Professional Services to be performed by Upsun.

## **2\. Order of Professional Services** 

2.1. Customers can order Professional Services from Upsun through signature of a Statement of Work. 

2.2. Unless otherwise expressly agreed upon in a Statement of Work, all Professional Services shall be performed by Upsun remotely. Upsun Personnel shall not be required to travel to Customer’s or any third party’s premises for the performance of the Professional Services.

2.3. Unless otherwise specified in the  Statement of Work, any unused Professional Services will expire 12 months from the Effective Date of the Statement of Work, and Customer will not be entitled to receive a refund for any Fees prepaid for such expired Professional Services.

## **3\. Obligation of Upsun**

3.1. Upsun will appoint suitably skilled, experienced and qualified Personnel to perform the Professional Services.

3.2. Prior to any Upsun Personnel commencing Professional Services hereunder, Upsun shall ensure that such Personnel:

3.2.1. Are bound by written confidentiality obligations;

3.2.2. Have successfully undergone background checks conducted by or on behalf of Upsun;

3.2.3. Comply with all rules, regulations, and policies of Customer that have been communicated to Upsun in writing in advance of the Professional Services start date, including all security procedures concerning Customer’s systems, data, and remote access.

3.3. Upsun shall:

3.3.1. review and test any suggested change in Customer Content or application code  in compliance with section 8.2.1. before submitting the acceptance request to the Customer,

3.3.2. only work in development or staging environments and shall not work in production environments, unless expressly requested to do so in writing by the Customer. 

3.4. Unless expressly stated otherwise in a Statement of Work, Upsun does not intervene on and is not responsible for Customer’s overall application architecture, business logic, or third-party integrations.

## **4\. Obligations of Customer**

4.1. Delivery of the Professional Services is contingent upon Customer’s full and prompt cooperation. Accordingly, Customer shall:

4.1.1. proactively inform Upsun about any fact, condition, or circumstance of material importance or that could reasonably be expected to affect, delay or otherwise impact Upsun’s performance of the Professional Services; 

4.1.2. promptly respond to all inquiries and requests for information from Upsun;

4.1.3. perform all necessary actions, approvals, and decisions reasonably requested by Upsun, each within the timeframe specified by Upsun or, if no timeframe is specified, within a reasonable time.

4.2. Customer shall, in a timely manner and solely when necessary and for the purpose of enabling Upsun to perform the Professional Services, grant Upsun access to Customer's Content, Console, network and systems required for Upsun to provide the Professional Services. Customer shall be solely responsible for revoking such access immediately upon the completion or expiry of the Professional Services.

4.3. Customer is responsible for the accuracy, quality, legality, completeness, and integrity of information, documentation, data, systems and networks provided to Upsun by Customer.

4.4. Customer shall:

4.4.1. maintain backups of its Content and application code, 

4.4.2. review and test Deliverables in development or staging environments before releasing into production,

4.4.3. retain ultimate responsibility for application behavior and production deployment decisions. 

## **5\. Acceptance** 

5.1. Upon completion of a Deliverable or Professional Service, Upsun shall submit it for acceptance to the Customer contact identified in the SOW via email or through the issue tracking system used by the Parties.. 

5.2. Customer must notify Upsun of acceptance or rejection in writing (which may be via email) within five (5) business days from the acceptance request. Failure by Customer to notify Upsun of rejection within this time frame and/or production deployment of a Deliverable shall be deemed acceptance of the Deliverable. 

5.3. In the event Customer rejects a Deliverable or Professional Service, Customer must provide written grounds of its rejection. The Parties will then discuss such grounds, and, to the extent within its control or responsibility scope, Upsun shall use commercially reasonable efforts to correct or re-perform the Deliverable or Professional Service at no additional cost to the Customer.

## **6\. Change management**

6.1. Any change to the scope of Professional Services, timeline, Deliverables, or other terms listed on the SOW must be formally requested to Upsun by Customer via email. 

6.2. Upon receipt, the Parties will discuss the proposed change. Any adjusted scope, timeline, Deliverable, or term and associated Fee will be agreed upon between the Parties in writing.

## **7\. Fees**

7.1. Customer will pay Upsun the Professional Service Fees set out in the SOW.

7.2. Where the Professional Services are provided on a time and materials basis:

7.2.1. The Fees payable for the Professional Services shall be calculated in accordance with Upsun's  daily or hourly rates set forth in the applicable Statement of Work;

7.2.2. Upsun shall issue invoices to Customer monthly in arrears for Fees for the immediately preceding month.

7.3. Where the Professional Services are provided for a fixed Fee or number  of hours, invoices will be sent upfront or as otherwise agreed in the applicable Statement of Work.

7.4. Upsun shall maintain complete and accurate records of the time spent and materials used by Upsun in providing the Professional Services. 

7.5. Customer agrees to reimburse Upsun for all travel and other expenses incurred by Upsun in connection with the performance of the Professional Services provided they have been approved in advance in writing by Customer.

7.6. Customer acknowledges that Professional Services may result in modifications to application code, system or application configurations, project resources, or data transfer. Customer shall be responsible for all Platform costs incurred in connection with or resulting from such Professional Services, including any usage, consumption, or other charges.

## **8\. Security** 

8.1. To the extent that the performance of Professional Services requires access to Customer’s consoles, applications, systems, or network infrastructure, 

8.1.1. Customer shall:

8.1.1.1. refrain from transmitting credentials via unencrypted email. All credentials must be exchanged via a secure, encrypted password management system or an alternative secure channel,

8.1.1.2. restrict such access solely to the resources and permissions strictly necessary for the performance of the Services.

8.1.2. Upsun shall:

8.1.2.1. ensure that the credentials shared by Customer are kept confidential and are not shared between several individuals. 

8.2 Upsun shall:

8.2.1. follow internal guidelines for secure code intervention, including manual peer review of code changes and adherence to Upsun’s general security standards, 

8.2.2. use encrypted data transfer protocols and secure temporary storage.

8.3. For the avoidance of doubt, security of the Customer application and code is the primarily responsibility of the Customer, including the implementation and operation of any security testing tools (such as SAST/DAST) and the final validation of all code changes before production deployment.

## **9\. Warranty**

9.1. Upsun warrants that any Professional Services will be performed in a professional and workmanlike manner in accordance with industry standards and substantially in accordance with the SOW. In the event of a breach of this warranty, Upsun will use commercially reasonable efforts to re-perform the Professional Services to correct the non-conformity, at no charge to Customer. 

## **10\. Intellectual Property**

10.1. Subject to full payment of the Fees, Upsun will assign all intellectual property rights in the Deliverable to the Customer.

10.2. Customer hereby grants Upsun a limited right to use any Customer Content or materials provided or made available to Upsun in connection with the Professional Services solely for the purpose of providing Professional l Services to Customer. Customer will retain all rights (including all intellectual property rights) in the Customer Content and materials. Customer represents and warrants to Upsun that Customer has sufficient rights in the Customer Content and materials to grant such rights to Upsun and that the Customer Content and materials do not infringe or violate the intellectual property, publicity, privacy or other rights of any third party.

## **11\. Liability** 

11.1. If Upsun's performance of its obligations under this Agreement is prevented or delayed by any act or omission of Customer  or its agents, subcontractors, consultants, or employees, Upsun shall not be deemed in breach of its obligations under this Agreement or otherwise liable for any costs, charges, or losses sustained or incurred by Customer, in each case, to the extent arising directly or indirectly from such prevention or delay.

11.2. Notwithstanding anything to the contrary in the Platform Terms, Upsun's total aggregate liability under or in connection with these Professional Services Supplemental Terms and the applicable SOW, regardless of the form of action, shall be limited to the total amount of Fees paid by Customer to Upsun under the applicable SOW for the Professional Services giving rise to the claim.

### [ IaaS Resources | Upsun](https://upsun.com/trust-center/security/iaas-resources/)

AWS

-   Compliance Page
-   Security white paper

Azure

-   Trust Center
-   Security Page
-   Data Retention

Google Cloud Platform

-   Compliance Information
-   Security Page

OVHcloud Public Cloud

-   Compliance and certification page

### [SOC 2 Type 2 | Upsun](https://upsun.com/trust-center/security/soc2/)

SOC 2 examination reports provide assurance of controls at service organizations relevant to cloud security.  The reports are commonly used by cloud service providers to demonstrate the security of their service(s) to customers, without the customers having to engage in costly audits with the service provider directly.

To demonstrate our commitment to security, Upsun engages a third-party auditor to produce a SOC 2 Type 2 examination report that includes a review of controls relevant to security, availability, and privacy.  The annual audit covers Upsun Platform-as-a-Service (PaaS) product as well as the Blackfire APM product.

Our most current SOC 2 Type 2 report can be obtained from a sales or account representative.

## Regions

### [Our cloud data center locations | Upsun](https://upsun.com/regions)

Deploy globally, _comply locally_

Each data center region lets you deploy the same application setup within a specific geography. This keeps data local, improves performance, supports regional compliance, and enables on-demand migrations to lower-carbon regions.

To help meet your environmental goals, Upsun identifies low-carbon intensity regions with a "Green" label. Projects deployed in these regions, including our Moses Lake (US West) location, automatically receive a 3% discount on resource usage.

Our cloud data center locations | Upsun

Discover our global cloud datacenter locations and datacenter regions which keep your data available, confidential, and compliant.

Sydney, Australia

APAC

AWS

Azure

Montreal, Canada

North America

Zurich, Switzerland

Europe

GCP

Frankfurt, Germany

Stockholm, Sweden

Dublin, Ireland

Gravelines, France

OVH

Paris, France

London, United Kingdom

Washington, US East

Moses Lake, US West

Charleston, US East

## Data center

## CDN Point of Presence

Many customers can also benefit from Managed CDN. We provide more than 60 points of presence (POPs). Contact our team to learn more.

We usually consider a region “greener” when it has a carbon density <100 C02e/kwh. Carbon intensity data sourced from IEA 2024, ElectricityMaps 2025.

## Blog Posts

### [Break things fast: accelerated QA and testing | Upsun](https://upsun.com/blog/accelerated-qa-and-testing-presentation/)

# Break things fast: accelerated QA and testing

_For a quick read-through of the main takeaways, keep scrolling for our distilled write-up. We utilized ChatGPT to enhance the grammar and syntax._

* * *

When you hear the phrase _“move fast and break things,”_ you might picture a high-octane startup, shipping code at warp speed—sometimes at the expense of stability. But I’d like to offer a twist on that famous line: move fast and break things _on purpose_. Because in software development, you’re either finding problems early or fixing them _much_ later at a steeper price. Proper testing and QA are how you break things quickly, learn from them, and ensure a reliable release for your end users.

In this post, I’ll walk through:

1.  Why testing early and often is crucial.
2.  The pitfalls of testing in production (and why you usually shouldn’t).
3.  How Upsun’s cloned environments can help you “test in production” without exposing your real users to risk.
4.  Practical steps to integrate these ideas into your workflow.

## The high cost of bugs in production

A common statistic in our industry is that bugs discovered in production can be up to **30 times more expensive** to fix than those caught earlier. Why? Because once an issue hits production, it has ripple effects:

-   **Unhappy users**—They can lose confidence in your platform or product.
-   **Brand and revenue impact**—Downtime or broken features often mean lost sales.
-   **Opportunity cost**—Time spent patching production issues is time not spent on new features or improvements.

In a perfect world, you want to find those bugs long before your end users do—and fix them before they become expensive fires to put out.

## Why “move fast and break things” still matters

Mark Zuckerberg’s 2012 quote—_“Move fast and break things. Unless you are breaking stuff, you are not moving fast enough.”_—captures a core truth about innovation: it requires constant iteration and risk-taking. Testing is essentially about _breaking stuff_ to see how and why it fails. The faster you break it, the faster you can fix it.

When it comes to QA, I like to say:

> _Move fast and break things…unless you’re breaking stuff, you’re not really testing or moving fast._

The goal of QA isn’t to _avoid_ breaking things—it’s to break them _as early and safely as possible_. Once you’ve identified the weak points, you fix them, refine, and iterate.

## Testing in production: the perennial temptation

What if you just deployed changes straight to production to “see if it works”? Testing in production offers immediate feedback, real-world data, and a truly realistic environment. But it also includes the single biggest risk factor: **real users** who expect everything to work flawlessly. One deployment gone wrong could mean downtime, data loss, or bad press.

### Is there a middle ground?

Yes. If you could replicate production _exactly_—including databases, services, and configurations—but without real users—you’d get all the benefits of testing in production while keeping your real environment (and your job!) safe. That’s where Upsun shines.

## Cloned environments with Upsun

Upsun provides **full-stack cloned environments** (often called “preview environments”) that replicate your production setup in minutes, minus real user traffic. Here’s what it looks like in practice:

1.  **Create a branch**: Since Upsun is Git-based, you simply create a new branch.
2.  **Spin up a cloned environment**: Upsun copies _everything_—the entire infrastructure, database, services, configurations—so your new environment is effectively “production” without end users.
3.  **Iterate quickly**: You can break, fix, and retest your changes _in this environment_, confident that any bug you encounter here would appear in real production too.
4.  **Merge and deploy**: Once it works in the cloned environment, merging into the main branch and deploying is straightforward.

All told, you don’t spend weeks or months setting up a dedicated QA server. Instead, you push your code and let Upsun handle the replicating magic behind the scenes.

## Collaborating with multiple developers

When there’s just one developer, testing and deployment are already simpler. But real teams complicate everything—_especially_ when multiple devs are making changes at once. With Upsun:

-   **Everyone can clone production**: Each developer spins up a unique environment that mirrors production. They break, test, and fix at will—without stepping on each other’s toes.
-   **No more environment brawls**: Tired of “it works on my machine” or merge conflicts in a single staging environment? Each dev has a personal environment, and merges happen only when their work is confirmed stable.
-   **Fast iteration**: By the time you merge changes upstream, you’ve _already_ validated them in an environment that matches production.

## Handling sensitive data

Of course, production clones raise questions about privacy and compliance. With Upsun:

-   **Data anonymization**: You can sanitize or anonymize any data that crosses over. That means protecting PII (Personally Identifiable Information) and staying compliant with regulations.
-   **Access control**: Not every team member needs full production-level data. You can manage access so that only the right people or branches get the sensitive details—or none at all.

## The payoff: faster, safer testing

When you leverage robust, production-like environments, you test faster and more accurately. You:

1.  **Reduce risk**: Catch issues pre-production, shield real users from big disruptions.
2.  **Deliver higher quality**: More thorough QA cycles mean fewer bugs ship.
3.  **Boost velocity**: Rapid iteration keeps you focused on building features, not firefighting.
4.  **Increase customer satisfaction**: Stable, reliable software translates to happier users (and higher retention).

A well-known data point shows that when organizations adopt solid QA practices—and can _trust_ their environment parity—they often see a **40% increase** in customer satisfaction. That’s no coincidence.

## Three takeaways to “break things faster”

Whether or not you use Upsun, here are three universal tips for any modern development process:

**Change your mindset**  
Don’t fear breaking things—_embrace_ it, because every break reveals exactly what needs to be fixed. It’s better to fail fast in a controlled environment than fail big in production.

**Leverage real testing environments**  
Testing “in production” sounds edgy but is usually reckless. Instead, build or adopt systems that replicate your production stack—without real users involved. This approach uncovers environment-specific issues in a safe, controlled space.

**Automate everything**  
Quick iteration demands automated pipelines. Continuous Integration/Continuous Deployment (CI/CD) is a must. The less manual work involved, the more you can focus on building cool stuff while your pipeline handles deployments, checks, and tests.

## QA (from the live session)

**Q: How does Upsun handle database cloning and anonymization?**  
A: You have flexible options. You can copy the entire database as-is or sanitize specific data fields. You also control which branches get full or anonymized data. This lets you protect PII while still testing against realistic datasets.

**Q: We have multiple developers with different features in progress. Can each one spin up their own environment?**  
A: Absolutely. Each developer can work in their own “clone” of production, ensuring they’re not stepping on each other’s toes. Once their work is validated, they merge into the main branch, and everyone’s environment can be updated accordingly.

**Q: Can we control access to certain branches or environments for compliance reasons?**  
A: Yes. Upsun integrates with common authentication and authorization flows. You can grant or restrict access to particular branches, anonymize data selectively, and ensure only the right people see sensitive information.

### Useful links

-   Move fast and break things: accelerating testing with Upsun

### [CI/CD Defined and Explained | Upsun](https://upsun.com/blog/what-the-heck-is-ci-cd/)

# What the heck is CI/CD?

For every developer coding up the next world-changing app, there's a publicist or a marketer or a salesperson working alongside them to make sure that world-changing app makes it out into the world. Ask a non-technical professional what the most challenging part of their job is, and you'll often hear, "Understanding what the heck our developers are talking about."

To help you understand what the heck your developers are talking about, we're launching this series of short articles to explain common development concepts in simple language. Today we're tackling continuous integration and continuous delivery (deployment), better known as CI/CD.

## **CI/CD automation allows faster app deployments and updates**

When developers talk about CI/CD, they're talking about a method for developing and implementing new application code. Similar to how you would send a package through the mail, CI/CD packs up code and ships it to its destination.

CI/CD starts with any change in your application, whether it's a new feature or just a bug fix. Once the change is made, the continuous integration process is automatically triggered. The CI process is the "boxing up the package" part of CI/CD. The CI system builds the code that will be used to make the application change and then prepares it for delivery. In addition, the CI process runs tests to make sure the new code won't break anything in the application.

Once the code passes the tests, the continuous delivery process kicks in. The CD process is the "shipping your package to the destination" part of CI/CD. Continuous delivery means code is always ready to deploy but requires manual approval, while continuous deployment automatically pushes approved changes to production without human intervention**.** The CD process installs the new code in a staging environment to be reviewed. Once the code has been approved, the CD process deploys it as an application update.

## **Why CI/CD automated testing and deployments are crucial**

The high level of automation from CI/CD provides important benefits:

-   Automation makes application changes predictable and reliable.
-   Automation reduces human error; repetitive tasks are put into the hands of computers that won't get bored and don't lose focus.
-   Automated testing and deployments are easier to audit and validate compared to manual work.
-   Automation speeds up the feedback cycle between making application changes and seeing the stakeholders' response to the changes, helping developers get the application to where it needs to be as quickly as possible.

## **Automate CI/CD tools with Upsun**

The CI/CD process requires implementing certain tools. Upsun helps automate the implementation of these tools so that developers spend less time managing the tools and learning how to use them. An example of Upsun automation is instant cloning. This feature provides you with a separate environment and a URL to look at the latest changes and to offer feedback. We even provide a clone of your existing production site with all the data.

The automation provided by CI/CD and supported by Upsun gives developers more time to focus on their most important mission: creating great experiences for users.

### [PaaS vs. IaaS: lower carbon emissions for applications | Upsun](https://upsun.com/blog/paas-versus-iaas/)

# PaaS vs IaaS: lower carbon emissions for your applications

Cloud computing is not as vaporous as its name suggests, and neither is the internet that cloud computing enables. The internet is powered by millions of servers based in either large data centers or located at the edge. And the energy required to power these large energy-intensive computers is the cause of approximately 1% of carbon emissions worldwide and this is growing fast.

In many other industries, such as the food system, Feeding America has found as much as 40% of food produced is wasted and ends up in the trash. Cloud computing is no different with resources continuously going to waste for a fairly simple reason. Teams want their application to be able to handle traffic peaks and therefore tend to over provision, while their servers consume pretty much the same amount of energy whether they are utilized or not, leading to waste. In particular, many studies—including a study by Cloud Carbon Footprint—have shown that most of the energy consumption of a server comes from the central processing unit (CPU) responsible for running applications.  

This is the primary reason why leveraging a modern Platform-as-a-Service (PaaS) is significantly more effective than using Infrastructures-as-a-Service (IaaS) and virtual servers. Efficiently distributing resources between apps and offering baked-in tools to optimize consumption such as profilers, relevant caching layers, and especially autoscaling. A modern PaaS can optimize underlying resources in many ways and reduce waste by only using what’s needed. 

## **The reasons why a modern PaaS is better**

Let’s zoom in on some numbers as to why a modern PaaS performs better in relation to resource consumption. Taking the example of Upsun— the latest offer from Platform.sh—which is targeting development teams who mainly build Softwares-as-a-Service (SaaS) applications with micro-service technical architectures. 

We have collected a lot of data on the Platform.sh product over the years. Conducting research to investigate how many CPU resources are saved by using our product compared to similar applications using bare metal deployments. This research has been carried out by our sustainability team and audited by an external source, Greenly. From the results, we found that instead of setting up an application on virtual instances (AWS EC2 style), having a container grid of servers reduces the CPU usage app **by a factor of 12 on average**. Take a look at the scheme below where you can see this represented and check out further details into the density research conducted in this case study. The resulting emission reduction depends on the electricity grid and application.

**Note**: The scheme above is a simplified scheme of what we call the Platform.sh grid region. Grid regions provide highly efficient levels of distribution that contribute to more server efficiency.

## **How can we get to 12 times CPU usage optimization?** 

Well, there’s no silver bullet—rather many elements work together to help optimize CPU usage. First, workload distribution plays a massive role: our grid servers are essential here. Grid architecture can leverage the underlying servers much better due to a higher and more diverse volume of requests. Unlike dedicated resources, these grid regions can continuously run and rebalance workloads with high levels of utilization. The scale effect enables more effective resource-allocation optimization in production environments and even more so in development environments as the grid self manages its resources by putting development containers to sleep when idle for an extended time.

Another big factor in optimizing resource consumption is our orchestration. One choice we have made is to offer very small containers by default within our container grid. With that approach, we can enable low traffic or trivial apps to run on nimble server resources. We can also help teams build very cheap development environments for more complex apps, while traditionally the same team would probably be running their development environments on similar infrastructure as their production environment. This is an approach which adds up very quickly, so from a resource consumption standpoint PaaS are a much leaner way to go.

Additionally, once the underlying infrastructure is optimized, the application’s code can often be optimized as well, and your PaaS should be there to help. Without the proper tooling, a development team can only guess at which parts of their codebase might benefit from a performance improving refactor.  This is why it’s incredibly helpful if progressive profiling and application performance monitoring (APM) are included as baked-in features of a PaaS product.  These two tools work together - APM is a high level view that helps teams identify which sections of their app need help, and fine-grained profiling zooms in to identify exactly which lines of code to focus on.  Below is an overview of the observability capabilities available on Upsun, which can help you with this process.

## **What’s unique about Upsun on the sustainability front?**

Upsun is a new offer for the Platform.sh PaaS. It is essentially the same product—including all the principles mentioned above—but it comes with a completely revamped pricing model designed to meet the needs of decoupled and composable architecture projects. It also comes with a few new advanced features that will soon be deployed on the Platform.sh PaaS too.

This pricing model can be summarized in two words: usage-based. While this aims at providing much more flexibility to development teams, it also provides some highly interesting benefits in terms of our goal to reduce the carbon footprint of applications.

**12x better CPU usage compared to AWS EC2.** With Upsun we are offering our most efficient cloud orchestration. Greenly calculated that the gains were 14x  higher density for development and 10x higher for production workloads. 

**It provides better alignment between cost optimization and carbon footprint**. We noticed that our previous plan approach was somewhat less efficient in this regard: we were bundling features together and some of them were not used while being paid for. Our new **usage-based approach** removes that friction and aligns price and resources more effectively. 

**Carbon intensity transparency.** Not all data centers are the same, and we have realized early on at Platform.sh that the energy source plays a massive role in the carbon footprint of a datacenter. Therefore the electric mix of the country or the region where the datacenter is located is super important. 

**The best is yet to come.** In the near future, we will be computing about the most important environmentally-impactful component of Upsun—stay tuned for more information coming soon.

If your digital carbon emissions are important to you and you’d like to discuss Upsun’s ability to reduce resource consumption, please get in touch with our team!

### [Building a fraud prevention component using Symfony | Upsun](https://upsun.com/blog/building-fraud-prevention-component-using-symfony/)

# Building a fraud prevention component using Symfony

_For a quick read-through of the main takeaways, keep scrolling for our distilled write-up. We utilized ChatGPT to enhance the grammar and syntax._

**Building a Robust Abuse Prevention System with Risk Scoring**

In today’s digital landscape, preventing abuse and fraud is critical to protect both businesses and their customers. In a recent presentation, Moritz, a Product Engineer at Platform.sh, walked through the journey of designing and implementing a sophisticated abuse prevention system, weaving together real-world scenarios with technical insights. Let’s break down the key elements of his talk and explore how risk scoring can effectively mitigate fraud.

### From Public Transport Fare Fraud to Digital Risk Management

Moritz began by sharing a compelling story about how public transport systems once faced widespread abuse. The anecdote centered on an individual, "Claus," who was unknowingly charged thousands of dollars for bus tickets due to his bank account details ending up on a list for automated purchases. This real-world case study highlights how repeated fraudulent use of a registered account can lead to significant financial damage, company mistrust, lawsuits, and systemic breakdown if left unchecked.

The scenario underscores a critical lesson: if preventive measures aren’t integrated early, the consequences can spiral out of control. While Moritz’s example was specific to public transportation, the principles of account abuse, payment fraud, and the cat-and-mouse game between fraudsters and system defenders are universal.

### Identifying Risks and Potential Abuses

The talk then pivoted to the various kinds of risks associated with registered user accounts:

**Automated Account Creation:** Fraudsters can create multiple accounts using variations of a single email address. With little to no identity verification, these accounts can be used to access free resources or test payment methods.

**Abuse of Free Resources:** Just like getting free samples at a supermarket, users might exploit free trials or resources repeatedly, draining company resources without consent.

**Payment Abuse:** Testing stolen credit cards, card cashing (using a stolen card across multiple accounts), and vulnerable payment methods are critical threats. Fraudsters may even exploit prepaid or digital cards that can be quickly generated and discarded to avoid detection.

### Balancing Security Measures and User Experience

Introducing stricter verification—like free email providers, demanding passport scans, or requiring video calls—might seem like a straightforward solution. However, such measures can alienate legitimate users and create friction. The goal is to balance necessary precautions with a seamless customer experience. Strategies discussed include:

**Duplicate Detection:** Normalize email addresses (removing dots, plus signs, etc.) to detect multiple account creations.

**Limiting Free Resource Access:** Put thresholds on how much free resource a new or unverified user can access until a trustworthy history is built.

**Phone Verification & Support Vetting:** Trigger additional verification steps (SMS, WhatsApp) selectively, based on the user's risk profile.

**Credit Card Requirements:** For certain free resources, requiring credit card details can introduce a layer of risk assessment, although it’s not foolproof due to prepaid and disposable cards.

### Crafting a Risk Scoring System

The heart of Moritz’s presentation was the introduction of a comprehensive risk scoring system. Instead of rigid rules that can create false positives or block legitimate users, a dynamic risk score helps systems make nuanced decisions. Key components that feed into this score include:

**Email Risk Assessment:** Checking for disposable email providers, unusual patterns, or recently created domains.

**IP Risk Scoring:** Evaluating the risk associated with an IP address, such as its origin (data center vs. residential), geolocation accuracy, and historical abuse patterns.

**Payment History & Patterns:** Leveraging data from payment providers that includes successful transactions, disputes, and early fraud warnings to adjust trustworthiness.

**Duplicate Account Detection:** Recognizing duplicate patterns across accounts and using that data to adjust risk.

Moritz explained how these factors are mathematically integrated into a neural network model. This model continuously learns and adjusts scores to mitigate false positives while still catching malicious behaviors. It ensures that legitimate users face minimal friction, while suspicious activities trigger additional verification steps or limitations.

### Implementing the Solution with Microservices

To bring this idea to life, the team built a microservice using Symfony. The advantages were clear: quick prototyping, easy integration with existing infrastructure (like Upsun), and the ability to expose a RESTful API. This microservice acts as a passive component that other systems query for risk scores during critical decision points, such as account creation, payment processing, and resource allocation.

The architecture involves endpoints for:

-   Feeding in staff-confirmed data (like verified accounts or confirmed abuses).
-   Webhooks from payment providers to gather risk data in real time.
-   Integration with external blocklists for IPs and emails.

By centralizing risk assessment in one microservice, teams can make consistent, data-driven decisions across the platform.

### Results and Continuous Improvement

After implementing the risk scoring system, the impact was significant. Support agents reported a drastic reduction in time spent analyzing and removing abusive accounts—from days to roughly one hour per week. Infrastructure load was also reduced in some regions by up to a third, thanks to automated prevention and early detection of abusive activities.

Moritz emphasized that building such a system is a continuous cat-and-mouse game. As fraudsters adapt, the risk scoring model needs regular updates, learning from new data, and refining its parameters to avoid false positives without compromising on security.

### Looking Forward

For developers interested in constructing their own abuse prevention systems, Moritz recommended:

-   Explore external services for IP and email risk scoring.
-   Leverage payment provider risk assessments.
-   Fine-tune data analysis to balance security with a smooth user experience.
-   Keep informed through community talks and resources, like Haylee’s upcoming presentation on crafting microservices tailored to specific needs.

By combining technical strategies with thoughtful system design, developers can create resilient solutions that protect both their businesses and their customers from ever-evolving threats.

### [Eliminate the "repro gap" with environment parity | Upsun](https://upsun.com/blog/environment-parity-platform-problem/)

# “It works on my machine”: why environment parity is still a platform problem in 2026

### **The hidden cost of environment drift**

How many hours did your team spend last quarter debugging issues that only appeared in one environment? What would change if every environment were guaranteed to be identical?

In 2026, environment inconsistency remains one of the most expensive bottlenecks in software development. Developers frequently spend more time debugging differences between infrastructure setups than they do on their own code. 

This "repro gap", the distance between development reality and production truth, directly impacts shipping velocity and release confidence.

### **I. The myth of "good enough" staging**

_Key takeaway: Manual environment management is the primary driver of technical debt; better documentation cannot solve a problem rooted in separate maintenance cycles. True parity requires the platform to treat environments as ephemeral, repeatable units rather than static, hand-configured assets._

-   **Disjointed workflows:** When local, staging, and production are configured differently, developers are forced to make assumptions that often fail upon deployment.
-   **The staging queue:** If a team shares a single staging environment, drift is accelerated by multiple developers applying manual hotfixes that never make it back to the local dev setup.
-   **Release anxiety:** The longer drift goes unaddressed, the more expensive and risky each release becomes, leading to extended code freezes and manual QA marathons.

### **II. Structural parity: same code, same config**

_Key takeaway: Environment parity should be a side effect of code branching, not a manual engineering task. By using a single declarative manifest, you ensure that the infrastructure behavior is identical across every stage of the delivery pipeline._

Upsun eliminates the gap between local and production by making environment drift structurally impossible:

-   **The single source of truth:** Every environment, local, preview, and production, is generated from the same unified configuration file.
-   **Automatic infrastructure branching:** When you branch your code in Git, the platform can branch the entire environment, ensuring identical service versions, routes, and runtimes.
-   **Infrastructure as Code (IaC):** Because the stack is defined in the repository, any change to a service (like upgrading a database version) is automatically propagated to every new branch.

### **III. Testing against reality with instant data**

_Key takeaway: Parity is not just about the code and the services; it is about the data. Testing against stale or "stubbed" data is the leading cause of late-stage deployment failures._

A modern Internal Developer Platform (IDP) must provide developers with the ability to validate their work against production reality:

-   **Byte-for-byte clones:** Upsun allows for instant cloning of production data into isolated preview environments.
-   **Safe sanitization:** Platform teams can implement automated data sanitization within the workflow, ensuring developers have real-world data without violating privacy or compliance mandates.
-   **Bug Validation:** If a bug appears in production, a developer can branch production and immediately have a replica of the environment, and the data, to diagnose and fix the issue.

### **IV. Freeing up engineering capacity**

_Key takeaway: Redirecting engineering capacity from infrastructure debugging back to product development is the primary ROI of platform engineering. Eliminating drift gives engineers their time back by removing the undifferentiated heavy lifting of environment maintenance._

-   **Buy-over-Build:** By utilizing a platform that enforces parity, organizations avoid the cost of building and maintaining custom parity-sync scripts and infrastructure.
-   **Zero-ticket velocity:** Developers no longer need to wait for a platform ticket to sync their local environment with the latest production changes.
-   **Higher confidence in every release:** What you test is what you ship, allowing for more frequent deployments and a significant reduction in emergency rollbacks.

### **Is environment drift stalling your roadmap?**

If your developers are still saying "it works on my machine," your platform is failing to provide the paved road they need.

**Audit your environment parity:**

1.  **Analyze rollback data:** How many production failures or stalled releases in the last quarter were due to configuration differences between environments?
2.  **Measure discovery time:** How long does it take for a developer to replicate a production bug in their dev environment?
3.  **Check service consistency:** Are your dev, staging, and production environments running the exact same versions of PHP, Python, MariaDB, and Redis?

* * *

### **Frequently asked questions (FAQ)**

**Why isn't Docker enough to solve environment parity?**

Docker and Docker Compose handle local service relationships well. The gap is everything that happens beyond your laptop: cloud deployment, routing, live data, and environment lifecycle. Your Compose file and your production infrastructure are still two separate things that someone has to keep in sync manually. That manual step is where drift enters. 

**How does Upsun’s unified configuration file prevent drift?**

It acts as a version-controlled manifest for the entire application. Since every environment is built from this single file, there is no manual step where a human can introduce a configuration difference between staging and production.

**What is a "byte-for-byte clone"?**

It is an exact replica of a production environment's stack, storage and state. This allows developers to test their code against the actual weight and complexity of production data rather than simplified mocks.

**Does environment parity increase cloud costs?**

On the contrary, it often reduces costs. By allowing developers to spin up ephemeral preview environments that are torn down after a merge, you avoid the cost of maintaining permanent, idle staging servers.

**How does parity support high-stakes migrations?**

It allows teams to test the migration process itself in a branch that is an exact replica of the target production environment, ensuring the move is safe before any live traffic is affected.

### [First Project Incentive: save every month on game-changing Upsun features](https://upsun.com/blog/first-project-incentive/)

# Introducing First Project Incentive: the same game-changing Upsun features for less

### What is the First Project Incentive?

The Upsun First Project Incentive, a monthly perk, is designed to help more developers like you benefit from feature-rich hosting. 

For each organization you create on Upsun, you’ll save up to $19 every month—the equivalent cost of your first user license and first project fee. Automatically.\* To get started, just add on your resources. Then spend your time focusing on what matters most—building great applications.  

### What Upsun features are included?

With the First Project Incentive you get all the same robust features we've always provided—including instant cloning + all your data, infrastructure management, built-in security and compliance, horizontal and vertical scaling—at a competitive price.

Use Upsun's pricing calculator to learn more about how the First Project Incentive can help you optimize your cloud hosting costs.

### How do I get the First Project Incentive?

Good news!  Whether you're a new or current subscriber, this perk is automatically applied to your organization's bill. After you’ve created a project, head to the billing section.

From here, you’ll be able to review your current and future months’ projected costs with the First Project Incentive.

###   
Your next great project starts here

The First Project Incentive is our commitment to supporting the developer community by making high-quality DevOps more accessible and affordable, providing the resources you need to succeed.

Ready to get started? Sign up or log in to Upsun now to create or migrate your first application. And remember to  check out our pricing calculator to see how the First Project Incentive can help you optimize your costs.

Stay tuned for more exciting features and updates as we continue to enhance your Upsun experience!

_\*The discount provided is based on prorated periods with active projects and excludes VAT. If the discount applied to your total bill exceeds the amount of your bill, you won’t be entitled to receive the difference in cash or credit. If you abuse this offer in any way, it will be rescinded immediately._

  

_By participating in this offer, you agree to be bound by the current terms and conditions as well as any future amendments. Upsun reserves the right to change or amend the terms of this offer at any time without prior notice. All changes will be effective immediately upon posting on our website or through direct communication._

### [Introduction to message queues and their key use cases | Upsun](https://upsun.com/blog/introduction-to-message-queues/)

# Introduction to message queues and their use cases

Due to the rising complexity of many organizations' digital stacks, message queues have become a vital component of their software architectures. Instead of maintaining point-to-point integrations of all components, message queues enable asynchronous communication between an architecture's different parts.

Architectures in which a message queue is a central component are often referred to as **decoupled systems**. Even when the consuming system is temporarily down, the messages created by the producing systems are stored in the queue. This makes these systems much less prone to failure. Furthermore, scaling an architecture is less troublesome because all it requires is an upgrade of the message queue and the relevant producer or consumer. There are no bottlenecks or weakest links.

In this article, you'll learn about the ins and outs of message queues, the most popular technologies, and various use cases to get started.

## **What is a message queue?**

In essence, a message queue is like a mailbox. Someone (the publisher) posts a letter (the message) in a mailbox (the message queue), which is then picked up by the receiver (the subscriber). However, there is one difference: in a message queue, multiple consumers can receive the message.

The sender and receiver don't need to be active at the same time. The queue is like a buffer; it stores messages until the consumer is ready to receive them.

**Publisher**

The publisher (or producer) creates and sends messages. This can be anything—a server producing logs, an application sending data to a database, and even a cloud storage bucket sending CSV files row by row. In a decoupled system, the publisher operates independently, without concern for who will consume the messages.

**Message**

The message contains the actual data being transmitted from publisher to subscriber. It can be anything, from a simple text string or a JSON object to an XML document or even serialized code. A message usually contains headers with metadata. It provides context and instructions about the message itself, for example, the sender ID, timestamp, priority, or in some systems, information about the intended recipient.

**Message queue**

The message queue stores messages temporarily and is responsible for delivering the message to one or multiple subscribers. Some message queues support maintaining a specific message order, like First-In-First-Out. However, ordered delivery may involve some trade-offs, like complexity and throughput. For example, if one specific message is delayed while waiting to be consumed, it can block all subsequent messages in the queue, causing the queue to grow rapidly.

**Subscriber**

The subscriber (or consumer) listens to the queue and takes (relevant) messages to process them. Like a publisher, a subscriber can be anything, another application, a service to update a database, or any other component that needs the information.

**Topic**

Some message queues include an exchange or broker system, a routing system that acts as a traffic controller for messages. The exchange decides which queue or subscriber should receive a message based on predefined rules. One common type of exchange is a topic exchange. This approach involves tagging messages with a **routing key**, a string separated by periods. Subscribers or queues use **binding keys** to filter and subscribe to messages that match specific routing patterns.

Here's an example from a sports website:

A publisher sends the final scores of sports matches from all sports and all leagues around the world with routing keys like "cricket.india.ipl" and "soccer.uk.premierleague". A topic uses the binding key "soccer" to contain all the messages about soccer, which subscribers can consume to receive all soccer results from around the world.

**Acknowledgment**

Some systems support acknowledgment (or "ack") of messages to ensure reliable message delivery. It's essentially a signal from the consumer to the message queue that a message has been successfully received and consumed. This ensures delivery guarantee (prevention of message loss) and prevents duplicate processing of messages. There are various delivery guarantee strategies:

-   At-most-once. No guarantee of delivery.
-   At-least-once. Messages are delivered at least once, but could also be duplicated.
-   Exactly-once. Messages are delivered exactly once. This is the most complex system to implement because you need to configure a separate topic for each link between the two systems.

**Messaging patterns**

Messaging systems follow a range of communication patterns, with each pattern supporting different kinds of use cases.

-   One-to-one. Messages are delivered over a single topic by a single publisher to a single predefined subscriber.
-   One-to-many (fan out). Messages are delivered over a topic by a single publisher to multiple consumers. Ensuring that at least one consumer reads the message can be achieved with an at-least-once delivery guarantee strategy. However, ensuring that all subscribers receive and process the message (atomicity) requires some extra steps known as the two-phase (2PC) pattern or a saga pattern.
-   Many-to-one (fan in). In a many-to-one pattern, messages are delivered over a topic by multiple publishers to a single consumer. This pattern is typically used when multiple systems produce streams of data, like logs or database changes, which are collected and stored in a single system.
-   Many-to-many (load balanced). Finally, in a many-to-many pattern, messages are delivered over a topic by multiple publishers to multiple consumers. Like with the one-to-many pattern, ensuring atomicity requires some extra engineering.

### **Popular message queue technologies**

Before moving on to real-world use cases, let's discuss some popular message queueing technologies.

**RabbitMQ**

RabbitMQ is a mature product and is widely used within IoT environments. Even though it only takes a couple of minutes to set up, it is known for its very low latency. Furthermore, it supports complex routing use cases. RabbitMQ is open source, and although it's written in Erlang, it is supported by most programming languages.

**ActiveMQ**

Like RabbitMQ, ActiveMQ is a mature and widely used product. It is built entirely in Java and excels in Java-based enterprise environments. While it doesn't meet RabbitMQ's low latency and is not as advanced in terms of routing features, it's more suited for high-throughput cases given its horizontal scalability features. It's also open source and supported by many programming languages.

**Apache Kafka**

Kafka is a modern queuing system with real-time processing and data manipulation. It has risen to prominence in the past couple of years as the go-to solution for streaming applications. Because of its distributed architecture, it has low latency, supports high throughput, and is fault-tolerant. The downside is that it is harder to set up and more expensive to maintain due to its distributed nature. While Kafka is open source, many providers are offering it as a service, including its original developer at Confluent.

#### **Message queues as a service: Amazon SQS, Azure Service Bus, and GCP Pub/Sub**

This brings us to the managed services. Each of the three largest cloud service providers has its own message queue technology. What they all have in common is that they integrate flawlessly with dozens of other cloud services from their respective provider. However, they all excel at one specific aspect. Azure's Service Bus is feature-rich and supports complex use cases. Amazon SQS is cost-effective. It doesn't excel at speed and throughout, nor in terms of features, but it gives the best bang for the buck. Finally, GCP Pub/Sub has the lowest latency and highest throughput, but its pricing model is complex and might result in unexpected costs.

### **Message queues in action**

Now that we have established an overview of message queues and their features, it's time to outline a variety of use cases from different sectors.

**Use case 1: Payment processing**

Payment processing systems, such as Stripe, utilize a message queue to handle asynchronous communication between different components of the payment processing pipeline. When a customer initiates a payment, the web application publishes a "payment\_request" message to the queue. This message would contain essential details like the customer ID, order ID, amount, and payment method.

A suitable routing key for this scenario could be "payment.process", allowing for filtering and prioritization if needed. Since multiple services might need to react to a successful payment (for example, inventory, shipping, and accounting), a one-to-many messaging pattern is appropriate, perhaps with a broker, to ensure data consistency. A saga pattern can roll back any changes in case of failures in downstream services. Finally, the system requires an "at-least-once" delivery guarantee to ensure that no payment requests are lost, even in case of temporary failures.

**Use case 2: Mobile multiplayer games**

In mobile games, each game server typically publishes in-game events—such as player actions, game state updates, and chat messages—to the message queue using appropriate routing keys like `"game.{game_id}.event" or "player.{player_id}.action"`  
  
Here's how that would work:

-   When players participate in an online event, like raiding a dungeon, they are subscribing to the events for that particular dungeon instance.
-   Anytime players interact, from encountering each other on the same map or sending each other text messages to engaging in combat, they are subscribing to each other's events.
-   A "notification\_service" would subscribe to relevant topics to gather events that trigger notifications, like achieving a high score, receiving a friend request, or starting a new match. This service would then generate and deliver notifications to players' devices through a push notification service.

For this scenario, an "at-least-once" delivery guarantee is crucial to ensure that critical game events and notifications are not lost. The messaging pattern would be many-to-many as multiple players interact with each other and the game server. In gaming, latency matters a lot, so a 2PC pattern isn't suitable. A saga pattern, however, can ensure data consistency across different game services.

**Use case 3: Load balancing**

A load balancer would initially receive all incoming requests. Instead of directly forwarding them to backend servers, the load balancer would publish each request as a message to the message queue. Multiple worker instances would subscribe to this queue, consuming messages and processing the requests. The message queue effectively distributes the workload among the available workers, ensuring no single server is overwhelmed. This approach also provides resilience; if a worker fails, the message remains in the queue for another worker to pick up.

An appropriate routing key for this scenario could be "request.process," allowing for potential prioritization or filtering of requests in the future. An "at-least-once" delivery guarantee is necessary to ensure that no request is lost due to worker failures. Clearly, the messaging pattern here is one-to-many, as a single request message is processed by one of many available workers.

**Use case 4: Data streaming**

Assume you want to track all database changes: A Debezium connector is deployed alongside a database to capture its changes. These changes are transformed into events and published to a message queue. The message queue acts as a central hub for distributing these change events to various consumers. A streaming platform, like Kafka, can be used to transform the events in real time and load them into the data warehouse for real-time analytics.

A suitable routing key strategy could be "database.{db\_name}.{table\_name}.{operation}", allowing subscribers to filter events based on the specific database, table, or operation type (create, update, delete).  An "at-least-once" delivery guarantee is important to ensure that no database changes are missed by the data warehouse. The messaging pattern here is typically one-to-many, as a single database change event can be relevant to multiple consumers besides the data warehouse.

### **How Upsun Simplifies Message Queue Management**

Setting up and running message queues shouldn't require a dedicated DevOps team. Upsun transforms complex message queue operations into simple, developer-friendly workflows that let you focus on building features instead of managing infrastructure.

**Deploy in minutes**

Traditional message queue setup involves dozens of configuration steps, security hardening, and extensive testing. You'll spend days installing software, configuring user permissions, setting up SSL certificates, establishing clustering for high availability, configuring monitoring and alerting, setting up automated backups, and performing security hardening.

With Upsun, you simply define your requirements in a configuration file, and we handle everything else. Within minutes, you have a production-ready message queue with automatic clustering, SSL encryption, monitoring, backups, and security patches already configured.

**Test with real production data**

The biggest challenge with message queues is that local development environments can't replicate production behavior. Messages that work perfectly on your laptop can fail spectacularly with real data volumes and patterns.

Upsun solves this with perfect environment cloning. You can instantly create a complete copy of your production environment, including exact queue configurations, real message patterns and volumes, same performance characteristics, and production-like data that can be optionally anonymized.

Example: An e-commerce company needed to test a new order processing system during their busy season. Instead of guessing how it would perform, they cloned their production environment with real Black Friday message volumes. They discovered and fixed three performance bottlenecks before deployment, avoiding potential downtime during their highest revenue day.

**Smart monitoring** 

Most monitoring tools show you that something is wrong, but not what to do about it. Traditional monitoring might tell you "Queue depth: 10,000 messages" or "Consumer lag: 5 minutes" without explaining what this means or how to fix it.

Upsun's integrated observability provides actionable insights. Instead of cryptic metrics, you get clear problem descriptions like "Payment messages are being processed out of order" with suggested fixes like "Enable single-active-consumer mode" and one-click resolution options.

**Automatic scaling** 

Message queue traffic is unpredictable. A viral social media post or flash sale can instantly overwhelm your system. Upsun automatically scales your message queues based on real-time demand.

During normal traffic, your queues run on minimal resources to keep costs low. When traffic spikes hit, the system instantly scales up to handle the load. Once the spike ends, resources automatically scale back down. You're charged only for what you use.

**Integration with your development workflow**

Upsun message queues work seamlessly with your existing tools and processes.

Every change to your message queue setup goes through your normal code review process using git-based configuration, eliminating "configuration drift" between environments. Queue connection details are automatically injected into your applications as environment variables, removing the need for hardcoded credentials or manual configuration updates.

You can view your application metrics, database performance, and message queue health in one unified dashboard, eliminating the need to juggle between multiple monitoring tools.

### **Conclusion**

Message queues have become the backbone of modern, scalable applications—but implementing and managing them shouldn't slow down your development process. While the concepts are straightforward, the operational complexity of running message queues in production can quickly become overwhelming.

Managing delivery guarantees, durability, persistence, and ordering across different message queue technologies is complex and prone to error. Each broker has its own configuration nuances, monitoring requirements, and failure modes that require specialized expertise to handle properly.

This is where Upsun comes in. As a developer-focused cloud application platform, Upsun takes the operational burden off your shoulders by providing pre-configured, battle-tested setups for both RabbitMQ and Kafka that handle durability, persistence, and ordering concerns out of the box. Whether you need RabbitMQ for complex routing scenarios or Kafka for high-throughput streaming, Upsun provides fully managed services with automatic scaling, monitoring, and maintenance.

Upsun integrated monitoring goes beyond basic metric, it shows you exactly when messages are being processed out of order or when durability guarantees are being violated, before your customers notice. With Upsun's git-based workflow and instant environment cloning, you can test your message queue configurations with production-like data before deployment, eliminating the guesswork that often leads to production issues.

Ready to implement message queues without the operational headaches? Start building with Upsun today and focus on what matters most: your application logic, not infrastructure management.

### [Understanding Graphs: Data & Code Analysis - Presentation | Upsun](https://upsun.com/blog/understanding-graphs-data-code-analysis-presentation/)

# Mastering linked data in PHP: graphs and algorithms

_This blog is based on a presentation by Christian Rades, Principal Engineer at Shopware, at the Symfony conference 2023. We utilized AI tools for transcription and to enhance the structure and clarity of the content._

When Christian started with an unusual proposition: to explore the "boring kind of graphs", not colorful charts, but kinds made of points and lines, used to show how things connect, what followed was a fascinating journey through centuries of mathematical thinking and its surprisingly practical applications to modern software development.

## The seven bridges problem: A quick story that changed the field

The story of graphs in computer science begins in 1736 in the Prussian city of Königsberg (now Kaliningrad). Picture this: a group of friends at a bar, perhaps after a few beers, pondering a seemingly simple question – could you walk through the city crossing each of its seven bridges exactly once?

What began as a casual puzzle evolved into a profound mathematical breakthrough. Mathematician Leonhard Euler tackled this problem not with traditional geometry or algebra, but by inventing an entirely new way of thinking. He abstracted the physical city into something simpler: points (representing the land masses) connected by edges (representing the bridges).

Euler's insight was elegant. To traverse a path where you cross each bridge only once, you must enter and exit each point. This means that each point requires an even number of connections – one to enter and one to exit. Since Königsberg had points with odd numbers of bridges, the puzzle was mathematically impossible.

This abstraction – reducing complex structures to points and connections – became the foundation of graph theory.

## What actually are graphs?

Christian breaks down the mathematical definition into human terms: "Vertices are points, edges are how those points are connected. Nothing else."

Unlike graphics in computer science, graphs have no coordinates or physical positions. They're purely about relationships. You can draw them however you like; the arrangement is just to help humans understand them better.

This simplicity is powerful. Tangled nets, sprawling cities, and complex maps all share something fundamental: they can all be transformed into graphs. Each intersection becomes a point, each connecting path becomes an edge. This is precisely how tools like Google Maps work: they convert road networks into graphs, then use graph algorithms to trace your route from point A to point B.

### Navigating Data Structures

Christian demonstrates this concept through JQ, a command-line tool for processing JSON data. When you write a JQ query, such as accessing `data[0].address.street.` You're essentially navigating through a graph.

He walks through an example: starting at the root JSON object, moving to the data array, selecting the first element, accessing the `address` field, and finally reaching the `street` value. Each step is moving from one node to another along edges with meaningful names.

"This is the Google Maps view of this data structure," Christian explains. By separating the structure of data from the data itself, you can perform operations purely on structure. You can define sub-paths and reuse them: "Get into the address field, then get into the street field" – and apply this pattern across entire datasets.

### The object-relational mapping challenge

Every developer working with databases knows this pain: objects exist in memory without a specific order, but databases require order due to foreign key constraints. You can't reference data that the database does not yet know about.

At Shopware, Christian's team aimed to create a developer-friendly API that allowed users to submit inventory data as nested JSON, including products with their categories - all in one go. However, there was a problem: you can't create a product referencing categories without those categories already existing and having IDs.

This is where thinking in graphs becomes transformative. The problem is primarily about directed graphs, where the direction of connections is significant. One table can reference another through a foreign key, but not vice versa, or a cycle is created.

## Topological sorting: ordering the chaos

Christian introduces Kahn's algorithm for topological sorting. The goal is to determine the correct order to insert data into the database.

The algorithm starts by counting incoming connections for each node. Then it follows a simple process:

1.  Select any node with zero incoming connections (if none exist, you have a cycle)
2.  Add it to the insertion stack
3.  Remove its edges from the graph
4.  Decrease the incoming connection count for affected nodes
5.  Repeat

Working through an example of a product with categories, the algorithm reveals the correct insertion order: root entities first, then their dependencies, and finally the product itself. Each step respects foreign key constraints automatically.

### Detecting cycles: when data goes wrong

But what happens when your data has circular dependencies? Christian explains that once you've modeled your problem as a graph, you can simply “Google it”,  established algorithms already exist.

Using depth-first search, you can detect cycles by traversing the graph and maintaining a stack. When you encounter a node you've already visited in your current path, you've found a cycle. Christian demonstrates how this reveals broken data: “Products reference root, root references awesome things, awesome things reference products”, an impossible situation.

With this detection, you can provide users with precise error messages or, in certain domains, make informed decisions about how to break cycles effectively.

## Git history as a social network

Christian's most intriguing application transforms Git repositories into social networks – not of people, but of files.

Git is already a Directed Acyclic Graph (DAG) that flows from present to past. Each commit represents a meaningful change. However, Christian views it differently: files that change together in commits are "talking" to each other.

If a commit creates a new service file D and modifies file A, those files are now related. A contained a test that broke, or needed updating for the new service. These connections accumulate across the entire commit history.

By transforming this data into a graph where files are nodes and co-changes are weighted edges (the weight being how often they changed together), Christian can analyze the architecture itself.

## Between centrality: finding architectural bottlenecks

Borrowing from social network analysis, Christian applies "betweenness centrality" – a metric that identifies which nodes connect different parts of a network. Companies like Facebook use this to identify influential people; Christian uses it to identify influential files.

Running this analysis on Shopware's codebase revealed eye-opening results. Using a Sunburst diagram showing each folder's contribution to overall connectedness:

-   The snippets folder contributed 25% of all connectedness. Why? Because UI changes require updating translation strings, a bridge is needed between the administration layer and snippets.
-   E2E tests showed high centrality – but this revealed brittleness. Every UI change broke tests, forcing developers to modify test files frequently.
-   The most brittle PHP test? The API schema validator, which intentionally compared the entire API schema against a committed JSON file. Any API change triggered this test.

Christian could identify these architectural "boulders" – obstacles that developers constantly encounter – purely from analyzing Git history.

## Beyond data: thinking structurally

Christian's closing message challenges developers to expand their toolkit. We have standard patterns for data: factories, commands, and various design patterns. But what about structure?

"We can analyze how our data looks and verify it with that, a bit like a type system," he explains. But more powerfully, you can calculate new information from the structure itself. Your commit history, your dependency graph, your data relationships – these structures contain insights waiting to be extracted using standard, well-documented algorithms.

He leaves us with another example: using dependency graphs from tools like deptrac and applying layout algorithms to visualize which parts of a system are tightly coupled. By coloring nodes by folder, teams could identify when supposedly independent components were in fact closely related.

## The practical takeaway

Christian's examples demonstrate that graph theory is not merely abstract mathematics confined to textbooks. It's a practical framework for solving real development challenges:

-   Ordering database insertions by modeling dependencies as directed graphs
-   Detecting invalid data through cycle detection
-   Analyzing codebase health through commit history
-   Identifying brittle tests and architectural bottlenecks
-   Visualizing system coupling and dependencies

The key insight? Many problems we face aren't really about data manipulation – they're about understanding and working with structure. And for structure, graphs and their algorithms provide robust, proven solutions.

As Christian puts it, "Graphs are everywhere." Once you start seeing your problems through this lens, you'll find applications in unexpected places. The algorithms exist, the libraries are available, and the patterns are well-documented. All that's needed is recognizing when you're facing a graph problem – and Christian's talk provides plenty of inspiration for making that recognition.

For developers interested in exploring these concepts further, Christian's tools are available on GitHub (including "rorqual," his Rust-based repository analyzer), and the techniques he describes are built on widely available libraries such as NetworkX for Python and various graph libraries in other languages.

The next time you're wrestling with dependencies, navigating complex data structures, or wondering why specific files always seem to change together, remember: you might just be looking at a graph problem in disguise.

### [Platforms and frameworks eat culture for breakfast | Upsun](https://upsun.com/blog/platforms-and-frameworks-eat-culture-for-breakfast/)

# Platforms and frameworks eat culture for breakfast

_For a quick read-through of the main takeaways, keep scrolling for our distilled write-up. We utilized ChatGPT to enhance the grammar and syntax._

## Harnessing technology to transform organizational culture

In today’s rapidly evolving tech landscape, the interplay between technology and organizational culture has never been more critical. Nigel Kersten, Chief Product Officer at Upsun, delved into this dynamic at a recent SymfonyCon, highlighting how strategic technology choices can drive meaningful cultural change within organizations. Here are the key takeaways from his presentation.

### A journey from DevOps to organizational culture

Nigel Kersten brings with him over 15 years of experience in DevOps and infrastructure. His background in cognitive science and philosophy of mind provided a unique perspective on the intersection of culture and technology, a central theme in the DevOps movement. Kersten’s work, including the “State of DevOps” reports, has focused on how technical practices influence organizational performance.

### The crucial role of organizational culture

Kersten emphasizes that strategy alone is insufficient without a supportive organizational culture. He references Peter Drucker’s famous aphorism: “Culture eats strategy for breakfast.” This underscores the importance of aligning cultural attributes with strategic goals to ensure successful execution.

### Technology as a catalyst for cultural change

One of Kersten’s standout points is the significant impact that technology choices, particularly platforms and frameworks, have on organizational culture. Unlike traditional change management, which often fails by focusing solely on one aspect of an organization, strategic technology adoption can influence multiple facets simultaneously. For example, the adoption of containers revolutionized the roles within organizations by democratizing deployment processes, shifting responsibilities from operations teams to developers.

### Understanding cognitive biases in tech teams

Kersten highlights several cognitive biases that affect how teams interact and make decisions:

-   **Anchoring effect:** Initial pieces of information disproportionately influence subsequent judgments. For instance, introducing a high initial price can make subsequent prices seem more reasonable, even if they are still high.
-   **IKEA effect:** People value products more highly if they have contributed to their creation. This is particularly relevant in software development, where developers may resist refactoring or replacing their own code.
-   **Loss aversion:** The psychological pain of losing something is greater than the pleasure of gaining something of equal value. This can make teams hesitant to abandon legacy systems or practices, even when better alternatives exist.

Understanding these biases can help leaders and developers make more informed decisions that foster a healthier, more collaborative work environment.

### Platforms and frameworks: Building the foundation for culture

Kersten discusses how well-designed platforms and frameworks can promote a generative, high-cooperation culture. He uses Symfony as an example, highlighting its features such as dependency injection, modularity, and consistent style. These attributes make it easier for separate teams to collaborate, understand each other’s work, and maintain a high level of code quality across the organization.

**Key attributes of effective platforms and frameworks:**

-   **Modularity:** Encourages separate teams to work on different components without stepping on each other’s toes.
-   **Consistency:** Facilitates easier transitions between teams and enhances code readability.
-   **Opinionated methodologies:** Provide clear guidelines and best practices, reducing ambiguity and fostering a unified approach.

### Practical strategies for driving cultural change

Kersten offers actionable advice for both developers and leaders looking to leverage technology for cultural transformation:

#### For developers:

-   **Amplify positive technology choices:** Use platforms and frameworks that encourage collaboration, testing, and continuous improvement.
-   **Create walking skeletons:** Implement basic CI/CD pipelines early to ensure that deployment processes are ingrained from the start.
-   **Promote fluid team membership:** Use consistent linting tools and style guides to make it easier for developers to move between teams.

#### For leaders:

-   **Monitor technology roadmaps:** Align technological advancements with cultural goals to ensure cohesive progress.
-   **Encourage transparency and observability:** Implement tools that provide visibility across the stack, fostering trust and collaboration.
-   **Mitigate negative impacts:** Recognize when technology choices may inadvertently harm the culture and take proactive steps to address these issues.

## Conclusion: Empowering change through technology

Nigel Kersten’s presentation highlights the significant influence that technology choices can have on an organization’s culture. By selecting platforms and frameworks that promote collaboration, consistency, and continuous improvement, developers and leaders can drive cultural transformations. As technology and culture become increasingly intertwined, Kersten provides a roadmap for building resilient, high-performing organizations.

Embracing the right technological tools isn’t just about enhancing productivity or streamlining processes; it’s about shaping your organization’s culture. As Kersten states, “Developers are given the power to make technology choices, and these choices can drive the change needed to create the kind of organization you want to work in.”

## Useful links

-   Techniques for high-performing DevOps teams

### [B2B multi-cloud platform that simplifies ops | Upsun](https://upsun.com/blog/b2b-multi-cloud-platform/)

# How B2B multi-cloud platforms simplify multi-cloud deployment

When a cloud provider experiences an outage, businesses that depend solely on that platform face limited options: wait for their vendor to restore service, or execute an emergency restoration on an alternative provider, which requires rebuilding infrastructure from scratch.

The days of putting all your digital eggs in one cloud basket are fast coming to an end. In the past, choosing a cloud provider was a gamble for B2B software teams, and switching providers meant rebuilding infrastructure from scratch, a costly and time-consuming process. Today's customers expect rapid recovery from disruptions, making single-vendor dependency a significant business risk. When a provider goes down, it doesn't just frustrate users; it halts operations for every business that depends on you.

This is why multi-cloud platforms have become essential infrastructure for business operations. Multi-cloud platforms enable enterprises to use portable configuration across AWS, Azure, Google Cloud, IBM, and OVHcloud, making provider transitions and disaster recovery more manageable without multiplying operational complexity.

This article breaks down what "multi-cloud for B2B" actually means, what a true multi-cloud platform should provide, and how Upsun's multi-cloud platform simplifies disaster recovery with portable configuration. While multi-cloud doesn't eliminate downtime during major outages, it enables your team to execute planned restoration procedures faster and more predictably than emergency infrastructure rebuilds.

## **Comparing cloud strategies: single, hybrid, and multi-cloud**

### **Single cloud**

When businesses first adopt cloud infrastructure, most choose a single provider to keep things simple. This approach keeps everything under one roof, either AWS, Azure, IBM, Google Cloud, or any other cloud provider. Single cloud deployment is well-suited for organizations with straightforward requirements, limited geographic reach, or those just starting their digital transformation. Startups and smaller companies often benefit from this approach during their initial growth phases. However, what happens when a cloud provider suffers an outage, and businesses depend solely on that platform?

**Challenges of a single cloud provider**      

The appeal of a single cloud is obvious: one provider to deal with, one bill to pay, and one ecosystem to manage. For smaller teams or companies just starting their cloud journey, this simplicity feels like a relief. But over time, cracks begin to show. While single-cloud simplicity appeals to early-stage companies, relying solely on one provider creates both technical and business risks that grow more severe as your organization scales.  

**The outage risk: when your single provider fails, everything fails**       
Even the most reliable cloud providers experience disruptions. A regional outage or service failure can cause critical downtime lasting hours and render your entire infrastructure inaccessible. Without alternative infrastructure, your disaster recovery options are limited to the same provider's backup regions, which may also be affected during major incidents. 

**Vendor lock-in**         
When all workloads and data are tied to a single platform's tools and services, switching to another provider becomes difficult and costly. This lock-in restricts your freedom to innovate and gives that provider significant control over your costs. Price changes, storage fees, or network costs can rise unexpectedly, making it harder to forecast budgets or maintain predictable expenses. Without viable alternatives, you have limited leverage to negotiate or switch providers.

**Limited flexibility and performance**        
A single provider may not offer the best global coverage or data-center locations for all your customers. This can lead to slower performance in certain regions and limit your ability to optimise workloads for different environments or compliance requirements.

**Compliance and data residency limits**        
Different regions have different rules on data storage and processing. Depending on a single provider may mean their data center locations do not meet regional regulatory or customer requirements, putting compliance at risk.

**Limited innovation options**        
Cloud providers innovate at different speeds. Depending on a single vendor may prevent you from utilizing newer tools, frameworks, or AI services available elsewhere, thereby slowing product development and competitiveness.

These complexities make the transition from single-cloud to hybrid or multi-cloud a strategic necessity for most organizations.

### **Hybrid cloud**

The limitations of single cloud have led many businesses to hybrid cloud. Hybrid cloud combines public cloud services (like AWS or Azure) with a company's private cloud or on-premises data center. Hybrid cloud mixes public and private infrastructure under one management approach. For companies with legacy systems that can't be easily migrated, hybrid offers a practical path forward. It allows them to modernize customer-facing applications in the cloud while keeping core systems on-premises.

But a hybrid cloud comes with its own challenges. Managing hybrid environments requires teams to master two distinct operational models: cloud-native tools and traditional on-premises infrastructure, which often creates silos and divided expertise. This eventually makes scaling across geographies far more complicated than it should be.

That brings us to **multi-cloud**, the model that has become the end state for many B2B deployments. 

## **What is a multi-cloud platform?**

A multi-cloud platform is a cloud-based platform that enables businesses to run applications and workloads across two or more cloud providers while maintaining a unified management experience. Using multi-cloud platforms, companies can deploy, manage, and scale applications across multiple cloud providers without rewriting code or reconfiguring architecture for each provider.

Organizations approach multi-cloud in different ways. Some run different workloads on different providers using one provider for core applications,  another for data analytics, or other specific services. Others maintain entirely separate deployments for different customers or regions. This article focuses on a third approach: configuration portability. Rather than maintaining active deployments across multiple clouds simultaneously, this strategy uses consistent configuration that works across AWS, Azure, Google Cloud, and OVHcloud, enabling disaster recovery, strategic provider transitions, and deployment flexibility.

The advantages of this approach are clear. Companies gain vendor independence, resilience against outages, and the ability to deploy closer to clients worldwide. For B2B organizations, this translates into faster performance, stronger compliance guarantees, and more leverage when negotiating costs. The drawback, of course, is complexity. Managing multiple providers often means juggling different dashboards, inconsistent environments, and duplicate processes. Without the right platform, multi-cloud can overwhelm the very teams it was meant to empower. 

      
_Now that we have defined single-cloud, hybrid, and multi-cloud, let’s simplify the decision. The table below compares each option's strengths, weaknesses, and when to choose it._   

### **Why multi-cloud matters now more than ever**

Cloud outages remain a persistent challenge. While overall outage frequency has improved over the past several years, organizations across industries continue to experience disruptions, from brief service degradations to multi-hour regional failures. For B2B businesses, the stakes are particularly high when your platform goes down: you're not just losing access to your tools, you're preventing your customers from serving their customers, creating a cascade of operational failures.

Single-provider dependency means your business continuity plan is only as good as your vendor's uptime. When that vendor experiences issues, you have no alternatives, no failover options, and no control over recovery timelines. This isn't a theoretical risk; it's a recurring reality that's driving the shift toward multi-cloud architectures.

### **Essential features of B2B multi-cloud platforms**

B2B multi-cloud platforms must deliver specific technical capabilities that distinguish true multi-cloud platforms from basic multi-provider compatibility tools.

-   **Full-stack preview environments**:  Ability to create consistent development, staging, and production environments across different cloud providers, with equivalent configurations and predictable performance characteristics.
-   **Disaster recovery:** When a cloud provider experiences an outage, multi-cloud platforms enable operations teams to restore their applications on alternative providers using the same configuration files and tested procedures. While restoration involves planned downtime, this approach gives organizations control over their recovery process and makes restoration significantly faster and more predictable than rebuilding infrastructure from scratch during a crisis.
-   **Consolidated monitoring and observability**: Unified visibility into application performance, security events, and infrastructure health regardless of deployment location, eliminating the complexity of managing separate monitoring tools for each cloud provider.
-   **Compliance and data sovereignty:** B2B clients often demand that their data remain within specific geographies. A single provider may not offer the right regions or may not guarantee residency. Multi-cloud solves this by letting businesses deploy exactly where needed.
-   **Reliability and uptime:** Single-provider dependency means your recovery timeline is tied to your vendor's incident response. With multi-cloud, organizations can restore workloads to alternative providers when one experiences issues, reducing dependency on any single vendor's uptime.

## **Challenges of multi-cloud platforms**

While the benefits are undeniable, many companies underestimate the complexity of a multi-cloud. Each provider has its own ecosystem, its own console, and its own quirks. Running two or more clouds often introduces duplicate pipelines, “snowflake” environments, and scattered logs. Development environments start to drift apart, so what works in one region doesn’t behave the same in another. The ops team, on the other hand, juggles upgrades, observability, and security controls across vendors. The result is slower releases and more risk.

Also, costs become difficult to predict without unified visibility. For B2B businesses, where client trust and compliance are on the line, these challenges can’t be ignored. Multi-cloud without the right platform can quickly create more risk than it resolves.

## **Upsun multi-cloud platform** 

Upsun was built for this exact challenge. Managing multi-cloud often means juggling different tools, configurations, and procedures for each provider. Upsun provides cloud-provider abstraction designed for B2B organizations that need flexible deployment across multiple cloud providers.

With Upsun, you define your infrastructure once using portable YAML configuration that works across AWS, Azure, Google Cloud, IBM, and OVHcloud. When a major outage occurs, your team executes documented restoration procedures using this consistent configuration, without having to rebuild provider-specific infrastructure during a crisis.

What this means in practice: If your primary cloud region suffers a severe incident, you initiate a planned restoration to a different provider or region. Your portable configuration, tested procedures, and Git-driven workflow make restoration significantly faster than emergency infrastructure rebuilds.

> **Note**: Upsun does not provide automated cross-region or cross-cloud failover. Instead, it gives teams the building blocks to execute business continuity and disaster recovery with confidence using portable configuration, tested procedures, and consistent workflows that your operations team controls.

### **Single interface for multiple cloud providers**

Upsun provides abstract deployment from underlying cloud providers, offering a consistent workflow across supported regions. Organizations can deploy applications using unified YAML configuration files that work consistently across AWS, Azure, Google Cloud, IBM, and OVHcloud regions. Users can choose regions based on criteria such as closeness to users and environmental impact, while maintaining identical development tools, web interfaces, and Git-based workflows.

This abstraction eliminates the typical complexity associated with multi-provider strategies. Development teams avoid learning provider-specific tools, such as AWS CloudFormation, Azure Resource Manager, or Google Cloud Deployment Manager, instead working through Upsun's unified interface, which allows the platform to manage provider-specific implementations.

### **Disaster recovery** 

Upsun simplifies disaster recovery through portable configuration. Define your application infrastructure once in YAML files that work across AWS, Azure, Google Cloud, IBM and OVHcloud. When a cloud provider experiences an outage, your operations team can execute tested procedures to migrate to a different provider using the same configuration and Git workflow.

This turns disaster recovery from a complex, provider-specific challenge into a manageable process. Instead of maintaining separate runbooks or rebuilding during a crisis, your team executes one documented workflow. While migrations still require time for planning, testing, data migration, and DNS updates, Upsun's portable configuration makes the process significantly more predictable and faster than emergency infrastructure rebuilds.

### **Environment cloning and preview capabilities**

Upsun can spin up production-perfect clones: data, config, and code, on any branch, enabling teams to test applications with real data rather than mocks or stale information. This functionality allows teams to validate application behavior and ensure consistent performance characteristics across different underlying cloud providers.

Upsun's abstraction layer enables teams to get the benefits of multi-cloud testing without the complexity of managing separate environments on each platform.

### **Integrated observability and performance monitoring**

Upsun includes built-in observability tools with infrastructure metrics, APM, profiling, and tracing. These monitoring capabilities function consistently whether applications run on Azure's European regions, AWS's North American infrastructure, or Google Cloud's Asia-Pacific locations.

The platform's observability suite provides unified visibility into application performance and infrastructure health regardless of the underlying cloud provider, eliminating the complexity of managing separate monitoring tools for each cloud platform.

### **Transparent pricing across providers**

Upsun provides transparent and predictable pricing options with environmental impact considerations, offering discounts for deploying to lower-carbon regions across Azure, AWS, IBM, Google Cloud, and OVHcloud. This approach enables organizations to make informed deployment decisions based on both cost and environmental factors without managing separate billing relationships with each cloud provider.

### **Security and compliance standardization**

Upsun includes managed security features like Web Application Firewall, DDoS protection, and security patching that work consistently across all supported cloud providers. The platform handles provider-specific security configurations while maintaining standardized security postures regardless of deployment location.

Upsun offers deployment options across various regions through major cloud providers, supporting compliance with various data sovereignty requirements.

## **Taking action: your multi-cloud checklist**

Organizations can reduce the impact of cloud outages by implementing portable multi-cloud configuration and tested restoration procedures. When a provider experiences an outage, downtime is inevitable but teams with portable configuration execute documented restoration workflows in hours rather than spending days rebuilding infrastructure from scratch. This requires advance preparation: a 90-day implementation plan including disaster recovery drills, data replication strategies, and tier-based recovery objectives for different services.

For B2B companies focused on sustainable growth, operational resilience, and competitive positioning, multi-cloud platforms have evolved from strategic options to essential infrastructure requirements. The critical decision involves selecting platforms that deliver genuine business value, rather than focusing on technical complexity.

Multi-cloud isn't about chasing every provider; it's about giving your B2B team choice (regions, providers), resilience (no single-vendor risk), and control (performance, cost, compliance) without multiplying operational work. A platform approach is what makes that practical. Upsun makes multi-cloud practical with a single, Git-driven workflow and portable YAML configuration. Each branch receives a production-like preview, allowing teams to validate changes before merging.

You select the provider and region for each project, maintaining the same pipelines, and observability across all locations. Book a demo to see Upsun multi-cloud in action with production-like branch previews.

### [Introducing Upsun Dispatch: a platform for the agentic SDLC](https://upsun.com/blog/introducing-upsun-dispatch/)

# Introducing Upsun Dispatch™

AI has made writing code fast, and you can feel it. Commits are up, pull requests are up, new repos spin up over a weekend, and your engineers swear they are faster. But where are all the new products? If every team really got faster, the software you use every day should be getting visibly better. AI helped your engineers ship more code. It didn't help your team ship more products.

For the past several months, we asked engineering and product leaders why, and we wrote down what we found: the 8 stages of AI engineering maturity, and how the bottleneck moved. The short version: the constraint was never typing.

It's tempting to blame the volume, but it isn't really the problem. Writing code was never the whole job; architecting and shipping it safely is. Is it tested? Is it secure? Will it scale? Will it hold up in production? A mature team answers those questions the same way every time, with the process, the tooling, and the test suite it has already built. Where it breaks is the individual who got fast on their own machine, on a framework that's theirs alone and may no longer be good enough. Remembering everything it takes to ship is overwhelming on its own, and hopeless once you have several agents running in parallel.

You've probably seen small "AI-native" teams shipping at a pace that makes no sense for their headcount. Same models as everyone else; the difference is that they embraced the shift and built the harness, the context and the process that turn a capable model into an effective one. We are building that platform as a product.

That is why today we are introducing Upsun Dispatch™.

## **What is Upsun Dispatch™**

Upsun Dispatch is a platform for the agentic software development lifecycle. The founding idea is that the workflow is the primitive, not the agent. Most tools in this space make one engineer faster in their IDE or terminal. The gains are real, but they stay on that one laptop. Upsun Dispatch puts the workflow where the whole team can see and run it, so the speed belongs to the team, not to whoever has the best setup.

Upsun Dispatch is built for the team and fits their rituals. You bring the tools your team already lives in (GitHub, GitLab, Linear, Jira, ...), the workflows that mirror how you actually ship, and the docs and processes that capture how your team works. Upsun Dispatch runs the rest: it picks up work, runs the agents, moves the work through your workflow one step at a time, stops where a human needs to decide, and keeps a logged cost record of every run.

> Writing the code stopped being the hard part, join us in rewriting the SDLC for the agentic AI era. **Register now for our Upsun Dispatch webinar on June 30,2026** and find out how you can help us build Upsun Dispatch.

## **Why we’re building Upsun Dispatch**

A handful of convictions shaped the product. Here they are.

-   **Agents belong in the cloud, not on your laptop**: Running agents on individual machines doesn't scale, and it's a security problem: production secrets and tool access spread across personal laptops, with no isolation and no record of what each agent touched. Upsun Dispatch runs them in an isolated environment, on the context and the process that the whole team relies on.
-   **Agents follow your process, not their own**: A workflow is a sequence of steps that runs the same way every time, with agents and humans both taking part. At the start, while you're still tuning the process and learning what the agents get right, the human gates are everywhere. As trust builds, you take gates out one at a time.
-   **Every change gets a real environment**: Upsun Dispatch works on its own, but pair it with Upsun Cloud, and every change gets more: a preview environment that's a byte-for-byte copy of production, the same infrastructure, the same code, the same data. The agent can test changes for real. And for web applications, anyone in the team can open that environment to judge the change for themselves.
-   **No model lock-in**: A smart router picks the right model for each task automatically. Models and providers will keep changing, and Upsun Dispatch absorbs that rather than bet your workflow on one vendor.
-   **Compliance is built in**: Every run is logged as immutable data: the issue, the agent's context, the plan, who approved it, and what it cost.
-   **You can see what it costs**: Agents spend tokens, and on individual laptops nobody can tell where the money is being spent. Upsun Dispatch shows cost per feature, per workflow, per team.
-   **The whole team ships, not just engineers**: Product, design, security, and managers take part in a workflow directly, approving gates and following runs without touching code.
-   **Built to be driven, not clicked**: Automation matters more to us than the UI. Everything Upsun Dispatch does is available through an API, and a run can start from a person, a GitHub event, a schedule, or an API call.

## **What this means for Upsun**

Upsun Dispatch sits under the Upsun brand because it runs on a decade of production infrastructure built for thousands of customers across every major cloud. The reliability, the security, the multi-cloud flexibility, the 24/7 support: that foundation carries forward into everything Dispatch does.

Upsun Dispatch is not a pivot away from what Upsun does. Upsun has always been about shipping software without infrastructure getting in the way; Upsun Dispatch extends that to the way software is built. It runs on its own and can be used as a standalone product with whatever infrastructure you already have. But it is compatible with Upsun Cloud.

## **How to be part of building Upsun Dispatch**

The conversations we have had with engineering leaders over the past several months shaped every decision in Dispatch. That process is not over: it is the point. We are not building this in a closed room.

The full public launch will happen in September 2026. But as soon as July 1st, our product will be available on an “invite-only” basis to continue gathering early feedback from a select group of users. Throughout the summer, we will continue working closely with a founding cohort of design partners who are already running AI workflows and hitting the orchestration wall. 

Design partners get direct access to our team, real influence on the product roadmap, and charter terms that reflect a genuine partnership rather than a vendor relationship. The product will reflect the people who help build it. 

The SDLC is being rewritten, and we are building the infrastructure to do so safely and at scale, with teams ready to move first. 

**Register now for our Upsun Dispatch webinar on June 30,2026** and find out how you can help us build Upsun Dispatch.

### [GraphQL vs REST: modern APIs explained | Upsun](https://upsun.com/blog/graphql-vs-rest/)

# GraphQL vs REST: a practical guide to modern APIs

REST APIs can box you in, forcing you to jump through hoops for the data you want. GraphQL flips that around. You ask for what you need, and that’s all you get without wasted payloads or filler.

If you’ve tried wiring up an app with lots of connected data, you’ve probably felt REST’s limitations. Sometimes you end up digging through a pile of data you didn’t ask for. Other times, the one thing you need just isn’t there. Either way, your users feel the lag.

Picture your storefront app. All you want are customer names and their latest orders. If you’re using REST, you’ll end up making a bunch of separate requests just to piece things together. With GraphQL, you fire off one query to a single endpoint and get everything you need in one go.

**REST example:**

1.  **Call/customer**: Retrieve all customer data, including unnecessary fields like email and age.
2.  **Call/orders**: Get all orders for that customer, filtering needed details manually.

The REST calls might look like this:

```shell-session
GET /customer/1

{
  "id": 1,
  "name": "Alice",
  "email": "alice@example.com",
  "age": 30
}

GET /orders?customerId=1

[
  { "id": 1, "title": "Laptop" },
  { "id": 2, "title": "Mouse" }
]
```

  
 This REST approach sends excessive data, requiring extra work to filter through it.

**GraphQL example:**

GraphQL handles this more efficiently with a single focused query:

```shell-session
query {
  customer(id: 1) {
    name
    orders {
      title
    }
  }
}

Result:

{
  "customer": {
    "name": "Alice",
    "orders": [
      { "title": "Laptop" },
      { "title": "Mouse" }
    ]
  }
}
```

  
The single request delivers exactly what the frontend needs. No extra roundtrips, no redundant data, simply direct and efficient.

### **The evolution of GraphQL: From Facebook to API standard**

Facebook built GraphQL in 2015 to get data quickly to the News Feed. After making it open source, other companies started using it because it let them handle data requests through a single endpoint with more precision.

Here's what makes GraphQL stand out:

-   It lets you request exactly what you need - no extra data
-   Your frontend code works better with the GraphQL schema
-   It streamlines data relationships between multiple data sources

If you're working with connected data structures, GraphQL's query system makes development straightforward.

## **GraphQL: One endpoint for all your data needs**

### **What sets GraphQL apart**

GraphQL is not just another API - it's a query language that lets you get exactly the data you need through a single endpoint. While this makes client-server communication simpler, you'll want to understand what it brings to the table.

Unlike REST APIs, where you'd need multiple calls for different data, GraphQL brings it all together in one query. Just keep in mind you'll need to think about caching and performance as you build.

Let's look at how GraphQL shapes real applications and why developers are choosing it for modern API development.

### **Core GraphQL concepts**

GraphQL handles data in some unique ways that matter for developers.

-   **Precise data fetching:** Request exactly what you need and nothing more. GraphQL eliminates over-fetching, but you'll need to manage query complexity.
-   **Type safety built in:** Schema validation catches issues early. Design your schema carefully.
-   **Client-driven data:** Clients request exactly what they need, but require solid caching for performance.

GraphQL gives you a flexible and precise API layer. With thoughtful implementation of caching, performance, and schema design, it can make your development process more efficient.

Now let's see how GraphQL uses schemas and types to balance flexibility with performance.

### **Let's talk GraphQL schemas and types: what you need to know**

### **What a GraphQL schema is**

A GraphQL schema defines what data your API can work with - think of it as a contract between your client and server. Using a simple language called SDL (Schema Definition Language), it sets clear boundaries for data exchange.

Let's see this in action with a basic "User" type:

```shell-session
type User {
  id: ID!
  name: String!
  email: String!
}

type Query {
  getUser(id: ID!): User
}
```

The schema acts like a clear set of rules for data requests. You tell GraphQL what fields you want, and the schema checks if those fields exist. Like a menu where you can pick exactly what you need.

Schemas help organize data connections in a way that makes your queries more efficient, giving you just the specific information you're looking for.

### **Building blocks of GraphQL data relationships**

Your schema also shows how different parts of your data link together. GraphQL lets you query these connections through a single endpoint, making it simpler than using multiple REST endpoints.

```shell-session
type Post {
  id: ID!
  title: String!
  content: String!
  author: User
}
```

Each post can link to its author. Unlike REST APIs that need multiple API calls, GraphQL queries can fetch both post and author data at once through a single endpoint - it's a streamlined query language for APIs.

### **Best practices for schema design**

Your schema needs to be both flexible and maintainable if you want it to grow with your app. Here's what works:

-   **Use granular types:** Split larger objects into smaller, focused types. This lets you query exactly what you need from your API.
-   **Leverage enums and input types:** Use enums when you know all possible values upfront, and input types to keep your mutations organized and clear. Since we’ve walked through the fundamentals, I’ll show you a code example so you can see how this plays out in real life.

```shell-session
enum Role {
  ADMIN
  USER
}

input UpdateUserInput {
  id: ID!
  name: String
  email: String
}
```

-   **Name with clarity:** Use simple, descriptive names in your schema that clearly show what each piece does.

A well-structured schema makes it easier for clients and servers to communicate clearly through a single endpoint.

Let's see how these schema concepts work in practice with GraphQL.

## **Core operations**

### **Working with Data in GraphQL**

GraphQL gives you two simple tools to handle data: **queries** and **mutations**. These make it easy to work with your API.

-   **Queries:** Think of these as your data requests. They let you ask for exactly what you want, making your app faster by avoiding unnecessary data.

```shell-session
query {
  getUser(id: "1") {
    id
    name
    email
  }
}
```

-   **Mutations:** You can change data on your server through a single endpoint. It's simpler than REST methods like POST, PUT, and DELETE, but you'll need to set up resolver functions carefully to handle different data changes. The type checking built into the interface finds errors during development.

```shell-session
mutation {
  updateUser(input: { id: "1", name: "John Doe" }) {
    name
    email
  }
}
```

GraphQL keeps things simple with two main ways to work with data: queries to get information and mutations to change it. Everything happens through one connection point, making your code clean and easy to follow.

### **Real-time updates with subscriptions**

GraphQL works with real-time updates through subscriptions that need WebSocket connections and server setup. Once it's running, your app gets updates right when they happen.

Here's what subscriptions look like in a chat app:

```shell-session
subscription {
  onNewMessage(roomId: "123") {
    content
    timestamp
  }
}
```

  
When something new happens (like a new chat message), subscriptions send the updates to connected clients through WebSocket connections. You won't need to keep checking for updates, but you'll need specific server setup and WebSocket support.

### **Error handling in GraphQL vs REST**

GraphQL and REST take different paths when it comes to errors. In REST, you get an HTTP status code and an error message in the response body, so you know what failed. GraphQL keeps it simple. Unless there’s a network issue, you’ll always get a 200 OK, and any errors show up in a dedicated errors field in the response.

Have a look:

```shell-session
{
  "errors": [
    {
      "message": "User not found",
      "path": ["getUser"]
    }
  ]
}
```

GraphQL provides clear error messages when something goes wrong. The schema validation helps developers catch and fix issues during development rather than in production.

Like a helpful translator, GraphQL simplifies communication between your app and data. It packages everything you need into a single request and keeps information flowing smoothly.

Let's see how to get GraphQL running in production with Apollo Server, a solid tool for building GraphQL APIs that many developers trust.

## **Setting up GraphQL in production**

### **Getting started with Apollo**

You can build a GraphQL API that handles all your data through one endpoint with the Apollo server. It's straightforward to get started.

1.  **Install dependencies**:

```shell-session
npm install apollo-server graphql
```

**Create a basic server**:

Here’s an example of creating an Apollo server with a sample schema and resolver.

```shell-session
const { ApolloServer, gql } = require('apollo-server');

// Define the GraphQL schema using `gql`
const typeDefs = gql`
  type Query {
    hello: String
  }
`;

// Define the resolvers for the schema
const resolvers = {
  Query: {
    hello: () => 'Hello, world!',
  },
};

// Create a new Apollo Server instance
const server = new ApolloServer({ typeDefs, resolvers });

// Start the server and log the URL
server.listen().then(({ url }) => {
  console.log(`Server ready at ${url}`);
});
```

To secure your GraphQL API, add a JWT validation step to your middleware layer. Here's how:

```shell-session
const server = new ApolloServer({
  typeDefs,
  resolvers,
  context: ({ req }) => {
    const token = req.headers.authorization || '';
    const user = validateJWT(token); // Custom function to decode/validate JWT
    return { user };
  },
});
```

This security setup means only users who've logged in can use your GraphQL API. You'll also need field and type-level permissions set up - this lets users access and change only the data they're meant to see, all while keeping your single endpoint efficient.

Next, let’s look at how to connect GraphQL with modern client apps using Apollo Client - a tool that makes frontend data management simpler.

## **Apollo Client integration**

Let's set up Apollo Client - it's a GraphQL client that makes your API connections simple. You can use it to link your frontend with a GraphQL API through a single endpoint, so you're only getting the data you need.

1.  **Install client dependencies**:

```shell-session
npm install @apollo/client graphql
```

**Initialize Apollo Client**:

Setting up Apollo Client with a GraphQL endpoint and in-memory caching:

```shell-session
import { ApolloClient, InMemoryCache } from '@apollo/client';

const client = new ApolloClient({
  uri: 'https://example.com/graphql',
  cache: new InMemoryCache(),
});
```

1.  **Enable global access** to query your GraphQL API via a single endpoint:

Wrapping your React app with the ApolloProvider makes data queries easy across your entire application:

```shell-session
import { ApolloProvider } from '@apollo/client';

import App from './App';

const Root = () => (
  <ApolloProvider client={client}>
    <App />
  </ApolloProvider>
);
```

With Apollo Client ready, let's get our API secure and make sure users can access only the data they should see.

### **Authentication and authorization with a single API**

Here's how role-based access control with JWT tokens works in resolvers. Here's a practical example showing how API calls get authorized:

```shell-session
const resolvers = {
  Query: {
    getUser: async (_, { id }, { user }) => {
      if (!user || user.role !== 'ADMIN') {
        throw new Error('Unauthorized');
      }
      return await User.findById(id);
    },
  },
};
```

Apollo Server takes your API data from the JWT token and makes it available in your GraphQL resolvers. This way, you can use that data to check if someone has permission to query or mutate the data source.

### **Testing setup**

Testing helps ensure your API is working correctly. We'll use Jest for our tests since it's straightforward and effective.

**Write a test for a query**:

```shell-session
describe('GraphQL Queries', () => {
  it('fetches user data', async () => {
    const query = `
      query {
        getUser(id: "1") {
          id
          name
        }
      }
    `;
    const response = await executeGraphQL(query); // Replace with test setup logic
    expect(response.data.getUser.name).toBe('John Doe');
  });
});
```

  
Catch issues early by testing often. Your schema will stay reliable, and you'll avoid debugging issues. With testing covered, let's look at optimizing your GraphQL API performance.

## **Performance optimization**

### **Making GraphQL faster with DataLoader**

GraphQL APIs often run into the n+1 query problem. This happens when an API request gets one piece of data, then needs related data - creating multiple database calls that slow things down.

DataLoader makes GraphQL faster by combining database calls and storing results. Here's how GraphQL optimizes API calls to get exactly the data you need:

```shell-session
const userLoader = new DataLoader(keys =>
User.findMany({ where: { id: keys } })
);
// Resolver example
const resolvers = {
Post: {
author: (post) => userLoader.load(post.authorId),
},
};
```

DataLoader combines database queries, reducing server load and speeding up API responses. It makes managing APIs straightforward.

Next, let's see how caching can make your GraphQL API even faster.

### **Caching in GraphQL Applications**

GraphQL doesn't come with built-in caching, but the tools in its ecosystem give you solid caching options. Here's what you can do to add caching to your GraphQL apps:

-   **Client-side caching:** Apollo Client stores your query results locally, so you'll get faster responses and snappier UI updates when you set it up right.
-   **Server-side optimization:** Apollo Server lets you cache responses, which cuts down on database load and speeds up responses for data that's requested often.

Let's look at how to set up caching with Apollo Client:

```shell-session
import { createPersistedQueryLink } from '@apollo/client/link/persisted-queries';
import { ApolloClient, InMemoryCache } from '@apollo/client';

// Configure Apollo Client with persisted queries
const client = new ApolloClient({
  link: createPersistedQueryLink().concat(httpLink),
  cache: new InMemoryCache(),
});
```

### **Keep an eye on performance**

Monitor your GraphQL API to ensure it stays fast and reliable. Apollo's tools show you which queries are popular and where slowdowns happen.

When queries get slow, you'll know right away where to add caching or use DataLoader to speed things up. Regular monitoring helps catch and fix issues early.

### **Running GraphQL with Upsun**

You'll find deploying with Upsun straightforward and fast. We've got built-in caching and deployment tools that let you run your API in production right away. Testing and production environments are quick to set up, so you can start working immediately.

If you've got APIs that need to work in different regions, our global caching keeps things fast and steady. That means your users don't have to wait around—they'll get quick responses no matter where they are, and your GraphQL service stays snappy as you grow.

## **Use cases**

### **Mobile apps: quick and efficient**

GraphQL lets mobile apps get data with a single API call. You'll request exactly what your app needs, just usernames rather than complete profiles.

Consider a mobile app displaying profiles, activities, and notifications. While REST APIs might require multiple calls, GraphQL can consolidate these into one request, which _may_ improve battery life and response times based on your specific implementation and caching strategy.

### **Connected data: streamlined queries**

GraphQL excels at handling linked data, letting you get all related information in one query.

Picture you’re looking up a customer’s order history and want details on what they bought, who sold it, and where each package is right now. With GraphQL, you just ask for everything in one go. If you’re working with REST, you’d be bouncing between multiple endpoints and piecing the info together on your own.

If you’re running microservices, GraphQL can act as your central API gateway. Tools like schema stitching or Apollo Federation let you pull all your services under one roof.

Picture this: users, orders, and products are split into their microservices. GraphQL ties them together with a single schema. The gateway figures out where to find each service, handles the requests, and merges the data for you.

Once you see this approach in action, it’s easier to compare how GraphQL and REST each deal with distributed systems.

## **GraphQL vs REST**

### **Data retrieval patterns**

REST APIs give you fixed endpoints for each resource, but that isn't always the best fit. Without good planning, you'll either get more data than you need (like getting full user profiles when you only want names) or you'll need to make multiple calls to get related data. Modern REST APIs can handle this better by letting you pick specific fields and using other methods to keep things efficient.

GraphQL lets you be precise. One endpoint, exact data. Want a user's name and recent posts? That's what you get.

Example REST response (overfetching):

```shell-session
{
"id": "1",
"name": "John Doe",
"birthdate": "1990-01-01",
"address": { "street": "123 Main St", "city": "Example City" }
}
Example GraphQL query (specific data fetching):
query {
getUser(id: "1") {
name
posts {
title
}
}
}
```

Now let's check out how REST and GraphQL handle data in real situations.

### **Performance differences**

REST works well for simple data that maps to endpoints. But when you need nested data (like users and their posts), you'll need multiple calls or get back extra data you don't need.

GraphQL shines with linked data when you set it up right. You'll write one query to get exactly what you need, which can make your app run faster when it's set up properly. But remember, how fast it runs depends on your caching setup and how you build it. Don't forget to set up DataLoader on your server to prevent N+1 query slowdowns.

### **Version management**

REST and GraphQL don’t handle updates the same way. In REST, it’s common to version your API right in the URL, think /v1/users. Modern REST can also use content negotiation and hypermedia to update without version numbers.

GraphQL lets you update gradually by marking fields as deprecated. Your code keeps working while giving developers time to adapt their code.

Here's how to mark fields as deprecated in your schema:

```shell-session
type User {
  id: ID!
  name: String!
  email: String @deprecated(reason: "Use 'contactEmail' instead.")
  contactEmail: String
}
```

GraphQL lets you update your API gradually. You don't need to push everyone to update at once - devs can shift their code when it works for them.

## **Benefits and challenges**

### **What makes GraphQL great for developers?**

GraphQL comes with built-in tools that let you explore APIs easily during development. While you'll want to turn off tools like GraphiQL and GraphQL Playground in production for security, the type system lets you catch errors early. This type checking works with schema validation to spot problems quickly and makes it simpler for frontend and backend teams to work together.

### **How does GraphQL address overfetching and underfetching?**

REST APIs often give you too much data (overfetching) or require multiple endpoint calls (underfetching). Neither is ideal.

GraphQL lets you request precisely what you need in one query. Want to grab a user's name and their latest posts? That's one query instead of multiple REST endpoints. When properly implemented, you can get smaller payloads and reduced network traffic. Development workflows might be simplified for certain types of applications, especially those with complex data relationships.

Let's look at how caching can make these quick queries run even faster.

### **Let's talk about caching in GraphQL APIs**

Here's what you need to know about making your GraphQL apps run faster with caching.

-   **Frontend caching:** When you use Apollo Client, it keeps a copy of your query results right on the device. Your app loads data more quickly, and you don’t have to hit the server as often. You'll want to pick the right cache settings (cache-first or network-only) to keep your data in sync.
-   **Backend caching:** GraphQL typically doesn't work with CDN caching since it uses POST requests. But don't worry - you can use Automatic Persisted Queries (APQ) to turn queries into cacheable GET requests with unique hashes.

Caching isn’t a one-size-fits-all deal. REST APIs play nicely with HTTP caching and CDNs right out of the box, but with GraphQL, you’ll have to do a bit more work to get the same results. It’s worth stepping back and considering what your app really needs before you settle on a caching approach.

### **Keep your GraphQL API secure**

Let's build security into your GraphQL API from the start. With the right protection, you won't run into issues with complex nested queries slowing down your server. Here's what you need:

-   Set limits on query complexity and depth to prevent slow performance from resource-heavy operations
-   Add rate limiting to protect your API and maintain stable service

You'll want to use graphql-shield on your server for authorization rules. With this middleware, you set up the rules for who can see or change certain data in your GraphQL schema. That way, users only get access to what they’re supposed to.

## **Quick tips for GraphQL**

GraphQL gives you a flexible query language for APIs. While GraphQL and REST can both get data efficiently, GraphQL's schema-first design and built-in type system work really well for certain tasks. It's got solid tools for type checking and real-time updates, which makes it great for modern apps that need lots of data.

-   **Start simple**: Design your GraphQL schema to match what your app needs to do
-   **Pick basic tools**: Use Apollo GraphQL to get started without complex setup
-   Test and monitor your GraphQL API calls to keep performance strong

New to GraphQL? Start by using it for just one feature in your app. This lets you learn the basics while keeping your current systems running.

Try GraphQL with small implementations first. This lets you see how it fits what your team needs to build.

## **Start building with GraphQL**

Want to start building with GraphQL? Let's look at how you can begin.

-   Begin with the basics at GraphQL.org and Apollo GraphQL documentation to understand the core concepts.
-   **Practice with real code:** Spin up a tiny project with Apollo Server and Client. Try out some real queries and mutations to see how things work in practice.

When you're ready for production, use infrastructure tools like Upsun that offer **environment cloning** and **caching mechanisms** to keep your deployment smooth.

Start small, pick a feature to try with GraphQL, test it thoroughly, and build from there. That's the straightforward path to creating clean, efficient APIs.

### [Building and deploying the Symfony ChatGPT app | Upsun](https://upsun.com/blog/building-and-deploying-the-symfony-chatgpt-app-with-upsun/)

# Building and deploying the Symfony ChatGPT app with Upsun

_This blog post is based on a live presentation by Guillaume at a SymfonyCon 2023 on deploying applications with the Upsun platform-as-a-service. We utilized AI tools for transcription and to enhance the structure and clarity of the content._

If you still use File Transfer Protocol (FTP) for deployment, this post is for you. In a 35-minute live session, Guillaume walked through what a Platform as a Service (PaaS) is, why it helps, and how to take a real app from local development to a scalable, observable production environment. 

Before diving into modern solutions, Guillaume posed an interesting question to the audience: "Are there still people deploying with FTP?" The question revealed a telling reality about the current deployment landscape. While some developers have moved to AWS and other cloud platforms, many are still seeking the optimal balance between simplicity and power.

Guillaume brings considerable experience to this discussion, having started his development journey with PHP 3 and Symfony 1.0, which gives him a unique perspective on how deployment practices have evolved over the years.

## Building a real-world application

To demonstrate practical deployment scenarios, let’s build a chat application that serves as a wrapper for ChatGPT. The application consists of two main components:

**The Backend**: A Symfony API that receives prompts via REST, sends them to OpenAI's ChatGPT, and streams responses back to the frontend. The backend stores conversations in a PostgreSQL database and implements real-time streaming using Symfony's StreamResponse functionality.

**The Frontend**: A React application built with Create React App, handling the user interface and real-time message display.

The streaming implementation is particularly noteworthy. Instead of waiting for ChatGPT to generate a complete response (which could take several seconds), the application streams each chunk of text as it arrives from OpenAI back to the frontend using Server-Sent Events. This approach significantly improves user experience by showing responses as they're generated.

## The challenge of streaming applications

Guillaume highlighted a critical scalability issue with streaming applications: "If the response takes three seconds to generate, I've got a PHP worker working for three seconds in the background. If you have 10,000 users using your application at the same time, you need those 10,000 PHP workers running."

This creates a resource allocation problem where workers are tied up waiting for external API responses, even though they're not consuming significant CPU resources. It's a common challenge that many developers face when building real-time applications.

## Upsun: a developer-first platform

Upsun represents a new approach to platform-as-a-service specifically for developers who create complex applications with multiple technologies and components. The platform launched on the day of Guillaume's presentation, targeting developers who work with sophisticated, multi-component architectures.

### **Pick an environmentally conscious region**

An interesting aspect of Upsun is its focus on environmental impact. When creating a new project, developers can choose from various cloud regions across AWS, Orange, Azure, and Google Cloud Platform. The platform provides carbon footprint indicators for each region, allowing developers to choose greener hosting options when sovereignty requirements don't mandate specific locations.

### **Simplified configuration**

One of Upsun's key innovations is its approach to configuration. Instead of the complex YAML configurations that plague Kubernetes deployments (often requiring "25 different YAML files from community plugins"), Upsun uses the Symfony CLI to detect project requirements and generate appropriate configurations automatically.

The process is remarkably straightforward:

1.  The Symfony CLI detects your project's PHP version, required extensions, and dependencies
2.  It automatically generates the necessary configuration files
3.  Everything is committed to your repository for reproducible deployments.

Guillaume then added the second app and the routes that split traffic across `api``.` and the main frontend. Conceptually, it looks like this:

```shell-session
# .upsun/config.yaml (illustrative)
routes:
  "https://api.{default_domain}/":
    to: "app:api"
  "https://{default_domain}/":
    to: "app:web"

apps:
  api:
    type: "php:8.3"
    build:
      flavor: composer:2
    extensions: [curl, pdo_pgsql]
    relationships:
      database: "db:postgresql"
  web:
    type: "nodejs:20"
    build:
      commands:
        - "bun install"
        - "bun run build"
    web:
      commands:
        start: "serve -s build -l 8080"

services:
  db:
    type: postgresql
```

### **Multi-application Support**

For projects with multiple components (like Guillaume's chat application with separate frontend and backend), Upsun handles routing automatically. Developers can define subdomains (such as `api` and `frontend`) and the platform manages traffic routing across different application containers.

## Deployment in action

The live demonstration showed the entire deployment process, from local development to production:

1.  **Project Creation**: Using the `symfony project:create` to set up the Upsun project
2.  **Configuration**: Automatically generating deployment configurations for both applications
3.  **Environment Variables**: Setting up external service credentials (like OpenAI API keys) through the CLI
4.  **Deployment**: A single `Symfony deploy` command handles building, containerization, and deployment

The platform performs deterministic builds, ensuring that deployments are consistent regardless of individual developer environments. This eliminates the common problem where applications behave differently due to variations in local PHP versions, database versions, or differences in JavaScript tooling.

## Performance monitoring and scaling

Upsun includes integrated Blackfire profiling for all environments, providing detailed performance insights without additional setup. This integration revealed that Guillaume's streaming implementation spent 85% of its time waiting for ChatGPT responses, confirming the concerns about resource allocation.

### **Dynamic resource allocation**

Unlike traditional hosting, which locks you into specific plans, Upsun allows for real-time adjustments to resources. Through the CLI or web interface, developers can modify CPU allocation, memory limits, and instance counts on the fly.

Guillaume demonstrated scaling his backend from one to four instances in real-time, with the platform automatically provisioning additional nodes within seconds. This flexibility extends to both horizontal scaling (increasing the number of instances) and vertical scaling (allocating more resources per instance).

### **Observability: requests, logs, metrics**

The platform supports notification-driven scaling, where monitoring systems can automatically trigger resource adjustments. For example, if Blackfire detects response time degradation on checkout transactions at 4 AM, it can automatically increase resources and scale them back down when performance normalizes.

## Pricing model

Upsun also includes a resource-based pricing approach. Developers pay per CPU-second and memory-second of actual resource, plus small user license fees. According to Guillaume, a basic production application (like a blog) can run for around $4 per month, while more complex setups typically cost $30-40 monthly.

This model aligns costs directly with usage, avoiding the common problem of paying for unused capacity or being surprised by scaling costs.

**Deployment strategies and zero-downtime**

Audience questions revealed essential details about Upsun's deployment approach. The platform employs a blue-green deployment strategy, where new container images are built in the background and network connections are switched at the last moment, thereby minimizing downtime.

For applications using database migrations, the platform:

1.  Puts the application in read-only mode
2.  Runs necessary migrations
3.  Switches to the new codebase
4.  Queues and replays any incoming requests that arrived during the transition

This process typically results in 5-10 seconds of apparent latency rather than actual downtime, as requests are queued and processed once the new version is live.

## The developer experience focus

Throughout the presentation, Guillaume emphasized that Upsun is built "by developers, for developers" while also considering broader organizational needs. The platform includes features for collaboration across teams, allowing marketing personnel to review pull requests and project managers to monitor deployments and environment status.

This holistic approach recognizes that modern development involves diverse stakeholders beyond just the engineering team.

## Why this matters for your team

-   **Speed:** From local to live in minutes, with repeatable builds.
-   **Quality:** Profiling and logs on every environment help you ship fixes confidently.
-   **Consistency:** Git-driven YAML keeps app and infra in one place.
-   **Reduced toil:** Scale with a command, not a war room.
-   **Predictable cost:** Pay for the resources you actually use.

## Try the flow yourself

Recreate the demo with your own API plus a small frontend:

1.  Generate the config with your framework’s CLI.
2.  Add a second app block for your frontend build.
3.  Define routes for `api` and the main host.
4.  Commit, deploy, and test using the temporary hostnames.
5.  Add secrets as environment variables and redeploy.
6.  Profile a real request, then scale to match your traffic pattern.

Your first goal is not perfection. It is a clean, repeatable pipeline from commit to production that the whole team can understand. After that, the knobs are there when you need them.

## Looking forward

Upsun represents an interesting evolution in platform-as-a-service offerings, focusing on developer experience while maintaining the flexibility needed for complex applications. The combination of automatic configuration, real-time scaling, integrated monitoring, and usage-based pricing addresses many pain points in the current deployment landscape.

As Guillaume noted, "We need to make sure that the product actually fits you super well." The platform's success will ultimately depend on how well it serves the real-world needs of developers building sophisticated applications in today's multi-component, multi-technology environment.

For developers tired of wrestling with complex deployment configurations or locked into inflexible hosting plans, Upsun offers a compelling alternative that promises to simplify the path from code to production while maintaining the control and observability that modern applications require.

### [HTTP status codes explained: full guide with examples](https://upsun.com/blog/http-status-codes/)

# What are HTTP status codes?

Think of them as three-digit notes from the server that let you know how a client’s request turned out. Did it succeed? Is there an error? Maybe it needs a follow-up? Each code gives a quick answer, letting you know where things stand without digging deeper. Knowing how to interpret these codes? That’s essential for running a stable app and catching issues before they snowball.

**In this guide**

1.  Complete Guide to HTTP Status Codes
    -      Informational (1xx) Responses
    -      Success (2xx) Responses
    -      Redirection (3xx) Responses
    -      Client Error (4xx) Responses
    -      Server Error (5xx) Responses
2.  Managing Status Codes Across Environments
3.  Testing and Implementation Patterns
4.  Best Practices and Real-world Solutions
5.  Getting Started with Upsun

  
Let's break down these status codes by category, then dive into how to handle them effectively across environments.

Status codes are grouped into five categories, each telling you something specific about what happened with a request:

### 1xx: Informational responses

These codes tell you "I'm working on it." They're less common but important for complex operations:

-   100 Continue: The server got your headers and likes what it sees. Keep sending the rest of the request.
-   101 Switching Protocols: Server's agreeing to switch protocols (like upgrading from HTTP to WebSocket).
-   102 Processing: For complex requests that need extra time - server's saying "Still working on it!"
-   103 Early Hints: Server's giving you a heads up about what's coming, often used for resource preloading.

### 2xx: Success responses

These are the "all good" signals:

-   200 OK: The golden standard - everything worked exactly as it should.
-   201 Created: Success! A new resource was created (common after POST/PUT requests).
-   202 Accepted: Request looks good but isn't finished yet - useful for long-running tasks.
-   203 Non-Authoritative Information: Success, but the data might have been modified by a proxy.
-   204 No Content: All good, but there's nothing to send back.
-   206 Partial Content: Here's part of what you asked for (great for streaming and large downloads).

### Additional important 2xx responses

-   205 Reset Content: Client should reset the document view
-   207 Multi-Status (WebDAV): Multiple status codes for single request
-   208 Already Reported: Avoid duplicate enumeration
-   226 IM Used: Server has fulfilled request for the resource

### **3xx: Redirection**

These codes say "Look somewhere else":

-   301 Moved Permanently: Resource has a new permanent home.
-   302 Found: Resource is temporarily somewhere else.
-   304 Not Modified: Your cached version is still good (saves bandwidth).
-   307 Temporary Redirect: Like 302, but keeps your original request method.
-   308 Permanent Redirect: Like 301, but keeps your original request method.

**Understanding redirect behavior:**

-   300 Multiple Choices: Server offers different formats of requested resource
-   305 Use Proxy (Deprecated but important to know): Resource must be accessed through proxy
-   306 Switch Proxy: No longer used but reserved

These redirect codes are crucial for SEO and application architecture decisions.

### **4xx: Client errors**

When the client (that's you) did something unexpected:

-   400 Bad Request: Server can't understand what you sent.
-   401 Unauthorized: You need to authenticate first.
-   403 Forbidden: You're authenticated but don't have permission.
-   404 Not Found: The resource isn't here.
-   405 Method Not Allowed: That HTTP method isn't allowed here.
-   408 Request Timeout: Your request took too long.
-   413 Payload Too Large: Request body exceeds server limits
-   415 Unsupported Media Type: Server doesn't support the content type sent
-   422 Unprocessable Content: Request syntax correct but semantically invalid
-   423 Locked: Resource is locked
-   428 Precondition Required: Server requires conditional request
-   429 Too Many Requests: Slow down! You're making too many requests.

**Additional important client errors:**

-   451 Unavailable for legal reasons: Resource legally restricted

**Critical 4xx codes for API development:**

-   409 Conflict: Request conflicts with server's state (common in PUT operations)
-   411 Length Required: Server requires Content-Length header
-   412 Precondition Failed: Server doesn't meet preconditions from client
-   414 URI Too Long: Request URL exceeds server limits
-   416 Range Not Satisfiable: Requested range cannot be fulfilled

###   
5xx: Server errors

When it's the server's fault:

-   500 Internal Server Error: An error occurred on the server side.
-   501 Not Implemented: Server doesn't support required functionality
-   502 Bad Gateway: Got a bad response from an upstream server.
-   503 Service Unavailable: Server can't handle requests right now.
-   504 Gateway Timeout: Upstream server took too long to respond.
-   507 Insufficient Storage: Server can't store data needed
-   508 Loop Detected: Server detected infinite loop while processing
-   511 Network Authentication Required: Client needs to authenticate to network

### **Common non-standard status codes**

You might also encounter these unofficial but widely used codes:

-   450 Blocked by Windows Parental Controls: Used by Microsoft
-   499 Client Closed Request: Used by nginx when client disconnects
-   520 Unknown Error: Used by Cloudflare for unrecognized server responses

## **Implementation considerations**

When implementing status code handling, consider these factors:

-   Cache implications of different status codes
-   Security implications of detailed error messages
-   Load balancer and proxy interactions
-   Client retry behavior expectations

### Common patterns and antipatterns

#### Good practices:

-   Use specific error codes instead of generic 500s
-   Include Retry-After headers with 429 and 503 responses
-   Maintain consistent error formats across all responses
-   Log detailed errors server-side while sending safe client messages

#### Antipatterns to avoid:

-   Returning 200 OK with error messages in the body
-   Using 404 for authentication failures
-   Sending sensitive information in error responses
-   Inconsistent error formats across services

#### From theory to practice: Managing status codes across environments

While knowing each status code's meaning is essential, the real challenge lies in implementing them effectively. Let's explore how to handle these codes in production-grade applications.

### Why consistent status code handling matters

Now that we understand the full range of status codes, let's tackle the real challenge: keeping them consistent across environments. Status codes and response messages should be straightforward, giving clear signals about the outcome of client request processing and server responses. But too often, developers find that what works in development goes haywire in production—flooding logs with unexpected error codes. When handling of response codes and request processing is inconsistent, it leads to poor user experience, complicates debugging, and introduces security concerns.

For developers, this means wasted time tracing request failures, network errors, and timeout errors and facing unpredictable responses across environments. As applications grow, ensuring consistent, informative status codes becomes essential to keep everything running smoothly. In this guide, we’ll explore practical strategies to help you handle status codes effectively, making your applications more resilient and your debugging process far smoother.

### Understanding response codes and error handling in web service APIs

With our reference guide in mind, let's look at how these status codes behave in practice. Like environment variables, their behavior can vary dramatically depending on context:

-   In development, you might get a 200 Success
-   In staging, the same endpoint returns a 404 Not Found
-   In production, it unexpectedly throws a 500 Error

Each of these codes (as we saw in our reference) means something specific, but their inconsistency across environments signals deeper issues that need addressing.

### Managing status codes across development and production environments

A common issue is when an origin server returns a different status code in production than in development—like a 404 Not Found instead of a 200 OK—often due to differences in file permissions, database access, or other environment factors.

The challenge isn’t just reading error responses; it’s figuring out why a 404 appears in production while a 200 works in development. This gap usually signals underlying issues in request handling or permissions between environments. 

### Common error situations across environments

#### Handling unexpected errors and error responses in production

Unexpected server errors and 5xx error responses in production can be especially frustrating since they're often impossible to replicate locally. These server errors can stem from database issues to configuration mishaps, making debugging tough.

You’ve tested thoroughly. Staging checks out. Yet, production still returns unexpected status codes. Sound familiar? It’s not just about the codes themselves—it’s about how your app behaves differently across environments.

#### Managing response codes and request processing in web service APIs and upstream servers

Modern web service APIs often involve multiple services communicating through request messages and response codes. Each service can return its own status codes, and these need to make sense not just individually, but as part of the whole system. A 200 from your auth service doesn't help if your resource service is returning 403s.

#### Testing error responses and handling request failures across environments

Setting up test scenarios for different response codes and error conditions is essential but challenging when dealing with asynchronous operations and concurrent requests. Manually triggering errors is risky, mocks lack real-world nuance, and feature flags add complexity.

So how do you test error handling without breaking things? Common approaches include:

-   Manually causing errors (risky)
-   Mocking responses (unreliable)
-   Using feature flags (complex)

### Authentication and user experience: Beyond basic status codes

Instead of listing every possible status code, let's focus on the ones that actually impact your daily work and how to handle them effectively:

#### Authentication flow (401 vs 403)

As we saw in our status code reference, 401 and 403 serve distinct purposes. In practice, here's how to implement them correctly:

```shell-session
# The common pattern
@app.route('/api/resource')
def get_resource():
    if not authenticated:
        return {'message': 'Login required'}, 401  # Not logged in
    if not authorized:
        return {'message': 'Access denied'}, 403   # Logged in but not allowed
```

The difference seems simple, but in multi-service architectures, getting this wrong can lead to confusing user experiences and hard-to-debug issues.

### **Handling server errors and timeout conditions effectively**

When your service hits issues or encounters server overload, returning a 503 Service Unavailable with a Retry-After header is far more useful than a generic 500 error—it tells the client the issue is temporary and when they can retry.

**Unhelpful example**

```shell-session
# Don't do this
@app.route('/api/data')
def get_data():
    try:
        # Something breaks
        return {'error': 'Something went wrong'}, 500  # Unhelpful!
```

**Better approach**

```shell-session
# Do this instead
@app.route('/api/data')
def get_data():
    if service_overloaded():
        return {
            'error': 'Service temporarily unavailable',
            'retry_after': '30 seconds'
        }, 503  # Clear, actionable response
```

Progressive enhancement is a solid approach for handling status codes. Start with the basics, like handling 200 OK responses, and then gradually layer in more complexity—such as handling 401 Unauthorized or 503 Service Unavailable.

### The reality of environment differences

Here's what most status code guides don't tell you: even a perfectly implemented status code system can behave differently across environments. When your origin server returns different response codes in production than in development, it often points to deeper issues in request processing and environment configuration.It's not just about getting the codes right - it's about understanding why:

-   Production enforces stricter security rules that can trigger unexpected 401s and 403s
-   Staging environments might lack complete data, causing 404s where you expect 200s
-   Development environments often use mocks, hiding real-world complexity

This environmental inconsistency isn't just an inconvenience - it's a fundamental challenge that affects every aspect of your application's reliability. Just as environment variables need careful management across contexts, status codes require a systematic approach to ensure consistent behavior.

This is where environment cloning becomes invaluable. With Upsun, you can create exact copies of your production environment, allowing you to:

-   Test real status code behavior without risk
-   Debug inconsistencies in isolation
-   Validate error handling across environments

**Real-world example: Handling environment-specific responses**

```shell-session
# Real-world example: Handling environment-specific responses
class EnvironmentAwareHandler:
    def handle_response(self, environment, response):
        if environment == 'production':
            # Production needs careful error logging
            if response.status_code >= 500:
                notify_ops_team(response)
                return fallback_response()
                
        elif environment == 'staging':
            # Staging can show more detailed errors
            if response.status_code >= 400:
                return detailed_error_response(response)
                
        # Development shows maximum debug info
        return development_response(response)
```

**Making testing reliable with environment cloning**

Testing error responses requires understanding both the meaning of each status code (as covered in our reference) and their behavior across environments. Let's look at practical testing strategies for different categories:

-   2xx codes: Verify successful operations
-   3xx codes: Validate redirect chains and caching
-   4xx codes: Test authentication and authorization flows
-   5xx codes: Simulate server issues and recovery

The traditional approach to testing response messages and error handling is fundamentally flawed: you either risk breaking production or rely on incomplete mocks. But what if you could test with production-perfect environments without the risk?

With Upsun, you can safely clone your production environment to test the `EnvironmentAwareHandler`. Specifically, you can leverage the PLATFORM\_ENVIRONMENT\_TYPE environment variable to distinguish between environments in your implementation. This allows you to:

-   Create exact replicas of your production environment in seconds
-   Test real error scenarios with actual data and configurations
-   Validate status code behavior across different conditions
-   Dispose of test environments when done, eliminating cleanup overhead

### From testing to implementation: Real-world patterns

Now that we understand how to test effectively, let's explore patterns that work in production environments. These approaches have been battle-tested across different scales and architectures.

#### Pattern 1: Progressive enhancement

Start with basic handling and add complexity as needed:

```shell-session
async function fetchData(endpoint) {
    try {
        const response = await fetch(endpoint);

        switch (response.status) {
            case 200:
                return await response.json();
            case 401:
                // Handle authentication
                return await refreshAndRetry(endpoint);
            case 503:
                // Handle temporary outage
                return await retryWithBackoff(endpoint);
            default:
                // Log unexpected codes
                logUnexpectedStatus(response.status);
                throw new Error('Unexpected response');
        }
    } catch (error) {
        handleError(error);
    }
}
```

#### Pattern 2: Environment-specific behavior

Different environments might need different handling:

```shell-session
const statusHandlers = {
    development: {
        404: showDetailedNotFound,
        500: showDebugInfo
    },
    production: {
        404: showFriendlyNotFound,
        500: logAndNotify
    }
};
```

### Solving common status code challenges

Development teams face similar challenges when managing status codes across environments. Let's look at how to address them systematically:

Inconsistent behavior across environments is often the first hurdle. Instead of letting each environment handle errors differently, establish a standardized approach. Configure your error responses consistently, implement uniform handling patterns, and most importantly, monitor how status codes behave across different environments. 

Upsun's approach to environment management addresses these challenges head-on. Instead of maintaining separate, potentially divergent environments, you can create instant clones of your production setup. This means your testing environments aren't just similar to production - they're exact copies, down to the last configuration detail.

Testing error scenarios becomes much more manageable when you have isolated environments. Rather than risking production stability, create dedicated test environments that perfectly mirror your production setup. This allows you to implement chaos testing safely - deliberately triggering error conditions to validate your handling - without affecting real users.

Traditional testing often fails to replicate production conditions accurately. Upsun's environment cloning changes this dynamic. You can create a new, isolated environment for each test scenario, complete with real data and configurations, then dispose of it when done. This means no more guessing about how your error handling will behave in production. 

```Python
# Example: Testing status codes across cloned environments
class StatusCodeTester:
    def __init__(self, base_url, environment_type):
        self.base_url = base_url
        self.environment = environment_type
        self.error_patterns = {}
 
    def test_endpoint(self, path, expected_status):
        """
        Test endpoints across different environments without risk
        This is especially valuable with Upsun's instant environment cloning
        """
        try:
            response = make_request(f"{self.base_url}{path}")
            self.error_patterns[path] = response.status_code

            if response.status_code != expected_status:
                log_environment_difference(
                    path=path,
                    expected=expected_status,
                    actual=response.status_code,
                    environment=self.environment
                )

        except Exception as e:
            handle_test_failure(e, self.environment)

    def compare_environments(self, production_patterns):
        """
        Compare status codes between environments
        Useful when validating cloned environments
        """
        differences = []
        for path, prod_status in production_patterns.items():
            if self.error_patterns.get(path) != prod_status:
                differences.append({
                    'path': path,
                    'production': prod_status,
                    'current_env': self.error_patterns.get(path),
                    'environment': self.environment
                })
        return differences
```

Debugging production issues requires visibility. Set up comprehensive monitoring that tracks status code patterns over time. When unexpected codes appear, ensure you're logging enough context to understand what went wrong. This monitoring becomes even more valuable when you can compare patterns across cloned environments, spotting discrepancies before they affect users.

### Understanding production behavior

Debugging status codes in production requires a systematic approach. Start by tracking request patterns, response times, and error status codes over time - this helps identify normal behavior versus anomalies. Combine this with detailed logging of unexpected codes, ensuring you capture enough context to understand what triggered them. Finally, set up alerts that notify you of concerning patterns before they impact users.

With Upsun's environment cloning, you can reproduce these patterns in isolated environments, making it safer to debug and test fixes without affecting production users.

## Principles of effective status code handling

Let's move beyond theory to practical implementation. The key to effective status code handling isn't just about returning the right codes - it's about building a system that's clear, consistent, and maintainable.

Start with clarity: Each response status code and error code should serve a specific purpose in your request processing. Instead of defaulting to generic 500 errors, use precise codes that communicate exactly what went wrong. This might mean using 429 for rate limiting, 503 for temporary outages, or 422 for validation failures.

Documentation becomes your team's shared language. When everyone knows exactly which codes to expect from each endpoint, debugging becomes collaborative rather than confrontational. This is especially crucial for those edge cases that only appear in production.

Building for scale and reliability.

As your application grows, your status code handling needs to evolve. Focus on:

Monitoring and visibility

-   Track patterns across environments
-   Set up alerts for unexpected behaviors
-   Maintain consistent logging

Performance and stability

-   Implement rate limiting (429) for API protection
-   Handle service degradation (503) gracefully
-   Use proper caching (304) for optimization

This systematic approach to error handling and request processing, combined with Upsun's environment management, helps maintain reliability as your application scales.

**The Path Forward**

As you review your status code handling, consider how closely it aligns with best practices. Are you returning specific codes like 429 Too Many Requests or 503 Service Unavailable when needed? Can you safely test error scenarios? Do you have visibility into status code patterns across environments?

## **Bringing it all together: Status codes in modern web development**

The challenge with status codes isn’t knowing what they mean—any developer can see that a 404 is “not found.” The real challenge is managing them effectively across complex, multi-environment applications to ensure consistent behavior and robust error handling.

### Key takeaways:

-   Different environments require different approaches to handling request processing, error responses, and status code monitoring
-   Testing error scenarios requires a systematic, environment-aware approach
-   Proper monitoring and pattern recognition help prevent issues before they impact users

Status codes are your application's nervous system, sending vital signals about its health and behavior across environments. When properly implemented, they provide clear insights for debugging, monitoring, and maintaining stability. The key isn't achieving perfect status code handling—it's building a system that's resilient and consistent across all environments.

This is where Upsun's environment management becomes transformative. By providing instant, accurate environment clones, you can validate your status code handling with confidence, knowing that what works in your test environment will behave the same way in production.

## Getting started with better status code handling

Armed with both our comprehensive reference and practical implementation patterns, you're ready to improve your application's status code handling. Think of status codes as more than just responses—they're a critical part of your app's communication system that needs careful management across development, staging, and production.

Ready to enhance your status code handling? Here's your action plan:

1.  Reference: Keep our status code guide handy for choosing the right codes
2.  Implementation: Use our patterns for consistent handling across environments
3.  Testing: Leverage Upsun's environment cloning to validate behavior
4.  Monitoring: Track patterns to catch issues before they impact users

Want to test your status code handling in a production-grade environment? Try Upsun’s free trial\*, where you can:

-   Test error handling and asynchronous operations safely with instant environment cloning
-   Monitor status codes across different environments
-   Implement proper error handling without risking production
-   Validate your implementation in a real-world setting

#### Start a free trial

\*Free trial provides ample resources to test and evaluate Upsun in a production-grade environment.

### [Introduction to WebSockets | Upsun](https://upsun.com/blog/introduction-to-websockets/)

# Introduction to WebSockets

WebSockets are a communication protocol that enables real-time communication between the client and the server. WebSockets keep the connection alive and allow bi-directional communication. This makes WebSockets suitable for chat and stock market applications, multiplayer games, and collaborative tools.

In this article, we'll explore how the WebSocket protocol works and the advantages of using it over HTTP. We'll also show you how to create a simple chat application using WebSockets in the frontend and backend.

### **HTTP vs. WebSockets**

HTTP is widely used for server and client interactions. It works well in retrieving data and creating resources. But it's unidirectional, meaning the client must initiate all requests and the server cannot send data on its own. This limitation makes it inefficient for applications such as stock market tickers or multiplayer games, where you need to transfer updates between the client and server hundreds or thousands of times per minute. For each update, the client needs to repeat a request-response cycle, which takes a lot of compute resources and bandwidth. Using HTTP for such applications also makes the server inefficient because it is overloaded with new requests even when there is no update available for the clients.

To address this limitation, you can try HTTP long polling, where the server keeps the connection open longer while waiting to send more data with the response. As soon as the client gets the response, it makes a new request to ask for more data. While this works well to replicate real-time behavior, keeping a long-running connection open can cause server timeout issues and hinder performance if too many clients keep polling the server even when new updates aren't available. Additionally, because the client makes requests at predefined intervals, the updates may not appear instantly. For example, imagine a multiplayer video game that needs to sync player locations and scores in real time. HTTP would need to send a new request every few seconds to fetch the latest game state, which adds unnecessary network overhead and latency.

On the other hand, WebSockets provide much lower latency and network overhead while keeping a bidirectional channel for real-time communication. Using a full-duplex connection allows the client and server to interact and send messages without creating a new connection, which reduces the transmission overhead related to creating a new connection for each request. The persistent connection in WebSockets minimizes bandwidth usage by not sending the HTTP headers with each message. WebSockets also offer a more real-time feel to applications because they don't need to follow a polling cycle. Hence, new data arrives instantly as soon as it's available. All these benefits make WebSockets a much more practical option for real-time uses, such as chat and stock market applications, multiplayer games, and collaborative tools.

Here's a diagram comparing the HTTP and WebSockets connection timeline:

If you've ever built a chat feature using HTTP polling, you know the pain: users complaining about delayed messages, servers groaning under constant requests, and that sinking feeling when you realize your "real-time" app has a 5-second delay. WebSockets solve this elegantly by maintaining a persistent, bidirectional connection that feels truly instant.

### Basics of the WebSocket protocol

The WebSocket protocol creates a persistent connection between the client and the server for bidirectional communication. The connection process starts with an HTTP request called a handshake, where the client requests the server to upgrade the connection to the WebSocket protocol. After the handshake, the connection shifts to the WebSocket protocol. The following diagram shows the connection sequence between the client and the server.

  
Here's how the WebSocket protocol connection works: The client sends an HTTP request to the server for a connection upgrade to the WebSocket protocol. The request includes `Upgrade: websocket` and `Connection: Upgrade` headers, as in the following example:

```shell-session
   GET /chat HTTP/1.1
    Host: example.com:8000
    Upgrade: websocket
    Connection: Upgrade
```

  
The server sends a response to the client with a `101` status code to indicate that the connection has been upgraded to the WebSocket protocol. The response includes `Upgrade: websocket` and `Connection: Upgrade` headers. Here's an example:

```shell-session
    HTTP/1.1 101 Switching Protocols
    Upgrade: websocket
    Connection: Upgrade
```

After the handshake, the client and the server can now communicate bidirectionally without any additional requests.

Either the client or the server can close the connection at any time.

#### **Using WebSockets in the frontend**

Next, we'll show you how to create a simple chat application using WebSockets that lets you send and receive messages. The frontend application will let the users send messages, and the backend server will broadcast the messages to all connected clients.

You can follow along using this GitHub repository.

To get started, create a project folder named `websockets-js-node` in your working directory by running `mkdir websockets-js-node` in your command line tool.

In the project folder, create a directory named `frontend` by running `mkdir frontend` in your command-line tool.

In the `frontend` directory, create a file named `index.html` by running `touch index.html` in your command-line tool.

In the `index.html` file, add the code to render a simple HTML page with input fields for the username and message, a button to send the message, and a `script` tag to include the `index.js` script file that implements the frontend WebSocket logic, as follows:

```shell-session
   <!-- frontend/index.html -->

   <!DOCTYPE html>
   <html lang="en">
     <head>
       <meta charset="UTF-8" />
       <meta http-equiv="X-UA-Compatible" content="IE=edge" />
       <meta name="viewport" content="width=device-width, initial-scale=1.0" />
       <title>WebSocket Client</title>
     </head>
     <body>
       <h1>WebSocket Client</h1>
       <input type="text" id="username" placeholder="Your username" />
       <input type="text" id="messageInput" placeholder="Type your message" />
       <button onclick="sendMessage()">Send</button>
       <div id="messages"></div>

       <script src="index.js"></script>
     </body>
   </html>

```

  
Create a file named `index.js` by running `touch index.js` in your command line tool, and add the following code to configure the WebSocket connection to the backend server:

```Javascript
   // frontend/script.js

   // Create a WebSocket connection to the server
   const socket = new WebSocket("ws://localhost:8080");

   // Display connection status
   socket.onopen = () => {
     console.log("Connected to the WebSocket server");
   };

   // Handle incoming messages from the server
   socket.onmessage = (event) => {
     const messageDiv = document.getElementById("messages");
     const newMessage = document.createElement("p");
     newMessage.textContent = event.data.toString();
     messageDiv.appendChild(newMessage);
   };

   // Handle connection closure
   socket.onclose = () => {
     console.log("Disconnected from the WebSocket server");
   };

   // Send a message to the server
   function sendMessage() {
     const usernameInput = document.getElementById("username");
     const messageInput = document.getElementById("messageInput");
     const message = messageInput.value;
     const username = usernameInput.value;
     if (message) {
       socket.send(`${username}: ${message}`);
       messageInput.value = "";
     }
   }

```

The code does the following:

-   It creates a WebSocket connection to the backend server.
-   The `socket.onopen` event is triggered when the connection is established.
-   The `socket.onmessage` event is triggered when a message is received from the server. It appends the message to the `messages` div.
-   The `socket.onclose` event is triggered when the connection is closed.
-   The `sendMessage` function is called when the user clicks the **Send** button. It gets the username and message from the input fields and sends them to the server using the `socket.send` method.

#### **Using WebSockets in the backend**

Now that the frontend is ready, let's create a backend server that the frontend can connect with to send and receive messages. In the following section, we explain how to implement a simple chat application that broadcasts incoming messages to all connected clients.

For the backend implementation, this example uses the ws npm package, which is a battle-tested library for creating a WebSocket server in Node.js.

Note that the code examples in this tutorial are made using Node.js version 20. We recommend using Node.js 22 (current LTS) for new projects.

In the project folder, create a new directory named `backend` by running `mkdir backend` in your command line tool. In the `backend` directory, create a file named `server.js` by running `touch server.js` in your command line tool.

Run the following command in your command line tool to install the `ws` package:

```shell-session
   npm install ws
```

In the `server.js` file, add the following code to create a simple HTTP server and a WebSocket server using the HTTP server:

```shell-session
   // backend/server.js

   const http = require("http");
   const { WebSocketServer } = require("ws");

   // Create a simple HTTP server
   const server = http.createServer((req, res) => {
     res.writeHead(200, { "Content-Type": "text/plain" });
     res.end("WebSocket server is running.\n");
   });

   // Create a WebSocket server using the HTTP server
   const wss = new WebSocketServer({ server });

   wss.on("connection", (ws) => {
     console.log("New client connected");

     // Send a welcome message to the newly connected client
     ws.send("Server: Welcome to the WebSocket server!");

     // Listen for messages from the client
     ws.on("message", (message) => {
       // Broadcast the received message to all connected clients
       wss.clients.forEach((client) => {
         if (client.readyState === ws.OPEN) {
           client.send(message.toString());
         }
       });
     });

     // Handle client disconnection
     ws.on("close", () => {
       console.log("Client disconnected");
     });
   });

   // Start the HTTP and WebSocket server on port 8080
   server.listen(8080, () => {
     console.log("Server is running on http://localhost:8080");
   });
```

The server code does the following:

-   The `on("connection")` event is triggered when a new client connects to the WebSocket server. The server sends a welcome message to the newly connected client and starts listening for messages from the client.
-   The `on("message")` event is triggered when a message is received from a client and the message is broadcast to all connected clients.
-   The `on("close")` event is triggered when a client disconnects from the WebSocket server.
-   The `server.listen()` method is used to start the HTTP and WebSocket server on port 8080.

To run the server, navigate to the `backend` directory and run `node server.js` in your command line tool. This will start the server and make it accessible for the frontend application at `http://localhost:8080`.

Open the `frontend/index.html` file in two web browser tabs to test the real-time chat application. Fill in the usernames and send messages from one tab, and they will appear in the other tab in real time.

The final result should look like this:

**Production Considerations**

While our example works great for development, production WebSocket applications need additional considerations like connection management, authentication, and handling network interruptions. Modern platforms like Upsun handle many of these concerns automatically, including load balancing WebSocket connections and managing SSL termination.

#### **Take your WebSocket app to production**

Building a WebSocket application is just the beginning; getting it running reliably in production is where things get interesting. You need to handle scaling when your chat app goes viral, debug performance issues in real-time connections, and test new features without breaking the live experience for your users.

This is where Upsun shines. As a developer-focused platform built for modern applications, Upsun makes deploying WebSocket apps refreshingly straightforward. Every Git push automatically creates a complete preview environment, including your WebSocket server, database, and all dependencies, so you can test real-time features with actual data before they hit production. 

Plus, with built-in observability and performance monitoring, you can spot connection bottlenecks or message delivery issues before your users do. Whether you're building a simple chat app or a complex real-time collaboration tool, Upsun handles the infrastructure complexity so you can focus on what makes your application special.

Ready to see how easy WebSocket deployment can be? Start your free trial and have your real-time app running in minutes.

### [Crafting Hybrid PHP-Go CLIs with Symfony Console | Upsun](https://upsun.com/blog/crafting-hybrid-cli-php-go-symfony/)

# Crafting Hybrid PHP-Go CLIs with Symfony Console

_This article is based on a presentation by Antonis Kalipetis, Staff Engineer at Upsun, delivered at SymfonyCon 2024 in Vienna. We utilized AI tools for transcription and to enhance the grammar and syntax._

At SymfonyCon 2024 in Vienna, Antonis, a staff engineer at Upsun, shared the story of how Upsun rebuilt a command-line interface as a single, portable binary that still runs years of PHP commands. The twist: the new CLI is written in Go, routes both legacy and new commands, and uses Symfony console for a consistent developer experience.

## The challenge: when your CLI needs to grow up

Upsun has been around for over 10 years, and in our early days, we were laser-focused on the PHP and Drupal communities. Naturally, our CLI was written in PHP; it made perfect sense. We could reuse existing code, share shortcuts with our users, and everything worked smoothly within our PHP ecosystem.

But then came the inevitable question that many growing companies face: **"Do I really need to install PHP just to use a CLI tool?"**

This hit us hard when we started targeting more ecosystems beyond PHP. Imagine a React developer or a Python developer being told they need to install PHP just to interface with our platform. It's not just about PHP – nobody wants to install any language runtime just to use a tool.

### Goals for the new CLI:

When we sat down to rethink our CLI strategy, we established three core goals:

#### **1\. Backward Compatibility**

We couldn't break existing workflows. Every command that worked with our old PHP CLI needed to continue working seamlessly. Our users had CI systems, scripts, and muscle memory built around our existing commands.

#### **2\. Performance Without Sacrifice**

We wanted a fast CLI that didn't compromise on functionality. No more waiting for runtime initialization or dealing with slow startup times.

#### **3\. Universal Accessibility**

The CLI should work for everyone, regardless of what languages they have installed on their machine. A single binary that just works.

### **Choosing Go for the new CLI**

After evaluating our options, Go emerged as the clear winner for several reasons:

-   **Single Binary Distribution**: Go compiles to a single binary with no external dependencies. Download, make executable, run, that's it. Seconds instead of minutes for setup.
-   **Cross-Platform Compilation**: From my Mac, I can compile binaries for Windows, Linux, and different architectures – all with the same codebase and toolchain.
-   **Performance**: Go is fast and has become the go-to language for developer tooling. Tools like Terraform and many other CLI tools are written in Go.
-   **No Runtime Dependencies**: This was the big one – no more requiring users to install PHP.

### Embedding PHP without requiring PHP

Here's where it gets interesting. Instead of rewriting everything from scratch, we chose a hybrid approach that gave us immediate benefits:

#### **Embedding legacy code**

We embedded our existing PHP CLI into the new Go binary. This meant:

-   **Instant backward compatibility** – everything that worked before continues to work
-   **Same user experience** – no need to retrain users or update documentation
-   **Gradual migration** – we could migrate commands one by one as needed

#### **Building a minimal PHP binary**

The technical challenge was: how do you run PHP code from Go without requiring PHP to be installed? Our solution was elegant:

1.  Build a minimal PHP binary with only the necessary extensions for our CLI.
2.  Compile this minimal binary for each target platform.
3.  Embed this binary into our Go CLI.
4.  Route commands to either PHP (legacy) or Go (new) as needed.

Yes, it was time-consuming to set up, but you only do it once.

### Command routing made simple

Our hybrid CLI works as a smart router:

`User Input → Go CLI → Route Decision → Execute in PHP or Go`

**Command Loading**: We load all commands (both legacy and new) on the Go side, providing a comprehensive view of available functionality.

**Parsing and Validation**: All argument parsing and validation occur in Go, allowing us to catch errors before they reach PHP.

**Execution**: Based on the command, we either execute Go code directly or shell out to our embedded PHP binary.

### Real results: The good, bad, and ugly

#### **The good**

-   **Single binary distribution** – users love the simplicity
-   **Easy embedding of Go tools** – we can include other Go-based tools directly in our CLI
-   **Code reusability** – our Go code can be reused in SDKs and other projects
-   **Better testing** – Go's testing ecosystem made our end-to-end testing much more robust

#### **The bad**

-   **Dual maintenance** – we now maintain both legacy PHP code and new Go code
-   **Release complexity** – coordinating releases across two codebases requires careful planning
-   **Developer laziness** – most functionality still lives in the PHP side because it's easier to maintain existing code than rewrite it

#### **The ugly**

-   **Symfony shortcuts** – PHP's Symfony Console supports command shortcuts (like `app:init` becoming `a:i`), but this doesn't work seamlessly across the hybrid boundary
-   **Autocomplete challenges** – getting autocomplete to work properly across two CLI systems required significant effort.

### Switching to the Symfony console in Go

Here's where our story takes an interesting turn. Did you know the Symfony CLI itself is written in Go? This was a revelation that completely changed our approach.

The Symfony team had already solved the problem of implementing Symfony Console's functionality in Go. All those shortcuts, autocompletion features, and command routing – it's all there in Go, open source and ready to use.

#### **Why this was perfect for us**

-   **Same UX/DX** – our legacy CLI used Symfony Console in PHP, so using the Go version meant an identical user experience.
-   **Argument parsing** – all the complex parsing logic worked the same way.
-   **Command routing** – we could handle both legacy and new commands in a centralized way.

### Implementation: making it work

Our new architecture with Symfony Console for Go works like this:

1.  **Load all commands** (both PHP legacy and Go new) into the Go-based Symfony Console
2.  **Route intelligently** – determine whether to execute in PHP or Go based on the command
3.  **Parse and validate** everything on the Go side before execution
4.  **Provide unified autocomplete** and shortcuts across all commands

### **Command Routing in Action**

```shell-session
# Legacy PHP command - routed to embedded PHP
upsun project:list

# New Go command - executed natively
upsun project init

# Shortcuts work for both!
upsun p:l    # Routes to PHP
upsun p init # Routes to Go
```

## The migration path

Our rollout strategy was intentionally gradual:

**Phase 1**: Legacy CLI only (where we started). 

**Phase 2**: Hybrid CLI with embedded legacy code.

 **Phase 3**: Symfony Console integration for unified routing.

 **Phase 4**: Gradual command migration from PHP to Go

This approach meant we never had a "big bang" moment where everything could break. Users could adopt the new CLI at their own pace, and we could migrate functionality incrementally.

## Testing without breaking production

When you're handling users' production code and deployment pipelines, reliability is paramount. Our testing strategy includes:

#### **Integration testing**

We run the same commands through both the PHP version and the embedded version, ensuring identical outputs. If a command works in the old CLI, it must work exactly the same way in the new one.

#### **Unit testing**

Standard Go unit testing for new commands and functionality.

#### **End-to-End testing**

Go made this much easier – we can spin up mock servers and test complete workflows without external dependencies.

## What's next?

We're not stopping here. Our roadmap includes:

### **Authentication improvements**

Moving all authentication logic to Go for better performance and security. Go's ecosystem offers better support for secure credential storage than PHP.

### **Plugin system**

We're exploring ways to enable users to extend our CLI with their own custom commands, potentially written in Go and integrated seamlessly.

### **Complete migration**

While we'll always support legacy commands, we're gradually moving core functionality to Go for better performance and maintainability.

### Live demo

During the presentation, I showed our CLI in action:

```shell-session
# Original CLI
upsun project init  # Works

# New hybrid CLI  
u project init          # Also works

# Symfony shortcuts now work across both!
u p init                   # This now works too!
```

The shortcuts and autocompletion work seamlessly across both legacy PHP commands and new Go commands, thanks to Symfony Console handling all the routing logic.

## Key takeaways for your projects

If you're facing a similar challenge, here are the lessons we learned:

1.  **Don't fear hybrid approaches** – you don't have to rewrite everything at once
2.  **Leverage existing solutions** – the Symfony Console Go implementation saved us months of work
3.  **Prioritize user experience** – backward compatibility is often more critical than technical purity
4.  **Plan for gradual migration** – big bang rewrites are risky; incremental change is safer
5.  **Test extensively** – when users depend on your tools for production workflows, reliability is non-negotiable

## Wrapping up

Building a hybrid PHP-Go CLI taught us that sometimes the best solution isn't the most obvious one. By embracing both languages and leveraging Symfony Console's Go implementation, we created a tool that's faster, more accessible, and more maintainable than what we had before.

The CLI is open-source – you can find it on GitHub under Upsun/cli – so feel free to explore our implementation and borrow ideas for your own projects.

Sometimes the best way forward isn't to abandon your legacy, but to build bridges that honor your past while embracing your future.

_Want to learn more? The Upsun CLI is open source, and we're always happy to discuss our approach. You can find us at Upsun or check out our GitHub repository to see exactly how we implemented this hybrid approach._

### [Greener hosting: Electricity Maps annual carbon intensities | Upsun](https://upsun.com/blog/upsun-annual-carbon-intensities-from-electricity-maps/)

# Upsun is using annual carbon intensities from Electricity Maps

## Upsun remains committed to carbon intensity transparency

One of the value propositions of Upsun is to offer greener hosting. By choosing cloud hosting instead of on-premise hosting, you are selecting a greener way to host your applications and websites. In addition, when creating a project, you have the option to choose the greenest region to host it.

How? Because Upsun is committed to greener hosting by displaying the carbon intensities (gCO2eq/kWh) of the different data centers it proposes so that you can make the best-informed decisions concerning your projects’ digital carbon footprint.

Due to the power source of the underlying electricity grid, the electricity used to operate the data center has a specific carbon intensity. This means that for a specific project (Y), the amount of electricity will be the same, but the carbon footprint, measured in gCO2eq, of a project will vary by location. This is the location-based approach that the Greenhouse Gas Protocol specifies for certified carbon audits.

## Our chosen source of data for carbon intensity

Upsun is powered by Platform.sh who, since May 2023, decided to use the annual carbon intensities from 2022 Electricity Maps (EM) to support greener hosting—and Upsun is no different. Below you can find a table of the carbon intensity values that were used for Platform.sh previously and those we will be using going forward. These carbon intensity values going forward will also be applied to Upsun.

\*Greener region  
†Added this datacenter 1 February 2024

## Why the change from 2020 IEA to 2022 Electricity Maps data?

Several reasons led us to choose the Electricity Maps (EM) carbon intensity data instead of that from the International Energy Agency (IEA) to align with our commitment to sustainability and greener hosting practices. When calculating the carbon intensities (g CO2/kWh), the IEA states that it uses emission factors that use the 2006 Intergovernmental Panel of Climate Change (IPCC) Guidelines whereas EM applies a more recent methodology outlined in the IPCC 2014 Fifth Assessment Report. As the IPCC update represents the scientific consensus of peer-reviewed published studies, we consider it to be more accurate.

Additionally, EM also uses some zone-specific emission factors for the EU and the US, with data coming respectively from the European Commission and the US Environment Protection Agency (EPA), further supporting greener hosting efforts. Regarding the United States, every year the EPA publishes the Emissions & Generation Resource Integrated Database, called eGRID. The eGRID data include generation, emissions, and other attributes for nearly all power plants in the US. For Europe, the European Commission publishes yearly verified emissions and allocations for all installations included in the EU-ETS, the EU Emissions Trading System.

Finally, EM is also using some direct emission factors coming from peer-reviewed scientific papers, or meta-analysis sources. So in addition to using a more recent methodology, EM supplements its data with additional sources when possible, enhancing our commitment to greener hosting solutions. From this, we conclude that the EM data are more accurate than the IEA ones.

In addition to a commitment to refining their work, EM is committed to an open-source approach (here’s the GitHub repository) and making their historical data available for free, stating, “This will remove barriers for companies trying to be at the forefront of granular carbon accounting.”

For all these reasons, Platform.sh and Upsun plan to use EM as the source of our carbon intensities going forward.

The author would like to thank Leah Goldfarb, Sabri Helal, and Deniz Evrard for their contributions to this article.

### Sources:

-   EM Default emission factors
-   EM regional emission factor
-   EM US emission factors
-   US emission factor dataset
-   EM European emission factors
-   EPA eGrid
-   EU dataset under “documentation”
-   IEA emission factors 2021 database documentation
-   2006 IPCC Guidelines for National Greenhouse Gas Inventories

### [The truth behind application modernization | Upsun](https://upsun.com/blog/application-modernization/)

# The truth behind “application modernization”

Are you currently considering refactoring, replatforming, or rearchitecting an application? Well congratulations because that most likely means that you’ve chosen to embark on the path to **application modernization** after discovering the four key benefits which the Cloud can provide.

## Unveiling the benefits of cloud application modernization

Specifically tied to application modernization, these benefits are as follows:

1.  **IT modernization:** by reducing the technical debt from outdated hardware and software and improving the underlying infrastructure including: improved security, operations, reliability, scalability, and more.
2.  **Cost savings:** by reducing the amount of money spent on costly hardware and software and improving the utilization of resources including: lower TCO or switching from CAPEX to OPEX.
3.  **Business agility:** by being able to react to market changes faster and improving the capacity to roll out new application modernization business initiatives to make the most of new opportunities.
4.  **Innovation:** by driving new value from technology and developing and releasing modern products and services.

However, even with all of these benefits to look forward to the path to application modernization isn’t always an easy one. It can often split across multiple different directions with many organizations not knowing which to take. But fear not - let us lead the way and reveal the truth about two paths which organizations frequently cross and don’t know which to take: DIY and Managed Kubernetes or the all-in-one PaaS.

## Foundational pillars of modern application evolution

Before we dive into the best choice for application modernization today, we need to look into where it all started. Whether you decide to develop your own platform or rely on a PaaS, they both rely on the same five fundamental principles of modern engineering practices that lead the path to modernize applications.

These principles form a coherent set of best practices to follow:

1.  **Open-source technologies:** If you’re still not convinced on adopting OSS then check out this article from our friends at Strapi.
2.  **Containerized applications:** Ready to say goodbye to your development environment that reflects your production from…2016? It’s time!
3.  **Microservices-ready:** But remember, stacking them up over and over again will bring you right back to a monolith - so remember to keep ‘em tidy.
4.  **Git-driven:** There’s truly no other way to code, it’s gotta be Git.
5.  **Serverless first:** Simply run your code and pay-per-use. And fingers crossed you don’t have any bugs in your code.

Now, with the basics down, it’s time to get into what it really means to lead an application modernization project with all its different stages and challenges. Allow us to lift the veil on any confusion around application modernization before we dive into those two paths we mentioned earlier.

## Charting the course to application modernization

By shedding some light on the methodology behind application modernization, we hope you will be able to identify which step(s) present a potential risk for your team or project. Allowing you to evaluate which of the two paths (DIY or PaaS) is the most suitable for you to take knowing the full picture:

-   **Step 1:** Assess what you have. It may seem obvious but we’ve lost count of how many times teams have discovered at the very last moment a small function or component their applications need to run that they missed out.
-   **Step 2:** Secure sponsorship. When a project is led by an individual without effective transparency with their team…usually things don’t go too well.
-   **Step 3:** Validate automatically. No organizational siloes or middlemen between development and operations. Adopt DevOps.
-   **Step 4:** Design as a standard. And you might, at some point, consider a rebuild rather than a migration.
-   **Step 5:** Track for efficiency. We’re not talking about operations monitoring but health metrics you can check on a weekly basis in your stand-ups.
-   **Step 6:** Change and train. Even if you’re a DIY-person and a great self-learner when it comes to enterprise-grade deployment, it’s strongly recommended to adopt the editor’s customer success methodology.

Got them all? Great! You’ve got everything you need to make the right decision. It’s time to dive into our two paths - DIY or PaaS - starting with the former.

### DIY and Managed Kubernetes

Are you willing and ready to design, build, and run your own implementation? Amazing - you’re most likely a DIY person! And like every DIY YouTube video, it starts by setting up your own workshop or as we call it in the cloud ecosystem, the landing zone. You can also view it as the foundation of your project and as a result, an unavoidable cost.

The Landing Zone is made of various different pillars and modules that evolve with time. And while it can vary depending on whether the application is made for PoC initiatives or global enterprise workloads, there are a few key items which are required for a production environment. These are:

1.  IAM and governance
2.  Networking
3.  Security
4.  Observability
5.  Shared services
6.  Billing
7.  Automation

Seems like a lot, right? In reality, a specialized agency is able to deliver a standard and production-ready setup in roughly 25 working days. That’s not including the additional time for training and documentation that would be expected with any project.

Now, let’s assume that your goal is to deploy Kubernetes, even though it relies on Managed Services like Google Kubernetes Engine or Azure Kubernetes Service. Unfortunately, certain features don’t work by magic. For example, Autopilot or Auto-scaling work really well…once you have the proper configuration, that is.

To deploy a Kubernetes-based application, the initial landing zone we mentioned earlier needs to have some modules adapted including network, security, observability, shared services, and automation. As well as a new key module created: the Kubernetes architecture.

Fine, but what does that mean exactly? Well, you’ll have to consider things like the isolation strategy, the high-availability, the node pools settings, the label settings, the workloads classifications, the LimitRange and quotas settings, etcd encryption configuration, Pod Security Policies and Security Context, and the list goes on.

A list that will need about 15 additional working days to work through meaning a total of 40 working days for a landing zone set up if you add in those 25 days from earlier. A minimum initial investment which should always be considered before embarking on a DIY strategy - especially in the long-term. And remember, it’s DIY which means that every time a new use case emerges, you’ll have to do it yourself again and maintain what you’ve already created for the foreseeable.

When it comes to DIY and Managed Kubernetes it’s important to consider the purpose of what you’re trying to build. Not all developers take up their role to engineer custom platforms and even major companies have failed at doing so. But that’s precisely why Platform-as-a-Service (PaaS) solutions were created.

### All-in-one PaaS

At this point in the article you’re probably thought to yourself “yeah, they’re right about DIY but…” or “hmm but what if…” and we hope you’ve done exactly that! It means that like the majority of other people, you want to see the full map before you take a new path for your next project. Ensuring that a PaaS is flexible enough to meet your project and development needs and getting answers for questions like:

-   Can I switch from AWS to GCP?
-   Can I host my application in France and not in Germany?
-   Can I migrate away from ElasticSearch to OpenSearch?
-   Can I develop in Node instead of PHP?
-   Can I build an independent middleware for modernizing apps?
-   Can I build a new microservice-architecture application?
-   …and no doubt, many more.

We get it, people need reassurance that a new path is going to lead somewhere better. And in many cases, we can all have some difficulty when letting go of some responsibilities on our projects. But if you can move beyond those concerns, then you can welcome yourself to the world of PaaS and embrace an easier road to development.

The concept of PaaS is a pretty attractive one - you focus on delivering the code while the provider manages everything else. Sounds good, right? No need to build a landing zone or anything else for that matter. And it all works in a declarative manner, just tell the provider what you want (usually in a YAML config. file), redeploy, and it’s usually yours. All while having the freedom to do a bit of customization or use external tools to bolster your application where wanted or needed.

PaaS really is a foolproof way of standardizing your infrastructure but it’s no secret that standardization can come at a cost. A higher cost which for us, delivers greater benefits.

When scouring the market for the best PaaS you should pay attention to attributes like: the platform’s dependency to the underlying IaaS providers and the localization available, the bring-your-own tool policy (like a CDN), and the set of supported runtimes they offer. You should also take a look at the history of the platform provider as it can reveal a lot about the philosophy and purpose of the solution they are providing. There’s a huge difference between an engineer who built a product to solve their former pain points and an entrepreneur who wanted to jump on a market opportunity. But there are plenty of PaaS providers who can provide you with it all.

## The better approach to application modernization

Imagine - you’ve decided it’s time to modernize your application, you already adopted the best practices we discussed earlier and have designed a methodology to make it happen. That means there’s only one question left unanswered: do I go solo or PaaS?

That’s something only you can decide, but if you want our opinion on the matter—a PaaS might just be the way. Test out if we’ve led you down the right path to PaaS with our free trial today!

### Watch this video

### [The hidden business risk of cloud lock-in | Upsun](https://upsun.com/blog/anything-but-that-cloud/)

# Anything but that cloud

"Anything but that cloud."

I asked why.

"Our biggest customer is a giant retailer," he said. "That hyperscaler's parent company is the retailer's biggest competitor. So our customer refuses to do business with anyone who uses that cloud. We use that cloud, we lose our biggest customer. Full stop."

That was the entire conversation about cloud choice. It wasn't a technical preference. It wasn't a pricing optimization. It wasn't a sovereignty concern. It was a single downstream customer, doing a long-running piece of competitive gamesmanship with a specific hyperscaler, and the ripple of that choice landed on my prospect's entire infrastructure strategy.

I’ve thought about that meeting a lot over the years. The shape of the problem kept showing up in other calls.

## The cloud decision you made before you needed to

When you pick an application platform, cloud choice rarely feels like a decision. You pick the platform for the developer experience, the preview flow, the framework support. The cloud underneath is an implementation detail somebody else's operations team thinks about. That's mostly fine.

Mostly.

There's a specific business moment where "an implementation detail somebody else thinks about" becomes "the one thing standing between you and a contract." My retailer guy is one version. The other versions show up under different labels. A regulator asks where data is processed. A large customer's procurement team requires deployment in a specific region. A CFO brings down a consolidation mandate to line up cloud spend with an existing committed-use agreement on one of the hyperscalers. An acquisition brings a different cloud into your org that now has to line up with the rest of the stack.

None of these show up in the evaluation spreadsheet when you pick the platform. All of them can block revenue when they show up later.

## Why most platforms hand you the answer

The platforms that popularized modern full-stack DX built their abstractions on top of their own infrastructure. That's what makes them feel magic. Push, preview, deploy, scale. It works because the platform operator owns the substrate.

Which also means the platform is the cloud. "Which region?" is a menu the platform operator controls. "Which cloud?" is not on the menu. If that prospect had been on one of those platforms, the conversation would have been short and final. "We don't support running outside our infrastructure." Deal over.

Here's the part that's easy to miss. Most teams never hit this wall until they start selling into a segment that cares. Then the wall moves from invisible to load-bearing overnight.

It's a passport that works in one country. You can have a great life inside that country. The day you need to cross a border is the day you learn which kind of passport you have.

## What Upsun does

Upsun deploys the same application, described by the same `.upsun/config.yaml`, to AWS, Azure, GCP, IBM, or OVH, across dozens of regions. Not with a different configuration per cloud. The same configuration.

When a customer's security team needs you in Europe, it's a regional decision. When a prospect tells you their biggest customer won't work with vendors on one particular cloud, you can pick a different one. When a CFO wants the cloud spend to count against an existing AWS, Azure, Google, or IBM commitment, Upsun is on all four marketplaces, so the answer is yes without rewriting the application.

The capability is multi-cloud deployment with a single declarative configuration, available through the hyperscaler marketplaces your company already buys through. The business capability is a yes, instead of a ninety-day project.

## The sentence you weren't expecting

The customers I talk to who need multi-cloud options rarely start the conversation there. They start somewhere else, talking about preview environments or backend runtimes or compliance scope. Multi-cloud comes up later, usually in a throwaway sentence. "Oh, and we have a customer who needs us on the west coast, is that doable?" Or: "we've got a procurement review where they're asking about a specific hyperscaler."

The throwaway sentence is the one that decides whether the deal closes or turns into an eighteen-month engineering project.

My prospect didn't know his biggest customer was going to land in his infrastructure strategy until the day they did. He was lucky. He was evaluating platforms, and we could provide him with options. The fact that his platform choice happened to align with his biggest customer's preferences was, in the most literal sense, an accident.

Most teams don't get to rely on that accident.

## A question to sit with

If your largest prospect this quarter asked you to deploy in a specific region, explicitly not in a specific hyperscaler, or on a cloud where their committed spend already lives, how would you answer, and how long would the project take?

If the answer is "we could, it's a simple drop down choice," you're in a good spot. If the answer is "we'll have to replatform," that might not be a crisis today. But it's a constraint you should know about before the customer asks, not after.

The "anything but that cloud" prospect signed with us, for what it's worth. Still servicing his biggest customer, last I heard. The preference has never shifted. What has shifted is that now, a platform that lets you answer "sure, which one" to a cloud question isn't a nice-to-have. It's the difference between a deal and a ninety-day project.

Pick the passport that works in more than one country.

## Further reading

-   Upsun platform overview
-   Upsun multi-cloud and multi-region deployment

### [Architecture blueprint for developer freedom | Upsun](https://upsun.com/blog/architecture-blueprint-for-giving-developers-freedom-on-top-of-standardized-infrastructure/)

# Architecture blueprint for giving developers freedom on top of standardized infrastructure

For the modern IT Middle Manager, the rise of **Shadow IT**, from marketing teams buying SaaS on credit cards to developers spinning up unapproved cloud instances, is not a sign of a rebellious workforce. 

It is a diagnostic signal that your current governance model is broken. 

When security rules and infrastructure bottlenecks slow down delivery, engineers will always find a path around the "gate."

The solution isn't more policy enforcement; it is a fundamental shift in architecture. We need to move from a "rules-based" culture to a "rails-based" system where developers move fast while governance remains intact by design.

## Freedom versus chaos: defining the boundary

In a fragmented organization, every team deploys their own stack, leading to a duplication of systems: 5 CMSs, 8 clouds, and 20 ways to handle authentication. 

This isn't autonomy; it's chaos.

The core of a modern architecture blueprint is **defining exactly where standardization stops and developer freedom begins**.

On a unified platform like Upsun, standardization happens at the platform and runtime layer. The "rails" consist of a hardened container runtime, standardized networking, and governed resource allocation. 

Within those rails, the developer has **100% freedom in the application code and feature logic**.

They can choose their framework (Node.js, Python, PHP, etc.) and their internal architecture, but they must use the standardized, read-only filesystem and managed services provided by the platform. 

This ensures that "freedom in code" never descends into "chaos in infrastructure."

## Standardization at the platform layer: predictable behavior

Traditional DIY cloud setups are unpredictable. 

A developer might manually tweak a security group in AWS or change a PHP version in an SSH session, creating a "snowflake" environment that is impossible to audit.

Predictable behavior in a standardized architecture is achieved through **Infrastructure-as-Code (IaC)**. 

By defining the entire environment in `.upsun/config.yaml`, you ensure that what works in a local preview environment is exactly what will run in production. 

For an IT manager, this means "sleeping better at night" because compliance is no longer a manual check. It is a deterministic outcome of the code. If a project doesn't match the configuration template, it simply won't build.

## Guardrails instead of gates: automatic enforcement

Traditional governance relies on "gates": manual approval steps that require a human to sign off before code is deployed. 

These gates are the primary driver of Shadow IT because they introduce latency.

A modern blueprint replaces gates with **automated guardrails**.

-   **The hard guardrail:** Upsun’s native build hooks act as your built-in CI/CD gatekeeper. You don't need to maintain a separate, complex CI pipeline to ensure safety. You can automatically run security scans and compliance checks within the platform itself.   
    If the code fails a scan, the build is rejected before it ever touches a server, ensuring security is a prerequisite for deployment, not an afterthought.
-   **The financial guardrail:** Enforce resource limits at the platform level. If a team tries to spin up a massive instance for an experimental project, the platform blocks the request based on the centralized policy, preventing budget leakage without a single email exchange.

## Scalability and the "exception to the rule"

One of the biggest fears in standardization is the inability to handle innovation. "What happens if a team needs to break a standard for a specific AI experiment?"

A "no-jail" architecture handles the exception through **governed extensibility**. 

Instead of a developer going rogue on a private AWS account, the platform provides an "escape hatch" via the Upsun API and CLI. This allows for specialized integrations or custom service configurations while keeping the project within the primary IT control plane. 

You get the 20% of specialized innovation without losing the 80% of standardized efficiency.

## Multi-cloud portability: abstracting the specific

Finally, this blueprint solves the multi-cloud headache. In a fragmented environment, developers must learn the specifics of every provider, AWS, Azure, GCP etc., leading to massive cognitive load.

By standardizing on a unified configuration layer, you provide **multi-cloud portability by default**. The developer writes the application intent in `.upsun/config.yaml`, and the platform handles the specific implementation details of the underlying cloud provider. This abstracts the complexity, allowing your team to scale across regions and providers without needing a 20-person DevOps team for each cloud.

### Next steps: Implementing the blueprint

Transitioning to a standardized backbone allows you to dismantle the "hidden factory" and reclaim your team's innovation capacity. Here is how to start:

-   **Audit your current exceptions:** Identify where developers are bypassing your current rules. These "shadow" areas are your first candidates for standardized rails.
-   **Define your base config:** Create a standardized `.upsun/config.yaml` template for your primary tech stack to ensure predictable behavior across all teams.
-   **Deploy a Golden Path:** **Start a free trial** and move one "Shadow IT" project into a governed Upsun environment to prove that speed and safety can coexist.
-   **Automate your guardrails:** Learn how to implement build and deploy hooks to replace manual approval gates with automated compliance.

## Ready to codify your standards?

**Request a technical demo** to see how Upsun uses `.upsun/config.yaml` to deploy Golden Paths and end the shadow IT cycle for good.

### [Avoid vendor lock-in with open source | Upsun](https://upsun.com/blog/vendor-lock-in/)

# Vendor lock-in: not even once

Vendor lock-in remains one of the most significant concerns when choosing a cloud platform. When your data becomes trapped in proprietary formats or services, migration costs skyrocket and your flexibility disappears. This challenge affects organizations of all sizes, from startups planning for growth to enterprises managing complex compliance requirements.

## Why open source matters for data control

Open source database solutions provide a foundation for true data portability. Services built on MariaDB, PostgreSQL, RabbitMQ, and Valkey give you complete control over your data. You can extract information using standard open source clients without encountering proprietary formats or undocumented APIs. There's no vendor-specific tooling required, and no special cases that lock you into a particular ecosystem.

This approach ensures you can audit every aspect of how your data is stored and accessed. When you need to migrate or create backups, you have the technical capability to do so using well-documented, industry-standard tools.

## The EU Data Act and data interoperability

The recent Data Act from the EU makes data portability even more critical. This legislation enforces easier data interoperability between cloud platforms, requiring providers to facilitate customer data movement. Open source solutions naturally align with these requirements since they use standardized formats that work across platforms.

When you build on open source infrastructure, you're already positioned to meet these regulatory demands. Your data exists in formats that any compliant platform can work with, eliminating the need for complex conversion processes or proprietary export tools.

## Trade-offs: flexibility vs. advanced features

Open source solutions do come with limitations. Features like transparent re-sharding for horizontal database autoscaling remain exclusive to proprietary systems like Vitess or Google Spanner. However, this doesn't mean you're restricted in your scaling options.

Proprietary databases and open source solutions offer different mechanisms for addressing scale. Guaranteed resources provide dedicated CPU and memory allocations for consistent, high-performance workloads. For application-level scaling, horizontal scaling lets you run multiple instances of your applications with autoscaling that dynamically adjusts based on CPU usage. Workers enable you to handle background processes separately from web requests.

Open source solutions can still reach substantial scale with these approaches. The trade-off comes down to configuration effort versus data portability. Proprietary databases might offer more automated scaling features, but you maintain full control over your data and can reach the scale your applications need with open source alternatives.

Some services offered include solutions with complex licensing histories, such as Elasticsearch and MongoDB. Both technologies were fully open source before transitioning to the Server Side Public License (SSPL). These remain available because existing customers required upgrade paths, but they represent exceptions rather than the standard approach.

## Balancing control with managed services

Data portability doesn't mean unrestricted access to every configuration setting. Managed database services apply Upsun's expertise to optimize settings based on infrastructure resources. For example, `innodb_buffer_pool_size` in MariaDB gets configured based on allocated memory rather than allowing manual adjustment.

You can always run databases as applications with full configuration control, but this approach trades the convenience and optimization of managed services. The key distinction is that your data remains accessible and portable, even when specific database tuning parameters are managed automatically.

## Start building with data portability in mind

Your data represents your most valuable asset. Choosing platforms that prioritize open source solutions and data interoperability protects your ability to adapt as your needs evolve. Whether you're navigating regulatory compliance or planning for future growth, data portability provides the flexibility your organization needs.

Ready to explore a platform built on open source principles? Create a free Upsun account to see how open source infrastructure can support your applications, or explore our documentation to learn more about available services.

### [Application security - It's more than just secure coding | Upsun](https://upsun.com/blog/application-security/)

# Application security

The truth about application security is that it's not really about application security. Secure coding practices are a good thing—please sanitize your inputs people. But actually, that's possibly the smallest piece of a much larger cybersecurity puzzle.

The basic goals of application security is that you don't want to get hacked and you don't want your application(s) to be down.

Unfortunately, an incredibly large amount of people for one reason or another want to hack you and bring your systems down. And isn't even personal. It's their job. They are paid for it. And their bosses don't want to spend their time needlessly. 

Like every good professional, these hackers automate. 

You don't need to be special to be a target. You don't need to have a billion in the bank. And you can't hide in the crowd. Computers are fast. Often faster than we intuitively imagine. Even if you have something hidden behind a billion permutations, it takes less than a second for a computer to try every one.

I love this joke: a few tourists are walking around in the jungle when they spot a beautiful, hungry looking tiger. "Run for your lives!" someone cries. And all, except one, start running. He stops, takes out running shoes from his backpack and puts them on. Another one of his comrades, still running, cries to him, "But are you mad?! Do you think you can outrun a tiger?!" - he responds "I don’t need to outrun the tiger, I only need to outrun you."

This joke has been used to explain to people they shouldn't be “soft targets” - you should make yourself look strong enough so the hungry tiger passes on to the next delicious target. 

But, as you might know, the great killer of the forests is not the awesome tiger. It's the mosquitos that get you. There are enough targets for all the thirsty mosquitos and enough mosquitos to sting anyone who is not covered.

And while evidently some systems are more important than others, and merit more protection - not every computer system on earth has nuclear launch codes on them - all need some. It's not if you are getting attacked, it's when. And _when_ is mostly all the time and a few minutes after your system went live (and possibly even before, we will get to that).

Let's take it as a given that you are a serious software developer and that you apply secure-coding practices. You sanitize your inputs like your parents told you to. You minimize the surface. You create defense in depth. You build your system to use ephemeral secrets (so evidently they are not lying around on hard disks anyway). 

The problem is that software by itself doesn't do much. Or anything at all. In order to do useful things it actually needs a whole lot more. A way to build it - including its dependencies. Somewhere to build it. Configuration. Sometimes with secrets (because while you only do ephemeral ones - the API you are using might want a static API key). Underlying operating systems with a network stack - that hopefully only exposes it, as it wanted to be exposed. Databases. Message Queues. Caches. There is also data. Data that can be a vector (usernames and passwords are data too).

Actually when you look at it, if you look at a trivial system and the number of lines of code that run, all could have a security issue hidden in them. Let's imagine a typical Ruby on Rails application:

-   **Typical Rails application:** 15,443 lines of code. 
-   **Ruby on Rails:** 338,728 lines of code. 
-   **Ruby on Rails's default dependencies:** 1,161,724 lines of code. 
-   **Postgres:** 1,491,985 lines of code. 
-   **Linux:** 34,279,868 lines of code. 

The tiny green square is your code. In a real picture you wouldn’t be able to see it. This is without SystemD:  add 1.3M lines just for that one. And that is without a distribution. Without openssl etc –and before we consider all of the other code that is going to be in the loop for deploying and running your application. Your observability stack. Your orchestration tooling.

_Source:_ _https://xkcd.com/2347/_ 

You know XKCD 2347 … this is somewhat of a similar situation - but the other way around. And think that if we mesh both pictures together - the truth is that most of the application hasn’t been written by you - it’s going to have a deficiency somewhere.  And even that is kind of a static view of things. The actual surface is different.

#### **People are the Weakest Link**

The most secure software can be undermined by a single person making a mistake or being successfully targeted by social engineering. Educating users about security best practices is just as important, if not more so, than the software's built-in security features.

#### **Infrastructure Matters**

Even if an application is secure, the infrastructure it runs on must also be secure. This includes the servers, the network, and even the physical facilities housing the hardware. A breach in any of these areas can undermine application security.

#### **Holistic Security Approach**

A truly secure environment considers not only application security but also network security, endpoint security, identity and access management, data security, and more. They all work together.

#### **It’s About Risk Management**

Absolute security is impossible. It's about understanding risks, prioritizing them, and managing them effectively. This includes regular security assessments, monitoring, and a proactive approach to potential vulnerabilities.

#### **Continuous Process**

Security isn’t a one-time thing. New vulnerabilities are discovered every day, and threat actors are continuously evolving their techniques. Regular updates, patches, and monitoring are essential to ensure that security measures are always up-to-date.

#### **Privacy Considerations**

A secure application also respects user privacy. Sometimes, the lines between security and privacy can blur. For instance, while collecting user data might enhance security measures, it can also infringe on users' privacy rights.

#### **Compliance and Regulations**

Application security also involves adhering to various regulations and standards, which may vary by industry and region. This can include GDPR for data protection, PCI DSS for payment card security, HIPAA for health information, and more.

#### **Vendor and Third-party Risks**

An application may be secure, but if it integrates with third-party services or vendors that aren't, the entire system becomes vulnerable. This means that securing an application also involves ensuring that all its connections and integrations are secure.

The harsh reality is this tangled web of risks and concerns are largely unavoidable in modern application delivery. We can’t be experts in everything, or monitor all of these pieces changing around us all the time.

In the end, we’ll be better off the sooner we accept it, and choosing a security-focused Cloud application platform like Upsun makes doing that that much easier. Upsun provides expertise in securing infrastructure, relying on explicit definitions to define access control, and managing services continuously behind the scenes to mitigate risks to always remain compliant, even for the most sensitive data. 

Protecting the code you don’t write yourself is tough – for many different reasons. Learn what you can, and keep yourself and your team as educated as is possible on best practices. Otherwise, accept that we all can’t be experts, control what you can as strictly as you can, and consider that when it comes to infrastructure and DevOps, an expert like Upsun could be your secret weapon.

### [Getting started with Django on the Upsun PaaS | Upsun](https://upsun.com/blog/setting-up-django-on-upsun/)

# Up(sun) and running with Django

Looking to get started with Upsun and Python? The Upsun CLI contains a command called `project:init` designed  to get you started on Upsun  with a number of frameworks—including Django—as quickly as possible.

## **Setting up**

Let’s start with a simple Django codebase, in this case using the popular Python templating utility cookiecutter: 

```shell-session
cookiecutter https://github.com/cookiecutter/cookiecutter-django
```

The cookiecutter CLI will prompt you to answer a series of questions about email, CI tools, and IDE. Answer according to your preference, but be sure to:

-   Select the latest version of PostgreSQL for your database
-   Select “Other SMTP” for the mail service
-   Include the Django Rest Framework (“use drf”)
-   Pick “Webpack” for your frontend pipeline
-   Include “Whitenoise”
-   Use “Celery”

After finishing the prompts, you’ll have a new skeleton project in whichever directory you passed as the name (in the examples below, new\_project):

```shell-session
.
├── README.md
├── bin
├── compose
├── config
|   ├── __init__.py
|   ├── api_router.py
|   ├── celery_app.py
|   ├── settings
|   |   ├── __init__.py
|   |   ├── base.py
|   |   ├── local.py
|   |   ├── production.py
|   |   └── test.py
|   ├── urls.py
|   └── wsgi.py
├── docs
├── locale
├── manage.py
├── new_project
|   ├── __init__.py
|   ├── conftest.py
|   ├── contrib
|   ├── static
|   ├── templates
|   ├── users
|   └── utils
├── package.json
├── requirements
├── requirements.txt
├── setup.cfg
├── tests
└── webpack
```

With the project in place, we can then generate a first draft of our Upsun configuration using the CLI:  

```shell-session
cd new_project && upsun project:init
```

Follow the prompts to include configuration for both PostgreSQL and Redis. This command will automatically detect the Django project based on the presence of a `manage.py` file, and generate two pieces of configuration: an environment file and a primary configuration YAML file.

The `.environment` file at the root of the project which will be created, sets environment variables that the cookiecutter project needs. You can inspect this file yourself, but a few important pieces that become available include general Django project settings:

```shell-session
# .environment

export DJANGO_SETTINGS_MODULE=config.settings.production
export DJANGO_SECRET_KEY="$PLATFORM_PROJECT_ENTROPY"
export DJANGO_ALLOWED_HOSTS=".platformsh.site"
```

This section appends Django’s allowed hosts to include all URLs generated for Upsun preview environments, to update Django’s secret key to match the unique project hash, and to leverage production settings (in this case) across all Upsun environments.

Additional credentials are expanded from built-in environment variables to establish connections with managed services provided by Upsun:

```shell-session
# .environment

# Set database environment variables
export DB_HOST="$POSTGRESQL_HOST"
export DB_PORT="$POSTGRESQL_PORT"
export DB_PATH="$POSTGRESQL_PATH"
export DB_USERNAME="$POSTGRESQL_USERNAME"
export DB_PASSWORD="$POSTGRESQL_PASSWORD"
export DB_SCHEME="$POSTGRESQL_SCHEME"
export DATABASE_URL="${DB_SCHEME}://${DB_USERNAME}:${DB_PASSWORD}@${DB_HOST}:${DB_PORT}/${DB_PATH}"

# Set Cache environment variables
export CACHE_HOST="$REDIS_HOST"
export CACHE_PORT="$REDIS_PORT"
export CACHE_SCHEME="$REDIS_SCHEME"
export CACHE_URL="${CACHE_SCHEME}://${CACHE_HOST}:${CACHE_PORT}"

# Set Redis environment variables
export REDIS_URL="$CACHE_URL"# Celery
export CELERY_BROKER_URL="$CACHE_URL"# General
```

An `.upsun/config.yaml` file is also added that configures build, deploy, and available services for the project. It includes configuration for the services you selected via prompts:

```yaml
# .upsun/config.yaml

services:
    postgresql:
        type: postgresql:15
    redis:
        type: redis:7.0
```

Application configuration is also added. It defines how Django is built and deployed via pip, how access is granted to the above services via `relationships`, and how to run the server with Gunicorn:

```yaml
# .upsun/config.yaml

applications:
    new_project:
        type: "python:3.11"
        hooks:
            build: |   
                set -eux
                pip install --upgrade pip
                pip install -r requirements.txt
                npm install
                npm run build
            deploy: |   
                set -eux
                python manage.py collectstatic --noinput
                python manage.py migrate
        web:
            commands:
                start: "gunicorn -b unix:$SOCKET config.wsgi"
            upstream:
                socket_family: unix
            locations:
                    "/":
                        "passthru": true
                    "/static":
                        "allow": true
                        "expires": "1h"
                        "root": "static"
        mounts:
            "/staticfiles":
                "source": "local"
                "source_path": "static_assets"
        relationships:
            postgresql: "postgresql:postgresql"
            redis: "redis:redis"
```

With these two pieces of configuration, we can create a new project and deploy Django on Upsun:

```shell-session
$ git add . && git commit -m  “Prepare for Upsun!”
$ upsun project:create 
$ upsun push
```

With this production environment deployed, we can now adjust the resources provided to that environment with the CLI command `upsun resources:set`.

## Next steps

You may have noticed that the cookiecutter project expected credentials to configure connect to Redis to run Celery to manage tasks for the application. We included an environment variable to connect but didn’t specify how to actually run that service.

We can now create a new preview environment that can match production with respect to its build images, containers, data, and resources as much as we’d like.

```shell-session
$ upsun branch try-celery --type staging
```

From this environment we can once again commit and push, with some Celery workers defined:  

```yaml
# .upsun/config.yaml
applications:
    new_project:

        ...

        workers:
           celery_worker:
               commands:
                   start: "celery -A config.celery_app worker"
           celery_beat:
               commands:
                   start: "celery -A config.celery_app beat"
```

Test the connection and performance of the workers in the isolated environment, and then when you’re satisfied promote the new workers to production:

```shell-session
$ upsun merge try-celery
```

And just like that, your next Django project is up, running, and ready to go with Upsun's Django PaaS!

### Useful links

-   Django Girls: community, python, and open source - Podcast

### Watch this video

### [Database indexing basics: how indexes make queries faster](https://upsun.com/blog/basics-of-database-indexing/)

# Basics of database indexing

At some point, we have all been there: a perfectly functioning application suddenly slows down as your database grows. The application, which previously worked on lightning speed queries with 10,000 records, now takes forever with 10 million records. The culprit? Missing database indexes.

Database indexing can transform sluggish table scans into lightning-fast lookups by creating optimized data structures that act as shortcuts to your information. Think of it as the difference between flipping through every page of a phone book versus jumping directly to the right section using the alphabetical tabs, except the performance difference can be measured in milliseconds versus minutes.

Understanding the basics of database indexing and its various types will allow you to significantly improve query performance for large databases.

In this article, we introduce database indexing and explore the different types of indexing techniques, and demonstrate practical implementations that can dramatically improve your query performance.

## **What is database indexing, and how does it work?**

A database index is a supplementary data structure that provides quick reference for specific columns, allowing the database to locate data without scanning the entire table.

The index is structured as a sorted list of values from the indexed columns, where each value is linked to a pointer that directs to its corresponding row in the main table. When you query the database, it first looks up this sorted index to find the desired values, then uses the stored pointers to directly access the relevant rows in the table.

Most indexes use a "B-tree" structure, which organizes data in layers, allowing the database to quickly narrow down its search by following branches. Some indexes, especially for unique values, use a hash table, which converts values into unique codes pointing directly to rows.

But since the index is a separate structure, it uses additional storage space in the database, and it also needs to be updated whenever data in the indexed columns changes. Different database systems may implement these storage and update mechanisms differently.

## **Why do we need database indexing?**

Indexes improve database search performance by eliminating the need for full table scans. Without an index, when you query a database, it must sequentially check each row until it finds the data you are looking for. An index allows the database to quickly locate records by referencing the sorted structure, which is especially useful for efficiently handling `WHERE` clauses without scanning every row. This dramatically improves query performance, especially for large data sets where sequential scanning would be impractical.

For example, when you're searching for a customer by their phone number in a database with millions of records, an index on the phone number column allows the database to pinpoint the matching records instantly.

While indexes significantly improve read performance, they come with a trade-off. Whenever you insert, update, or delete data in an indexed column, the database must also update the associated index structures. This adds extra disk I/O and processing overhead, which can slow down write operations. Thus, it's essential to carefully weigh these trade-offs when deciding which columns to index.

## **Types of indexes**

This section discusses three index types that can improve the performance of SQL queries.

### **B-tree indexes**

B-trees are a widely used index type in databases to organize data in a sorted, layered structure. This self-balancing tree structure allows databases to locate specific rows quickly, avoiding the need to scan entire tables.

As shown in the diagram, B-trees organize data into smaller, sorted sections across different branches. Values are arranged from lowest (on the left) to highest (on the right). This structure makes them well-suited for efficient range queries and rapid lookups. As data is added, the B-tree adjusts its branches and nodes to maintain its sorted, balanced form, which also ensures that lookups remain efficient even as the database grows.

The database uses the indexed value as a B-tree key and stores a pointer to the record as the B-tree value. When you search for a record with a specific value, the database finds the matching key, retrieves the pointer, and then gets the record.

The B+ tree is a variation specifically designed for database storage systems. Unlike standard B-trees, B+ trees store all data only in leaf nodes and link these leaves together. This structure makes B+ trees ideal for range queries and table scans, which is why most database engines (like MySQL's InnoDB) use B+ trees rather than standard B-trees for their indexes.

**Did you know?** Many popular databases, such as MySQL, PostgreSQL, and Oracle, use B-tree or B+ tree indexes as their default indexing method, including for primary keys.

### **Hash indexes**

Hash indexes differ from B-trees in their underlying mechanism. They use a hash function, a mathematical algorithm that converts input data into a unique code, or hash, representing that data.

Hash indexing works in two steps:

1.  The indexed column value is passed through the hash function to generate a unique hash code.
2.  This hash code serves as a pointer to the row's location in the database table.

The diagram below illustrates how hash indexes map hashed values to database locations.

This direct-mapping approach allows for constant-time `O(1)` lookups, making hash indexes especially efficient for exact-match queries, such as finding a specific customer ID or order number with `WHERE column = 'value'`  clauses.

However, hash indexes have a critical limitation: they only work for exact matches. Since hash functions scramble the natural order of data, you cannot use hash indexes for range queries (like WHERE age > 25), sorting operations, or pattern matching. This makes them unsuitable for most real-world scenarios where you need flexible querying.

### **Full-text indexes**

Full-text indexes are specialized indexes that make searching large text fields much faster by indexing individual words (terms) within a text column. Rather than treating a text as a single entity for an exact match, a full-text index breaks it into searchable terms, which improves the database's speed when handling complex text searches, like finding all records containing a specific word or phrase.

A commonly used structure for full-text indexing is the inverted index, which essentially maps words (or terms) to the documents containing those words. For instance, if we have three documents and the first and the second one contain the word _strawberry_, then the mapping would show _strawberry_ pointing to documents 1 and 2.

Here is a simple illustration of this concept:

**Note:** Full-text indexes typically ignore common words like "the," "is," and "and" (called stop-words) to save space and improve search performance. By ignoring these frequent, low-importance words, the index can save space and increase search efficiency.

Full-text indexes are particularly useful for applications that require advanced search capabilities. They are ideal for searching large volumes of text, such as finding specific keywords in articles, identifying features in product descriptions, or locating phrases within user messages. Consider creating a full-text index on a large text field if an application needs to search within its content. For example, you might add a full-text index to the `product_description` field if users frequently search for product features, such as _bluetooth_ or _wireless_.

But, full-text indexes take up significantly higher storage space and require ongoing maintenance as text data is added or updated. They're also slower for simple exact-match queries compared to other index types, making them best suited for text search operations.

### **Clustered and nonclustered indexes**

Indexes can also be classified into clustered and nonclustered (secondary) indexes. A clustered index defines the physical order of data in a table, and a table can have only one clustered index. Nonclustered indexes are stored separately, with pointers to the relevant rows, and a table can have multiple nonclustered indexes. Think of a clustered index as the entire book organized in a specific order (like a phone directory, sorted alphabetically), while nonclustered indexes are like bookmarks that point to relevant pages.

**Did you know?** In MySQL (InnoDB), the primary key serves as the clustered index by default. In PostgreSQL, there are no true clustered indexes; every index, including the primary key, is technically a secondary index.

## **When to use indexes and when to avoid them**

Indexes are most effective on columns that are frequently searched, sorted, or used in `JOIN` operations, such as primary keys, foreign keys, or fields in `WHERE` clauses. One best practice is to create indexes on columns that are used to filter large data sets (such as age and experience level) and improve query performance. Additionally, consider indexing columns involved in sorting (`ORDER BY`) or aggregation (`GROUP BY`) as these operations benefit from faster data access through indexes. Indexes can also be valuable for columns involved in aggregations (SQL functions such as `SUM(...)` and `AVG(...)`), where summarizing data could become a bottleneck without quick access paths.

But indexes add storage and maintenance overhead, so be careful when using them on frequently updated tables. If a table is constantly being inserted into or updated, each change requires the index to be modified, which can slow down write operations. Avoid creating indexes on columns with low selectivity, such as Boolean or binary fields, as they have few distinct values, providing little performance benefit while adding unnecessary overhead. Finally, for very small tables, indexing is often unnecessary as the database can quickly scan the entire table without a noticeable performance impact.

**Real-world examples of database indexing**  
Let's take a look at some real-world examples of database indexing. The following sections use a basic SQL table to demonstrate how indexing can improve query performance. These examples use standard SQL syntax unless mentioned otherwise.

Here's a basic "users" table with columns for `name`,`email`,  `age`, `bio`, and `id` as the primary key:

```shell-session
CREATE TABLE users (
	id SERIAL PRIMARY KEY,
	name VARCHAR(100),
	email VARCHAR(100) UNIQUE,
	age INT,
	bio TEXT
);
```

**B-tree index example**

Suppose you frequently query the `age` column to find users in a specific age range, such as those aged between twenty-five and thirty-five. A typical query for this would be as follows:

```shell-session
SELECT * FROM users WHERE age BETWEEN 25 AND 35;
```

Without an index, the database performs a full table scan, checking each row to see if the `age` falls within the range. This approach can be very slow as the table grows larger.

To optimize such queries, you can create a B-tree index on the `age` column:

```shell-session
CREATE INDEX idx_age ON users(age);
```

**Note**: B-tree is the default index type in both MySQL and PostgreSQL, so when you create a standard index, it's typically a B-tree index.

With this index in place, the database can navigate the sorted `age` column using the B-tree structure. This allows it to skip irrelevant rows and focus only on those matching the query conditions. For range queries like `BETWEEN`, B-tree indexes are particularly effective as they're designed to support ordered data access.

Thus, if you run the same query with the index, the database workload is significantly reduced, resulting in faster query execution. This performance gain becomes increasingly important as the table grows larger.

**Hash index example**

Another common use case is searching for users by their email, for example, during a login process. Since email addresses are unique and looked up exactly, hash indexing can be an effective solution for exact-match queries.

Here is a query that finds a user by email:

```shell-session
SELECT * FROM users WHERE email = 'jane.doe@example.com';
```

  
Without an index, the database has to check each row's `email` field to match the exact value, which can be very slow for large tables.

To ensure good performance on this crucial query, you can create a hash index with the following SQL:

```shell-session
CREATE INDEX idx_email_hash ON users USING hash(email);
```

  
If you rerun the same query now, with the index in place, the database directly jumps to the matching email row (or checks the specific hash), significantly speeding up exact matches.

Again, the database no longer has to scan each row; instead, it uses the hash index to directly locate the matching row, making exact lookups extremely efficient, especially for large data sets.

So any applications with large numbers of users that log in with their email addresses would benefit greatly from a hash index on the `email` field.

**Note**: Hash indexes are natively supported in PostgreSQL, but MySQL doesn't have native hash indexes. Even when you ask an InnoDB table to create a hash index, it turns it into a B-tree. 

**Full-text index example**

Lastly, imagine you have a user database with engaging bios, and you want to find users interested in _movies_.

A common query for this would be as follows:

```shell-session
SELECT * FROM users WHERE bio LIKE '%movies%';
```

  
 Without a full-text index, this query requires scanning each row's `bio` field and checking if it contains the specified text (using the `‘%keyword%’` pattern), which can be extremely slow for large text fields.

If you need to frequently search for specific keywords within large text fields in a database, creating a full-text index can greatly improve performance.

The syntax for creating a full-text index differs between databases. Here's how to create one in PostgreSQL and MySQL:

```shell-session
-- PostgreSQL
CREATE INDEX idx_bio_fulltext ON users USING GIN (to_tsvector('english', bio));

-- MySQL
CREATE FULLTEXT INDEX idx_bio_fulltext ON users(bio);
```

MySQL has built-in support for full-text indexing on `VARCHAR` and `TEXT` columns. In PostgreSQL, you create a full-text index using the Generalized Inverted Index  (`GIN`) on the result of the `to_tsvector` function.

With the full-text index in place, you can now run full-text search queries to find users interested in **movies**:

```shell-session
-- PostgreSQL
SELECT * FROM users WHERE to_tsvector('english', bio) @@ to_tsquery('movies');

-- MySQL
SELECT * FROM users WHERE MATCH(bio) AGAINST ('movies' IN NATURAL LANGUAGE MODE);
```

With a full-text index, the database can search for keywords within large text fields, eliminating the need to scan every row. This makes keyword searches much faster, particularly when dealing with large text-heavy columns.

## **Conclusion**

Database indexing isn't just a performance optimization; it's often the difference between an application that scales and one that crashes under load. The techniques we've covered today can transform your slowest queries into lightning-fast operations, but only if you implement them strategically.

**So, what’s the next step?** Start by identifying your application's most frequent queries and heaviest traffic patterns. Focus on indexing columns that appear in WHERE clauses, JOIN conditions, and ORDER BY statements. Remember, every index is a trade-off between read speed and write performance; choose wisely.

**But here's the reality**: managing database performance optimization across multiple environments, monitoring query patterns, and maintaining indexes as your application evolves can quickly become overwhelming. You need more than just indexing knowledge; you need a platform that makes performance optimization seamless.

This is where Upsun transforms your development workflow. Instead of juggling database configurations across staging and production, Upsun provides instant environment cloning with real data, so you can test your indexing strategies against actual query patterns before they go live. With built-in observability profiling, you'll spot performance bottlenecks instantly and get actionable recommendations for optimization.

Ready to stop guessing about database performance? Start your free Upsun trial and experience what it's like to optimize with confidence, complete with the tools and insights that make database performance management effortless.

### [Stateful AI sandboxes for reliable validation | Upsun](https://upsun.com/blog/the-strategic-case-for-stateful-ai-sandboxes/)

# Beyond code execution: the strategic case for stateful AI sandboxes

_Key takeaway: While ephemeral sandboxes are effective for isolated code execution, enterprise AI agents require a more robust context to be reliable. Upsun provides production-like preview environments, complete with byte-level clones of apps and services, offering a higher standard of validation for agentic workflows._

## **The evolution of the AI sandbox**

In 2026, the discussion around AI infrastructure is rapidly shifting. Many emerging platforms focus on the speed of blank sandbox environments for code execution. These are excellent tools for testing isolated functions or running safe, ephemeral scripts.

However, for a Modernization Architect or CTO, the requirements are different. When an AI agent is tasked with optimizing a database schema or reconfiguring a service binding, it needs more than just a blank box. It needs ground truth.

## **Moving from code execution to stateful validation**

_Key takeaway: AI agents are most effective when grounded in actual environment configuration rather than static examples or empty environments._

While some platforms focus on hardware-level isolation (like microVMs) to run AI code, Upsun prioritizes environment integrity.

-   **The unified configuration file:** By defining your stack in `.upsun/config.yaml`, the agent understands the relationships between your code and your integrated services (like MariaDB or Redis) before it ever proposes a change.
-   **Byte-level clones:** Upsun triggers a clone of your production state in seconds. This allows the agent to interact with a replica of your actual data, ensuring its suggestions are grounded in reality.
-   _**Live platform context via MCP:** Through the Upsun MCP server, AI assistants can read your project's actual state:  environment variables, deployment status, routing config, service relationships, rather than guessing at resource limits or inventing settings._

## **Addressing the toil of manual sandbox management**

_Key takeaway: Custom-built sandboxes or BYOC (Bring Your Own Cloud) strategies can inadvertently introduce a complexity tax that drains engineering resources._

Some platforms advocate for self-serve BYOC as a way to maintain control over AI experiments. While this approach offers flexibility, it often requires senior engineers to spend a significant portion of their time on the operational glue of managing those sandboxes, tasks that Upsun automates natively.

Upsun offers a professional alternative: standardized isolation. 

We provide enterprise-grade compliance (SOC 2, PCI, HIPAA) and environment cloning natively. This allows your team to focus on the logic of the AI agents rather than the maintenance of the infrastructure hosting them.

## **Reducing operational overhead with production previews**

_Key takeaway: High-velocity development requires a validation layer that humans can trust before they approve an agent’s output._

By utilizing Upsun’s production-like environments, you reduce the time human operators spend fixing AI-generated hallucinations.

-   **Verified Outcomes:** Every AI-driven experiment is tested in an isolated, production-like clone.
-   **Governance as Code:** Because Upsun is Git-driven, every action is version-controlled and auditable, aligning with the growing requirements of the EU AI Act and internal security policies.

## **The enterprise standard for agentic infra**

The cloud application platform of the long haul is one that provides options and flexibility without sacrificing stability. As your organization moves beyond simple prompts to autonomous agents, the question is no longer just how fast you can run code. It's how reliably you can validate it.

Upsun provides the predictable world that humans and AI agents need to be successful.

* * *

## **Frequently asked questions (FAQ)**

**Does Upsun provide GPUs for AI sandboxes?** 

No. We focus on providing the infrastructure, runtimes, and middleware for the logic of agentic applications. We’ve found that the vast majority of our customers prioritize data sovereignty and environmental integrity over internal GPU hosting.

**How long does it take to create these environments?** 

Upsun can trigger a full-stack preview environment, including code, services, and data, in moments, significantly reducing the "wait time" in your developer loops.

**Does running these isolated environments increase cloud costs?**

_Yes, every environment on Upsun is a billable resource. To prevent runaway costs, you can define a resource profile in your unified configuration file so previews use a cost-optimized footprint. Upsun also automatically pauses preview environments after 14 days of inactivity._

### [An integrated SaaS development and management platform | Upsun](https://upsun.com/blog/saas-management-platform/)

# Upsun as a SaaS development and management platform

The Software as a Service (SaaS) model treats each customer as a tenant of the application. To use the SaaS application, each tenant is usually required to pay a subscription.

## Exploring three SaaS management platform tenancy models

-   **Multi-tenant architecture**: All customers share the same application instance and database, but their data is logically separated and isolated.  
     

-   **Single-tenant architecture**: Each customer has their own instance of the application and database, running in their own environment.  
     

-   **Mixed-tenant architecture**: This model combines both architectures above.  
     

In this article, we'll focus on specific challenges brought about by the single-tenant model, including developing, deploying, and keeping several instances of the SaaS application up-to-date.

## Just another web app

First things first: a SaaS application is, at its core, just another ordinary web application. As such, the product engineering team that works on it can’t help but benefit from the features offered by Upsun, provided we can support all the components of their tech stack—which we most likely can. Some of our clients are SaaS companies employing the multi-tenant model, benefitting from the excellent features our PaaS provides to their engineering teams.

But how can we push the boundaries by leveraging Upsun for scaling and managing single-tenant SaaS applications?

## Single tenant: a fleet of web applications

Enabling organizations to run thousands of apps and websites easily is already part of our mission. The peculiar thing about a single-tenant SaaS application is that the many instances resulting from the serial deployment of the same app will all share the same codebase.

Yet, by default, each Upsun project is backed and driven by its own Git repository. At first glance, this would seem to suggest that managing a single-tenant SaaS model on Upsun might be a nightmare!

Thankfully, that is not the case.

If your SaaS is single-tenant, then the main pain point is that you need to build automation and pipelines to:

-   Deploy new instances of your SaaS application every time a new subscription is purchased
-   Test new features and pre-releases on production-like environments
-   Roll out new releases/code changes to _all_ the active instances of your SaaS application

We already know that Upsun helps with a lot of that. What I want to show you today is how to leverage two of our features that will make all of that even _easier_.

## Enter source integrations and source operations

Source integrations allow you to keep your code in a third-party repository that’s then linked to your Upsun project. The result is that whatever happens on that repository is automatically reflected on the project’s own Git repository. The hidden power of this feature is that you can also link the same third-party repository to as many Upsun projects as you like.

Since, however, that feature may have limits (for instance, GitHub has a limit of 20 webhooks per repository), our very own source operations feature completes this picture. Both features can be used together and in a complementary fashion.

So, for example, you can now have 10, 100, 1000 projects _all_ driven by the same Git repository. And that opens up countless new possibilities.

## Create a new instance

A new customer comes along and buys a subscription to your SaaS application.

When using source integrations all you have to do is (a) create a new empty project, and (b) create a new integration between the repository that holds your SaaS app’s codebase and your project. This latter action will effectively deploy a new instance of your SaaS application to the newly created project.

Don’t worry, you may automate this by using either our CLI or our API. For example, you could run something as simple as the following from a CI tool:

```Javascript
upsun project:create --region='eu-2.platform.sh --title='A SaaS' --environments=1 --storage=5 --default-branch=main --yes
upsun integration:add --type github --repository your-org/your-repo --token TOKEN -p project_id_from_previous_command
```

Or you could use our API to build the functionality above directly into the software that is processing your purchases.

Similarly, with source operations, one must essentially create an empty project and then initialize the main environment with a template already configured to use source operations to pull the code down from the repository where development occurs.

## Develop and test

One of our flagship features is the ability to instantly clone production into a non-production environment with all of your data included, whenever we branch off the main branch (the one that powers the production environment). That affords the developer the luxury of having a live-like environment where they can deploy and test their feature changes.

When a source integration (for example, GitHub) is active on an Upsun project, the default behavior is that a feature environment is created whenever a new pull request is issued. If more than one project is linked to the same external repository, then that happens for each of those projects, provided the integration is configured to do so on each of them.

Indeed, if you create all your source integrations according to the default settings, the result will be that every time you issue a new pull request on the repository that holds the code for your SaaS application, _all_ the instances on Upsun connected to that repository will create a new environment.

You may or may not want new environments to be created, but you are free to configure each integration as you prefer. That said, you probably want to reserve a specific pool of your instances for testing so that you don’t end up creating too many environments every time you issue a new pull request.

You can also use source integrations to link your development repository to the instances you want to use for automated testing and instead use source operations for all your other instances, where new releases can easily be pulled down when ready and tested.

## Roll out new features to production

Regardless of how many instances you have chosen to test your changes, at some point those changes will be ready. For the sake of simplicity, let’s assume you have chosen to use a micro-release model. For example, every pull request that you have is a new release candidate on its own, and merging it will result in the changes going directly to production, whether they are instances linked with source integrations or source operations.

This might seem scary, but if you keep your changes small and you have lots of automated testing, it’s actually a very productive and lean way of rolling out new changes.

As I was saying: at some point, those changes will be ready to merge. And when you do merge them, the new commits will be pushed to those instances linked via source integrations, and eventually land to the instances pulling down updates via source operations.

The result is the same either way: the new release of your SaaS application is instantly rolled out to all active instances of your application on Upsun. Job well done!

## Leverage the power of ROI

Upsun is uniquely positioned to provide two more benefits you can take advantage of here at Upsun.

1.  You can leverage the power of the massive ROI that it will afford you while building your SaaS offering
2.  You can choose to get into the PaaS market yourself, via the Platform.sh OEM program, as Platform.sh powers Upsun.

And…they are not mutually exclusive. You can do both at the same time! And when you do, that’s when you are in a truly unique position—you can offer a seamless upgrade path from the SaaS version of your product to the PaaS version. In a single-tenant model, that essentially means giving your customer access to the very same Upsun project that has been behind their application’s instance all along!

How neat is that?

## Why not get in touch and make it happen?

If you are in the SaaS market, Upsun is an incredible solution that will address a plethora of management platform needs. And if you are thinking of offering both a SaaS and a PaaS version of your product, then Upsun is the perfect solution.

### [Improved onboarding with Upsunify | Upsun](https://upsun.com/blog/improving-onboarding-with-upsunify/)

# Upsunify: improving onboarding with `upsun project:init`

Embarking on a new project should be an exciting journey, not a labyrinth of configuration struggles. At Upsun, we understand the value of a smooth onboarding process and a great developer experience, and that's why we introduced the `upsun project:init` command, or _Upsunify_. To strengthen our mission to empower developers by eliminating the headaches of project setup and allowing them to focus on what they do best as quickly as possible: crafting great applications.

## Detecting your stack

_Upsunify_ is not just another command; it's your intelligent onboarding companion. Using a combination of sophisticated heuristics and pattern recognition, the command swiftly identifies your project stack—whether it's Django, Express.js, Strapi, Flask, Laravel, or another popular framework. No more tedious manual configuration, _Upsunify_ automagically tailors the setup for your specific tech stack, putting you on the express lane to deployment. All you have to do is commit and push your code to Upsun and we’ll handle the rest.

## Configuring a Django project

Let's dive into the magic with a Python Django example, with a PostgreSQL database and a Redis cache. Run `upsun project:init` in your project directory, and watch the enchantment unfold:    

```shell-session
➜ django4 git:(main) ✗ upsun project:init
  
  Welcome to Upsun!
  Let's get started with a few questions.
  
  We need to know a bit more about your project. This will only take a minute!
  
  ✓ Detected stack: Django
  ✓ Detected runtime: Python
  ✓ Detected dependency managers: Poetry
  …
  
  Select all the services you are using:
  Use arrows to move, space to select, type to filter
    [ ]  MariaDB
    [ ]  MySQL
    [x]  PostgreSQL
    [ ]  Redis
    [x]  Redis Persistent
    [ ]  Memcached
    [ ]  OpenSearch
```

That’s it, all you have to do is select the services you’d like to use—in our case a persistent Redis cache and a PostgreSQL database—and you’re ready to go.

Below you can find a few Django-related snippets in the configuration:

```yaml
# .upsun/config.yaml Django-specific sections

# Gunicorn is automatically configured
        web:
          commands:
            start: "poetry run gunicorn  -b unix:$SOCKET myapp.wsgi --log-file -"
        hooks:
        
# Poetry is installed (as it was detected) and static files are built
          build: |
            set -eux

            # Set PIP_USER to 0 so that Poetry does not complain
            export PIP_USER=0

            # Install poetry as a global tool
            python -m venv /app/.global
            pip install poetry==$POETRY_VERSION
            poetry install

            # Collect static files so that they can be served by Upsun
            poetry run python manage.py collectstatic --noinput

# Migrations are run on deployment
          deploy: |
            set -eux
            poetry run python manage.py migrate

# Static files are served with caching by Upsun
          locations:
            "/":
              passthru: true
              
            "/static":
              allow: true
              expires: "1h"
              root: "static"
```

Within moments, _Upsunify_ analyzes your project structure, identifies the dependencies, and generates the perfect configuration files. It's like having a wizard in your terminal enabling you to wave goodbye to tedious setup and embrace onboarding simplicity.

## Try Upsunify for yourself

Getting started with _Upsunify_ is a breeze, simply follow these steps to install the CLI and kickstart your project.

_Upsunify_ will guide you through the process, ensuring a hassle-free setup tailored to your project's unique requirements. We’re always looking for ways to improve _Upsunify_ and the CLI itself, so if you’d like us to include your favorite stack, have suggestions for improvements or corrections, or just want to see how everything works, you can check out the open-source GitHub repositories for our CLI and the library itself below:

-   https://github.com/platformsh/cli
-   https://github.com/platformsh/platformify

In the dynamic world of development, where time is of the essence, _Upsunify_ emerges as your trusted ally. Say goodbye to configuration headaches and embrace a new era of onboarding simplicity with upsun project:init. Elevating your development experience, one command at a time. Register for Upsun today and get started with your first project.

### [Meet Upsun. A bright brand, a bright future | Upsun](https://upsun.com/blog/upsun-a-bright-brand/)

# Meet Upsun. A bright brand, a bright future.

### **The catalyst for a new brand**

We’ve always loved testing and feedback as the backbone of our brand, conducting regular user research to continually refine and improve. This year, our founders shared the plan to launch an exciting new product offering that supports development teams who primarily build Software-as-a-Service (SaaS) applications with technical microservices architectures. For us, the product offering presented a perfect opportunity to introduce a new, _powered by_ _Platform.sh_ brand. A new brand meant more research. A chance to learn. And to adjust during the beta phase before launching the new brand we call Upsun.

### **What is Upsun?**

By dictionary definition, _upsun_ means the hours between sunrise and sunset—your productivity hours. Five letters, two syllables, easy to speak and spell across the globe. Landing on a single word that also tells a  product story? Well, that’s extremely rare. 

From a brand perspective, Upsun, the product, means a few things:

We’re a global company, with a 24x7, globally distributed support team keeping the lights on while you rest. Because of our unique cloning solution (code + data + everything else), developers know things will work whenever they push to production. 

As Upsun, we speak to a certain level of optimism. We do believe in a tomorrow as reliable as the sunrise–and that tech can be used to improve that tomorrow. Upsun provides a stable platform that enables developers to build applications that matter.

The rise and fall of the sun (or more accurately the spinning of the earth) tells a story about orbits and cycles. Patterns that repeat and travel in time. A central location and a process. Upsun is a fully managed PaaS that gives developers a central place to develop and deploy applications. 

### **An inclusive approach to brand-building**

We tackled the Upsun brand like we tackle everything else: with open doors and open minds. For Upsun design teams, research is always step one. We collected ideas from customers, partners, prospects, and our own teams. As part of that process, we hosted more than a dozen, cross-team  brand workshops, collaborating  across the board (and oceans) to help us build the  strongest possible brand. 

What we learned from the  experience was that letting people join the process helps build trust, gives each person a sense of brand ownership, and is just plain fun. We scrapped some ideas we thought were sure bets. Came away with new ideas that we never would have in a silo (e.g., _Test in prod without testing in prod_. Genius, Simon!). And built confidence in decisions we were able to validate and refine with feedback from internal Upsun engineers and other colleagues.  

When you work for analytical people, it’s always easier to sell a color like pink or oozey green when you have data to back it up. Research and collaboration can’t hurt a brand; they can only give it a stronger voice. 

**The brand-creation process**

As part of our research, we created a vast competitor comparison board in Figma, along with 50 of the top disruptors of the last year. We looked at fonts, imagery, colors, and landing pages. 

After that, we developed robust moodboards and started to hone in on those elements that matched our criteria without making us look like a lifestyle brand or nature conservancy. Pairing an untechnical name with a technical company meant we needed the visual brand to quickly help our audience place us in the appropriate category. 

From a foundational perspective, we took our gobs of research and interviews (as well as our own takeaways after spending time with the product) and came up with lists of words that fit—and didn’t fit—Upsun. From there, we bucketed them and distilled them into three concept words that encapsulate our brand: stability, freedom, and control. Separately, they speak to features and benefits. Together, they tell the Upsun brand story. 

The three concept words (or _pillars_) are used to categorize features and benefits in our messaging framework. Each audience-relevant product proof point was assigned to its related pillar and written in language appropriate for the identified audience. For example, developers might care more about _declarative infrastructure_ while business leaders might care more about _compliance_. But both belong in the framework. 

When you work on a product as complex as Upsun, any early organizational and structural work around brand and messaging is paramount to keep teams aligned and on-point. 

#### **The Upsun brand logo** 

For the Upsun mark, we wanted something simple that we could use for years to come. We began with internal exploration, then collaborated with two freelancers who devote their days to brand-mark creation. 

These amazing, collective efforts presented us with a difficult decision. Ultimately, we chose a simple sun mark from designer Lucas Fields. Our new logo fuses  a sun, moon, reflection, and rainbow.   
 

#### **The Upsun colors** 

To start, we  explored sunset and sunrise colors, which led us to wonder what a sci-fi sunrise would look like. That landed us in a neon world of vibrant colors, with soft pastels to lean on.

We wanted a standout color that did what pink did for Platform.sh. Our ooze or neon lime color does it. Love it or hate it, you have a feeling and will notice this color. Paired with strong, new neutrals, it’s a bold choice that feels modern, tech, and confident. 

As much as we wanted to avoid blue, we needed a neutral color that could cross from product to brand. We chose a vibrant violet that is neither purple nor blue. It’s a calm color in our product console that works as a button and complements our neon ooze.

#### **The Upsun visual style** 

Developers tell us they sniff marketing from a mile away, so it was important to be authentic. Having an audience that loves to scrutinize gives us a chance to hide easter eggs and get cheeky. We wanted to update our illustration style to be more flexible and modern, while elevating console-style illustrations that show off some buttery code with plenty of frameworks to see. 

We chose to launch in dark mode, the preference of many developers. The future goal is browser-based modes (or location, is it night where you are?), with options for developers to choose what works best for them.    

### **What did we learn?**

We believe that brand doesn’t come from a person or a single voice. The brand’s job is to be a translator of a message or vision. We take the technical, mucky, hard-to-understand ideas and mold them into something tangible and meaningful. Brand needs to be a visual and experiential representative of the vision of our founders and engineers building the product. It needs to make a person feel the way our product makes them feel when they understand what it can do. And sometimes, it just needs to feel cool and something other people want to be a part of. 

If you’re a developer or a manager of a development team and want to share branding or product feedback, please let us know by contacting design@platform.sh.

### [Navigating deterministic and probabilistic profiling | Upsun](https://upsun.com/blog/deterministic-vs-probabilistic-profiling/)

# Observability insights: navigating deterministic and probabilistic profiling

Observability is about gaining deeper insights into application behavior from the inside out. By harnessing data from various components, developers can have a front-row seat to watch the intricate workings of their applications—get your popcorn at the ready.

Imagine having X-ray vision for your applications—seeing performance pitfalls, and architectural bottlenecks, and understanding exactly where to focus your efforts. This is what observability brings to the development table. When seamlessly integrated into development and deployment workflows, observability not only saves time and effort—it elevates them to best practice standards.

With Upsun, we're not just advocating for observability; we're making it a seamlessly unified experience. Our robust PaaS offers observability out of the box. 

## What is profiling?

Profiling is a dynamic analysis process that measures the complexity of certain parts of a web application. Many metrics can be collected with a profile. This can range from the time taken for certain functions to execute, memory consumed by the software, or even the frequency of function calls. In this article, we’ll spotlight two key observability approaches: deterministic and probabilistic profiling.

### Deterministic profiling

A deterministic profiler, such as Blackfire for PHP and Python, captures a wealth of metrics for every function and service call during a particular request or script's execution.

Deterministic profiling lets you understand precisely what happened during an isolated event. It does not, however, provide any information about other events that may have occurred at the same time.

### Probabilistic profiling

Probabilistic profiling is taking periodic snapshots. It taps into data points at defined intervals, recording functions or services summoned by any active request or script. This method paints a broader picture of your application's behavior over time, although some specific event details might be glossed over due to sampling rates.

Deterministic and probabilistic profiling serve distinct roles, much like medical imaging tools. Claiming that fMRI is superior to a PET Scan or ultrasound is misguided; each has its unique diagnostic function.

## Pros and cons

-   **Deterministic profiling**: Its strength lies in precision, facilitating meticulous script analysis. But it's resource-intensive, which can lead to considerable overhead and potential data overload, making analysis potentially tedious.
-   **Probabilistic profiling**: Lightweight and scalable, it's tailored for holistic application oversight. However, its periodic snapshots might miss rapid function calls, yielding a not-so-perfect application map.

## Why observability matters

In an era dominated by microservices, cloud architectures, and distributed systems, ensuring that our applications function optimally is vital. Both deterministic and probabilistic profiling offer valuable insights into system performance through:

1.  **Bug identification**: Profiling helps identify areas where the code might be underperforming or causing issues, leading to quicker resolutions.
2.  **Optimization**: Through profiling, developers can pinpoint inefficient areas in their code and optimize them for better performance.
3.  **Resource allocation**: By understanding which parts of the code consume more resources, developers can make informed decisions about resource allocation.

Both deterministic and probabilistic profiling have their place in the development workflow. While the former offers a detailed, granular perspective, the latter provides a broader, more scalable approach. Depending on the project's nature and the challenges at hand, developers might opt for one over the other or even use both in tandem.

Upsun uniquely provides both solutions. A deterministic profiler through an included Blackfire subscription for your PHP and Python applications, and probabilistic profiler for your NodeJS and Go ones. And, detailed infrastructure metrics complete the observability tool set for all applications.

## Get started!

Incorporating observability tools, including either deterministic or probabilistic profiling, into the development lifecycle isn't just a nice-to-have—it's essential for modern software development. It not only ensures better-performing applications but also results in a more streamlined and proactive approach to development.

Stay ahead of the curve by integrating these profiling techniques into your workflow and experience the difference firsthand. Observability is not just about watching; it's about understanding and optimizing. Find out more about Upsun Observability in our dedicated docs.

#### Useful links

-   Continuous profiling comparisons

### [Life on the Edge: Understanding the Upsun Edge Layer | Upsun](https://upsun.com/blog/edge-layer-upsun/)

# Life on the edge: understanding the Upsun edge layer

First things first, what is the edge layer and why do we need it? The edge layer is what allows a request sent from your browser to a site hosted on Upsun to actually reach the right site, and then return the response. It also puts you in the correct server when you type `upsun ssh` in your terminal, making sure requests are sent to exactly where they need to be.

But what exactly does life on the edge with Upsun look like? How do requests work? And what are the key things you should know about how the edge layer works?

## **Foundational concepts of Upsun**

Before we dive in, it’s useful to understand a few key pieces of the puzzle that we call Upsun. Specifically, we should be clear about the hierarchy of components that Upsun manages.

The broadest component here is the region. A region refers to a cloud region from one of our underlying cloud providers, specifically a Virtual Private Cloud (VPC) that represents a single Upsun region. A region manages hosts, which are virtual machines (VMs) provided by the region’s cloud provider. We have different kinds of hosts such as gateways, grid hosts, and coordinators, and a single host can contain many clusters with a cluster able to span multiple hosts. A cluster is a logical grouping of a few related services. 

A service is an abstraction that represents, well, a service we manage. This can be the database (DB), cache, or the customers’ app itself. Internally, a service runs in containers. A container is like a lightweight mini-VM, and we manage a _ton_ of containers—a single host can have a lot of containers! Each service maps either to a single or multiple containers if running on High Availability mode. 

## **The problem statement**

Now we know the bare minimum to formulate our problem statement in less vague terms: **how do we accept a request to a site hosted on Upsun, forward it to the exact container that has the server for this site, and convey the response of the server back to the user?**

The first step is for the request to reach the right Upsun region. This is achieved by the customer adding a DNS record (of type CNAME/ALIAS, if you’re interested) that says, “My custom domain resolves to the public IP address of this Upsun region.” This makes the browser of the user browsing the site send the request to the Upsun region which hosts the site.

From this point onwards, our Edge Layer takes over—cue dramatic music.

## **Peeling back the Edge Layers**

Most of our hosts (i.e. the Virtual Machines that constitute an Upsun Edge Layer region) don’t even have a public IP. This includes the hosts that house the servers for the sites hosted on Upsun. The hosts that do have a public IP are the hosts at the edge. Naturally, any request that is directed toward the public IP of a region will then hit the edge.

Let’s recall that an edge host is just a VM provided by a cloud provider. Let’s also recall that a host can contain clusters. You might also be losing patience here as we peel back layer upon layer to find nothing of value. But stay with us, we promise you the next edge layer will be interesting!

### **Edge-proxy** 

The official description is a bit of a mouthful: Edge is a dynamic, transparent, multi-protocol proxy.

Here’s the breakdown:

Dynamic: Nuntius can fetch changes and update its configuration without any manual intervention.

Transparent: The world doesn’t need to know about what nuntius is or how it works. You just send a request to nuntius and you get the appropriate response as if the app server itself was directly responding to you.

Multi-protocol: Nuntius is capable of dealing with HTTP (v1.1 and 2), HTTPS, and even SSH!

Proxy: This is the important bit: nuntius itself cannot handle any requests sent its way. Instead, it forwards them to the right place, waits for the right place to respond, and forwards this response back to you.

In other words, Edge Proxy is the first component that does something with the request. Meaning it has quite a few important responsibilities:

Act as a proxy for customer projects

Act as a Web Application Firewall

Act as a proxy for the Upsun API

### **Edge Proxy: finding the way**

Our focus for this article will be the first role: a proxy that routes a request to the right application.

Each container on the region has an IP that is unique in the (overlay) network on which all containers are. The aim is for the proxy to forward the request to the correct container that houses the app server of the project. For this to work, the proxy maintains a mapping of URLs to container IPs. This is information that the proxy isn’t privy to, so it must ask something which is: the container orchestration or distributed datastore. The container orchestrator exposes information about routes to projects, ACLs, etc via an RPC. The proxy leverages this to know a) if the user making this request is allowed to do so and b) the container that can service this request.

The container IP that the proxy figured out is on a different VM. And to complicate things even further, we may have any number of container hosts in a region.

In other words, when the proxy forwards a request to the container IP, _something_ needs to figure out which VM the said container is on. That something is the ARP daemon. This is slightly misleading because the ARP protocol is used to convert an IP address into a physical (i.e. MAC) address. In our case, ARP daemon figures out which grid host a container lives on based on the container IP i.e. converts container IP to host IP.

In fact, container IPs don’t even belong to the same network as the hosts. They actually belong in an overlay network. For now, it is important to know that the ARP daemon will take care of making sure a request addressed to a certain container IP gets there.

### **The gates of the environment: the router**

Remember when I told you that the proxy figures out the container IP of the app container so that it can forward requests to it? Well, I lied. The requests are actually routed to a special service called the router. The router service contains a single router container, which is the gatekeeper for the environment—yes, we have one router per environment.

The router container runs a caching reverse proxy. A reverse proxy is something that sits in front of your server and forwards requests to and responses from it while also acting as a cache or a load balancer. 

This is the service that you can configure via the routes.yaml file in your Upsun project. That’s how you have one router per environment—if your routers.yaml differs between two environments, those environments will have differently configured routers.

The router _finally_ sends the request to the application container i.e. the server that actually serves the site. 

At this point, the request has finally reached the server!

All the connections between the various nodes on the path of a request are TCP connections. The good thing about TCP is that the connection used by a request can be kept open. This means that the response from the server can take the same path back to the host at the edge and out to the world. This is how the response from the request reaches the user.

### **Container-to-world networking and other things**

There is an important part of the edge layer that this post doesn’t cover—how can you have the app container interact with the external internet?

This is a lot more challenging than you might expect. We have separate routes for the egress traffic via the edge hosts (sometimes dedicated to egress traffic alone) that allow us to have fine-grained control over the outgoing traffic from our regions. 

We’ll see you over there! 

**Acknowledgments**

Big thanks to our fellow expert contributors to this post: Ricardo Kirkner, Pilar Gomez, Colin Strickland, Krishna Kashyap, and Eder Leão Moosmann.

### [How to start a Ruby on Rails project with devenv.sh | Upsun](https://upsun.com/blog/how-to-start-a-ruby-on-rails-project-with-devenv.sh/)

# How to start a Ruby on Rails project with devenv.sh

In this article, we are going to take a look at the process of pushing a Ruby on Rails project to Upsun using the power of devenv.sh. 

Devenv is a local development tool, similar to Docker Compose but without the container build step, meaning it's faster and reproducible as it uses Nix, a powerful package management and system configuration tool. If you are a beginner at Rails and want to try out Nix tooling as a development environment without diving too deep, it’s faster to do so on your Linux and MacOS compared to docker-compose or devbox since both focus on containers. And as it already has a lot of languages and services support built-in, Nix is a pretty easy tool to test out. 

## **How to use devenv.sh with Ruby on Rails** 

This first step is to follow your favorite install method to install devenv.sh—I recommend using a flake which allows you to just add `experimental-features = nix-command flakes`to `~/.config/nix/nix.conf`. 

Once you’ve successfully installed devenv.sh, it’s time to create a new Rails project by using the following command—we can skip the bundle since we will handle it on devenv later.

```shell-session
> rails new rails-7-mysql --database=mysql --skip-bundle
```

Then, create the base files with this command:

```shell-session
> devenv init
• Creating .envrc
• Creating devenv.nix
• Creating devenv.yaml
• Creating .gitignore
```

As you can see devenv will generate a .envrc for direnv to set up automatic shell activation when you go into your project and the devenv.nix will contain the project definition—more about it later.

For now, you can start adding some packages to the devenv.nix:

```Javascript
# https://devenv.sh/packages/
packages = with pkgs; [
  git
  ruby_3_3
  pkg-config
  libyaml.dev
  openssl.dev
];
```

**Please note**: in this article, we will only cover the standard Rails assets, if you are using a different assets framework please refer to its documentation.

The next step is to set things up for when you enter the devenv shell. When you go into your project directory it will load the environment it needs to replace the PATH with nixpkgs instead of locals and run the commands defined in there. I prefer to run \`bundle\` every time to install the project dependencies and ensure we always have the latest dependencies fetched and don’t run into any trouble when we switch to the devenv environment. 

```Javascript
enterShell = ''
    git --version
    ruby --version
    bundle
'';

# https://devenv.sh/languages/
languages.ruby = {
  enable = true;
  package = pkgs.ruby_3_3;
};
```

  
If gems start to fail—an example of an error on build can be seen below—you might need to install `postgresql` or `libmysqlclient` to resolve it:

```shell-session
W: Gem::Ext::BuildError: ERROR: Failed to build gem native extension.
W:
W: 	current directory: /app/vendor/bundle/ruby/3.2.0/gems/psych-5.1.1/ext/psych
W: /nix/store/7apky1wg5v258lk066d6xw1g3ddmy6dn-ruby-3.2.2/bin/ruby extconf.rb
W: checking for yaml.h... no
W: yaml.h not found
W: *** extconf.rb failed ***
W: Could not create Makefile due to some reason, probably lack of necessary
W: libraries and/or headers.
```

  
From the terminal, you can find the right package by starting nix interactive shell `nix repl --file ‘<nixpkgs>’` and exploring packages outputs with `libmysqlclient.outputs`. Usually `dev` output will contain headers needed on compiled gems, for example `libyaml.dev` for `psych` Ruby YAML parser gem. 

From the browser, go to https://search.nixos.org/packages which also shows the outputs—most of the time it's `dev` and can be added to the `packages` list into `devenv.nix`.

Once you get your bundle complete, firstly congrats, it can be tricky sometimes with dependencies, and you can now move on to services.

For a MySQL database, don't forget to add `libmysqlclient.dev` to the packages list, or else the mysql2 gem won't compile:

```Javascript
services.mysql = {
  enable = true;
  package = pkgs.mysql;
  initialDatabases = [{ name = "rails_7_mysql_development"; }];
  ensureUsers = [
    {
          name = "root";
          password = "";
          ensurePermissions = {
            "rails_7_mysql_development.*" = "ALL PRIVILEGES";
          };
    }
  ];
};
```

To have the rails server start when using `devenv up` we just need to add the command as follows to the processes:

```Javascript
processes.rails.exec = "rails server";
```

At this point, you should be able to develop locally, update your Gemfile.lock, and run database migrations and tests. Enjoy the fast setup and development!

## **How to push to Upsun**

To generate the basic Upsun config you can run `upsun project:init`, this will ask you some questions and generate `.upsun/config.yaml`. We are in the process of integrating the Rails stack to the `project:init` command so you will need to add some things to the config as you can see below.  Don't forget to add to Git the `.environment` file and remove it to the default Rails `.gitignore`.

```shell-session
Welcome to Upsun!
Let's get started with a few questions.

We need to know a bit more about your project. This will only take a minute!

What language is your project using? We support the following:
Use arrows to move up and down, type to filter
  C#/.Net Core
  Elixir
  Go
  Java
  Lisp
  JavaScript/Node.js
  PHP
  Python
> Ruby
  Rust
—
Select all the services you are using:
Use arrows to move, space to select, type to filter
> [x]  MariaDB
  [ ]  MySQL
  [ ]  PostgreSQL
  [ ]  Redis
  [ ]  Redis Persistent
  [ ]  Memcached
  [ ]  OpenSearch
```

  
On hooks, you will need to do the following:

```yaml
hooks:
  build: |
    set -eux
    bundle install
    bundle exec rails assets:precompile
  deploy: |
    set -eux
    bundle exec rake db:migrate
```

On the variables side, you will need to do the following:

```yaml
variables:
  env:
    PIDFILE: "tmp/server.pid"
    RAILS_ENV: "production"
```

Last thing is the mounts for logs, tmp, and storage:

```yaml
mounts:
  "log":
    source: "tmp"
    source_path: "tmp"
  "storage":
    source: "storage"
    source_path: "storage"
  "tmp":
    source: "tmp"
    source_path: "tmp"
```

Once that is complete, you can create a project with `upsun project:create` and `upsun push`. You should then see the default Rails index when everything goes well. Hooray!

**You can always find more info on** **our docs**.

Thank you to Eder Leão Moosmann and Paul Gilzow for contributing to this post.

### [Adventures in converting a big app to TypeScript | Upsun](https://upsun.com/blog/converting-to-typescript/)

# Adventures in converting a big app to TypeScript

At Upsun, we’ve been working on converting our customer dashboard (Console) from JavaScript to TypeScript. In theory, this is as simple as adding some packages, making a small change to our build script, and changing thousands of file extensions. But as the saying goes: in theory, there is no difference between theory and practice. In practice, there is.

We’re now over a year and a half into this process of converting to TypeScript, and we’ve learned a lot along the way, developing many of our own strategies. We knew this would be a monumental undertaking from the outset and many of the challenges we’ve faced were expected, but there have been a few unexpectedly complex hurdles along the way as well. And while the work isn’t done yet, we’re already reaping the benefits of catching bugs earlier in the development process and having increased confidence in our code.

Any reasonably complex application—multiple developers, serving customers, taking payments, etc—will benefit from the same conversion. So, if you’re considering a similar migration, our experience may help you navigate the road ahead a little easier.

## Getting up and running

For an existing JavaScript (JS) project, the first step is to simply get TypeScript (TS) working with your code base. TS can’t be run directly in browsers, so conversion to JavaScript is required. The specifics of this will depend on your setup, but if you already have a build step in your deployment pipeline, it shouldn’t be difficult to add. Projects hosted with Upsun have access to hooks which can automate this process, making the conversion process even easier.

Broadly speaking, this manual process will involve adding the TS package (and other supporting packages for linting, testing, etc) to your project and configuring your bundler to handle TS files. For the Upsun Console, this requires adding and modifying a couple of rules in our Webpack config; for other bundlers, the process may be even simpler. You’ll also need to add a config file for TS to tell it about your project and preferences.

The main decision to make when configuring TS is how strict you want it to be—several settings impact this. With them turned off, your TS code will function essentially like JS; that is, basic type information will be inferred, but you won’t be enjoying the full power of the language.

Starting with this looser approach would lower the initial friction of converting files to TS, but it does come with some significant downsides. By using a strict approach from the outset, the compiler—and your integrated development environment—will not only keep track of types but also point out when and where it needs type information to be specified. This can take a bit more effort up-front, but if you wait until all code has been migrated before you enable those switches, you’ll be greeted with a massive error report which can be overwhelming.

## Time to start converting

Once TS has been set up and an initial approach has been chosen, the next daunting decision is where to start converting. We’ve had success with a couple of different philosophies. The first is to identify and migrate _leaf_ files. These are files that aren’t dependent on any of your other code. They only import external libraries, if that. The TS compiler can infer some types from JS files, but anything beyond the absolute basics won’t be typed, more specifically, it will have the dreaded `any` type—more on that below. If a TS file isn’t dependent on JS code—which will be the case for these files—you won’t have to go down the rabbit hole of figuring out complex types without the benefit of the compiler and manually adding types that will later be automatically inferred. Simple user interface (UI) components and utility functions often fall into this category.

The other conversion approach we’ve used is to convert files upon which many other files rely. We know that their type information will be widely consumed, so the sooner we ensure they’re accurate, the easier all those conversions will be. Examples include data stores (e.g. Redux) and API communication. These central files may import other local files, so you’ll need to judge whether to convert those files early in the process as well or defer them until later on. Our guiding principle has been to find logical stopping points so that each unit of work remains relatively self-contained.

The other side of the fence here is external packages. Even _leaf_ files may import these. Increasingly, community packages include type information directly, but many still don’t. In these cases, there are a couple of options. Many popular packages have external types available via Definitely-Typed. These types aren’t always perfectly in sync with the actual code, but they’re usually entirely adequate and a wonderful part of the open-source community.

Occasionally, you may find that you’re using a less-common library that doesn’t have any type information available. In these cases, you can easily provide your own types. For the Upsun Console, we store these in `./types` and tell the compiler about them with this config:

```Javascript
{
  "compilerOptions": {
    "paths": {
      "*": ["types/*"]
    }
  }
}
```

Existing types can also be overridden with the same mechanism, and you can contribute your types back to the community via Definitely-Typed.

## When to add types

It would be reductive to say that the best way to add type information is to add none at all, but the fact is that the TS compiler is very powerful and usually right about inferring types. As much as possible, we let it do its job and only manually specify types when necessary. These situations fall into a couple of categories:

The first is where type information doesn’t exist, for example, function arguments, the `Array.reduce` initial arg, API responses, and `JSON.parse`. In each of these cases, we must tell the compiler what it’s dealing with. In these cases, we’re fully responsible for accuracy here. The compiler will alert us if it doesn’t think the provided type makes sense, but otherwise, it trusts that we know what we’re doing.

The other category is to specify a type as a contract. If a type is changed—for example, by changing what a function returns—you may not realize it until an error is discovered downstream, which may be several imports away, if it even throws an error at all. To avoid these situations, we sometimes manually specify what type a function is expected to return—even if it could be easily inferred—so that if the return type changes, an error is guaranteed to be thrown, and it will be right where the change has been made.

## The danger zone: things to be aware of when converting to TypeScript

TypeScript does bring measurable benefits to complex JS applications. However, it does have a couple of features that are easy to misuse. It should be noted that these aren’t purely evil, and we do use them occasionally, but they should be well-understood and only used when truly necessary.

The first is the `any` type. `any` used to be an unavoidable part of the type system, intended to represent any possible type. In practice, it effectively disables type checking and all the benefits that come with it. We can now mostly replace this with the `unknown` type. `unknown` continues to check types, but makes no assumptions about the underlying type. To perform any operation on an `unknown` type, we must first prove that it’s valid. There are still rare times that we reach for `any`, but it always raises the question of whether there’s a better option.

The next feature that can get you into trouble is the `as` operator. `as` is a critical part of the language, but it puts the onus of accuracy on the developer. It’s used to cast one type to another. Again, the compiler will complain if it doesn’t think the conversion makes sense—that the types don’t sufficiently overlap—but there’s an escape hatch by casting as `unknown` first. As with `any`, there are times when this is called for, but we only reach for it when there’s no other option.

The final one isn’t a feature, but it is something to be wary of: complexity. The type system is incredibly powerful, but it’s possible to implement things that are hard to comprehend—both for others and for your future self. Conditional types, mapped types, and recursive types can fall into this category. As with the above caveats, this is often unavoidable in the process of conversion to TS, so we try to isolate and carefully manage this complexity. When possible, we implement a complex type as a black-box utility. We try to define the problem space and constraints at the outset so that the code does one thing well, and doesn’t have to be updated frequently, if ever. Thorough and thoughtful commenting also goes a long way to being prepared for any future changes that may come up.

## The impact of migration on your Git workflow

As we conclude this post, we’ll broaden our view and look at the impact that a migration like this has on other aspects of development, beginning with Git workflow.

The initial step of converting a file from JS to TS is to change the file extension. Git is usually able to recognize that it’s still the same file, and all of the file’s history will remain with it. However, if too many changes are made to the renamed file before it’s committed, Git will no longer see it as the same file. Instead of a rename operation, it will be seen as deleting the old file and adding an entirely new one. The worst part of this is that the file’s history will be lost in the process. To get around this, we use two steps: the first only changes the extension on the relevant files. We then commit those renamed files.

If you run linting or type checking locally on pre-commit, you may need to bypass that here, as the renamed files may not pass those checks. This can be done with Git commit’s `—no-verify` flag, which will skip running the pre-commit hook. Once the renamed files have been committed, we then add types where necessary and fix any errors that have surfaced.

Often, adding type information to one file will necessitate changes to others—both those that it imports and those that import it. This can be due to pre-existing bugs that weren’t visible previously. Needing to handle `undefined` explicitly is something we run into frequently. If you use the `prop-types` library for JS React components, it will be superseded by TS types, which are usually much more granular, and that switch will also sometimes necessitate further changes.

It can be a challenge to identify all these changes before beginning an individual migration, so the scope of one change may grow as you proceed. Again, a judicious approach is needed to find the right limits for a given migration, and we often find we need to split one up into two or more.

You may also discover underlying issues with your code in the process that aren’t even related to type information. In our experience, rather than performing that work as part of a migration, it can be better to fix it upfront and commit it separately so the scope of the migration work remains relatively small. In the end, this means we often have up to four stages for each migration:

1.  Fix any underlying issues that are discovered with the code in question.
2.  Change the file extensions for all affected files and change nothing else.
3.  Add necessary type information to these files and fix type (and other) issues that may be uncovered.
4.  Ensure no functionality has been changed in the process. This may involve manual testing, as well as linting, type checking, testing, and any other QA processes you have in place, and fix any remaining issues that are found.

Regarding that last point, you may need to make adjustments to your other dev tools to support TS. If you’re running eslint, you’ll probably want to add `@typescript-eslint/parser` and `@typescript-eslint/eslint-plugin` and configure additional lint rules that run on your TS files. Some of them even take advantage of type checking and provide a great complement to the error checking provided by the TS compiler.

You may also need to make some changes to your test runner so it supports TS files. Jest requires TS to be transpiled to JS before running, but Vitest supports TS out of the box. The more challenging issue when it comes to writing tests in TS is that the typing doesn’t need to be nearly as stringent as your production code, and it’s not practical to hold it to the same standards. For example, needing to mock an entire complex type because a function is expecting it, even though a test is only concerned with a portion of it.

In these cases, we’re much more likely to rely on quick and dirty tricks like typecasting with `as`. It’s also possible to create config overrides for the TS, eslint, and many other tools that are specific to tests. You still need to be mindful that you’re not using a hack to paper over a legitimate problem, but it’s a worthwhile trade-off to avoid having to strictly type your tests.

## The big picture: our verdict on TypeScript conversion

For such a large undertaking as converting your entire code base, it would be ideal to be able to halt all other work until the migration is complete. Unfortunately, this will rarely be practical. That said, if possible, it’s beneficial to be able to prioritize one major refactor at a time. New features, bug fixes, and other day-to-day tasks will still need to be accommodated, but performing other huge-scale projects simultaneously will result in overall complexity growing exponentially.

We’ve also learned to minimize functional changes when adding types. While performing an in-depth survey of your entire code base, you’ll undoubtedly come across technical debt and other issues that would be nice to fix. These are best documented and left until a later date, because otherwise, the scope and complexity will spiral out of control, and the amount of time required for the complete conversion will too. In general, we try to isolate manageable chunks of changes that are quick to turn around into TS. They’re easier to understand and review and will result in fewer merge conflicts.

When we started this process at the beginning of 2022, we had just over 100,000 lines of JS code for Console. A year and a half later, we’re at approximately 70,000 lines each of JS and TS. We’ve also added plenty of great features along the way, and there’s more to come! At this point, all our new development starts as TS.

There have been challenges along the way. We’ve had to get all our existing tooling to interact with a new language, train the team to use it, and accept that things that were easy—or easily ignored—in JS may now require a stricter approach. But the benefits have far outweighed the downsides. We have more confidence in the code we’re running in TS. We’ve found and fixed numerous shortcomings in our older code. We can catch issues much earlier in the development process—usually before they make it to production.

A migration of this scale isn’t something to take on lightly, but it’s an attainable goal. While we still have a way to go before this project is complete, TS is now integrated smoothly into our workflow, and whether we’re adding new features or converting old ones, it’s been a great addition to the Upsun Console.

### [Ship a POC in an afternoon with Claude Code | Upsun](https://upsun.com/blog/ai-augmented-development-poc-guide-claude-code/)

# How to ship a POC in an afternoon: a Claude Code and Upsun walkthrough for product and product marketing

I have an Upsun project that's nothing but proofs of concept.

It's a dashboard, basically. Each POC gets its own tile. Click in, and you land on a page with three tabs. The first tab is a written explanation of what the POC argues. The second tab is the POC itself, with a built-in demo that automates a walkthrough of the feature so the recipient can watch it run without me on the call. The third tab is a list of the product primitives that already exist to support this POC, plus the ones we'd actually have to build to make the thing ship for real.

I didn't build the dashboard. I asked Claude to build the dashboard. Then I started living inside it.

When someone on product or engineering wants to see what I've been thinking about, I send the dashboard URL. They pick a tile. The conversation that follows is twice as good as the one I used to have with a slide deck.

This post is the walkthrough I wish someone had handed me before any of that existed. I'm going to assume you're a product manager or a product marketer who has never deployed an app, who has a real product idea you want to make tangible, and who has been told you should learn to vibe code. By the end of this post, you'll have the path, the tools, and the specific skills and MCPs that pull the most weight.

(Side note on terminology. We're calling it AI-augmented development from here on. Same thing, sounds fancier, harder to dismiss in a board meeting.)

A note on stakes before we start. The artifact you build here is a conversation tool, not production code. The line matters. We'll come back to it.

One more assumption I'm making: you don't have a hard token cap on your AI usage at work. If you do, this changes the math a little. Build the foundation in stages instead of one afternoon. Set up your product template, your principles file, and your dashboard across a few sessions. Once that foundation exists, every new POC after it costs a fraction of the tokens, because the AI is mostly cloning and tweaking instead of generating from scratch.

## **What you actually need**

Three things.

1.  **An AI coding tool.** The most accessible option, by a long way, is the Claude Desktop app. Sign in, click over to the Claude Code tab. That's it. The same workflow works in OpenAI's Codex or Google's Antigravity if your team prefers one of those.
2.  **An Upsun account.** This is where your POC lives so other people can click it. Sign up at upsun.com.
3.  **A clear idea of what the POC needs to argue.** This is the part most people skip. We'll talk about it.

You do not need to know JavaScript, Python, Docker, or any of the rest. You need to know what your idea is supposed to do. The AI handles the technical load. You handle the product judgment.

**Heads up if your company won't let you use a desktop AI app.** If you're required to use your own API key, opencode is the open-source CLI I've used. Slightly more setup. Same end result.

## **Step 1: Open the tool and pick a folder**

If you've never used an AI coding tool, start with Claude Desktop. Download it, sign in, and click over to the Claude Code tab.

Here's the thing nobody tells you up front: you have to pick a folder. Claude Code (and every other agentic coding tool) works inside a single project directory on your computer.

You do not need a separate folder for every POC, and I'd actively recommend against it. The pattern I use is one folder for everything. Your product template lives in it. Every POC lives in it. Your dashboard lives in it. When you want to start your fifth POC, you open Claude Code in the same folder and say "let's start another POC." The AI already has all the context: your template, your principles, your past POCs, your dashboard.

Create a new empty folder somewhere sensible (Desktop, Documents, wherever your work files live). Name it pocs and let it grow. Point Claude Code at it when it asks. From now on, every file the AI writes lives inside it.

Codex, Antigravity, and opencode work the same way. Pick a folder first, then start the conversation.

Don't agonize over which tool to pick. The work matters more than the tool.

## **Step 2: Set up your skills and MCPs first**

Counterintuitively, the right move before your first prompt is to install your skills and MCPs. They change how the AI behaves from the very first message, and one of them (grill-me) is specifically designed to make your first prompt land cleaner.

Skills are reusable instructions the AI follows automatically. MCP servers are connectors to other tools (Notion, Linear, Figma, Slack, GitHub, and so on). Plugins are bundles of both.

The list of what to install is overwhelming if you go shopping. Don't go shopping.

The prompt I actually use is something like:

> "I'm using Claude Desktop on Mac. Install the grill-me skill from Matt Pocock's repo, the Upsun skill, and Context7 for me. Walk me through any setup I need to do, or just do it directly if you can."

That's it. The AI knows how its own ecosystem works. Let it do the install. You're not optimizing for an elegant skill list. You're optimizing for the next prototype.

**The three I install on every POC project:**

-   **Matt Pocock's skills repo**, especially the grill-me skill. It forces the AI to interrogate you about your idea before it generates anything. Catches half my bad assumptions before they become bad code.
-   **The** **Upsun skill****.** Teaches Claude how to write Upsun config files correctly the first time. Saves you a deploy round-trip.
-   **Context7.** Feeds the AI fresh documentation for whatever library you're using. Without it, the AI occasionally makes up function names. With it, the code actually compiles.

Beyond those, install the MCPs for the tools where your context actually lives. Notion or Confluence for spec docs. Linear or Jira for tickets. Figma for designs. Slack for customer conversations.

## **Step 3: Frame the prompt like a product brief**

This is the part most non-engineers get wrong on their first try. They type "build me an app that does X." The result is a generic shell that doesn't quite do X.

Frame it the way you'd brief a senior engineer who you trust to make decisions, and lean on the skills you just installed.

A bad first prompt:

> "Build a tool where users can upload a CSV and see a chart."

A better first prompt:

> "I'm a product marketer at a developer tools company. I want to build a clickable POC that demonstrates a single positioning idea: 'your team's onboarding doc is the product.' Use grill-me first to push back on my framing and surface anything I haven't thought through. Once we've sharpened the brief, here's the shape I have in mind: two-page web app. Page one accepts a markdown file. Page two renders a clickable, navigable version with a sidebar of headings and a 'rate this section' widget at the bottom of each section. Use React. Use the Upsun skill so the project is deploy-ready for Upsun from the start. No auth, no database, in-memory state is fine. This is a throwaway prototype. Optimize for me being able to demo it Thursday."

The difference: you've told the AI what the POC is _for_, what shape it should take, which skills to invoke, what you're optimizing for, and what tradeoffs are okay. Same brief you'd give a senior engineer. Same brief works here.

**Tip: feed it your real product.** At minimum, drag in three or four screenshots of your production app so the POC inherits your real look and feel. Better, give the AI your product's URL and tell it to read your site, figure out the stack you're using, and recreate it as closely as it can. The closer your POC looks to the real thing, the easier it is for engineers and customers to react to the idea instead of getting distracted by unfamiliar UI.

**Tip: start in plan mode.** Most agentic tools have one. It makes the AI propose a plan before it touches a single file. Read the plan, push back on anything that's off, switch to auto mode once you've agreed on what's getting built. This is a POC. Fast and dirty. But "dirty" still benefits from a five-minute plan.

## **Step 4: Iterate out loud**

Once the AI starts building, your job is to talk to it like a colleague who has all the technical skill and none of your product context.

What works:

-   "The button on page two is too small. Make it feel like a primary CTA, not a footer link."
-   "When I upload a file with no headings, the sidebar is empty and the page looks broken. Show a helpful empty state."
-   "This is too polished. Make it look more like a prototype, on purpose. Less production, more sketch."

What doesn't:

-   Vague directives. "Make it better." The AI will make something different. It won't be better.
-   Stacked changes in a single message. Hand it one thing at a time. You'll move faster, not slower.
-   Treating it like a finished spec. The POC will reveal that you didn't actually know what you wanted. Good. That's the point.

Most of my POCs go through 15-25 rounds of this conversation in the first hour. That's normal. The conversation is the work.

**Tip: tell the AI to write down its principles.** Something like, "Create a PRINCIPLES.md in this project. Record the design choices we just agreed on, and update it any time we change one." My standing principles look like: API first. Mobile first. Always offer a light and dark mode. Give me two versions to choose from, not one. Always clone the template, never edit it directly. Once those are written down, you stop re-explaining your taste on every new chat. The next session reads the file and picks up where you left off.

## **Step 5: Deploy to Upsun**

Now you have a working app on your laptop. Your engineer can't see it from there. This is where Upsun comes in.

Upsun is a cloud application platform. Translation: you point it at your project, it figures out how to host it, gives you a URL, and stays out of your way. For a POC, you want exactly this. You do not want to think about servers.

The fast path is to let the AI do all the setup work through the Upsun MCP server. You log in once. The AI does the rest.

1.  Sign up or log in at upsun.com.
2.  Click your name in the upper right corner of the Upsun console to open the profile menu, then click "API Tokens." Generate a token and copy it.
3.  Drop this in your AI:

> “I want to deploy this project to Upsun. I have an Upsun API token I'll paste in next. Treat the token as a secret: don't repeat it back to me, don't write it to any visible file, don't log it. Install the Upsun MCP server with read/write enabled (the default is read-only, we need write so you can create the project), then create a new Upsun project, push this codebase, and give me the URL when it's done.”

**A word on the token.** That API token is the keys to your Upsun account. Don't paste it in Slack. Don't commit it to a repo. Don't share it with a coworker who already has their own login. The "treat this as a secret" line in the prompt above is there on purpose, including it tells the AI to keep the token out of logs and files where someone else could read it later.

The AI installs the MCP, talks to Upsun directly, creates the project, pushes the code, and hands you a URL. Usually a few minutes end-to-end.

**Tip: CLI as backup.** If the MCP gets stuck for any reason, fall back to the Upsun CLI: "Switch to the Upsun CLI. Install it, run `upsun login`, create a project, and push." Same result, slightly more manual.

The official MCP walkthrough lives at developer.upsun.com.

If something errors anywhere along the way, paste the error back into the AI. Nine times out of ten, it knows the fix.

## **Step 6: Make it accessible (the dashboard pattern)**

This is the move I wish someone had handed me six months ago.

Don't deploy each POC as a standalone app you have to dig through Slack threads to find. Build one Upsun project that hosts all of your POCs, and put a dashboard at the front. Because your folder from Step 1 already contains the template, every POC, and the dashboard side-by-side, the whole thing deploys together as a single Upsun project. The dashboard is just the front door.

Each POC gets a tile. Each tile links to a page with three tabs:

1.  **The argument.** A written explanation of what the POC is and what idea it's making the case for.
2.  **The demo.** The POC itself, with a built-in walkthrough button that automates a tour through the feature. Drop the link in Slack, let the recipient watch it work on their own time.
3.  **The primitives.** A list of what already exists in our real product to support this POC, plus what would have to be built to ship the feature for real.

That third tab is the one that earns the engineering team's trust. It says, plainly, “I'm not pretending this is easy. Here's what we'd actually have to build.”

**Tip: build a template of your real product, once.** Spend an afternoon creating a stripped-down scaffold that looks and feels like your actual product. Major UI components in place, no real backend, mock data. From then on, every new POC starts with git clone from that template. You're already 30% done. Your demos look like the product. Your engineers stop wincing at unfamiliar UI patterns in your prototypes.

**Tip: build your own POC skill after a couple of runs.** Once you've shipped one or two POCs and figured out what your personal process looks like, ask the AI to package that workflow into a custom skill. Tell it your conventions (folder structure, README format, primitives-tab pattern, Upsun config style) and have it create the skill for you. After that, every POC starts with the right scaffolding automatically.

**Tip: the second POC is much faster than the first.** Once your folder has a template, a principles file, a dashboard, and at least one POC in it, your prompt for the next POC collapses to one sentence: "Let's start another POC. Here's the idea: \[your idea\]. Clone the template, add a tile to the dashboard, follow the principles." The AI does the rest. Most of my POCs after the first one go up in under an hour because all the scaffolding is already there.

## **Step 7: Share it like a prototype**

This is the cultural part. How you share the POC determines whether it stays a POC or accidentally becomes the starting point for production.

I'm not big on "POC alert!" formality. Nobody actually talks like that. What I send in Slack is closer to:

> "ok so hear me out....what if \[the idea this POC argues for\]? Working sketch here: \[link\]. Click around for a few. Tell me what reads, what doesn't, and what you'd cut. This is a POC, not a starting point. Tossing the code either way."

The casual "hear me out" framing matters. It invites a conversation instead of demanding a review. The "POC, not a starting point" line draws the production-vs-prototype line on purpose, so nobody mistakes the working app for a head start on the production system.

Don't skip the framing.

## **The recommended starter kit (in one place)**

A copy-paste version of what to install.

**AI tool:**

-   Claude Desktop app (most accessible), Claude Code tab
-   Alternatives: Codex, Antigravity, or opencode if your company requires API keys

**Skills:**

-   Matt Pocock's skills repo, especially grill-me
-   The Upsun skill
-   Context7
-   Your own custom POC skill (after a couple of POCs)

**MCPs (install where your team actually lives):**

-   Notion or Confluence
-   Linear, Jira, or Asana
-   Figma
-   Slack
-   GitHub (optional)

**Project hygiene:**

-   A PRINCIPLES.md file the AI maintains
-   A working template of your real product to clone from for new POCs
-   One Upsun project that hosts all your POCs, with a dashboard

You can be operational in an hour. Faster if you let the AI do the installing.

## **The tradeoff I owe you**

POCs built this way have a real failure mode. They look done. A working app with real buttons creates the illusion of completeness. When the demo lands, the natural next question is "okay, let's ship it" and that's where teams get into trouble. The code the AI wrote in an afternoon is not the code anyone should run in front of customers. Gartner warned that "prompt-to-app approaches adopted by citizen developers will increase software defects by 2500%" by 2028. They're right about what happens when nobody draws the line.

Draw the line. Then cross it on purpose, with the engineer driving. The POC was the conversation. The product is the next thing you build, with the right people, the right rigor, and the right architecture.

## **Back to the dashboard**

The dashboard wasn't the plan.

My first POC went up as its own standalone project. So did the second. By the third or fourth, I had a mess: links scattered across Slack threads, half of them stale, nobody able to find yesterday's demo when they wanted to show a coworker.

So I asked Claude to build the dashboard. Same workflow as every other POC. Two hours later I had a tiled page that pulled all of them into one place, with the three-tab format I described above. Now I send one URL and let the recipient browse.

This is the thing nobody tells you. The most valuable artifact in this workflow isn't any individual POC. It's the system you build around them, which makes the POCs accessible to everyone else.

Build the ugly thing. Deploy it to Upsun. Make it accessible. Then make the next one easier than the last one.

The prototype isn't the product. It's the fastest argument you can make for what the product could be. The dashboard, eight months in, is the argument that all of this works.

Now go ship one.

### [The ultimate PaaS haven for developer zen | Upsun](https://upsun.com/blog/ultimate-paas-solution/)

# Upsun: the ultimate PaaS haven for developer zen

In the ever-evolving world of web applications, developers find themselves playing multifaceted roles—juggling between writing pristine code, permitting collaborative development workflows, and ensuring a seamless deployment process.

With a rise in the number and the complexity of tools and platforms, the line separating development and infrastructure management is becoming increasingly blurred. But what if there was a PaaS solution to streamline this experience?

Enter: Upsun, the unified Platform-as-a-Service (PaaS) solution designed to offer simplicity into the lives of developers by taking care of infrastructure management. With Upsun, developers can focus on what they do best: writing code and developing new features.

## The juggling developer’s dilemma

Developers today don't just code. Their day-to-day tasks stretch far beyond simply creating new features—they are often balancing multiple tasks including:

-   Installing, configuring, and maintaining deployment tools
-   Provisioning development, staging, and production servers
-   Regularly updating servers and services
-   Applying security patches
-   Upgrading different software versions

These multitudinous tasks can be daunting and mentally exhausting, creating an overhead that detracts from our primary passion as developers: crafting elegant code that adds value to our end-users.

## Upsun: a game-changing paradigm

This is where a PaaS solution like Upsun steps in to champion a shift in the developer ecosystem. By adopting Upsun, developers can redirect their energies towards what they excel at.

Here's how Upsun changes the game:

1.  **Unified interface**: With Upsun, there's no more hopping between multiple tools or platforms. Everything you need for deployment and management is unified under one intuitive interface.
2.  **Peace of mind:** Say goodbye to the incessant worries about server provisioning or security patching. Upsun is designed to handle these aspects, letting developers enjoy a trouble-free coding and deploying experience.
3.  **Simplicity in configuration**: No more complicated setup processes. With Upsun, all configurations can be done through concise and efficient YAML files, making the setup a breeze.
4.  **Git as the source of truth**: integrations with your repositories create an environment for every branch, clone the data for the parent environment, and provide a public URL simplifying collaboration.
5.  **Future-proofing**: Upsun is built keeping in mind the future of software development. As tools and technologies evolve, the all-in-one platform is primed to adapt, ensuring developers using this PaaS solution are always a step ahead.

## Embrace the future with Upsun

As an all-in-one PaaS solution, Upsun brings to the forefront a hassle-free development environment. By effectively eradicating the overheads of deployment and server management, it gifts developers the invaluable asset of time and focus. The core benefits lie in simplifying tasks, reducing mental strain, and granting a streamlined coding and deploying experience.

Grant your journey as a developer new ground by giving Upsun a try. Beyond a unique PaaS, you'll find a vibrant and supportive community eager to share, collaborate, and innovate. Dive in, and be part of the revolution that is setting new standards in developer experience.

### Useful links

-   PaaS Pricing calculator - Estimate your costs

### [A highly flexible, robust alternative to Heroku | Upsun](https://upsun.com/blog/a-heroku-alternative/)

# Upsun: a Heroku alternative

**Upsun and Heroku are two enterprise-grade cloud platforms with proven track records. Let’s look at some of the similarities and differences that set the two apart.**

The Platform-as-a-Service (PaaS) solutions’ market has seen meteoric growth in recent years—primarily attributed to the ever-increasing use of containers that’s revolutionized software development.

While the total number of available platforms continuously grows, there are only a handful of mature, enterprise-ready solutions; the others are in early bootstrap or young startup mode—not a good fit for mission-critical operations.

Upsun and Heroku are two of those proven, enterprise-ready solutions.

### **Upsun in short**

With developer experience as its top priority, Upsun fuses the reliability and stability of an enterprise with the brightness, innovation, and agility of a new brand. Built on top of award-winning Platform.sh, Upsun benefits from years of experience and brand recognition that saves it from many of the growing pains new startups often encounter.

### **Heroku in short**

Heroku was one of the first cloud platforms and is still considered one of the bigger players. 

But it hasn’t changed dramatically over the years. This stability can appeal to enterprise clients who wish to stay away from too many moving parts. At the same time, it seems that Heroku's trajectory isn't bending toward innovation or keeping up with the ever-rising need for quality and speed. The commoditization of cloud platforms created many Heroku rivals, and the company will need to work harder to remain an industry leader.

Let’s dive into some of the differences between the two solutions:

-   Technical features
-   Developer experience and productivity
-   Pricing/transparency

## Technical features

### Multicloud

Heroku’s physical infrastructure is hosted solely on a limited number of Amazon Web Service (AWS) regions. This constraint may be a problem if your organization requires a different IaaS or cannot work with AWS for various reasons (e.g., regulations, cloud sovereignty).

Upsun lets users choose between a wide range of IaaS providers and multiple regions for each of them, so every project can be hosted where it fits best in terms of geography (distance from end users) and regulations (identity of the IaaS provider).

### Sustainability 

With sustainability as one of its core values, Upsun leads in responsible and sustainable cloud operations.\* In an era where digital carbon footprints are under scrutiny, Upsun’s sustainable hosting solutions and practices help ensure your applications get all the power they need while being environmentally responsible—a contrast to the lesser green approaches subscribed to by other providers.

To solidify our commitment, Upsun offers users a 3% discount on resource usage when users choose to deploy to a data center powered by renewable energy sources in one of our incentive-eligible greener regions. All to help lower their carbon footprints.

Heroku doesn’t have any published sustainability policy or incentives.

\*Upsun offers efficient cloud orchestration, with 12x better CPU usage as compared to AWS EC2. Greenly calculated the gains were 14x higher density for development and 10x higher for production workloads.

### Persistent storage

Persistent storage is, as the name suggests, data storage that persists even when the container that runs the application is restarted or replaced for whatever reason. In most cases, the storage of the container itself is ephemeral and should not hold any information on which the application depends to function properly. 

Heroku doesn’t have persistent storage. Anything one might store on a Heroku container is ephemeral by definition. And any data that needs to persist between deployments must be stored outside of the platform (i.e., AWS S3). This makes deploying to Heroku much more complicated as it requires you to: 

1.  Find a third-party provider for the persistent storage.
2.  Adapt your application to read files from the external provider.
3.  Adapt your deployment scripts to use the external storage—not only when deploying to the main environment, but also when cloning environments to preview changes.

Unlike Heroku, Upsun doesn’t expect users to shop for third parties to build a complete project, including storing data and media. Upsun enables you to choose any amount of persistent storage directly on the platform, using the same easy configuration as for other parameters of the application, so running a stateful application is simple. When cloning an environment, the data and files stored on the persistent disk will be cloned in seconds, too, ensuring any preview environment is not only fast and easy to create, but is also a perfect copy of production.

### Requests timeout

Heroku has a non-configurable, hard response timeout of 30 seconds.

Upsun has no request timeout. Even if you need to upload very large files, the upload will not break because of any platform limitations.

### Protecting data services

Because of how the Heroku platform is built, its default behavior has services like databases and search available from the internet, which may potentially expose sensitive data to unauthorized users. Protecting these services requires Heroku’s Private Spaces—a premium service for high-end clients.

Upsun offers many different data services (e.g., PostgreSQL, MongoDB, ElasticSearch, Redis, MariaDB) available only from within your applications, helping you make sure your data isn’t directly exposed to the internet.  

### Runtimes, Dockers, buildpacks

Both Upsun and Heroku have native support for an extensive array of runtimes, including Python, Node.js, PHP, Go, Java, and  Ruby.  Each of the platforms also has native support for a divergent set of languages: Upsun images for C#/.Net Core, Elixir, Lisp, and Rust; Heroku buildpacks for Clojure, Gradle, Grails 3.x, JVM, Play 2.x and Scala.

You can feel the big difference when you want to deploy software written in languages not natively supported by the platform. This may be the case, for example, when working in a microservices architecture. On Heroku, development in non-native languages is close to impossible and would require you to develop your own buildpack. On the other hand, Upsun has a composable image based on Nix, enabling you to develop and deploy software even in new or less popular languages. While also possible with Dockers or buildpacks, Upsun doesn’t sacrifice simplicity for versatility; using the composable image is as simple as using any of Upsun’s aforementioned runtime images.

### HTTP/2 support

The industry-standard protocol for the internet, HTTP/2 makes browsing faster and more efficient. It’s been around since 2015 and is supported by most web servers and web browsers. Yet, Heroku continues to deliver content over HTTP/1.1. As it stands today (April 2024), years after the newer protocol version was released, Heroku only has HTTP/2 support in beta.

Upsun serves content through a recent version of nginx and fully supports HTTP/2.

### Security – DDoS protection

As with other aspects of the platform, Heroku recommends using third-party services for DDoS protection, which means your monthly bill will increase as you add the complexity of dealing with more providers.

Carefully configured against DDoS attacks, Upsun uses a built-in, reverse proxy cache that protects your applications from malicious attacks. With security under the single Upsun roof, you don’t need to shop elsewhere for additional protection.

### Service continuity 

Heroku containers (dynos) restart at least every 24 hours in a process called `Cycling`, losing in-memory state (e.g., caches) and breaking websocket connections. Heroku application restarts obviously lead to downtime. To avoid them, you have to purchase more instances and load-balance them, hoping they won’t cycle at the same time. 

Upsun restarts containers and services only when developers initiate such a restart, usually when deploying a new version of their applications. In rare cases, Upsun will also trigger a forced rebuild to apply critical security patches.

### Cron jobs

Scheduled operations critical to a system’s health and performance, cron jobs form an essential part of any operating system. Web applications leverage this capability to execute ongoing automated maintenance tasks.

Heroku has a basic, free add-on called _Heroku Scheduler_, which launches a dedicated container for running cron jobs. It’s important to note these two key factors:

1.  Heroku itself makes it clear in their docs that their own scheduler add-on should not be relied on for critical tasks and recommends using a custom process.
2.  The fact that the scheduled tasks run in a dedicated container means increased usage and, therefore, an increased monthly bill.

Upsun provides full cron support natively and directly within an application’s configuration. It uses the standard Unix syntax and enables fine-grained control over task execution and its termination. With Upsun, cron jobs run within the allocated container and don’t incur any extra fees or count toward additional billable usage.

## Developer experience and productivity

### Preview environments

The ability to create byte-for-byte clones of production environments for development, reviews, testing, and approvals is one of Upsun’s most robust features. A game-changer for developers, team leads, QA teams, and other stakeholders alike.

In Upsun, each project may have several environments. One would usually be used for production, while the others for various testing purposes. It’s as simple as running `upsun branch staging main` to create a new preview environment called `staging`, available at a unique URL, which is an exact copy of the `main` environment, together with all of its services, workers, databases, and stored files. 

(See the _Pricing_ section below to learn more about how multiple environments affect pricing.)

Unlike Upsun, Heroku doesn’t have the concept of _projects_, and each environment is a separate app. However, Heroku does have a feature called _Review Apps_ that’s similar in concept to Upsun’s preview environments. That said, the process is a much heavier lift that  includes many manual steps and configuration, making it far less developer-friendly. Finally, Heroku doesn’t clone the database together with the application’s code; rather, it becomes a developer’s responsibility to have a separate process to load data into the Review App. 

### Observability

Upsun offers unparalleled insights into your applications’ performance and health, going far beyond basic monitoring. Upsun observability tools are intuitive, providing clear, actionable data. With built-in Blackfire, you can drill down to the function level of your code to help reduce execution time, your monthly bill, and your application's carbon footprint. Upsun provides all levels of observability and telemetry under the same roof, where all stakeholders have access, and internal task management becomes much more efficient. 

Heroku, like many other platforms, gives you basic telemetry, which may be sufficient if you want to know when to purchase more storage or when it’s possible to reduce container size. For anything beyond that, especially the insights of the application’s performance itself, you’ll need to integrate an external service like NewRelic, Datadog, or other similar, third-party commercial services.

## Pricing and transparency

When choosing a cloud provider, pricing is obviously a critical differentiator and one many users will try to figure out on their own.

This is where _predictability_ comes into play. It’s about giving customers all the transparent data they need to calculate monthly billing on their own, or, at least, to see in advance what it would be incurred at the end of the month.

By definition, usage-based pricing changes from month to month, so it's not possible to predict it at 100%. Yet, if you have easy parameters to calculate with, the predictability increases, making you less prone to experience any unpleasant surprises.

### Pricing

Upsun has a fully transparent and simple pricing model. We provide you with everything you need to run your applications, and you pay only for what you actually use. Upsun also lets you modify your plan as you wish without limitations and provides an estimate of what your next billing cycle would look like. So you’re always in control, with a full picture available at any moment. To protect you from bloating your monthly bill, Upsun enables you to set different size values for preview environments, so you don’t have the same spend on testing environments as in production. 

When comparing Upsun and Heroku, it’s important to note that Heroku’s pricing isn’t as transparent and requires its customers to go through a lengthy process, especially (as noted previously) as Heroku relies heavily on third-party providers for almost every detail, except for computing. So, it may be very difficult for customers to have a clear picture of what their monthly bill would look like.

Below is a simulation of a reasonably sized, business-critical web application, maintained by a team of three developers, each working on a different preview environment. 

You can see that prices are relatively similar between Upsun and Heroku, with a slight advantage to Upsun. But the real value lies in the two comparisons mentioned here, but aren’t visible on the below graph:

1.  With Upsun, you get everything under the same roof: single invoice, single provider, single responsibility. Heroku delegates services and responsibilities to third parties.
2.  Upsun’s pricing model is predictable and extremely easy to understand and control. Heroku’s is very complicated and unpredictable.

### A word on transparency

With Upsun, what you buy is exactly what you get, especially when it comes to resources. You have the information you need to calculate your expenses in advance. By using simple values and price units, Upsun has the most straightforward model any cloud service could have. Because Upsun provides all the services directly (i.e., no need to purchase third-party services), it becomes very clear what billing will look like.

Conversely, Heroku has an opaque and rather complicated concept of dynos that represents the computing power allocated to your container. This lack of transparency makes it quite challenging to make data-driven decisions about the amount of resources an application may need to run properly in different scenarios. 

As demonstrated above, Heroku expects users to purchase third-party services, increasing the monthly expenses on cloud services—even if those services are not provided directly by Heroku.

## Wrap-up

Choosing the right PaaS for your organization is an important decision. Both Upsun and Heroku offer valid platforms to support your applications. But for development teams who build modern web applications in a constantly changing environment, Upsun provides a highly flexible, robust, transparent alternative for your consideration.

**Learn more:**

-   This Heroku alternative includes everything under the sun

### [Crafting a new developer experience | Upsun](https://upsun.com/blog/crafting-a-new-developer-experience-through-user-research/)

# Why Upsun? Crafting a new developer experience through user research

Our newest offering, Upsun, is now live—and we wanted to give you an insider's look into how it came to be. Over the course of a year, we gathered feedback from developers (our primary users) to better understand some of their key Platform.sh product challenges.

Through extensive user research and testing, we identified three key product areas to  improve: 

Streamlining onboarding and project creation

Providing flexible, container-based resource allocation 

Creating a usage-based billing model to cater to flexible resources and more

To set some context, when Platform.sh was built 10-plus years ago, our key target users were building Drupal websites. Today, we have users around the world who build a diverse set of applications, not only Drupal sites. This, along with insights from our research, led us to build a new product with a wide range of new features and to enable functionality, onboarding, and configuration for _any_ application. Read on to find out how we did it! 

## **Making a good first impression: it all starts with onboarding**

To begin our journey to optimize our product and deliver the ultimate developer experience, we first needed to streamline our onboarding process. 

From feedback gathered through surveys, interviews, and data analytics, we learned that some of our users found our onboarding process simple enough—mostly engineers, backend devs, and those with expert-level knowledge—and had no issue creating a project and deploying code. There was, however, a large portion (48.1%) of our users who found it far too complex to create or build a project, even with our documentation and our at-the-ready support team. Some users found account creation tedious while others had considerable difficulty configuring their projects, connecting their repository and other integrations. In Platform.sh, these setup steps are not in a combined flow. Rather, they’re disjointed and need to be accessed from different areas in the Platform.sh product. 

In aggregate, these factors led us to reset our goal: for all new customers to create and build a project with ease—without the need to rely on documentation. We wanted users to see the power and magic of our product sooner by eliminating unnecessary complexity. To reimagine our core onboarding experience, the team stripped back the flow through customer-journey mapping while our engineers led discussions about new and improved ways we could create and configure projects. Our product team pushed for a demo-project-first user experience, enabling users to quickly see how simple projects could be created. In parallel, our product design team led efforts to streamline a new stepped flow and interface that enables users to focus on completing certain tasks without distraction. Our design team prioritized both mobile and desktop views for these experiences. 

We shortened our account creation process from four steps to two, introduced an organization\-first approach, and moved users straight into project creation, where one of the first steps requires users to connect to their repository; previously, this had been a disjointed step for users and lived within the product’s integrations’ area. 

From user experience and interface design perspectives, we created a new onboarding flow for our key account, project, and conversion flows within the product. These new flows are all full-page experiences—a design approach that limits distractions for users during some of our key product moments (e.g., sign up, organization creation, project creation, integration setup). The result? The simpler, smoother onboarding experience developers asked for.

## **With resource flexibility, the choice is yours**

Our next goal was to enable users to size their application and service containers themselves rather than default auto-sizing. We know that every project has different needs—think what you’d need to create a Headless Chrome project vs a WordPress site or ecommerce store. On top of that, every application and service naturally has different CPU (computing), RAM (memory), and disk (storage) needs. We set out to provide this flexibility as well as usage-based pricing for resources. 

Originally, our plan sizes (e.g., Standard, Medium, Large, X-Large) restricted flexibility because they had total resource limits. For example, a Standard plan with 0.96 vCPU and 0.75 GB RAM might require a big jump in plan size to get more resources when you may have needed just a little more, for a short period of time. Think Black Friday traffic increasing the CPU and RAM you need only over that weekend. 

Our UX team set out to find user flows that intuitively and easily enable users to configure and size their own application and service containers. We looked to the obvious pathways: 

From the metrics page, when users review the CPU, RAM, and disk performance of their containers

From the Apps and Services cards, which are the visual representation of all user applications and services, with links to view the services page details of those containers

From our environment overview cards, where we summarize total CPU, RAM, and disk resources of the environment

From the services page, the detailed overview of each and every container

And, last but not least, from within our Projects billing page, where users can compare the resource allocation of all environments and view resource costs

With Upsun, users can now set the size of any container's CPU, RAM, and disk as well as increase the number of instances for any application (a brand new feature) through the product. Memory ratios are now also configurable through the CLI (the CPU-to-RAM ratio), and we provide more transparency to containers’ memory ratio in the configuration screen. 

Giving users the flexibility and control to size their projects, applications, and services allows them to size containers however they need to suit their applications and sites while only paying for the resources they want and use. This freedom has underpinned the Upsun flexible-resources initiative, and, in turn, led us to change our pricing model. Moving away from set plans into resource-based and flexible, usage-based pricing as well as looking more broadly at our tiers and business offerings.

## **Organization-first user pricing**

Flexible resources were just the beginning of our new pricing model exploration. When we dove into creating a new pricing model, we found an opportunity to change how our user licenses are built and charged. Previously, users were billed for every user on every project. To put this into perspective, say you had a team of five agency developers working on new website projects every week/month/year, at four projects/month. For every project, you would be charged $10 USD/user/project. This looks like this:

Project 1 x 5 users = $50 USD

Project 2 x 5 users = $50 USD

Project 3 x 5 users = $50 USD

Project 4 x 5 users = $50 USD

Total user license fees for the month = $200 USD, (even if it’s the same development team users working on your projects).

This model isn’t ideal for an agency; typically PaaS and SaaS products bill per user license _not_ per project access granted. So, we looked for ways to move our user licenses to an organization object, where user licenses are billed once, with the ability to grant access to any projects without incurring any additional costs. This results in a cost similar to:

Organization A, with 50 projects and 5 users = $50 USD total user licenses

Moving to an organization-first experience in our onboarding flow—and moving our billing to the organization—were fundamental shifts not only in user experience, but architecturally through our billing infrastructure. Both have resulted in huge benefits for Upsun users.

## **Building Upsun**

A lot of what we’ve done with Upsun is built around giving users more freedom and control to do more of what they want, how they want, and when they want. We’ve created a product that targets diverse applications, with a user experience tailored for individual contributors. We achieved this in under a year by introducing self-service and usage-based billing, with an organization-first approach. 

Upsun became a playground to try, fail, and iterate rapidly in many ways, across many features. In building Upsun, we’ve worked on more than 20 new feature projects this year alone, encompassing emails and conversion flows, repository connection, scaling resources vertically and horizontally, teams—and let’s not forget the big visual branding changes on the frontend side, which we’ll cover in an upcoming article. Stay tuned for that because it’s a fun one.😉

In the coming months, as we continue moving through its beta phase, Upsun will continue to evolve and improve with all of the user feedback we receive. So, if you haven’t already, sign up for a free trial to test Upsun. Let us know what you think, and then watch its evolution firsthand.

Start a free trial

### [How to build an AI company investors will back | Upsun](https://upsun.com/blog/building-vc-ready-ai-companies/)

# Building VC-ready AI companies: sustainability as an advantage

_This blog post is based on a panel discussion about AI sustainability and investment trends, featuring insights from industry leaders at an AI conference. We utilized AI tools for transcription and to enhance the structure and clarity of the content._

The AI investment is increasingly growing. While major tech companies plan to spend over $300 billion on AI infrastructure in 2025, investors are no longer just asking about powerful models or rapid scalability.  In a recent panel, leaders from the investing, climate, and infrastructure sectors cut through the hype to discuss what “sustainable AI” really means for founders.

## The investment reality check

The host began with a simple fact: in 2025, major tech firms, including Amazon, Alphabet, Microsoft, and Meta, are pouring unprecedented resources into AI infrastructure. President Macron recently announced a 109 billion euro investment. But as Resa, General Partner at Partech Global, explains, "What we don't want is for people to keep spending $2 to make a dollar or to hit a wall that will limit their growth."

This perspective reflects a broader understanding that sustainability encompasses both environmental responsibility and business viability. The days of unlimited compute spending are numbered, not just because of environmental concerns, but also because the economics simply don't work in the long term.

## The sustainability paradox in high-growth startups

Jean-Baptiste Rudelle, president of the Galion project and former founder of Criteo, shared a crucial insight about the apparent contradiction between hyper-growth and sustainability. "The whole point of a startup is to go in hyper growth, and how can you sustain hyper growth and at the same time be sustainable? There's some kind of mental tension between those two concepts."

His experience at Criteo, where revenues doubled every year for seven consecutive years, provided a practical framework: When you achieve 2x growth in traffic and revenue, you should aim for only 1.5x growth in infrastructure costs. This ratio ensures that your scaling curve creates leverage rather than consuming it.

The cost of ignoring this principle became clear when Criteo hit a ceiling at around $100 million in revenue. The company had to dedicate 18 months to rebuilding its platform from scratch, with the entire technical team focused solely on sustainability improvements while no new products were shipped. As Rudelle noted, "This was the cost to pay for long-term sustainability."

## Breaking the misconceptions

Anise, sustainability manager at Reva, highlighted a critical misconception that has shaped the tech industry for years: "For a long time, we thought that tech companies and IT in general weren't part of the problem. We used to say it's the industrial companies that are the problem."

Recent data have challenged this view. A 2019 study by the Shift project revealed that IT represents 4% of global emissions, nearly equal to aviation emissions. Without action, this could grow to 10-11% of global emissions. Even companies like Microsoft, which announced ambitious Net Zero pathways, have seen their emissions grow by 50% due to AI activities.

However, the story isn't entirely negative. AI startups can also be part of the solution, with companies working in healthcare and using AI to optimize energy grids, showing how technology can address social and environmental problems.

## Practical implementation

Guillaume, Vice President of Advocacy at Upsun, shared concrete examples of how sustainability translates to business optimization. When their platform reached around $40 million in annual revenue, a dedicated FinOps team reduced cloud bills by 40% in just six months by removing overlooked services and optimizing resource allocation.

The key insight is that sustainability isn't just about reducing carbon footprint—it's about optimizing for cost and ensuring that profit margins are sustainable. This includes tracking hidden expenses, such as bandwidth between regions and backups, which can represent 20-25% of cloud bills.

## The tools and metrics that matter

For early-stage companies, the first step isn't complex carbon accounting; it's understanding that sustainability isn't a burden but a competitive advantage. Anise recommends starting with carbon footprint assessments to know where emissions originate, enabling targeted optimization.

For AI-specific applications, the focus shifts to model efficiency. Rudelle emphasized the threshold nature of AI: "If you are below a certain level of quality, the whole thing is useless. If you are below 80% predictability, you can throw the whole thing out of the window."

This creates pressure to increase parameters and computational power, making optimization techniques crucial for effective solutions. Model compression can achieve dramatic results, sometimes reducing model size by a factor of five with only a 1% loss in accuracy. The ability to predict traffic peaks also matters significantly, as dimensioning for maximum load can result in doubling system requirements for minimal gain.

## The investment perspective: Beyond the pitch deck

When asked about integrating sustainability into pitch presentations, Resa offered a different perspective: "It's not really about the pitch deck. I want to turn the question around because a pitch deck is just a snapshot of a story they want to tell at a given time."

The more important matter is incorporating the understanding that throwing money at problems isn't sustainable. Investors want to see founders thinking about optimization from the beginning, planning for "what's next" beyond just market size and growth projections.

The example of Facebook's early data center challenges illustrates this point. When California faced a shortage of electricity and water for new data centers, Facebook initiated the Open Compute Project, which developed more efficient server designs and data centers that utilized natural ventilation rather than air conditioning. This wasn't driven by environmental concern but by practical necessity.

## Emerging trends and future opportunities

Several trends are reshaping how AI companies approach sustainability:

-   **Federated Learning**: This approach distributes model training across user devices rather than centralizing it in the cloud. This reduces resource consumption while addressing privacy concerns, as data doesn't need to be centralized for training.
-   **Smart Infrastructure**: Companies are leveraging AI to optimize electricity usage in response to grid conditions. In France, for example, carbon intensity varies significantly between 7 PM and 1 AM or between seasons. Innovative dispatch systems can redistribute workloads to regions with cleaner electricity sources without compromising user experience.
-   **Alternative Hardware**: The current reliance on NVIDIA GPUs isn't sustainable in the long term. New architectures, including TPUs and NPU, are emerging, potentially offering better efficiency and reducing the environmental impact of hardware production.

## The economic reality

Despite the compelling sustainability narrative, Jean-Baptiste Rudelle provided a sobering economic perspective: "To be completely honest, in the short term, the hard answer is there is very little commercial edge by trying to be low carbon for a startup."

The primary incentive today remains largely reputational, with brand power influencing hiring talent and attracting clients. However, this could change significantly with the introduction of meaningful carbon pricing. “What would really address this in the long term would be a carbon tax. If there is a real serious carbon tax, then businesses will have a real incentive to decarbonize.”

## The productivity argument

The panel discussion touched on a crucial economic argument: AI's role in funding the green transition through productivity gains. While productivity improvements from new technologies often take years to materialize in economic statistics, the potential impact on coding and software development could be transformative.

As Rudelle explained, "The area where the productivity is going to be the most spectacular in terms of gains in the short term is going to be in terms of writing code." If the cost of writing code approaches zero, companies can develop customized software tailored to their specific needs, rather than relying on generic SaaS products, which could potentially result in significant productivity gains.

## Regulatory and market pressures

The regulatory landscape is pushing sustainability requirements downstream. According to Anise, 87% of companies at the Series C stage have performed carbon footprint assessments. "From Series B onwards, investors make it compulsory to have a climate strategy," she noted, driven partly by regulations like SFDR (Sustainable Finance Disclosure Regulation).

This isn't just about regulatory compliance; it's about risk management. As one panelist noted, "Venture capital is the other name for risk capital, and sustainability is a risk management framework."

## Key takeaways for AI startups

The panel's closing recommendations provide a clear roadmap:

1.  **Act now**: It's always less costly to implement sustainable practices early than to repair problems later. Studies by actuaries suggest that the effects of climate change could decrease global GDP by 50% by 2070-2090.
2.  **Make AI part of the solution**: Rather than viewing AI as purely a resource consumption problem, focus on how it can drive efficiency and solve environmental challenges.
3.  **Think outside the box**: Don't rely on traditional scaling approaches. The shift to AI requires rethinking how applications are built and solutions are deployed, much like how cloud technologies have forced architectural changes.
4.  **Leverage expertise**: Don't try to solve infrastructure optimization on your own. Collaborate with specialists and tap into the growing ecosystem of sustainability-focused startups and tools.

## Looking forward

The AI sustainability discussion represents more than environmental responsibility; it's about building businesses that can scale efficiently and survive long-term market pressures. As infrastructure costs continue to rise and regulatory requirements increase, companies that integrate sustainability thinking early will have a significant competitive advantage.

The message from investors is clear: demonstrate not just what you're building and how fast you can grow, but how you plan to sustain that growth efficiently. In a world where throwing unlimited resources at problems is no longer viable, optimization becomes the key differentiator.

For AI startups, sustainability isn't a constraint; it's an opportunity to build more resilient, efficient, and ultimately successful businesses. The companies that recognize this shift early will be the ones that attract the right backing and create lasting value in the evolving AI landscape.

### [Optimize resource allocation and services for Express apps | Upsun](https://upsun.com/blog/express-performance-optimization/)

# How to optimize resource allocation and cloud database services for Express applications 

You may have seen our previous quick-start guide on hosting Express on Upsun which details how to set up your Express applications quickly and effectively on the Upsun PaaS. Well, we wanted to take this guide one step further—providing a guide on how you can optimize the performance of your Express applications by leveraging flexible resource allocation and MariaDB cloud-managed database services. Let’s dive right in!

## **Flexible resource allocation for your Express apps**

Upsun projects are container-based with each service/runtime given its very own container, each with its own CPU/RAM and disk resources available. With flexible resource allocation, you can easily scale up or down by simply changing container storage and CPU/RAM per container, per environment, at any time. 

During the first push of your production environment, Upsun will use the default size for each of your service/application containers. In general, the following resources should be effective but you can always adapt those values to your application's needs:

-   1 Node.js container instance
-   with CPU: 0.5, memory 224MB
-   and 0MB of Disk/Storage

Here’s how you can adapt your resources to serve the needs of your Express application: 

### **How to scale your container storage and CPU/RAM**

If you need to define custom resources (CPU, memory, and disk), the process is simple. When in the environment view in the Upsun console, click on **configure resources** which you'll find on the left of the console interface—this can also be done via the CLI. From there, you can adapt the allocated resources to support your application's requirements.

**Please note**: if you push a new Git branch, the corresponding Upsun environment will use the same resources as the parent environment.

Once you’ve confirmed your choices, Upsun will then take your selections, gather the previously built images from earlier, apply your resource selections to them, and redeploy your full application. For more information, refer to our documentation on how to manage resources on Upsun.

## **Utilizing MariaDB open-source database**

MariaDB is a much-loved open-source database and cloud-managed database services provider designed to enhance database performance, efficiency, and scope. Want to get those benefits for yourself? Here’s how to start using MariaDB with your Express applications on Upsun: 

### **Create a new environment**

**Please note**: the same rules that apply to Git workflows, apply to Upsun projects: never update your production environment directly, and always create a new branch to test your local changes.

To update your application, create a new Git branch as usual via your terminal, implement the changes you wish to make, and push the branch to your GitHub repository. 

```shell-session
git switch -c add-mariadb && git push -u origin add-mariadb
```

### **Add a MariaDB service to your environment**

To add a new MariaDB service to your application, you need first to add a new service definition into your `.upsun/config.yaml` file, within the `services:` top-level key: 

```yaml
# .upsun/config.yaml
services:
  mariadb:
    type: mariadb:11.0
```

Then, add a relationship setting in your application matching the service name `mariadb`:

```yaml
# .upsun/config.yaml
applications:
  app:
    relationships:
      mariadb: 
```

Then push your changes to your repository:

```shell-session
git commit -am "Adding MariadDB 11 service" && git push
```

### **Use MariaDB in your application**

First, you need to import a Node.js module named `mysql2` to interact with your local database. Import it using the following command:

```Javascript
npm install mysql2
```

Then update your `index.js` file with the following: 

```Javascript
const express = require('express')
const app = express()
const mysql = require("mysql2/promise");
const port = (process.env.PORT || '3000');
function openConnection() {
  let database_password = 'express'
  if (process.env.MARIADB_PASSWORD !== undefined) {
    database_password = process.env.MARIADB_PASSWORD
  }
  return mysql.createConnection({ host: (process.env.MARIADB_HOST || '127.0.0.1'), port: (process.env.MARIADB_PORT || '3306'), user: (process.env.MARIADB_USERNAME || 'user'), password: database_password, database: (process.env.MARIADB_PATH || 'express') });
}
function createTable(connection) {
  return connection.execute(
    'CREATE TABLE IF NOT EXISTS upsuninfo (uid INT(10) NOT NULL AUTO_INCREMENT, username VARCHAR(64) NULL DEFAULT NULL, departname VARCHAR(128) NULL DEFAULT NULL, created DATE NULL DEFAULT NULL, PRIMARY KEY (uid) ) DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;'
  );
}
function insertData(connection) {
  return connection.execute(
    "INSERT INTO upsuninfo (username, departname, created) VALUES ('upsun', 'Deploy Friday', '2023-09-29')"
  );
}
function readData(connection) {
  return connection.query("SELECT * FROM upsuninfo");
}
function dropTable(connection) {
  return connection.execute("DROP TABLE upsuninfo");
}
// Define the main route.
app.get('/', async function(req, res){
  // Connect to MariaDB.
  const connection = await openConnection();
  await createTable(connection);
  await insertData(connection);
  const [rows] = await readData(connection);
  const droppedResult = await dropTable(connection);
  // Make the output.
  const outputString = `Hello, World! - A simple Express web framework template for Upsun
MariaDB Tests:
* Connect and add row:
  - Row ID (1): ${rows[0].uid}
  - Username (upsun): ${rows[0].username}
  - Department (Deploy Friday): ${rows[0].departname}
  - Created (2024-04-30): ${rows[0].created}
* Delete row:
  - Status (0): ${droppedResult[0].warningStatus}`;
  res.set('Content-Type', 'text/plain');
  res.send(outputString);
});
// Get PORT and start the server
app.listen(port, function() {
  console.log(`Listening on port ${port}`)
});
```

Finally, commit your changes by using the following: 

```shell-session
git commit -am "use MariaDB in index.js" && git push
```

**Please note**: if you have already installed the Upsun CLI, you can also use **upsun push** command (instead of **git push**) as it will use the **upsun** Git remote to push your code too, and this remote is defined as the same as **origin**.

When pushing a new branch to your repository, It will automatically create a new, inactive Upsun preview environment, based on your branch source code and parent environment data (database and/or assets). **This new environment is not active by default** which means it does not consume resources, so, to finally test it out, you need to activate it, using the following command: 

```shell-session
upsun environment:activate
```

At the end of the activation, your `add-mariadb` environment will be deployed and you can access it via the Console by going to the corresponding environment and clicking on its front URL or by using the following CLI command: 

```shell-session
upsun environment:url --primary
```

### **A little extra, create a local Docker container using MariaDB** 

To be able to test MariaDB locally, you need to use a local MariaDB database engine. The fastest way to do this is to either open an SSH tunnel to your environment or add a local Docker container. To add a local Docker container, at the root of your project, create a `docker-compose.yaml` file with the following: 

```yaml
version: '3.1'
volumes:
  data:
services:
  db:
    image: mariadb:latest
    restart: always
    environment:
      MARIADB_ROOT_PASSWORD: express
      MARIADB_PASSWORD: express
      MARIADB_USER: user
      MARIADB_DATABASE: express
    volumes:
      - data:/var/lib/mysql
    ports:
      - "3306:3306"
```

You can then start the corresponding Docker container:

```Javascript
docker-compose up -d
```

Then, commit your file for other teammates to be able to use it:

```shell-session
git commit -am "Docker-compose file" && git push
```

### **How to run your Express application locally**

If you want to test your route locally, you can use the following commands to start the Node.js server on your `index.js` file: 

```Javascript
node index.js
```

And then open in your browser the following link: http://localhost:3000/. When you’re satisfied with your changes, merge your feature branch `add-mariadb` to the `main` branch using the normal Git workflow to do so:

```shell-session
git checkout main 
git merge add-mariadb 
git push
```

Your `main` environment will then be automatically deployed and you can access it by either using the Console by going to the corresponding environment and clicking on its front URL or by using the following CLI command: 

```shell-session
upsun environment:url --primary
```

**Please note**: don't forget to remove your **add-mariadb** Git branch (locally and remotely) to ensure you remove the corresponding Upsun environment. This can be done using the following:

```shell-session
git branch -D add-mariadb
git push origin --delete add-mariadb
```

Copy

This will delete your local and remote branches, and then the GitHub integration process will deactivate and remove the corresponding Upsun environment. 

And just like that, you’re ready to play with your Express applications now complete with optimized resources and MariaDB magic. Enjoy! 

Stay up-to-date on all the latest from us over on our social media and community channels. Catch us over on Dev.to, Reddit, and our Community.

### [Getting started with Express on the Upsun PaaS | Upsun](https://upsun.com/blog/setting-up-express-on-upsun/)

# A quick-start guide on hosting Express on Upsun

Welcome to our quick-start guide on hosting Express (at the time of writing, the most recent version of Express is 4.18.2) on Upsun where we will demonstrate just how simple it is to host your Express projects on our PaaS.

Before we get started, for the purpose of this tutorial we will assume that you have already installed the Upsun CLI locally.

**Have you seen the Upsun demo?** It’s the perfect place to find out how Upsun works and gain a better understanding of what we provide. To check it out, create a new project then choose "Deploy demo project."

## Get started locally

If you already have an existing GitHub repository with a functional Express source code, clone it locally using the following command and then jump to the second step: Configure your project.

```shell-session
git clone git@github.com:<YourRepoUrl>.git
```

### Initialize your local project

First things first, if you don’t have a local Express project yet, you need to create a new one locally following the Express installation guide. Please refer to all of the steps of the installation guide for full details, but to summarize, these are the four commands needed to create an Express application locally as seen below:

```shell-session
mkdir my-express-app
cd my-express-app
npm init
npm install express
```

### Initialize your Git repository

Once you’ve created a new Express project locally, it’s time to initialize the local Git repository and commit local files, using the following command:

```shell-session
git init
git add package.json package-lock.json
git commit -m "Init Express application"
```

**Please note:** You can ignore adding the `node_modules` folder to the Git repository and instead, use the following commands to do so:

```shell-session
echo "/node_modules" >> .gitignore
git add .gitignore && git commit -m "adding node_modules folder in .gitignore file"
```

### Add a Hello World route

To ensure your Express application is easily testable, you need to create your first Express page. To do so, create a new `index.js` file at the root of your source code, it will contain a basic Hello World script, as seen below:

```Javascript
const express = require('express')
const app = express()
var port = (process.env.PORT || '3000');
app.get('/', (req, res) => {
 res.send('Hello World!')
})
app.listen(port, () => {
 console.log(`Example app listening on port ${port}`)
})
```

Then commit your file using the following commands:

```shell-session
git add index.js
git commit -m "adding a Hello World"
```

### Create your GitHub repository

The next step is to create a GitHub repository, to do so follow the official GitHub guide which provides all of the information you need.

### Push source code to your remote repository

The final step of the local setup is to push your source code to your remote GitHub repository, using the following command:

```shell-session
git remote add origin https://github.com/OWNER/REPOSITORY.git
git push -u origin main
```

## Configure your project

To host your Express application on Upsun, some YAML configuration files are needed at the root of your project to manage the way your application behaves. See the code to automatically generate them below. These YAML configuration files are located in a `.upsun/` folder at the root of your source code, the architecture of which will look like this:

```shell-session
my-express-app
├── .upsun
│   └── config.yaml
├── [.environment]
└── <project sources>
```

**Please note**: An additional `.environment` file can also be located at the root of your source code, this file can contain Upsun-specific environment variables.

To generate these YAML files, run the command `upsun project:init` from the root of your Express project and follow the prompts, as you can see below:

```shell-session
upsun project:init
Welcome to Upsun!
Let's get started with a few questions.
We need to know a bit more about your project. This will only take a minute!
✓ Detected stack: Express
✓ Detected runtime: JavaScript/Node.js
✓ Detected dependency managers: Npm
Tell us your project name: [app]
                       (\_/)
We're almost done...  =(^.^)=
Last but not least, unless you're creating a static website, your project uses services. Let's define them:
Select all the services you are using: []
You have not selected any service, would you like to proceed anyway? [Yes]
┌───────────────────────────────────────────────────┐
│   CONGRATULATIONS!                                │
│                                                   │
│   We have created the following files for your:   │
│     - .upsun/config.yaml                          │
│                                                   │
│   We're jumping for joy! ⍢                        │
└───────────────────────────────────────────────────┘
        │ /
        │/
        │
  (\ /)
  ( . .)
  o (_(")(")
You can now deploy your application to Upsun!
To do so, commit your files and deploy your application using the Upsun CLI:
  $ git add .
  $ git commit -m 'Add Upsun configuration files'  
  $ upsun push
```

The `upsun project:init` command will automatically detect that you’re using an Express stack, ask if you want to add any services (please don’t add any for now), and generate the corresponding `.upsun/config.yaml` YAML files, like so:

```yaml
# Complete list of all available properties: https://docs.upsun.com/create-apps/app-reference.html
applications:
 app:
   source:
     root: "/"
   type: "nodejs:20"
   mounts:
     "/.npm":
       source: "storage"
       source_path: "npm"
   web:
     commands:
       start: "node index.js"
     upstream:
       socket_family: tcp
     locations:
       "/":
         passthru: true
   build:
     flavor: none
   hooks:
     build: |
       set -eux
       npm i
# Full list of available services: https://docs.upsun.com/add-services.html#available-services
#services:
#  db:
#    type: postgresql:15 # All available versions are: 15, 14, 13, 12, 11
# The routes of the project.
# More information: https://docs.upsun.com/define-routes.html
routes:
 "https://{default}/":
   type: upstream
   upstream: "app:http"
 "https://www.{default}/":
   type: redirect
   to: "https://{default}/"
```

Then commit your new files, using the following command, and the project configuration is complete:

```shell-session
git add .upsun/config.yaml
git commit -m "Upsun config files"
git push
```

## Create a new Upsun project

**Please note**: If you do not have an Upsun account yet, please create one to complete the following steps.

The next step in setting up Express on Upsun is to create a project which is simple to do via the Console. On your Console homepage (all projects), in the top right corner, please click on the **create project** button, as seen below:

If you do not already have an organization created to put the project into, you’ll first be instructed to create one. Once you have done so, select that organization from the dropdown, and then select **Deploy with GitHub**, as seen in the screen below:

Then select **Connect with GitHub** from the options provided as seen here:

In the next form that appears as seen in the screen below, select your GitHub organization from the first dropdown and then select **Install & Authorize** and fill out the GitHub credentials**.** You will need to select your GitHub organization and previously created GitHub repository and select **Continue**.

You will then be taken to step three of this setup—as seen below—where you will fill in various details including project name, environment name, and region. Once you’ve done so, select **create project**.

On the next page, while the project creation process is ongoing in the background, you will see on the left some further setup instructions, if you need them. On the right, you can follow the project creation process and you will be informed when it is complete, as seen in the screen below:

Once your project has been created, the GitHub integration process will automatically deploy your application based on your GitHub repository source code. Wait for the integration to finish deployment and it will then display your application information which you can see an example of in the screen below:

At the end of the process, please execute the following command to set the remote, using the Upsun CLI:

```shell-session
upsun project:set-remote <ProjectID>
```

## Time to deploy, right?

And just like that, it’s time to deploy! But wait…

As you already ensured your source code was Upsun-ready in the project configuration section of this guide, **your project will have been automatically deployed during project creation and your application will already be live**, with no deployment needed. Check out your new project URL at the bottom of the console interface.

The next step is to access your project console by clicking on the **view project** button at the bottom of the setup page, et voilà, your Express application is live and you can start playing around with it and adding lots of cool new features!

### Useful links

-   How to optimize resource allocation and cloud database services for Express applications

### [Build and host your React project effortlessly | Upsun](https://upsun.com/blog/getting-started-with-react/)

# Up(sun) and running with React

Upsun is well-suited to host JavaScript applications of all kinds, including React apps. This short guide will get you started on the first steps of creating your React project, deploying it to Upsun, and then leveraging its features to kickstart your development. 

## **Building React projects**

For this tutorial, we can leverage the React quickstart to create our application. 

Run the command:

```shell-session
npx create-react-app upsun-react --template cra-template-kendo-typescript
```

`create-react-app` will set up the scaffolding for the new repository, in this case leveraging KendoReact - a project that contains a collection of ready made React components according to the KendoReact UI System. 

When the project has finished building and installing dependencies, we can run a development version of the site locally with `cd upsun-react && npm run start` and visit the site at http://localhost:3000. 

If we instead wanted to build a production version of the application, we can do so with the command

```shell-session
npm run build
```

which will build static HTML, JS, and CSS in the local `build` subdirectory. We can then run that built site quickly with a local server, such as the below Python\-based approach:

```shell-session
python3 -m http.server --directory=build 3000
```

## **Deploying React projects**

With the Upsun CLI installed and an account already created, running the following command from the React repository:

```shell-session
upsun create -o YOUR_ORG_NAME --title=React-Upsun --region=ca-1.platform.sh --default-branch=main -y 
```

Replace `YOUR_ORG_NAME` with the desired organization, and feel free to substitute with another region if you’d like. Next, create a minimal Upsun configuration file to build and then deploy the React project.

```shell-session
# .upsun/config.yaml

applications:

    upsun-react: 

        type: "nodejs:20"

        hooks:
            build: |
                set -eux
                npm install
                npm run build

        web:
            locations:
                /:
                    root: build
                    index:
                        - index.html        
```

Stage, commit, and push to Upsun. In a few minutes, you’ll see your React app has been built and deployed successfully.

```shell-session
git add .upsun/config.yaml
git commit -m "Migrate to Upsun."
upsun push -y 
```

## **Making revisions**

An accumulated activity log appears locally in your terminal and in the push activity in the Upsun management console. You may have noticed – depending on when you go through this tutorial – that there may be some outdated and even potentially vulnerable dependencies present  in the repository. We can dedicate a preview environment to upgrading and improving this situation a bit.

First, create that environment:

```shell-session
upsun branch upgrades
```

Then let’s get our versions in order and use the latest version of Node.js both locally and on Upsun. We can use a tool like nvm to download the latest available version of Node.js – which at the time of this writing is Node.js 22 (adjust the commands below to the current version, depending how far you’re living in the future). Install `nvm`, and then use it to install the most recent version of Node.js:

```shell-session
$ nvm install 22
$ node -v
v22.11.0
```

We can update `.upsun/config.yaml` to match this recent version.

```shell-session
# .upsun/config.yaml

applications:

    upsun-react: 

        # Updating this line from 20 --> 22
        type: "nodejs:22"

        hooks:
            build: |
                set -eux
                npm install
                npm run build

        web:
            locations:
                /:
                    root: build
                    index:
                        - index.html      
```

Then using `npm`, audit vulnerable dependencies and edit either manually or with the CLI tool itself with the commands `npm upgrade` and `npm audit fix`. Commit (`git add . && git commit -m “Make upgrades”`) and push the changes (`upsun push -y`). Verify the deployment has succeeded, and merged into production!

```shell-session
upsun merge -y
```

## **You’re all set!**

That’s it! Now not only do you have a deployed React-based project on Upsun, you’ve gone through the same workflow you will develop with for every revision – whether for dependency upgrades or feature additions – you’ll make, complete with a preview environment for each one. 

Keep an eye out for more articles for deploying all kinds of applications on Upsun—follow us on our social channels to stay up-to-date: Dev.to, Reddit, and our Community. Make sure to join us on the brand new Developer Center for even more resources. 

Be seeing you!

### [PHPun with FFI: C PHP run | Upsun](https://upsun.com/blog/integrating-c-libraries-with-php-ffi/)

# Integrating C libraries with PHP FFI

Today we're going to plug that C library into PHP and get it all running on Upsun.

## Understanding PHP’s Foreign Function Interface

FFI, or Foreign Function Interface, is a feature of many languages to allow that language to call code written in another language. PHP got that functionality in the PHP 7.4, although as one might expect there are some bumps in the road.

One concern is that PHP is, by nature, accessed by remote systems. That creates a natural security risk. With FFI, if you could exploit any sort of hole in an application, then you could potentially achieve a remote code execution hole for system level code. On a security scale from 1–10 that ranks a "holy crap!", so by default PHP doesn't even support that. FFI is only enabled by default from the CLI or in preloaded code.

There's a caveat there, however. Preloading (also new in PHP 7.4, more on that in a bit) relies on the opcache. So does FFI. The opcache, however, is disabled by default since on the CLI it has nowhere to persist cached opcodes from one execution to the next. To use FFI with the CLI, therefore, we're going to need to manually enable the opcache.

## FFI on the CLI

Let's start with some code to use the `points` library we created earlier. First, we'll want a structure in PHP to mimic the `point` struct. (That's not required, but mirroring value objects on both sides makes the API easier to follow.)

```shell-session
class Point
{
   public int $x;
   public int $y;

   public function __construct(int $x, int $y)
   {
       $this->x = $x;
       $this->y = $y;
   }
}
```

The next step is to tell PHP about the library. There's a couple of ways of doing so, but we'll start with `cdef()`:

```shell-session
$ffi = FFI::cdef(file_get_contents('points.h'), __DIR__ . '/points.so');
```

`FFI::cdef()` is not an alphabet lesson gone wrong; it stands for "C definition" and takes two parameters: a string that defines the C structures to expose and the path to the `.so` file in which they can be found.

In this case, it's easiest to just read in the `.h` file for the definition. However, PHP's FFI doesn't use a standard C header parser. It has its own, which as of this writing is... rather weak. It doesn't support a lot of syntax that is completely legal in modern C code and is in fact quite common in most real C programs today. While custom written libraries like this can reuse their header, most real production C libraries will have headers that are too complex for PHP's FFI to handle. That means you'll need to reimplement your own.

That's actually fine; the coupling between a header file and a library is much weaker than, say, a PHP interface and class. The header file is just saying, "There exists, somewhere, a function named `distance` that takes 2 `points`." The `.so` file itself publishes "BTW, I've got a function named `distance` that takes 2 `points`." As long as those line up at loading time, it will work out.

It also means that if we want to expose only a small portion of a larger library, we can write a header file that only declares those functions and structs we want to expose to PHP, leaving the rest inaccessible. That can be useful with larger libraries.

We won't go into it here, but Anthony Ferrara has written a tool called `FFIMe` that wraps the FFI API to make it easier to work with and also handles preprocessing C headers into the subset of the language that PHP supports. It's not perfect, but it's worth investigating for serious FFI use.  
We can now use that `$ffi` variable to access the parts of the `.so` file that are exposed.

```shell-session
// inline.php

// ...

$p1 = new Point(3, 4);
$p2 = new Point(7, 9);

$cp1 = $ffi->new('struct point');
$cp2 = $ffi->new('struct point');

$cp1->x = $p1->x;
$cp1->y = $p1->y;
$cp2->x = $p2->x;
$cp2->y = $p2->y;

$d = $ffi->distance($cp1, $cp2);

print "Distance is $d\n";
```

First, we make two `Point` objects. Then we create two variables that are bridges to the `point` struct from the header file. Those variables are of type `FFI\CData` and act as an adapter between PHP land and C land. As they're objects we can use them as objects and they handle the translation back to C, so copying our `Point` PHP object values to them is a straightforward and boring process.

Finally, we can call the `distance` method on the `$ffi` object, which is an adapter for the C function. The data gets handed off to the C library which produces a `double` (aka a `float`), and returns it. Running this code dutifully prints out `Distance is 6.4031242374328`.

Or, well, almost. Recall that we said above that FFI requires a working opcache, which the CLI doesn't have by default. We can either enable it in `php.ini` or on the command line itself. The latter is easier:

```shell-session
$ php -d opcache.enable_cli=true inline.php
Distance is 6.4031242374328
```

Now we get the output we want.

## Setting up in advance

There's one problem here, though. Instantiating the FFI library, parsing the header file, and setting up the appropriate adapters in the background takes a non-trivial amount of time, especially if the C library is larger than this simple example. On the CLI there's no good way to avoid that cost on every request, but once we connect this code to a web request we want to skip that overhead if possible.

Fortunately, FFI offers an alternative way to bridge to a C library that has no runtime overhead that leverages preloading. Preloading is another new PHP 7.4 feature that lets you load class and function definitions into PHP-FPM's memory once at server startup and then never reload them again. We've written about preloading before, and it's a really neat addition.

You can also initialize a C library via preloading and keep it in memory, avoiding the initialization cost in future requests. By default, that is the only way you can use it in a web request, for the aforementioned security reasons. It's possible to enable `FFI::cdef()` to work in web requests for development, but please never ever do so in production.

We'll show preloading on the command line first. Since we're using preloading anyway, we'll move the `Points` class definition to another file named `classes.php`, like it's 2006 all over again. (It's retro.) Next, we need to make some additional changes to the header file by adding these two lines at the beginning:

```shell-session
#define FFI_SCOPE "POINTS"
#define FFI_LIB "./points.so"
```

The `FFI_SCOPE` specifies a unique identifier by which PHP FFI will recognize this library. `FFI_LIB` specifies the library file that it refers to. Note that the path is evaluated relative to the system library path, which does not include the current directory by default. That means the `./` is required, and if missing it will fail to load.

Another important caveat for the header file: As of this writing, a bug in PHP prevents it from parsing the header file if there are any comment lines prior to a `#define` line. All `#define` statements must come before any comments. We've reported this bug to PHP (see previous link) and hopefully it will get resolved, or at least documented, in a future version.

Now we can go about setting up a preload script. In this case it's a very simple file:

```shell-session
<?php
// preloader.php

declare(strict_types=1);

FFI::load(__DIR__ . "/points.h");
opcache_compile_file(__DIR__ . "/classes.php");
```

The `opcache_compile_file()` call tells the preloader to load everything in `classes.php` into PHP's shared memory. The other call, `FFI::load()`, tells PHP to load the header file then create and save the FFI adapter for that definition. The library file to use and the identifier for that library are specified in the header file.

Finally, we can setup another test script to see the preloaded version in action; it can be nearly identical to the inline version, just with a change to the FFI setup code:

```shell-session
<?php
// preload.php

$ffi = \FFI::scope("POINTS");

$p1 = new Point(3, 4);
$p2 = new Point(7, 9);

$cp1 = $ffi->new('struct point');
$cp2 = $ffi->new('struct point');

$cp1->x = $p1->x;
$cp1->y = $p1->y;
$cp2->x = $p2->x;
$cp2->y = $p2->y;

$d = $ffi->distance($cp1, $cp2);

print "Distance is $d\n";
```

The `$ffi` adapter is now created using `FFI::scope()` and specifying the previously loaded library (`POINTS`) that we want to use. Because the library is already loaded into memory in the preload step, this is a much cheaper call. The rest of the code is identical.

Also note that since we preloaded it, there's no need to `require` the `classes.php` file. It's already in memory and usable.

To run this script from the command line, we need to specify the preload script to use, again either inline or via `php.ini`:

```shell-session
$php -d opcache.preload="preloader.php" -d opcache.enable_cli=true preload.php
Distance is 6.4031242374328
```

Et voilà.

## Improving the API

The FFI API can feel a bit unnatural at times; in fact a lot of the time, especially once you start using its more advanced features that we're not going to get into here. Fortunately, as programmers we have a standard solution for clunky APIs: “Hey look, an abstraction!”

There's two main tweaks we're going to make to our code base. First, we'll let `Point` objects convert themselves to an FFI variable:

```shell-session
class Point
{
   public int $x;
   public int $y;

   public function __construct(int $x, int $y)
   {
       $this->x = $x;
       $this->y = $y;
   }

   public function toStruct($ffi)
   {
       $cp = $ffi->new('struct point');
       $cp->x = $this->x;
       $cp->y = $this->y;
       return $cp;
   }
}
```

Second, we'll wrap the FFI logic up into another object. There's a dozen ways to do so depending on the context of what you're doing, but we'll go for simple now just to make a point (no pun intended):

```shell-session
class PointApi
{
   private static $ffi = null;

   public function __construct()
   {
       static::$ffi ??= \FFI::scope("POINTS");
   }

   public function distance(Point $p1, Point $p2): float
   {
       $cp1 = $p1->toStruct(static::$ffi);
       $cp2 = $p2->toStruct(static::$ffi);

       return static::$ffi->distance($cp1, $cp2);
   }
}
```

A given FFI scope is safe to reference multiple times, so rather than try to make it a global singleton and inject it, we'll just stash it into a private static variable.

Now, we can simplify our example script to just this:

```shell-session
<?php
declare(strict_types=1);

$p1 = new Point(3, 4);
$p2 = new Point(7, 9);

$api = new PointApi();

$d2 = $api->distance($p1, $p2);

print "Distance is $d2\n";
```

No FFI in sight, but that's what's happening behind the scenes.

## Compiling the C library for PHP FFI

The next question, of course, is how to get all of this code working for web requests. It's fairly straightforward on Upsun, but the moving parts are essentially the same on any server.

We'll start with our latest code in a project repository and assume the `routes.yaml` and an empty `services.yaml` are already setup. Then we'll add a `web` directory with a simple web script that is just the `preload.php` script from a moment ago, with our cleaned up API.

The interesting part is in the `.platform.app.yaml` file, where there's a few moving parts. We're going to compile the shared library on every build so we always have the latest version of it. Fortunately `gcc` is already available on all Upsun environments so that's trivial to do. Here's the complete example, with relevant comments:

```shell-session
name: app

type: php:7.4

# FFI is an extension. It must be explicitly enabled.
runtime:
  extensions:
    - ffi

# Setting a variable in the `php` namespace makes it an ini setting. This block
# tells PHP-FPM to run `preloader.php` on startup. It's the same file we saw before.
variables:
  php:
    opcache.preload: "preloader.php"

hooks:
  build: |
    # Using the Makefile we defined in part 1, compile the `points.so` file.
    set -e
    make points.so

web:
  locations:
    "/":
      root: "web"
      passthru: "/index.php"

disk: 128
```

  
Now on every `git push` the points library will be recompiled to a new `.so` file. Then at deploy time, PHP-FPM will start up, load the FFI extension, and run the one-time `preloader.php` script to initialize our `POINTS` FFI scope (plus whatever else we want to do). The web configuration is as simple as can be; every request goes to our basic `index.php` file, which is the same code we've already seen.

If we wanted to ensure that the FFI library worked from the command line, say for a `cron` task, the easiest way to do it is to make sure the `cron` command includes both the `opcache.preload` and `opcache.enable_cli` directives as above. Both are required.

## But is it wise? That's iFFI

Whew! Not much code, but a lot of concepts. Is it worth it?

As is usually the case, the answer is "It depends”. Most of the time? No, it's not. For a trivial case like this it's counter productive.

For one, modern PHP is pretty darned fast in its own right. The performance benefits of moving mundane PHP code to C are marginal at best most of the time; eliminating a database call or two will give a much better speed up for much less effort.

For another, FFI has its own overhead. Every time you call across the PHP/C boundary, there is a translation overhead converting data structures from one style to the other. Just accessing a variable through FFI can be twice as slow as if the variable were in PHP. For trivial code like this example, it is almost certainly slower than just implementing `distance()` in PHP directly.

So when is it appropriate to move logic from PHP to C using FFI? I see two main use cases:

-   When you have a significant amount of heavy processing to do. Often that will be done offline in a command line script or a worker process, but it might be done in a web request if it needs to be dynamic. Think image processing, machine learning, heavy graph manipulation, and other tasks that might entail hundreds or thousands of objects or loop iterations if done in PHP. Those will be faster in a precompiled library.
-   When you have an existing library from someone else that you want to leverage. Historically this would require writing a PHP extension, which is much harder and more involved than using FFI. With FFI, however, you can now take an existing C library, wrap it in FFI, and use it from PHP just as you would were it an extension. The use cases are similar: image processing, machine learning, and other CPU intensive tasks for which there is a plethora of existing code written in C or C++ already. In this case, you'll almost certainly need to custom-write a header file or use FFIMe to bridge it to PHP. I would strongly recommend also building a nicer API atop FFI, as we did in this example, to make it easier for end users to use.

If your use case falls into one of those areas, you now have a new tool with which to tackle the problem.

Gabriel Couto has collected a series of examples of using FFI with existing libraries where reimplementing them in PHP would make no sense at all. Now that you have a good grasp of FFI basics, the examples there offer the next level up.

### Useful links

-   PHP | Upsun Docs

### [Make the simple trivial and the complex possible | Upsun](https://upsun.com/blog/make-the-simple-trivial-and-the-complex-possible/)

# Make the simple trivial, and the complex possible

This is part of a series about some of our design principles and, more generally, about composable infrastructure.

I’ll start with a list taken verbatim from a design document I contributed to while working on Upsun a few months back:

## Articles of the faith

-   Only Explicit Magic That is Easy to Override
-   YAML is code but YAML is not a programming language.
-   We make the simple trivial and the complex possible
    -   We strive for generality
    -   We allow for specificity

To be clear, this was much more of a reminder to myself than anything handed down as orders. The work on Upsun was fascinating for me. For the first time in a very long while, we were capable of releasing ourselves from the shackles of another article of faith _Never Break BC_.

This last one, backwards compatibility, is possibly the most important one when you care about **robustness** and **uptime**. And we _do_ care.

But Upsun is a new product offering. No existing production customers yet. We can go wild.

## Things that _just work_

As a PaaS, a lot of our work focuses on making an infrastructure that _just works_ and comes with a bunch of bells and whistles—features our users won’t have to think about ever again. Like making sure backups can _actually_ be restored. That a service that shouldn’t be exposed to the internet _isn’t_. And that a service that should be _is_. Or that everything hums and scales.

All of that is the invisible baseline. If you do your job nicely, users become oblivious to it. That’s the hard stuff. Day two operations. And more than anything else, that’s what we care about.

But part of the work is to deliver magic on another level—the initial onboarding.

I know how much I enjoyed it the first time I typed `vagrant up` and I had a VM running a minute later. And as much “cringe” as it was for me initially, piping a raw GitHub URL to bash `sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"`, and having a beautiful setup of ZSH with everything you might have hoped for, was a tantalizing experience.

But as always with software, everything has a tradeoff. In a later blog post, I’ll go into the _Curse of Defaults_. For now, I’ll just say that we chose to produce more friction in onboarding. Not because we like to torture people, but because we prefer having users complete a bit more upfront work and much less work later on.

So, we chose to have an explicit configuration of the application. You can’t just type `upsun up`. Users must add a configuration file—a file that will explicitly define the behavior of the infrastructure that will get deployed—to the repository, commit, and push it.

## Here comes the YAML

Now, we aren’t bad people, so the most minimal thing that would deploy isn’t that complex.

`.upsun/config.yaml`

```Javascript
applications:
 app:
   type: nodejs:20
```

It won’t do much though. You can push this and you’ll have a container running in the ether. But it won’t be serving any http requests. To have some joy you would add:

`.upsun/config.yaml`

```Javascript
applications:
 app:
   type: nodejs:20
   web:
       locations:
         '/':
           index:
           - index.html
```

Voilà. If you have an index.html at the root of your repo, when pushing it to Upsun, you’ll get a URL back. It’ll be live. And everything will be dandy. By the way, if you’re _way too tired_ (I know I often am) to write YAML by hand, you could also use “upsun ify” and the CLI will generate one for you. As I said, we aren’t bad people.

From this little snippet, you can already figure out quite a bit. And possibly more about why we like explicitness.

-   Applications is a plural. \*
-   An application has an explicit name and an explicit type.

But you could ask. Why an explicit configuration? When you look at it, it’s simple. Can’t we figure this out? I mean “index.html” what could it be? “thingamebob.burp”?

This is about making things as simple as they could be, but no simpler.

-   If you don’t have an explicit runtime, either Node.js has to be locked at some ancient version or you risk breakage when it’s implicitly upgraded.
-   If you didn’t give the app a name, you wouldn’t be able to deploy a second one in the same environment. And you wouldn’t be able to have nifty routing rules for your multi-app/microservices setup.
-   And why a `locations` block? Maybe there could be one by default. Unclear. But then it would have to be the root of the repo. And it sounds like an unsafe default. We err on the side of caution. In earlier versions, you didn’t have default routes either. But it seemed reasonable enough to imagine that if all you deploy is a single app, you probably would like for it to have an ingress route.

There are defaults that are _actually_ set here. And you’d see _everything_ we set as defaults when you push the repo:

-   For example “As no routes configuration was detected, a single default route will be deployed.” If you had two apps, we’d error-out and force you to make a routing choice.
-   Or “Environment configuration: app (type: nodejs:20, cpu: 0.5, memory: 224)”

That’s the other side of the explicitness story. It’s often fine to make some reasonable choices. But it’s vital to give the user feedback on those. So you know you can override them.

There are even more choices you could make. The “locations” block is quite a beast. You can do URL rewriting there. Configure static asset caching. Control buffering and custom headers (best served with websocket routes). But that’s probably for day two of configuration. This is what _make the complex possible_ is about. When you have explicit configuration, you also have a way to override any default behavior. But you can also postpone complexity for when you will need it.

When all you need is simplicity, the configuration should be trivial. And, hopefully, the YAML above is not overwhelming.

But when you want to use the full power of the platform—run multiple apps with complex relationships between them, run a bunch of databases and message queues—we want that to be as simple as possible too. We need to strike a balance.

## Too simple now is too complex later

If you look at a service where deploying a single app requires no configuration at all, you will also discover that either it’s impossible, or difficult, to deploy multiple apps in a single command. You’ll discover that creating a consistent preview environment—that contains all of the data of all of the services—is either hard, or impossible. Sometimes the apparent simplicity of today is the horrendous complexity of tomorrow.

These design principles are our guiding lights. We try to adhere to them. Make everything as simple as it can be. But not simpler. Even if there is friction to pay. We always think about day two. About how we make things such as that we would never have to break BC. But these days we are still in Beta! So we are still allowed to make changes. And we’d love feedback on how you find our configuration format.

You can go to docs.upsun.com for a full, detailed description - and join our community to chat with us.

### [How to host a Symfony Demo application on Upsun | Upsun](https://upsun.com/blog/upsun-and-running-with-symfony-demo/)

# Up(sun) and running with Symfony Demo

Focus more on creating incredible user experiences and less on Symfony infrastructure management—as well as a few Symfony Demo development tips along the way—with this simple, two-step guide. Learn how to host and configure your Symfony Demo project on Upsun, and get up and running as smoothly as possible. 

## **How to start using Symfony Demo on Upsun** 

### **Create an Upsun-ready Symfony Demo**

Creating a new Symfony Demo application is simple. Use the following commands to get your Symfony Demo project Upsun-ready, and don’t forget to add `--upsun` option to your command to auto-configure your local project for our PaaS: 

```shell-session
symfony new my-symfony-app --demo --upsun
cd my-symfony-app
symfony server:start -d #optional
```

Please note: if you’re starting from an existing local Symfony project, you can generate the Upsun config by using the following command:

```

symfony project:init --upsun
```

The `--upsun` option generates an Upsun YAML configuration file—`.upsun/config.yaml`—to manage how your application behaves when deployed on Upsun. This YAML configuration file is located in an `.upsun/` folder, at the root of your source code, the architecture of which will look like this: 

```shell-session
my-symfony-app
├── .upsun
│   └── config.yaml
└── <project sources>
```

There are a few basic rules for Upsun configuration: 

1.  The YAML format is used for config files.
2.  The `**.upsun/**` folder, containing a `**config.yaml**` file, with routes, services, and application configuration shared across all applications, must stay at the root of your project.

Finally, for this step, you need to create an Upsun project using the Symfony CLI.

### **2\. Create an Upsun project and deploy**

The next step in setting up your Symfony Demo application on Upsun is to create a project that is simple to do via the Upsun CLI in your terminal. Use this command and follow the prompts to choose the name of your project, region, and many other options: 

```shell-session
symfony project:create
```

Please note: During project creation, you are asked if you want to set the local remote to your new project. Enter Yes (y). Your local source code is automatically linked to your newly created Upsun project by creating a `.upsun/local/project.yaml` file. This file will contain the corresponding `<projectId>` and set a Git remote to `upsun`.

Then, deploy your local code to your Upsun project by using the following command:

```shell-session
symfony deploy
```

When the deployment is complete, browse your website using your favorite browser by using the following command:

```shell-session
symfony environment:url
```

### **You’re all set!**

Hosting a Symfony application on Upsun has never been so easy—with just the 5 commands detailed above, you can be Up(sun) and running in no time. 

```shell-session
symfony new my-symfony-app --demo --upsun
cd my-symfony-app
symfony project:create
symfony deploy
symfony environment:url
```

Keep an eye out for an upcoming article from me on how to use FrankenPHP in this Symfony Demo application on Upsun - follow us on our social channels to stay up-to-date: Dev.to, Reddit, and our community forum. 

Want to learn more about restructuring Symfony code without messing with functionality? You can dive into the topic of refactoring monolith to multi-application code with me in this video tutorial.

### Watch this video

### [How to host multiple-application projects | Upsun](https://upsun.com/blog/upsun-and-running-with-multiple-applications/)

# Up(sun) and running with multiple applications

We’re here to shed a little light on **how you can host and configure your multiple application projects on Upsun** with this step-by-step guide. The goal is to enable your team to focus more on creating incredible user experiences and less on multi-application infrastructure management—as well as a few multi-application development tips along the way.

We’re going to look at this through the lens of a customer looking for multi-application hosting with a few specific constraints. These constraints are:

-   A backend using API Platform Admin component
-   A legacy frontend, hosting an API and a corporate frontend, developed with Symfony 6.2
-   A white label frontend developed with Gatsby, consuming the "Legacy" API
-   A Mercure Rocks server for marketing purposes (push notifications)
-   All customer sources on a public GitHub repo

## How to start hosting your multi-application project with Upsun

### Creating a fork of BigFoot multi-app repository

To be able to perform the following steps in this process, you first need to create your own repository—a Fork—using an Upsun example. To do so, simply follow the steps in this Github article to create a fork from our BigFoot multi-app project to your own Github organization. This Bigfoot multi-app project has a backend using API Platform, a frontend+API using Symfony, a white label frontend using Gatsby, and a Mercure Rocks server.

After creating your fork, clone it locally and open it in your favorite integrated development environment (IDE).

```shell-session
git clone https://github.com/<YourOrgName>/upsun_multi-app-example bigfoot-multiapp
cd bigfoot-multiapp
```

Then remember to replace the **<YourOrgName>** value with your own Github organization.

**Please note**: For all of you impatient developers out there, you can skip ahead to find the final result of this tutorial in the final-version branch of this repository.

### Configure your project

To host your multi-application project on Upsun, a YAML configuration— `config.yaml`—is needed in your source code to manage the way your application behaves. This YAML configuration file is located in a `.upsun/` folder, at the root of your source code, the architecture of which will look like this:

```yaml
bigfoot-multiapp
├── .upsun
│   └── config.yaml
└── <project sources>
```

To configure your multi-application project, there are a few basic rules:

1.  YAML format is used for config files.
2.  The **.upsun/** folder, containing a **config.yaml** file, with routing, services, and application configuration shared across all applications needs to stay at the root of your project.
3.  Each app is located in a dedicated folder:
    -   **admin:** API Platform Admin component
    -   **api:** BigFoot API and default frontend
    -   **gatsby:** Gatsby frontend
    -   **mercure:** Mercure Rocks Server

**Please note**: Individual application's source code can live in separate repositories that are pulled together using Git Submodules. Another blog post is coming that will cover this subject in depth so stay tuned.

Upsun YAML configuration is located in the `.upsun/` folder and can be automatically populated using the `upsun project:init` command, see below:

```yaml
├── .upsun
│   └── config.yaml
└── <project sources>
```

This command generated a `.upsun/config.yaml` file, based on your local stack, and it contains 3 top-level YAML keys:

-   `applications`: this contains the list of your application definition
-   `services`: this contains the list of your service definition
-   `routes`: this contains the list of your route definition

#### Create .upsun/config.yaml file

To configure your project, you first need to create a new `.upsun/config.yaml` file with the following first top-level YAML keys:

```yaml
# .upsun/config.yaml
applications:
services:
routes: 
```

Then commit your newly configured file:

```shell-session
git add .upsun/config.yaml
git commit -m "init Upsun configuration"
git push
```

Now, let’s configure our four applications one by one:

#### Configure the API application

First, we need to configure the `applications`’ top-level key with the behavior of our Symfony BigFoot application, named `api`.

```yaml
# .upsun/config.yaml
# Complete list of all available properties: https://docs.upsun.com/create-apps/app-reference.html
applications:
  # A unique name for the app
  api:
    # Information on the app's source code and operations that can be run on it.
    source:
      # The path where the app code lives. Defaults to the directory of the .upsun/config.yaml file. Useful for multi-app setups.
      root: api
    # The runtime the application uses.
    type: php:8.3
    # The relationships of the application with services or other applications.
    relationships:
      database: "database:postgresql"
    # Mounts define directories that are writable after the build is complete. If set as a local source, disk property is required.
    mounts:
      "/var/cache": { source: storage, source_path: files/cache  }
      "/var/log": { source: storage, source_path: files/log  }
      "/var/sessions": { source: storage, source_path: files/sessions  }
      "/data": { source: storage, source_path: files/data  }
    # The web key configures the web server running in front of your app.
    web:
      # Each key in locations is a path on your site with a leading /.
      locations:
        "/":
          root: "public"
          passthru: '/index.php'
          index:
            - index.php
          scripts: true
          allow: true
          headers:
            Access-Control-Allow-Origin: "*"
    # Variables to control the environment.
    variables:
      env:
        APP_ENV: 'prod'
      php:
        assert.active: off
        #opcache.preload: config/preload.php
    # Specifies a default set of build tasks to run. Flavors are language-specific.
    build:
      flavor: composer
    # Installs global dependencies as part of the build process.
    # Hooks allow you to customize your code/environment as the project moves through the build and deploy stages
    hooks:
      # The build hook is run after any build flavor.
      build: |
        set -x -e
        curl -s https://get.symfony.com/cloud/configurator | bash
        symfony-build
      # The deploy hook is run after the app container has been started, but before it has started accepting requests.
      deploy: |
        set -x -e
        symfony-deploy
    # Scheduled tasks for the app.
    crons:
      update-sighting:
        spec: '*/5 * * * *'
        cmd: './bin/console app:update-sighting-scores'
      security-check:
        # Check that no security issues have been found for PHP packages deployed in production
        # See https://github.com/fabpot/local-php-security-checker
        spec: '50 23 * * *'
        cmd: if [ "$PLATFORM_ENVIRONMENT_TYPE" = "production" ]; then croncape php-security-checker; fi
    # Customizations to your PHP or Lisp runtime.
    runtime:
      extensions: [ ctype, iconv, apcu, mbstring, sodium, xsl, pdo_pgsql ]
```

**Please note:** The Upsun config file is not in the same directory as your _**api**_ app sources, at the beginning of this config.yaml file, meaning we need to configure the `source.root` section with the corresponding _**api**_ directory.

You probably noticed that our `api` application has a relationship with a service called `database`, see the YAML configuration below. This means we need to declare this service `database`.

```yaml
applications:
  api:
    ...
    relationships:
      database: "database:postgresql"
```

Still, in the same `.upsun/config.yaml` file, let's define this service in the `services` top-level YAML key:

```yaml
# .upsun/config.yaml
applications:
  api: ...
# The services of the project.
#
# Each service listed will be deployed
# to power your Upsun project.
# More information: https://docs.upsun.com/add-services.html
# Full list of available services: https://docs.upsun.com/add-services.html#available-services
services:
  database:
    type: postgresql:15
```

Finally, we need to define the routing for our API application in the same `.upsun/config.yaml` file, to do so add the following:

```yaml
# .upsun/config.yaml
applications:
  api: …
services: …
routes:
  # BigFoot API
  https://{default}:
    type: upstream
    # the first part should be your project name
    upstream: "api:http"
    id: api
```

Then, we need to configure the environment variables, specific to Upsun for the **api** application. Please create an _**api/.environment**_ file. When present, this file will be sourced in the applications’ environment.

```shell-session
# api/.environment
export N_PREFIX=$HOME/.n
export PATH=$N_PREFIX/bin:$PATH

# Set dynamic CORS_ALLOW_ORIGIN for NelmioBundle
export CORS_ALLOW_ORIGIN=.*$(echo $PLATFORM_PROJECT)..*.platformsh.site
export TRUSTED_HOSTS=.*$(echo $PLATFORM_PROJECT)..*.platformsh.site
export TRUSTED_PROXIES=.*$(echo $PLATFORM_PROJECT)..*.platformsh.site

# Admin Site Name
export API_SITE_NAME="API Platform"

export APP_SECRET=$(echo $PLATFORM_PROJECT_ENTROPY)

# Mercure Rocks uri
export MERCURE_URL=$(echo $PLATFORM_ROUTES | base64 --decode | jq -r 'to_entries[] | select(.value.id == "mercure") | .key'| awk '{print substr($0, 0, length($0))}')
export MERCURE_PUBLIC_URL=$(echo $PLATFORM_ROUTES | base64 --decode | jq -r 'to_entries[] | select(.value.id == "mercure") | .key'| awk '{print substr($0, 0, length($0))}')
export MERCURE_PUBLISH_URL=$(echo $PLATFORM_ROUTES | base64 --decode | jq -r 'to_entries[] | select(.value.id == "mercure") | .key'| awk '{print substr($0, 0, length($0))}')

# The secret used to sign the JWTs
export MERCURE_JWT_SECRET="!ChangeThisMercureHubJWTSecretKey!"
```

**Please note**: as you can see, there is no need to add a `DATABASE_URL` environment variable as it is done in the **.env** file. The Symfony configurator automatically generates it, within your container, based on your database service definition.

You can then commit your configuration file to your Git repository:

```shell-session
git add .upsun/config.yaml api/.environment
git commit -m "adding api configuration for Upsun"
git push
```

#### Configure the Admin application

Secondly, we need to configure the `applications` top-level key with the behavior of our API Platform Admin component, named `admin`. To configure your admin application, add the `applications.admin` block in your `.upsun/config.yaml` file:

```yaml
# .upsun/config.yaml
applications:
  api: …
  # A unique name for the app
  admin:
    # Information on the app's source code and operations that can be run on it.
    source:
      # The path where the app code lives. Defaults to the directory of the .upsun/config.yaml file. Useful for multi-app setups.
      root: admin
    # The runtime the application uses.
    type: nodejs:20
    # How many resources to devote to the app. If not set, default to the predefined runtime definition.
    # For more information, please see https://docs.upsun.com/manage-resources/adjust-resources.html#advanced-container-profiles
    container_profile: BALANCED
    # Mounts define directories that are writable after the build is complete. If set as a local source, disk property is required.
    mounts:
      '/.tmp_platformsh': { source: "storage", source_path: "files/tmp_platformsh" }
      '/build': { source: "storage", source_path: "files/build" }
      '/.cache': { source: "storage", source_path: "files/.cache" }
      '/node_modules/.cache': { source: "storage", source_path: "files/node_modules/.cache" }
    # The web key configures the web server running in front of your app.
    web:
      # Each key in locations is a path on your site with a leading /.
      locations:
        "/admin":
          root: "build"
          passthru: "/admin/index.html"
          index:
            - "index.html"
          expires: 300s
          scripts: true
          allow: false
          rules:
            .(css|js|gif|jpe?g|png|ttf|eot|woff2?|otf|html|ico|svg?)$:
              allow: true
            ^/admin/robots.txt$:
              allow: true
            ^/admin/manifest.json$:
              allow: true
            ^/admin/_next:
              allow: true
            ^/admin/sitemap:
              allow: true
          headers:
            Access-Control-Allow-Origin: "*"
    # Variables to control the environment.
    variables:
      env:
        NODE_OPTIONS: '--max-old-space-size=1536'
    # Specifies a default set of build tasks to run. Flavors are language-specific.
    build:
      flavor: none
    # Hooks allow you to customize your code/environment as the project moves through the build and deploy stages
    hooks:
      # The build hook is run after any build flavor.
      build: |
        set -eu
        corepack yarn install --immutable --force
      # The post_deploy hook is run after the app container has been started and after it has started accepting requests.
      post_deploy: |
        corepack yarn build
```

**Please note:**

-   **Please note:** As the Upsun config file is not in the same directory as your _**admin**_ app sources, at the beginning of the **admin** configuration, we then need to configure the `source.root` section with the corresponding _**admin**_ directory.
-   We also need to define another container\_profile as the **Admin** app needs more RAM than defined in the default Node.js image container profile (`HIGH_CPU` by default, changed to `BALANCED`)

As you probably noticed, the `applications.admin.web.locations` is defined on `/admin`. This means that the **admin** will be reachable on `<defaultUrl>/admin`. We need to define the corresponding route in the same `.upsun/config.yaml` file, into the `routes` top-level YAML key:

```yaml
applications:
  api: ...
  admin: ... 
services: ...
routes:
  # BigFoot API
  https://{default}: …
 
  # API Platform Admin component
  https://{default}/admin:
    type: upstream
    # the first part should be your project name
    upstream: "admin:http"
    id: "admin"
    cache:
      cookies: [ '*' ]
      default_ttl: 0
      enabled: true
      headers: [ Accept, Accept-Language ]
    ssi:
      enabled: false
```

Then, we need to configure the environment variables, specific to Upsun for the **admin** application, which leverages the pre-installed tool jq. Please create an _**admin/.environment**_ file.

```yaml
# admin/.environment
export REACT_APP_PUBLIC_URL=$(echo $PLATFORM_ROUTES | base64 --decode | jq -r 'to_entries[] | select(.value.id == "api") | .key')api
export PUBLIC_URL=$(echo $PLATFORM_ROUTES | base64 --decode | jq -r 'to_entries[] | select(.value.id == "admin") | .key')

# Admin Site Name
export REACT_APP_ADMIN_SITE_NAME="Admin API Upsun"
```

You can then commit your configuration file to your Git repository:

```shell-session
git add .upsun/config.yaml admin/.environment
git commit -m "adding admin configuration for Upsun"
git push
```

#### Configure the Gatsby _application_

Thirdly, we need to configure the `applications'` top-level key with the behavior of our white label frontend—named `gatsby`—developed using the Gatsby stack.

```yaml
# .upsun/config.yaml
applications:
  api: ...
  admin: ...
  
  # A unique name for the app
  gatsby:
    # Information on the app's source code and operations that can be run on it.
    source:
      # The path where the app code lives. Defaults to the directory of the .upsun/config.yaml file. Useful for multi-app setups.
      root: gatsby
    # The runtime the application uses.
    type: 'nodejs:20'
    # How many resources to devote to the app. If not set, default to the predefined runtime definition.
    # For more information, please see https://docs.upsun.com/manage-resources/adjust-resources.html#advanced-container-profiles
    container_profile: BALANCED

    # Mounts define directories that are writable after the build is complete. If set as a local source, disk property is required.
    mounts:
      '/.cache': { source: "storage", source_path: "cache" }
      '/.config': { source: "storage", source_path: "config" }
      '/public': { source: "storage", source_path: "public" }
    # The web key configures the web server running in front of your app.
    web:
      # Each key in locations is a path on your site with a leading /.
      locations:
        '/site':
          root: 'public'
          index: [ 'index.html' ]
          scripts: false
          allow: true
    # Variables to control the environment.
    variables:
      env:
       NODE_OPTIONS: --max-old-space-size=1536
    # Specifies a default set of build tasks to run. Flavors are language-specific.
    build:
      flavor: none
    # Installs global dependencies as part of the build process.
    dependencies:
      nodejs:
        yarn: "1.22.17"
   # Hooks allow you to customize your code/environment as the project moves through the build and deploy stages
    hooks:
      # The build hook is run after any build flavor.
      build: |
        set -e
        yarn --frozen-lockfile
      # The post_deploy hook is run after the app container has been started and after it has started accepting requests.
      post_deploy: |
        yarn build --prefix-paths
```

**Please note:**

-   As the Upsun config file is not in the same directory as our **Gatsby** app source code, at the beginning of the **Gatsby** configuration, we then need to configure the `source.root` section with the corresponding **Gatsby** directory.
-   We also need to define another container\_profile as the **Gatsby** app needs more RAM than defined in the default image container profile (`HIGH_CPU` by default, changed to `BALANCED`)

As you probably noticed, the `applications.gatsby.web.locations` is defined on `/site`. This means that the Gatsby will be reachable on `<defaultUrl>/site` and we need to define the corresponding route in the same `.upsun/config.yaml` file, into the `routes` top-level YAML key:

```yaml
applications:
  api: ...
  admin: ... 
services:
  ...
routes:
  # BigFoot API
  https://{default}: ... 
  # API Platform Admin component
  https://{default}/admin: ...

  # Gatsby App
  https://{default}/site:
    type: upstream
    # the first part should be your project name
    upstream: "gatsby:http"
```

The `gatsby` app is consuming our BigFoot **api** REST API. If you look at the `gatsby` source code, in the `gatsby/gatsby-config.js` file, you’ll find the route to your `api` app by using `process.env.PLATFORM_ROUTES` meaning we don’t need a `gatsby/.environment` file to find this route. You can then commit your configuration file to your Git repository:

```shell-session
git add .upsun/config.yaml 
git commit -m "adding gatsby configuration for Upsun"
git push
```

#### Configure the Mercure _application_

The API Platform Admin component, made by Les Tilleuls, communicates with a Mercure.rocks server—a GO stack used for real-time push communication. We need to configure the `applications` top-level key with the behavior of a standalone Mercure.rocks server, named `mercure`.

```yaml
# .upsun/config.yaml
applications:
  api: ...
  admin: ...
  gatsby: ...
 
  # A unique name for the app
  mercure:
    # Information on the app's source code and operations that can be run on it.
    source:
      # The path where the app code lives. Defaults to the directory of the .upsun/config.yaml file. Useful for multi-app setups.
      root: mercure/.config
    # The runtime the application uses.
    type: golang:1.21
    # Mounts define directories that are writable after the build is complete. If set as a local source, disk property is required.
    mounts:
      "database": { source: "storage", source_path: "database" }
      "/.local": { source: "storage", source_path: ".local" }
      "/.config": { source: "storage", source_path: ".config" }
    # The web key configures the web server running in front of your app.
    web:
      # Commands are run once after deployment to start the application process.
      commands:
        # The command to launch your app. If it terminates, it's restarted immediately.
        start: ./mercure run --config Caddyfile.upsun
    # Each key in locations is a path on your site with a leading /.
    locations:
      /:
        passthru: true
        scripts: false
        allow: true
        request_buffering:
          enabled: false
        headers:
          Access-Control-Allow-Origin: "*"
    # Variables to control the environment.
    variables:
      env:
        MERCUREVERSION: 0.14.4
        SERVER_NAME: ":8888"
        MERCURE_TRANSPORT_URL: "bolt:///var/run/mercure.db?size=1000&cleanup_frequency=0.5"
        MERCURE_EXTRA_DIRECTIVES: |
          cors_origin *
          publish_origins *
          subscriptions
          demo
        GLOBAL_OPTIONS: |
          auto_https off
        MERCURE_PUBLISHER_JWT_KEY: "!ChangeThisMercureHubJWTSecretKey!"
        MERCURE_SUBSCRIBER_JWT_KEY: "!ChangeThisMercureHubJWTSecretKey!"
    # Specifies a default set of build tasks to run. Flavors are language-specific.
    build:
      flavor: none
    # Hooks allow you to customize your code/environment as the project moves through the build and deploy stages
    hooks:
      # The build hook is run after any build flavor.
      build: |
        # Install Mercure using cache
        FILE="mercure_${MERCUREVERSION}_Linux_x86_64.tar.gz"
        if [ ! -f "$PLATFORM_CACHE_DIR/$FILE" ]; then
          URL="https://github.com/dunglas/mercure/releases/download/v${MERCUREVERSION}/$FILE"
          wget -O "$PLATFORM_CACHE_DIR/$FILE" $URL
       else
         echo "Found $FILE in cache, using cache"
       fi
       file $PLATFORM_CACHE_DIR/$FILE
       tar xvzf $PLATFORM_CACHE_DIR/$FILE
```

**Please note:** as the Upsun config file is not in the same directory as our Mercure app source code, at the beginning of the Mercure configuration, we then need to configure the `source.root` section with the corresponding Mercure directory, pointing to the `.config` folder.

For the Mercure app routing, we will use a sub\\domain of the default URL of your environment (to complete the discovery of Upsun routing). This means that the Mercure app will be reachable on `mercure.<defaultUrl>`.

So, we need to define the corresponding route in the same `.upsun/config.yaml` file, into the `routes` top-level YAML key:

```yaml
applications:
  api: ...
  admin: ... 
  gatsby: ... 
  mercure: ... 
services: ...
routes:
  # BigFoot API
  https://{default}: ... 
  # API Platform Admin component
  https://{default}/admin: ...
  # Gatsby App
  https://{default}/site: ...
 
  # Mercure Rocks app
  https://mercure.{default}:
    type: upstream
    # the first part should be your project name
    upstream: "mercure:http"
    cache:
      enabled: false
```

You can then commit your configuration file to your Git repository:

```shell-session
git add .upsun/config.yaml 
git commit -m "adding mercure configuration for Upsun"
git push
```

Et voilà, your project is ready to be pushed to Upsun! You can check out the final result of a `.upsun/config.yaml` file here for reference.

## Create an Upsun project

The next step in setting up this multi-app project on Upsun is to create a project that is simple to do via the Console. On your Console homepage (all projects), in the top right corner, please click on the **create project** button, as seen below:

If you do not already have an organization created to put the project into, you’ll first be instructed to create one. Once you have done so, select that organization from the dropdown, and then select **Sync Your GitHub Repo with Upsun**, as seen in the screen below:

Then select **connect with GitHub** from the options provided as seen here:

In the next form that appears as seen in the screen below, select your GitHub organization from the first dropdown and then select **install and authorize** and fill out the GitHub credentials. You will need to select your GitHub organization and previously created GitHub repository and the production branch and select **continue**.

You will then be taken to step three of this setup—as seen below—where you will fill in various details including project name, environment name, and region. Once you’ve done so, select **create project**.

**Please note:** you can access a 3% discount for any project hosted on Upsun when you choose one of six, incentive-eligible, greener data-center regions that have a grid carbon intensity score of less than 100 g CO2eq/KWh. Learn more.

On the next page, while the project creation process is ongoing in the background, you will see on the left some further setup instructions, if you need them. On the right, you can follow the project creation process and you will be informed when it is complete, as seen in the screen below:

Once your project has been created, the GitHub integration process will automatically deploy your application based on your GitHub repository source code. Wait for the integration to finish deployment and it will then display your application information which you can see an example of in the screen below:

## Time to deploy, right?

And just like that, it’s time to deploy! But wait…

As you already ensured your source code was Upsun-ready in the project configuration section of this guide, **your project will have been automatically deployed during project creation and your application will already be live**, with no deployment needed. Check out your new project URL at the bottom of the console interface.

The next step is to access your project console by clicking on the **view project** button at the bottom of the setup page, et voilà, your multiple application project is live and you can start playing around with it and adding lots of cool new features!

**Please note**: For now, the **API** database hasn’t been initialized yet, you will need to **populate the data** for your application to be fully working. We will do it in a later step.

## Set a remote to your Upsun project

To ease interaction from your terminal with your Upsun project, you need to set a remote using this CLI command:

```shell-session
upsun project:set-remote <projectID>
```

**Please note**: your `<projectID>` can be found in the console interface of your project, or by finding it in your project list, as shown below:

```shell-session
upsun project:list
```

## Populate the data

The Bigfoot app (API app) contains fixtures that could be populated into the database. To do so, complete the following commands:

```shell-session
upsun ssh --app=api "php bin/console d:s:u --dump-sql --force"
upsun ssh --app=api "php bin/console d:f:load -e dev"
```

## View the deployed sites

Your multiple applications project is now live and you should test it. To open one of your websites, you can either use the Console interface or use the following CLI command and then choose one of the listed routes:

```shell-session
upsun environment:url
```

## Create a staging environment

To create a new environment on our project, we need to create a new Git branch, push it to the Github repository, and then the Github integration process will automatically create the environment. To do so, complete the following commands:

```shell-session
git checkout -b staging
git push --set-upstream origin staging
```

Remember that each time you create and push a new Git branch, GitHub integration generates a new inactive environment within your Upsun project. As the environment is inactive by default, you need to activate it to deploy it by doing the following:

```shell-session
upsun environment:info type staging
upsun environment:activate staging
```

**Please note:** With Upsun, you are only charged for your activated environments. So, be sure to activate your environment when you’re ready to test it.

## Create a dev environment

Now it’s time to create a new dev environment by creating a new Git branch from the staging environment by doing the following:

```shell-session
git checkout -b dev
git push --set-upstream origin dev
```

Remember that each time you create and push a new Git branch, GitHub integration generates a new inactive environment within your Upsun project. As the environment is inactive by default, you need to activate it to deploy it:

```shell-session
upsun environment:info type development
upsun environment:activate dev
```

And the Git guides don’t stop there, stay tuned for our next article on Git submodules coming very soon. Remain up-to-date on the latest from us over on our social media and community channels: Dev.to, Reddit, and our Community.

### [Chapter 3: Upsun and the decades of the open web | Upsun](https://upsun.com/blog/chapter-3-upsun-and-the-decades-of-the-open-web/)

# Chapter 3: Upsun and the decades of the open web

In the first chapter of this series, I touched on the pendulum of the open web: the desire to leverage the economies of scale of Infrastructure-as-a-Service (IaaS) providers but avoid vendor-lock-in as much as possible. In the second chapter, I dove into the history of the web and how the technologies and methodologies have evolved to lead us to where we are today, and why Upsun was created.

In this chapter, I will discuss how 2023 and 2024 are recognized as pivotal years for the web as after a decade of slow and steady growth, machine-learning techniques are becoming pervasive. A topic which we want to delve a little deeper into this third and final chapter of our decades of the web series—let’s talk artificial intelligence!

## Open source as we know it is changing

If we accept the idea that organizations today cannot be separated from their digital infrastructure, as discussed in chapter 1 of this series. We can also see that the digital infrastructure and its relationship to open source is changing in a very significant way at the moment with the rise of artificial intelligence (AI).

In today’s context, we already know some tasks—many of which are already outsourced to low-value engineering forces—will soon be mostly replaced by some forms of AI-assisted software development. However, we have yet to have any level of understanding on how this plays out through a complete five-to-ten-year cycle. Especially in terms of the forms of investment AI will require in terms of maintenance, security, and scaling.

Some argue the rise of AI-assisted software could lead to the role of the software developer being reduced in the coming years. While outsourcing through Software-as-a-service (SaaS) offerings and APIs alongside the pervasiveness of AI will replace many traditional software development tasks within low-code or no-code frameworks. However, this is an improbable outcome in my opinion. In the long term, there will very likely not be fewer people producing code nor fewer people maintaining jobs around the creation and management of code. Instead, the nature of the code will somewhat change as will the nature of processes around bringing software from idea to production.

## The IT cycle: how our technologies have changed

Throughout the history of the internet, we have witnessed the cyclic nature of the IT world. With moments of great creativity and great chaos occurring as new technologies disrupt the old. But this doesn’t happen within one, single cycle. There are multiple, overlapping movements happening across various levels of the production cycle, over multiple dimensions of technology and organizational structures, all influencing how those cycles take place.

Sometimes the strongest movements happen in the actual programming languages landscape. We have seen that first with PHP, then Javascript, then Ruby, followed by Python as dynamic languages ruled the web for the first two decades of its existence. The enterprise mostly stayed on compiled languages with the world mostly split between Java and .NET stacks.

Other times movement happens at the architectural level. We saw this first with start-of-the-century, service-oriented architectures (SOA) then with the microservices movement, and now with the Lambda/serverless approaches. We also saw this with data stores, from the monolithic central Oracle to the explosion of purpose-built stores—such as ElasticSearch, Redis, InfluxDB, and Graph database—to using Postgres for everything.

And now we’re witnessing movement at the meta-infrastructure level with so-called _platform engineering_. Posing the question: how do you select, implement, and manage the tools that manage the tools that run the actual useful workloads?

The continuum goes from creative and dispersed, to standardized control. Each time the pendulum on any of the dimensions of IT swings too far one way or the other, we either get out-of-control costs and loss of quality, or stagnation and inefficiency, each yielding their own cost inefficiencies.

## The next phase in the cycle: a flexible, self-service PaaS

Upsun tries to be a proposition for an equilibrium. Instead of investing a huge amount of time and money in building the bureaucracy and tooling that would possibly allow you to make modest gains in productivity, Upsun allows you to go for the end result immediately. You accept some constraints and some choices—and some of those choices might be challenging. We can automate and run most workloads, not all of them. But you don’t have to make compromises on the blockers: security and compliance. With flexible resource allocation, instant preview environments, and observability among a variety of robust features, you can get to that end result with more flexibility, efficiency, and collaboration for your team.

Machine learning-assisted coding is happening and it is changing how software gets created. It is also going to very likely change some of our assumptions about the place of open source: something is going to be commoditized.

If you bet on the cycle we are in to be one of creativity it makes sense not to spend time on Infra, neither in the development cycle nor in the production cycle. This is a bet on the idea that our domain is going to traverse some very interesting chapters, not a moment to lock yourself in.

### [What is an IDP and can a PaaS be the solution?  | Upsun](https://upsun.com/blog/what-is-an-idp-and-can-a-paas-be-a-solution/)

# What is an IDP and can a PaaS be the solution?

Imagine a world where developers can focus on their code, not the complexities of infrastructure—that's the power of an Internal Developer Platform (IDP). IDPs are transforming software development, boosting efficiency, and unleashing developer creativity. And the best part is—you don’t need to build your own.

## Ok, but what’s an IDP?

An IDP is a single system that integrates various technologies and tools, enabling a streamlined workflow that enhances developer productivity and simplifies complex processes. IDPs are understood easiest through their three key components:

-   **Internal**: the platform is designed for use within an organization. It's crafted by platform engineering teams to specifically cater to the unique workflow needs and technological environments of their internal development teams.
-   **Developer**: the primary users of the platform are software development teams. The IDP is geared towards facilitating their work, enabling self-service, and reducing the mental overhead involved in handling complex technology stacks.
-   **Platform**: it serves as a comprehensive foundation integrating various technologies and tools. This platform is treated as a product by the engineering teams, who develop and maintain it based on user research and feedback, ensuring its continuous evolution and alignment with developer needs.

## The rise of IDPs

The rise of IDPs marks a pivotal moment in software development. As the complexities and demands of building and deploying software escalate, IDPs are becoming increasingly essential for streamlining processes and enhancing productivity within development teams. Let's delve into the reasons behind this growing trend and the advantages IDPs bring to the table:

1\. **Handling complexity and cognitive load**: in software engineering, the need to manage architecture, abstractions, and implementation details can place a heavy cognitive load on team members. IDPs help compartmentalize this complexity, allowing developers to focus on what's critical to their role, without being bogged down by the intricacies of the entire system.

**2\. Providing necessary abstractions**: IDPs serve as the bridge connecting multidisciplinary teams working on the same project. They effectively make infrastructure an implementation detail for developers, allowing them to remain focused on their core development tasks. Conversely, for operations teams, the software running on that infrastructure becomes an implementation detail, streamlining their workflow as platform engineering teams don’t have to cater to application-specific needs. This mutual abstraction promotes a more efficient working environment courtesy of this agnostic approach.

3\. **Key benefits and impacts for organizations**: improvements in infrastructure and IT management, increased productivity due to reduced communication times between development and infrastructure teams, and granular user management—see _collaboration_ below—in larger organizations are some of the key benefits of IDPs. Key reported impacts include a marked increase in development velocity, improved productivity, system reliability, and enhanced security.

4\. **Key features of IDPs**: IDPs integrate seamlessly with existing tools and services, including source control systems, CI/CD pipelines, and monitoring tools. This integration enables effective application and infrastructure management, automated deployment processes, and management of multiple environments. Moreover, they offer developer self-service capabilities, empowering developers to access tools and resources on demand, which facilitates faster development cycles and reduces dependency on operations teams.

5\. **Collaboration and governance**: IDPs enhance security and compliance by providing role-based access controls (RBAC), ensuring appropriate permissions for team members, and minimizing risks. They also support collaboration among cross-functional teams and maintain transparency and accountability throughout the development process, which is vital for issue resolution and compliance with regulatory requirements.

The rise of IDPs is a response to the growing challenges in software development, driven by the complexity of modern software architectures and the need for more efficient DevOps practices. IDPs offer a comprehensive solution that caters to the needs of both developers and platform teams, fostering a collaborative environment that enhances productivity, security, and compliance. As digital transformation continues to reshape the business landscape, the role of IDPs in enabling agile and responsive software development becomes increasingly vital.

## Upsun as an IDP

Upsun, powered by Platform.sh, builds off a decade of expertise to deliver a single, fully managed, self-service PaaS empowering development teams to securely and easily experiment, quickly iterate, and confidently deploy applications at scale.

If we revisit the five factors mentioned above, they closely match the reasons for Upsun’s creation, and highlight Upsun as a strong IDP solution:

1\. **Handling complexity and cognitive load**: Upsun reduces complexity in deployments, aligning with IDPs' goal to manage complexities and reduce cognitive load. Its self-service capability allows developers to focus on development rather than infrastructure management.

2\. **Providing necessary abstractions**: the ability to clone production environments provides necessary abstractions, once again enabling developers to focus on coding rather than underlying infrastructure, mirroring IDPs' purpose.

3\. **Key benefits and impacts for organizations:** Upsun’s self-service capabilities reduce communication between developers and platform teams to virtually zero. Its built-in security and compliance, its reliability, and its collaboration features complete the overall benefits brought to an organization.

4\. **Key features of IDPs**: Upsun has all the features expected from an IDP and more, including self-service production environments, built-in CI/CD, monitoring tools, and more. Not to mention the ability to integrate with external services that provide and/or extend the same functionality.

5\. **Collaboration and governance**: once again, Upsun’s security and compliance fulfills a wide range of requirements often desired within an IDP. Our PaaS also provides advanced user management and collaboration enabling cross-functional teams to work easily on the same project with Upsun.

The additional benefits of Upsun—explicit resource allocation, usage-based pricing model, and a comprehensive observability suite—included by default in all projects, amongst many other things, then help to complete the picture for a stellar IDP solution.

## A decade of IDP pioneering

The pain points that thousands of development teams experience today were experienced by our Platform.sh founders over 10 years ago, and led them to set out to solve them with our original core PaaS product, Platform.sh, and now with Upsun.

What Platform.sh and Upsun do for many development teams and agencies around the world is solve the very same problems an IDP sets out to solve—just without the hassle of strategizing, planning, building, and maintaining an entire IDP.

By design, an IDP provides environments and tools for software development and deployment, which is exactly what Upsun provides. The main difference lies in their focus and scope. An IDP primarily—even solely—caters to internal development and is not preoccupied with providing enterprise-ready production hosting. Upsun, instead, fulfills all the requirements of an IDP but it goes further by including production hosting in a single, unified solution.

The flexible, expert design of our product means that it can serve both purposes with ease. In fact, in many instances, organizations will recognize the value of two products in one and will realize that they will be able to streamline their processes even further. They will not need to preoccupy themselves with deploying production-ready artifacts to a whole different set of servers and platforms, using different pipelines and processes, but they could leverage the same platform used by their internal development team to ship their feature to production with the click of a button.

## Upsun, a powerful IDP solution

IDPs are reshaping software development, empowering organizations to tackle complexity, boost developer productivity, and deliver innovation at speed. Upsun embodies these ideals, acting as a powerful IDP solution that also offers seamless production hosting capabilities. Its comprehensive set of features and focus on streamlining the entire development lifecycle uniquely positions Upsun to support organizations on their digital transformation journey.

The advantages of IDPs and platforms like Upsun are clear. If you're seeking to optimize your software development processes, supercharge efficiency, and elevate developer satisfaction, it's time to explore the world of Internal Developer Platforms.

Discover the transformative potential of Upsun firsthand—start your free trial today.

## Stay tuned

In the next installment of this series, we’ll be exploring how to overcome operational challenges with IDPs and Upsun! Stay tuned.

### [Achieve GDPR compliance: a GDPR everywhere approach | Upsun](https://upsun.com/blog/gdpr-compliance-everywhere/)

# Adopt a GDPR everywhere strategy

**Navigating GDPR compliance in a complex landscape**

Companies used to have an easier time complying with regulations, but compliance has really never been a straightforward endeavor. In the past, there was one set of rules for businesses to obey, the local rules in the place where companies do business. If the business expanded into new parts of the world, it would have to comply with new rules, but these would apply only to those new territories

The global economy means an end to this approach. Companies hoping to grow can no longer stay siloed in their states, regions, and countries, and need to abide by regulations beyond their borders. Whether it’s a company in Indiana hiring remote workers in Scotland, or one in Dundee hiring a contact center in India.

It’s especially true of data privacy laws, thanks to the ease of moving data between different regulatory regions, sometimes without realizing it. With the cloud, companies can have servers anywhere, but if they don’t take good care, data can end up being stored in or transmitted through parts of the world with different regulations, and compliance efforts may have been wasted.

Plus, every country’s regulatory body has its own ideas about how far it should go in protecting its citizens and what that means for businesses collecting and processing data. Making life easier for businesses comes second to protecting privacy— but it does mean businesses have to make sure they are following the rules wherever they store, collect, or process data.

This combination of cloud services and a patchwork of shifting regulations means that it would seem impossible to work with data and meet every demand for data privacy. But there’s a way to make compliance easier again—if not easy.

## Cut the Gordian Knot of GDPR regulation

Companies don’t have to boil the ocean when it comes to GDPR adoption and compliance. Don’t overthink and overdo projects if it’s possible to simplify and spend less time on something that covers all the requirements.

With privacy, it’s the exact opposite. Make data privacy a core value for all businesses this year for one big reason: consumers and businesses have become more aware of how their data can get used and misused and this increasingly informs their decisions to share it or not. It’s easy to dismiss these concerns, but consumers are more aware of these issues than one might assume.

So, if not boil the ocean, then businesses at least may want to raise the temperature enough that it’s comfortable to go for a swim everywhere.

## GDPR: the highest data privacy standard

GDPR has become the highest standard of data privacy law in the world, and the majority was codified into the international standard ISO 27701. The EU takes GDPR compliance so seriously that in 2020 the Schrems II judgment invalidated the Privacy Shield, the international agreement that allowed companies to export data to the U.S.—under GDPR transfers outside of the EU are prohibited unless adequate safeguards are provided.

By adopting the standards of GDPR, no matter where a company holds or processes data —a.k.a a _GDPR everywhere_ strategic businesses know that they are meeting a very high standard and can boast about maintaining these standards where rivals can’t. And, as GDPR gets used as a template for other countries adopting data privacy laws, it becomes easier to look at how these new laws differ and change appropriately. Mostly, it requires minimal to no change.

## GDPR compliance: a universal approach

What does this GDPR compliance strategy look like? Consider GDPR a worldwide standard and enforce it internally, for every company group, every country, and every applicable process. Meeting this higher standard means easily meeting all new standards cropping up—and it also means more efficiency and fewer mistakes, thanks to one universal approach and process.

GDPR may not fit all situations and companies may need to use a vendor that does not comply. An example: a vendor in the U.S. processes only U.S. personal data. Technically there’s no need for GDPR standards here, but not enforcing it means missing out on building consumer and client trust. Making exceptions means creating a new process to learn and can convey that privacy is not a priority. But if it’s absolutely necessary to use a non-GDPR-compliant vendor, document everything. Create a supplemental measure assessment, do a full privacy and security review on the vendor, set plans in motion to replace the vendor with a compliant one, and obtain a written executive risk exception sign-off. Consider this last piece an important documentation trail that proves a business acknowledges and accepts the risk because using the vendor is more critical than a breach.

Once a business has adopted a GDPR everywhere approach, it shouldn’t stop there. It’s important to look at the trends. Are there new regulatory requirements in countries where the company doesn’t yet do business? Choose to opt-in! By staying not just up-to-date with regulations, but ahead of them, businesses can turn privacy compliance into not just a way of following the rules, but a differentiator to boast about.

## GDPR everywhere: Upsun’s data privacy commitment

Upsun adopts this ‘GDPR everywhere’ approach to ensure that our data privacy practices are consistent and unified for all of our customers across the world. Visit our features page for more details on Upsun PaaS security and compliance.

Article originally published by Joey Stanford on SC Media.

#### Useful links:

-   Security and compliance

### [Will AI replace developers? Why human-led coding still matters](https://upsun.com/blog/why-ai-wont-replace-developers/)

# Why AI won't replace developers—but it has changed the industry

## My journey back into development—thanks to AI and a few mimosas

I originally learned the core fundamentals of development back in 2002 in college. However, after graduating, I drifted away from coding and didn't touch it again until about two years ago. One day, after I had a couple of mimosas, I had an idea for an app. Having recently played around with ChatGPT, I felt bold enough to dive in.   
I only had experience with HTML and CSS.  So when I asked the AI which language I should use, it recommended Python.  There was no looking back from there. After a week of working with AI, I had a functioning app running locally on my machine. 

But that’s when both the AI and I hit a wall: deploying it to a production environment. Neither of us could figure it out, and it took the help of a few developer friends to finally get the app live…at which point it quickly broke. It couldn’t scale.  It didn’t have an access limitation.  It didn’t even have a database and instead used the browser cache to store everything.  It was only an app in the simplest of terms.

Since then, I’ve grown in my abilities to use AI to create web applications.  I’ve built several other apps using Flask, Django, Laravel, React, Next.js, Hugo and even Go—all without deeply learning any of those languages/frameworks. Over time, I graduated from copy-pasting in and out of ChatGPT to using more advanced tools like Copilot and Cursor and even experimenting with local AI models on my computer.

But here’s the biggest lesson I’ve learned from this experience: AI is still just that—artificial intelligence. The only reason I’ve been able to create the apps I have is because of the help of my extremely experienced developer friends and the problem-solving foundation I built back in college. My understanding of core programming concepts like functions, variables, loops, data structures, control flow, algorithms, operations, and networking allows me to give the AI precise instructions. When I don’t guide it carefully, the AI can go completely off the rails, producing either something overly complicated or something far too simple.

I still have to hold the AI’s hand every step of the way.

## AI is not coming for every developers' job—just the bad ones

AI development tools are evolving at a rapid pace. Today, platforms that integrate AI agents promise the ability to build fully functional apps without writing a single line of code. And from experience, I can say—yes, it's possible. But only with a lot of human oversight.

This is the paradox of AI in software development: while AI makes development faster and more efficient, it still relies heavily on human intelligence to guide the process. Developers aren’t going away anytime soon—but the role of developers is changing, and in some cases, those changes will mean the end of the road for certain types of developers.

Let’s dive into why this is happening.  
 

### Building with AI still requires real intelligence

No-code app-building with AI is often marketed as a hands-free experience. The reality is far from it. Even with AI agents designed to automate tasks, I still have to build my apps piece by piece, steering the AI every step of the way. For each challenge I encounter, I can’t rely on the AI to "magically" solve the problem. Instead, I have to figure out the solution and then articulate my instructions clearly.

This resonates with my own experience. When I first deployed that Python app, the AI wasn’t capable of managing the production launch without outside help. While it excels at generating code and automating tasks, AI lacks creativity and problem-solving skills. 

It can’t understand context the way humans do. AI works best when given clear directions—but coming up with those directions still requires a developer with deep domain knowledge.

This reveals one of AI's key limitations: it's only as good as the person guiding it.

### Here’s an example for the skeptics at the back of the room

A recent experience I had with AI development involved creating my first command-line interface (CLI) app in Go—another language I had never used before. The goal of the app was to help migrate a Hugo site from one theme to another, where the syntax and shortcodes were completely different.

One particular conversion involved taking guide buttons, which were handled by a shortcode at the bottom of pages, and moving that information to two fields, prev: and next:, in the front matter.

If you listen to some AI influencers, you might think you could solve this problem with a simple prompt: "Create a conversion that changes the guide button shortcodes to prev: and next: fields in the front matter." Easy peasy lemon squeezy, right?

That’s exactly what I tried, because sometimes the simplest prompt is the best. You don’t always need to spend hours on complex prompt engineering to get results. And when things break, I’ve learned a lot through the process of "breaking things fast." But in this case, it didn’t work out that easily.

I had to guide the AI step by step through building out the code. The process looked something like this:

1.  Create a function to extract the next page route from the guide button shortcode and store it.
2.  Create another function to add the next: field to the front matter with that route.
3.  Develop a function to extract the base route for the directory.
4.  Write a function to determine the weight of all pages in the directory, allowing the app to figure out which page comes before the current one. (The previous guide button had relied on the browser's back button, which was not a good solution.)
5.  Add a function to insert the prev: field with the determined route.
6.  Finally, create a function to remove the old guide button shortcode from the page content.

Without clear, iterative guidance, the AI couldn’t produce a fully functional solution. It would consistently miss pieces to the puzzle or produce code that didn’t work. It required me to break down the task, define the logic, and ensure each function did what it was supposed to.

No-code app-building with AI is often marketed as a hands-free experience. The reality is far from it. Even with AI agents designed to automate tasks, I still have to build my apps piece by piece, steering the AI every step of the way. For each challenge I encounter, I can’t rely on the AI to "magically" solve the problem. Most of the time, I have to figure out the solution and then articulate my instructions clearly.

### What AI will actually replace: junior and bad developers

If you’re worried about AI "stealing" developer jobs, you’re not wrong. But here’s the truth: AI won’t replace all developers—just inexperienced or underperforming ones.

Junior developers, especially those with no industry experience, are at risk. Companies may prefer to use AI as a cheaper alternative for tasks that would normally be handled by an entry-level developer. Similarly, bad developers—those who struggle with problem-solving and critical thinking—won’t be able to keep up in a world where AI handles routine coding tasks. 

Problem-solving, not coding ability, is becoming the most valuable skill in software development.

My own success with AI-driven development is proof of this. Because of my foundational knowledge in development, I can troubleshoot, guide the AI, and avoid pitfalls. Without those problem-solving skills, I would have been stuck at step one.

Lastly, developers who refuse to embrace AI may face challenges too. Like any other major technology shift, those who adapt to AI tools early will have a competitive edge. Developers who ignore these tools risk falling behind their peers who use AI to accelerate their productivity.

## Developers see past the AI hype

There's a reason so many developers are skeptical of AI. We've all seen the flashy demos of AI generating apps in seconds, but those demos are deceptive. They're designed to show off AI’s potential, not its limitations.

In reality, the fully developed AI-hype-train-generated apps are usually simplistic and disconnected from real-world development. They lack the scalability, security, and maintainability required for production-ready software. AI can assist with certain aspects of development—like generating code or automating tests—but without a developer to direct it, the end result is often a fragile, half-baked solution.

Developers understand this because they know how complex production software really is. Developers aren’t just creating simple todo apps or landing pages which sometimes tends to be the example used for AI development. Most developers work on projects for months or even years building it one function at a time.  Each function and variable is a complex web of multiple variables that involves multiple people working on it from various angles.  

Building an app isn't just about generating code; it's about designing reliable customer experiences, on scalable architecture, handling edge cases, ensuring security, managing integrations, and maintaining performance.  Managing all these variables and their relationships falls outside of the capabilities of current AI models (yes even DeepSeek and OpenAi o1) These management of so many variables is where AI still falls short for the time being.

## Advice for business leaders: Don't fall for the hype

If you're a business leader contemplating whether AI can replace your development team, you need to take a step back and avoid getting swept up by the hype. AI can certainly assist with development tasks, but it's not capable of fully managing the end-to-end process of creating robust, production-ready software.

If app development is a core function of your business, you need skilled developers to steer the ship. AI lacks the creative problem-solving and complete contextual understanding that human developers bring to the table. 

On the other hand, if all you need is a basic, static website, AI can probably handle that. But don't expect anything groundbreaking. The result will likely be a cookie-cutter solution—like the cheap, identical homes in a property development. Functional, sure. But generic, uninspired, and easy to spot as a low-effort build.  It will look like every other site on the internet, because that is where the AI learned to make those kinds of websites.

Businesses that depend on high-quality, differentiated applications can’t afford to gamble on AI alone. Instead, AI should be seen as a tool to enhance your developers’ productivity, not as a complete replacement.

## AI supplements development—it doesn’t replace it

For developers who embrace AI, the future looks promising. By automating repetitive tasks, AI allows us to focus on high-value work like solving complex problems and improving user experience. It enhances productivity but doesn’t eliminate the need for technical expertise. The best developers will use AI as a tool, not a crutch (like I do).

On the other hand, developers who lack problem-solving skills—or refuse to work with AI—may find themselves phased out. This isn’t a bad thing for the industry. AI will help elevate software development by removing inefficiencies and allowing talented developers to focus on innovation.

## Conclusion: Adapt or be replaced

The next time you see a demo of AI creating an app, take it with a grain of salt. AI isn’t going to take over the entire development process anytime soon. Real intelligence is still required to direct artificial intelligence.

AI is changing the way we develop software, but it isn’t the end of the developer as we know it. The developers who succeed in this new era will be those who understand how to use AI effectively, focusing on problem-solving and strategic decision-making. Those who fail to adapt—or who never had strong development skills to begin with—may find themselves replaced by the very technology they fear.

As developers, our role is evolving. But with the right mindset and skills, we can harness AI to build better, faster, and more scalable applications than ever before.

### Useful links

-   5 reasons why I'm building our RAG application on Upsun
-   AI deployment strategies: balancing efficiency and environmental impact

### [Bedrock for WordPress: a modern workflow for cleaner projects](https://upsun.com/blog/bedrock-wordpress-development/)

# Bedrock for modern WordPress development

WordPress is _the_ legacy content management system. It's remained tremendously popular since its release in 2003 for the power it gives users to quickly put together a website with tools that offer them real, intuitive control over their content. That popularity has both inspired and depended upon constant modernization efforts by WordPress fans. The latest project to keep the classic CMS clicking two decades after its birth is Bedrock, an effort to turn WordPress into a Twelve-Factor app by the folks at Roots.

Roots is a team of developers creating and maintaining tools to improve the development process for WordPress. Some of their projects focus on standardizing plugin and theme development. Bedrock, however, focuses on the WordPress installation itself, simplifying configuration and customization by completely integrating with the PHP package manager, Composer.

With Bedrock, Roots is trying to bring WordPress closer to the Twelve-Factor app methodology. Twelve-Factor is a kind of “best practices” guide that’s only satisfied when an application explicitly defines external codebases it depends on and when the configuration for that app can be pulled from the environment no matter where it is deployed. Both of these characteristics make builds repeatable and therefore more dependable. They’re also both features WordPress doesn’t follow by default, making maintenance much more difficult.

## **Maintaining WordPress sites**

Once you deploy WordPress, the installation process is famously simple (one of the many reasons for the application’s enduring appeal). But maintaining WordPress is unfortunately not so simple. For instance, updating WordPress with anything other than minor version upgrades can be a hassle. The Bedrock project is an attempt to make maintaining WordPress less burdensome by defining themes and plugins like any other PHP dependency—components that can be installed and updated with single commands through a package manager.

When an update is available, WordPress exposes a button that allows administrators to download and switch out updates with a single click. However, many hosting solutions, Platform.sh included, enforce read-only filesystems at runtime. These solutions deploy a highly reproducible build image as a consequence of your codebase and its explicitly defined build process, all committed to version control. That is to say, your application is an artifact of these definitions rather than just the files in the repository alone. External code (dependencies) that your application depends on, and ideally definitions of your infrastructure itself, are committed to exact versions so that your entire DevOps process from start to finish is repeatable and reproducible by anyone who needs to do so. This is a good thing.

WordPress by comparison requires write access to the server so that plugins and themes can be updated at runtime. Additionally, WordPress does not track the code for those themes and packages in your site's version control, merely swapping them when updates are needed. The two of these aspects together can introduce unintended vulnerabilities that are completely untraceable. If themes and plugins _are_ version controlled, they can quickly bloat your codebase. Since Bedrock treats these components as dependencies, nothing is written at runtime and individual packages do not need to be committed, making it possible to eliminate both the vulnerabilities and the bloat.

### **The Bedrock solution: Composerify WordPress!**

Composer is at the heart of everything for Bedrock. If we can treat WordPress core and all of our customizations as dependencies, we can commit less code, be more specific in our versioning, support deployment on more environments than WordPress would allow, and drastically simplify its maintenance.

We recently shared a method for updating "vanilla" WordPress on Upsun using Source Operations. This method allows you to still maintain a read-only file system, commit everything to Git, and expose an endpoint that triggers updates to occur in a separate container that makes traditional WordPress maintenance compatible with our platform.

But you can also accomplish this by integrating WordPress with Composer, PHP's package management system. This has been, unsurprisingly, the recommended way of deploying WordPress on Platform.sh for some time now. Our WordPress template relies on the popular John Bloch Composer fork, which mirrors the default WordPress codebase and then adds the `composer.json` file needed to treat WordPress core as a dependency. This same pattern is applied to the vast ecosystem of WordPress themes and plugins, accessible with Composer from the WPackagist repository.

### **Bedrock: the WordPress development starter**

A lot of what Bedrock does differently starts with its project structure, so let's clone a local copy of the repo to compare to WordPress’s typical structure:

```shell-session
.
├── config/
│   ├── application.php
│   └── environments/
│       ├── development.php
│       └── staging.php
├── web/
│   ├── app/
│   │   ├── mu-plugins/
│   │   ├── plugins/
│   │   ├── themes/
│   │   └── uploads/
│   ├── index.php
│   └── wp-config.php
├── composer.json
├── composer.lock
├── phpcs.xml
└── wp-cli.yml
```

The structure is a lot different here than what we’d see in vanilla WordPress: it's a lot smaller, for one. Most of the files that make WordPress work—including WordPress core files, as well as default and custom themes and plugins—are not actually committed to the repository. Instead, those files are downloaded on the fly as dependencies for the final application, all defined in its `composer.json` file.

```shell-session
 "repositories": [
   {
     "type": "composer",
     "url": "https://wpackagist.org",
     "only": ["wpackagist-plugin/*", "wpackagist-theme/*"]
   }
 ],
 "require": {
   "php": ">=8.0",
   "composer/installers": "^2.2",
   "vlucas/phpdotenv": "^5.5",
   "oscarotero/env": "^2.1",
   "roots/bedrock-autoloader": "^1.0",
   "roots/bedrock-disallow-indexing": "^2.0",
   "roots/wordpress": "6.6.1",
   "roots/wp-config": "1.0.0",
   "roots/wp-password-bcrypt": "1.1.0",
   "wpackagist-theme/twentytwentyfour": "^1.0"
 },
 "extra": {
   "installer-paths": {
     "web/app/mu-plugins/{$name}/": ["type:wordpress-muplugin"],
     "web/app/plugins/{$name}/": ["type:wordpress-plugin"],
     "web/app/themes/{$name}/": ["type:wordpress-theme"]
   },
   "wordpress-install-dir": "web/wp"
 },
```

In the above snippet, `roots/wordpress` is given an exact version of WordPress: 6.6.1. That same version will be downloaded during every build (when `composer install` is run) to a subdirectory, which has become a popular practice even outside of "Composerified" versions of WordPress.

Already we're moving away from some of the problems outlined above. WordPress is a dependency, one that can be explicitly defined and locked to a specific version to ensure repeatable builds. None of it is committed, and only that specific version is downloaded during a `composer install` build command.

### **Extending WordPress with Composer**

The same goes for themes and plugins. But you'll notice that the `composer.json` needs some additional configuration to support this new way of defining WordPress dependencies. By default, any Composer dependency is installed to an uncommitted subdirectory `vendor`. On Platform.sh, this is installed using our build flavor or during your build hook.

The thing is, that isn't where we'd like WordPress core to end up. In the snippet above, you'll see the attributes `extra.wordpress-install-dir` and `extra.installer-paths`. The first instructs Composer (using `composer/installers`) to download the version of WordPress we've defined into `web/wp` and the second to install themes and plugins to `web/app`. Everything upstream from WordPress is in one directory, and everything else we’re adding to WordPress goes into another. You'll notice something similar for your configuration, which has been isolated to `config`, complete with environment-dependent control. Everything here has clear separation, is version controlled, and with Composer becomes reproducible.

With this setup, we can do a lot of things very easily. If we want to update WordPress core and all of our themes and plugins, all we need to do is run `composer update`. We can customize the appearance of the site using a community theme with `composer require wpackagist-theme/magsoul`, (as an example) then enable it in the admin dashboard once deployed. If we want to extend the site into an online store, we can add the WooCommerce plugin in the same way:

```shell-session
$ composer require wpackagist-plugin/woocommerce
```

If we want to be able to manage the application using the WordPress CLI:

```shell-session
$ composer require wp-cli/wp-cli
```

Anyone out there trying to reproduce our application only needs to run `composer install` to start contributing to it. Everything is a dependency and is completely installable and updatable through Composer.

### **Deploying Bedrock on Upsun.com**

Now all this talk would be for not if we didn't address deployments, and it’s here that Bedrock really opens up configuration to do so. Bedrock allows you to use environment variables to connect to the database and set routing variables like `WP_HOME` and `WP_SITEURL` in more flexible ways than traditional WordPress. This is another component of the Twelve-Factor app idea: configuration stored in the environment. The application can be moved to many different environments and still maintain the same build, so long as those variables are defined. Below is a similar `.environment` file included in our Platform.sh WordPress Bedrock template (which works identically on Upsun):

```shell-session
# .environment

export DB_NAME=$MARIADB_PATH
export DB_HOST=$MARIADB_HOST
export DB_PORT=$MARIADB_PORT
export DB_USER=$MARIADB_USERNAME
export DB_PASSWORD=$MARIADB_PASSWORD

export WP_HOME=$(echo $PLATFORM_ROUTES | base64 --decode | jq -r 'to_entries[] | select(.value.primary == true) | .key')
export WP_SITEURL="${WP_HOME}wp"
export WP_DEBUG_LOG=/var/log/app.log
export WP_ENV=production
# Uncomment this line if you would like development versions of WordPress on non-production environments.
# export WP_ENV="${PLATFORM_ENVIRONMENT_TYPE}"

export AUTH_KEY=$PLATFORM_PROJECT_ENTROPY
export SECURE_AUTH_KEY=$PLATFORM_PROJECT_ENTROPY
export LOGGED_IN_KEY=$PLATFORM_PROJECT_ENTROPY
export NONCE_KEY=$PLATFORM_PROJECT_ENTROPY
export AUTH_SALT=$PLATFORM_PROJECT_ENTROPY
export SECURE_AUTH_SALT=$PLATFORM_PROJECT_ENTROPY
export LOGGED_IN_SALT=$PLATFORM_PROJECT_ENTROPY
export NONCE_SALT=$PLATFORM_PROJECT_ENTROPY
```

Our database service information is exposed as a set of environment variables prefixed with the name of the database service we define in the relationships property of our configuration file (see below). In this case, I've named it mariadb so the service information is prefixed with MARIADB\_\*. However, Bedrock needs the environment variables to be prefixed with DB\_ so the first block in the .environment file is simply mapping the information to what Bedrock requires.

We then use `jq` to retrieve the primary route to our application since the URL will change depending on the environment (production vs staging vs development),  and the project variable `PLATFORM_PROJECT_ENTROPY` for our security variables, all of which can be called in our environment-specific configuration (the `config` subdirectory). The remaining configuration is fairly similar to what you have seen before in our composer WordPress template for Platform.sh.

```shell-session
.upsun/config.yaml
```

`.upsun/config.yaml` is also similar, including a build hook step that allows us, if we’d like, to continue to use plugins that cannot be downloaded as dependencies. Not every WordPress theme and plugin has been made compatible with Composer (their upstreams do not include a `composer.json` file), so this is always a helpful step to include. Unlike .platform.app.yaml, Upsun's configuration file also includes routes (routes.yaml in Platform.sh) and our services (services.yaml in Platform.sh)

```shell-session
# .upsun/config.yaml
applications:
  wp-bedrock-upsun:
    source:
      root: "/"

    type: "php:8.3"

    relationships:
      mariadb:
    
    
    # Mounts define directories that are writable 
    web:
      locations:
        "/":
          root: "web"
          passthru: "/index.php"
          index:
            - "index.php"
          expires: 600s
          scripts: true
          allow: true
          rules:
            ^/composer\.json:
              allow: false
            ^/license\.txt$:
              allow: false
            ^/readme\.html$:
              allow: false
        "/wp/wp-content/uploads":
          root: "web/wp/wp-content/uploads"
          scripts: false
          allow: false
          rules:
          '(?<!\-lock)\.(?i:jpe?g|gif|png|svg|bmp|ico|css|js(?:on)?|eot|ttf|woff|woff2|pdf|docx?|xlsx?|pp[st]x?|psd|odt|key|mp[2-5g]|m4[av]|og[gv]|wav|mov|wm[av]|avi|3g[p2])$':
            allow: true
            expires: 1w
    
    build:
      flavor: none

    dependencies:
      php:
        composer/composer: "^2"

    hooks:
      build: |
        set -eux
        composer --no-ansi --no-interaction install --no-progress --prefer-dist --optimize-autoloader --no-dev
        rsync -a plugins/* web/app/plugins/

    mounts:
      "web/wp/wp-content/cache":
        source: storage
        source_path: "cache"
      "web/wp/wp-content/uploads":
        source: storage
        source_path: "uploads"

# The services of the project.
services:
  mariadb:
    type: mariadb:11.0

# The routes of the project.
routes:
  "https://{default}/":
    type: upstream
    upstream: "wp-bedrock-upsun:http"
  "https://www.{default}":
    type: redirect
    to: "https://{default}/
```

With this configuration, Upsun.com will download each of your dependencies (which again is WordPress itself, along with all of your themes and plugins), connect to the database, and deploy Bedrock for you.

### **Disk Space**

One distinct difference between Platform.sh and Upsun.com is you do not define the amount of disk you allocate to your services and application mounts in the configuration file. Instead, the first time you push, Upsun.com will automatically assign 512MB of disk to both the MariaDB service and to the mounts that WordPress will use for uploads. To adjust the disk space allocated to each, you can either use the console or the `upsun resources:set` CLI command. Refer to Manage resources in the docs for more information. 

There's no telling what the future of WordPress will be, but it's safe to say that it will continue to be widely popular. Bedrock provides a method for developing with WordPress in interesting ways. The few constraints it places on your project’s structure opens up greater flexibility to customize quickly, all while considerably decreasing the maintenance burden long term.

### [Chapter 2: Upsun and the decades of the open web | Upsun](https://upsun.com/blog/chapter-2-upsun-and-the-decades-of-the-open-web/)

# Chapter 2: Upsun and the decades of the open web

In chapter 1 of this series, I talked about the changing relationship between companies and their digital infrastructure and code-creation capabilities today. In this chapter, I’d like to take a step back in time and investigate how that relationship has changed over time throughout the decades of the web.

The reason for this? To understand how and why the web has evolved over time to become what it is today will hopefully help you to understand what it is we want to achieve and the kind of service provider we want to be with Upsun.

So without further ado, allow us to take you back to where it all began: 1995.

## The first decade of the web: 1995-2005

The web’s youthful years saw the democratization of personal computing as prior to this decade, most people did not have their own computers in their homes. From a dedicated business function, computing and the internet became pervasive. Concurrently two very strong and very contradictory phenomena happened.

On one side the web, there was a broadcast. As large corporations began talking to the public via a one-way conversation, they were not going to expose internal systems and transactional capabilities.

On the other hand, computing changed. You could have a computer under your desk that could be connected to from anywhere on Earth without having to ask anyone for permission. The barrier to entry running a networked computer program got so low that the reduction in cost allowed anyone to develop their own media. Leading to blogging and Wikipedias, as well as peer-to-peer ecommerce such as eBay and PayPal.

All of this was powered and accompanied by the growth of open source. During the years of 1995 to 2005, servers still ran Unix and Windows but Linux had started becoming the default choice. As were dynamic programming languages that were easy to deploy, particularly PHP. With little method to the madness these were the years of boom and bust (the dotcom crash) of fake-it-till-you-make-it. This is what allowed for the unit-economics to work with almost no cost to get started and very low marginal costs to consider. After all, when you don’t have to pay license fees for operating systems and programming languages, you can scale very quickly. Some of the current giants—like Amazon or Google—were created with almost no capital investment at that time.

## The second decade of the web: 2005-2015

The second decade of the web saw the rise of centralized social media in its current form including Facebook. But also, with the growing number of available consumers, this decade welcomed the explosive growth of re-centralized ecommerce—such as Amazon Prime, Shopify, and Etsy. These kept some of the hallmarks of the peer-to-peer era as marketplaces that allowed others to play in their closed gardens but were centrally controlled.

Maybe more importantly, this decade was the moment where the internet became mobile with the apparition of the iPhone and the Android ecosystems. Suddenly with the scale of internet usage running a webserver under your desk was no longer an option. This was when server virtualization started happening with the likes of VMware, Solaris Zones, Xen, and KVM.

The unit-economics of building software kept trending down—these were the actual start-up years—while the unit economics of running hardware kept growing. So these were also the years in which the cloud appeared with again an incredible effect on democratization accompanied by a strong movement towards centralization. Led by Amazon Web Services (AWS) and slowly accompanied by Google and Microsoft.

2005 to 2015 were also the years of open source. Alongside profound changes in the way software was built and developed with agile methodologies, software testing, and automation. At the heart of the revolution was the arrival of a new distributed source code management tool, Git.

Git—initially developed for the Linux Kernel—allowed for much more scalable development compared to previous tools like SVN, CVS, and SourceSafe. Basically, it offered collaboration at scale. But at the same time, open source itself was centralized with Github becoming the centerpiece further democratizing software development. And while open source became dominant, most projects didn’t have a sustainable business model, other than serving some other business competitive goal—for example, Google with Android and Google with Chrome.

During this time, PHP, trivial to deploy and still running some of the largest sites—Wikipedia, Facebook, and Slack—and the most numerous ones—Drupal, and WordPress—starts getting displaced in the start-up world. Firstly by Ruby and then by Python, which was possibly a more productive option but much harder to deploy and manage.

These were the glory years of bespoke internet solutions. Frameworks appear—like Rails, Symfony, and Django—that allow the development of robust and scalable solutions at a rhythm unimaginable in the previous decade. These more productive, less trivial-to-operate solutions see operations automation tooling starting to appear—such as Chef, Puppet, and Ansible—which will soon be referred to as DevOps tools. While the “cloud” develops from a small number of low-level primitives to a large suite of high-level value-added tools. From proposing just-in-time provisioning and elastic capacity, Infrastructure-as-a-Service (IaaS) providers start building tightly-coupled services that produce strong vendor lock-in.

Courtesy of the growth of mobile usage and the reduction of complexity with the popularity of REST architectures displacing other forms of machine-to-machine communication, Web APIs become widespread. The web is no longer just something consumed by web browsers but something that is going to enable the interconnection of many different services from multiple providers in a predominately seamless way.

These are also the days of the divergence of hyperscalers: digital native companies that are going to define the cloud. Facebook, Amazon, and Google design their own hardware and build bespoke software architectures that have magical capabilities inaccessible to the common players. They continuously deploy systems that are highly distributed and redundant with elastic scalability. They will build and define what operations at-scale in the cloud mean. Node.js appears as another democratization allowing front-end developers to intermingle with the backend people. As well as enabling highly-concurrent use cases that were only accessible beforehand to hyperscalers and, to a degree, the good-old enterprises with Java and .NET. This is also the moment of copycat astronaut architects epitomized by MongoDB and Kafka.

A concept appeared in the early days of the second decade, a concept that would become dominant and yet disappear to the background shortly after. The concept involved a service by a computer system no longer being rendered by a single system, not even a single company. Many companies contributed their capabilities: first by simply injecting javascripts to a front-end; the “third party” ecosystem. Web pages are composed of resources coming from all over the place but also backends coordinating through APIs, often something that ends up with the GAFAMs.

As an echo to the first days of the web where web scale was accessible to all and IaaS providers and these new open-source technologies reduced the barrier to entry. But often at double the cost and a growing operational complexity.

Platforms-as-a-Service (PaaS) were created during this decade to reduce the cost of operations, mostly for monolithic applications with players such as Heroku and AppEngine. They promise to absorb this growing operational complexity by offering an opinionated runtime with some strong constraints. These constraints being no local files, only one supported database, and one way to deploy. Accompanied by the productivity of web frameworks, PaaSs reduced not only the initial time-to-market but also the time-to-scale. But both the architectural limitations and non-scalable pricing models meant that most companies migrated away from those after their initial growth.

## Our decade of the web: 2015-2025

It’s the decade of 2015 to 2025, the internet of everything is ubiquitous. We no longer simply connect to the internet, most of the developed world lives and breathes it. Netflix, Uber, Airbnb, Booking, Amazon, Gmail, Google docs, Slack, and Teams are present in every waking hour of our lives. In business, these are the years of SaaS.

The unit economics of software development peaked bringing a new movement of centralisation. Encouraged by very few B2C platforms and the growing tendency to forgo bespoke software development and use SaaS solutions instead. Open source still powers all of these services in the backend but the value is captured by SaaS from one side and the cloud from the other.

As a counter-reaction, commercial open-source solutions start maturing with strong actors in the database (MongoDB, Elastic), DevOps (Hashicorp, Cloudbees, and Docker), and CMS/ecommerce spaces (Automattic, Acquia, and Magento).

From monolithic applications of the previous decade built with a simple, multi-tiered architecture—native to the internet, new solutions started to form. Often built with stateless microservices on one side, and a scalable data-fabric proposed by the cloud provider on the other. These new topologies brought with them an enormous level of operational complexity which led to Observability-as-a-Service—like NewRelic and Datadog—thriving as a remediation.

These new topologies see the need for other forms of deployment and workload isolation. Initially, as a development tool containers started to be democratized and the units of execution became smaller. Kubernetes quickly gained in popularity and in a way displaced Linux as the abstraction layer of the “thing you deploy to”. This is accompanied by a further explosion of operational complexity of the underlying infrastructure—on top of what was already contributed by the workloads.

New forms of PaaS appear that rather than manage the whole infrastructure—with an opinionated approach—only manage the smallest elements of the system. Small, stateless bits are tied together through service-meshes like Lambda and Serverless. Even though the inherent complexities of distributed systems make the adoption of those anecdotal at best. Most organizations either deploy actual monolithic applications to those or use them only at the very edge of the application for very simple tasks.

A lot of the current cloud is about the separation of the data-fabric which is the lock-in mechanism of the hyper-scales—BigQuery and RDS. But part of these trends is actually about the data layer moving to an isolated tier. Often “as a service” we can see that in the explosive growth of Snowflake, but also in the strong market position of MongoDB, Confluent, and Elastic search. This is even more true with the data-layer containing actual third-party data. Initially this was the OpenData paradigm but now this is all about machine learning and trained models. OpenAI and Anthropic are the main examples here of when “your” data becomes a fine-tuned layer on top of a closed-source large language model (LLM). Only accessible as a remote API, you are no longer in control of your data.

The first “decade” of production-grade LLMs was all-around proprietary SaaS-mode APIs—a decade that lasted all of a few months. The second and third quarter-length decades already saw the pendulum swing to open-source models with LLAMA generating an explosion there. We also saw the growing importance of on-device inference, private fine-tuned models, and explainable AI—all indicators that both approaches will be relevant.

Correlated to these growing usage patterns, cloud services expressed themselves as simple edge services. While another group of important players, CDN providers, introduced runtime capabilities beyond their initial caching features to run parts of applications at the edge.

And as this decade comes to an end, we are seeing the apparition of platform engineering as a response to the increasing complexity of modern software architectures, as Gartner puts it. Part of this trend is the failure of first-generation PaaS to scale beyond the initial simple monolithic use case. As a counterpart, we see MACH, a new moniker that we don’t expect to last, as potentially an ultimate example of the end of a decentralized cycle. The future is all about composability and will possibly end with companies running no IT infrastructure of their own—everything on SaaS.

Platform.sh, through Upsun, is in a very unique position regarding software composability, to propose a technical and organizational solution for product teams to both hedge the bets and integrate best-of-breed practices. Whether these teams are going fully SaaS/API, or are re-integrating capabilities in-house, or are early-adopters of AI-assisted coding and pervasive production-use of LLMs, or are waiting for the dust to settle and for technologies to mature.

Chapter 3: Upsun and the decades of the open web

### [PHP 8.0 feature focus: nullsafe methods | Upsun](https://upsun.com/blog/php-nullsafe-methods/)

# PHP 8.0 feature focus: nullsafe methods

Let's be honest, null values suck. They've been called the billion dollar mistake, but programmers in most languages still have to deal with it. (Except for those working in Rust.) They especially suck when you have a variable that could be an object or null. If it's an object, presumably you know its type and what it can do; if it's null, you can't do much of anything with it. 

The standard way to deal with that situation is to branch using a conditional check, the eponymous "if null" pattern:

```shell-session
<?php
$user = get_user($id);
if (!is_null($user)) {
    $address = $user->getAddress();
    if (!is_null($address)) {
        $state = $address->state;
        If (!is_null($state)) {
            // And so on.
        }
    }
}
```

This is, of course, gross and hard to read, but necessary if you want to avoid the dreaded `Call to a member function on null` error.

In an ideal world, we could structure our code so that null is impossible. Sadly, we're not living in an ideal world, especially when we have to deal with someone else's code. For that reason, a number of languages have what is called a "nullsafe operator." And, as of version 8.0, PHP is one of them.

The nullsafe operator is really a modifier on object access, either properties or method calls. If either of those are preceded by a `?`, it has the same effect as wrapping the access in an `if (!is_null))` check. The example above, for instance, becomes:

```shell-session
<?php
$state = get_user($id)?->getAddress()?->state;
```

In this example, the value returned by `get_user()` is either a `User` object or null. The value returned by `User::getAddress()` is either an `Address` object or null. If `get_user()` returns null, the `?` catches that and returns null, ignoring the entire rest of the line. The same happens for `getAddress()`. At the end, `$state` is either a valid state value pulled from the `state` property of the address, or it's null.

The nullsafe operator short-circuits the rest of the line the first time a null value is encountered. That means even dynamic calls or erroring calls later in the process don't happen. For example:

```shell-session
<?php

$bestSaleItem = $catalog?->getProducts(get_seasonal_type())?->mostPopular(10)[5];
```

If `$catalog` is null, `get_seasonable_type()` won't be called at all. The entire chain stops after detecting that `$catalog` is null and sets `$bestSaleItem` to null. Similarly, if `getProducts()` returns `null`, then `mostPopular()` is never called. However, that does not extend to arrays. If `mostPopular()` is still called and it returns null, you'll still get a `Trying to access array offset on value of type null` error.

There are a few limitations to the nullsafe operator, of course. It only works for reading properties or methods, not for writing to values. It also doesn't deal with references, because references require real values. (This is consistent with other languages that have a nullsafe operator.)

It also provides no indication of which step in the chain returned null.; If `$bestSaleItem` is null, it could be because `$catalog` was null, or `getProducts()` returned null, or `mostPopular()` returned null. There's no way to tell. Sometimes that's fine. If you do need to tell the difference, though, nullsafe won't help you. For that you really need an Either monad, but that's a topic for a very different time...

Nonetheless, nullsafe can help reduce the amount of boilerplate code floating around your object-oriented method chains. We have Ilija Tovilo to thank for the nullsafe RFC.

_Stick around for our next installment, when we cover a series of smaller improvements that will make PHP 8.0 just generally more pleasant to live in_.

### Useful links

-   PHP | Upsun Docs

### [Our new greener-region discount | Upsun](https://upsun.com/blog/greener-region-discount/)

# An industry first: greener-region discount for Upsun users

You may already know cloud computing accounts for approximately 3% of the electric power consumption in the world. Depending on the physical location, the carbon intensity of cloud computing in data centers varies drastically; carbon intensity can be up to 30 times more intensive, depending on whether the electricity is powered by coal or gas. Or from lower-carbon sources of electricity like hydro, solar, wind, or nuclear. 

To further our support for developers and organizations who strive to reduce their carbon footprints, we're now offering a **3% discount on your Upsun resource usage** when you choose to deploy to a data center in one of six, incentive-eligible greener regions.

Greener regions are those that have a grid carbon intensity score of less than 100 g CO2eq/KWh. You can learn more about how we measure carbon intensity with Electricity Maps. 

The Upsun greener-region discount applies to application CPU, application memory, service CPU, service memory, and build resources on a project level—empowering Upsun users to save on money and emissions, one deployment at a time. The discount doesn’t apply to project fees, storage, or other dimensions involved in your project. If you have multiple projects within an organization, the discount will only apply to the projects hosted on incentive-eligible, greener data-center regions.

### **How to access your greener-region discount** 

1.  Beginning in March 2024, when you create a new project on Upsun, you’ll be prompted to select a region of your choice in the console. Eligible, greener data-center regions are identified by a green-leaf icon—as seen in the screenshot below.
2.  Simply select one of these greener regions to receive your 3% discount. 
3.  If you already have current projects on Upsun, you can manually migrate them to an eligible, greener data-center region by following these steps. 
4.  To check if the discount has been applied, navigate to the project’s billing page or to the invoice page, both found under the _billing_ tab.
5.  Projects hosted on eligible, greener data-center regions can be identified by the same green-leaf icon you see when your discount is applied.        
     

Run into any issues? Can’t see your green-leaf icon? Reach out to our support team for assistance.

Happy, greener hosting!

The greener-region discount is now available to all Upsun users.

Free trial

### Useful links

-   Upsun is using annual carbon intensities from Electricity Maps

### [Nested locations blocks in nginx config | Upsun](https://upsun.com/blog/nginx-config-nested-locations-blocks/)

# Nested locations blocks in NGINX configuration

If you’re anything like me, you’ve often found yourself looking at the NGINX documentation (you know, just for fun) and finding the following:

> `location` blocks can be nested, with some exceptions mentioned below

And you’ve thought to yourself, “Wow, that’s so non-specific. What does nesting a location block _actually_ mean? Why would I want to do it?”

Well, I’ve investigated the nginx config at length and can offer some insights from my findings. You can always take a look at the NGINX documentation if you need a refresher on how NGINX config location blocks work.

## Locations

Four types of NGINX config locations can be defined, and I’ll call them like so:

-   Exact-match (=-type) locations
-   Plain config locations
-   Strong prefix config locations
-   Regex config locations

The first three are alike in that they’re all prefix-type NGINX config locations. They all have to match the start of the requested Uniform Resource Identifier (URI). So `location /foo` will only ever match a request for `http://some.site/foo/bar/`, it can’t match `http://some.site/bar/foo/`, even though `/foo` is in there somewhere. Although RegEx locations are treated a bit differently, as we’ll see later in this article so stay tuned.

### Prefix NGINX config locations

When NGINX is handling a request, it will try to figure out which NGINX config location block applies—only one location can apply. To do that, it scans through the NGINX config file from top to bottom—well, building the _file_ is another topic, too. Just think of it as an NGINX config file looking for prefix-type locations, for now. Whenever it finds a location that matches the current request, it checks to see if this location is a longer match than the last one it saw. If it is, NGINX remembers it. If the location matches exactly and is an `=`\-type, then it terminates its search and immediately just uses that location block right away without even consulting RegEx-type locations. Notably, `=`\-type locations can’t have locations nested in them at all, and NGINX will treat it as an error if you try.

If there are any prefix-type locations nested within the newly-remembered block, it considers those at this time, just as if they were defined at the top level.

### RegEx NGINX config locations

If NGINX gets to the end of the NGINX config file without having matched an `=`\-location, then it will have a record of the longest prefix-type location that matches this request. It will then proceed to test any RegEx-type locations, starting with the locations defined _inside_ the prefix-type location that matched. The first time one of these matches, it stops looking and simply uses that NGINX config location block. When it gets to the end of the prefix-type location with no match, it keeps looking at the start of the NGINX config file.

Please note: there is one exception to this, NGINX will look inside the matched location block for more deeply nested RegEx location blocks that match.

You can’t have a prefix-type location block nested within a RegEx-type location block at all, and NGINX will call this out as an error if you try.

Finally, there’s one last exception to what happens after prefix NGINX config locations are finished being searched. If the best prefix-type location block has the strong-prefix modifier (`^~`), then it won’t check any RegEx locations at all, except for nested RegEx locations.

### Share your insights on NGINX config locations with Upsun

Hopefully, that was helpful for my fellow NGINX investigators out there. I jumped down the rabbit hole of NGINX config intricacies a little while ago and found it surprisingly difficult to find a complete answer so I wanted to share what I did find after taking a deep dive. Have you ever taken on your own NGINX investigation? What did you find?

Share, chat, debate–let us know your thoughts and findings in our Community.

### [Master regex: From basics to advanced - Presentation | Upsun](https://upsun.com/blog/master-regex-presentation/)

# Master regex: From basics to advanced pattern matching

### Video transcript

_We utilized ChatGPT to enhance the grammar and syntax of the transcript._

Hello everybody! Wow, you're really awake. Thank you so much for being here to demystify regular expressions with me. I'm sure many of you already have some knowledge about it. This is very much Regex 101, and I should note that I’ll be referring to it as "regex." Apologies to those who say "regx" or something else—I'm not entering the GIF/GIF pronunciation debate here! We can discuss that after; I have opinions.

You can follow along if you'd like. This session was designed as a workshop where participants would engage and do things as we go. Everything is in the GitHub repo, and I also encourage you to open regex101.com. I’ll be showing you that in just a moment. The slides are available as well, so if you want to review them later, feel free.

A couple of disclaimers: you don't need advanced math to understand regular expressions. Yes, they originate from mathematical theory, but you don’t need to be a math expert to grasp them. It’s more about learning and practicing, so I encourage you to try it out on your own to really get the hang of it.

I’m going to show you a tool. Unfortunately, I don’t have time today to go through every example and show you how it works, but I encourage you to explore it on your own. It's my favorite, and the repo is structured accordingly, with an informative README, slides from my colleague Paul, who is the original author of this talk, and some text examples. There's plenty of content, so feel free to dive in and test it out.

Now, what's this? Oh, I’ve encountered a demo effect—how fun! I'm locked out of my slides, which is fantastic. But don’t worry, I’m a professional—don’t try this at home. Oh, it looks like I’m still sharing my screen—great for security as well.

I’m sure you’re eager to learn about my password, but let’s move on. Sorry about that, folks. If you’ve never seen someone crash live, here I am, happy to oblige.

Regular expressions come from math. Essentially, they are a way to describe language through mathematical equations. While they originate from the mathematical world, you don’t need to be a mathematician to understand them. And now that my screen is back to normal, let’s continue.

Typically, this presentation takes 50 minutes, but I’ve only got 35, and I’ve already lost five minutes. Yay!

So, a bit of history: regular expressions were created by Stephen Cole Kleene in 1951. They describe language, as I’ve mentioned, and they’re essentially just a mathematical way to explain language. However, what you really want to know is, what exactly are regular expressions? By the end of this session, you will understand that they are sequences of characters that specify a search pattern. That’s what we’re doing: creating a pattern to search through vast amounts of text for the specific pieces we’re interested in.

It’s important to note that regular expressions are not a programming language. They are not difficult to learn, and I promise you can do it. I have a degree in English language, and if I can master it, so can you. However, it’s also not a perfect solution to every problem. Sometimes, using regular expressions can be more costly than other methods, like a simple SQL query. It’s a great tool, but you’re responsible for how you use it.

Now, for some fun—here’s the obligatory comic to lighten the mood. I’ll give you a moment to enjoy the artistry.

So, what can you use regular expressions for? The most obvious use is finding text. But did you know you can use regular expressions in Google Docs and Word? Yes, you can! It’s also useful for validating text, like email validation. You can even use it in Excel and Google Sheets.

Now that you know where you can use it, let’s talk about how to use it. There are different types of characters: literal characters, special characters, character classes, shorthand character classes—there are characters everywhere! The syntax is what makes it fun, and we’ll go over all of these, so hang on to your seat because it’s going to go fast.

Literal characters are pretty straightforward. If you’re looking for "foo," that’s a valid regular expression. See, you were already doing it without even realizing it! But if all you need is a basic text search, why use regular expressions? Let’s explore more interesting characters.

Delimiters are common; I’m sure you’ve seen them. If you visit regex101.com, this is the default. Delimiters tell the engine where the pattern begins and ends. In PHP, for example, the slash is most common. Different engines will handle them differently, so always check which engine you’re using, as it can affect your results.

Special characters, also known as metacharacters, are the main reason you’re here today. There are 12 of them, and that’s a lot! Here they all are—we’ll go over each one.

First, we have anchors. The caret (^) is an anchor that signifies the beginning of a string or line. For example, the regular expression "^The" looks for lines that start with "The." The dollar sign ($) is another anchor, but it signifies the end of the line. You won’t get the same results if you anchor at the beginning or the end, so it’s important to be mindful of that. Anchoring helps make your searches more efficient and accurate.

Next, we have character classes. The opening square bracket (\[) defines the beginning of a character class, allowing you to specify a range of characters. For example, "\[a-z\]" finds any lowercase letter. Inside a character class, you don’t need to escape special characters, except for a few, which are listed here.

Negation is another concept—using the caret inside a character class negates the characters inside. For example, "\[^a-z\]" would match anything that is not a lowercase letter.

Shorthand character classes, like "\\d" for digits, are useful for simplifying your patterns. There are many shorthand classes, and they can make your expressions more readable.

The dot (.) is a wildcard that matches any character except a line break. For example, "b.r" could match "bar," "bir," "bur," etc. However, use it with caution, as it can lead to unintended matches.

The pipe (|) is for alternation, meaning "or." For example, "cat|dog" matches either "cat" or "dog." However, the pipe looks for the first match on the left, so be mindful of the order of your expressions.

Quantifiers, like the question mark (?), asterisk (\*), and plus sign (+), allow you to specify how many times a character or group should appear. For example, "fo?" matches "f" followed by zero or one "o." The asterisk matches zero or more times, and the plus sign matches one or more times.

Finally, we have grouping with parentheses, which allows you to group parts of your pattern and apply quantifiers or alternations to the group. For example, "(foo|bar)" matches either "foo" or "bar."

In conclusion, regular expressions are a powerful tool that allows you to perform complex searches and text manipulations. With practice, you can master them and use them effectively in your work.

Thank you so much for your attention. I hope you learned something valuable today.

### [Nix: Container maintenance and management - Presentation | upsun](https://upsun.com/blog/nix-container-maintenance-management-presentation/)

# Nix: Container maintenance and management

_This blog post is based on_ _a product presentation by Jérôme Andrieux, VP of Strategic Operations,_ _at SymfonyCon 2023 about Upsun's experience with Nix. We utilized ChatGPT for transcription and to enhance the grammar and syntax._

Managing containers at scale is no joke. When you're running a platform that needs to support dozens of programming languages, multiple versions of each, and countless combinations of dependencies, traditional container management quickly becomes a nightmare. This is the story of how Upsun discovered an elegant solution to what many consider an unsolvable problem.

## The scale of the problem

Jérôme, a product manager at Upsun, recently shared their infrastructure challenges at a developer conference. The numbers are staggering: Upsun maintains 166 different container images just to support their platform-as-a-service offering.

Here's the breakdown:

-   71 images for different application runtimes (PHP versions, Node.js, Python, Ruby, Go, Java, etc.)
-   95 images for various services (databases, cache stores like Redis, message queues, search engines like Elasticsearch)
-   166 images to keep secure, patched, and working.

This massive undertaking requires three full-time engineers who, in Jérôme's words, are "freaking good at this." But even with talented teams, maintaining this many images is exhausting and error-prone.

## When dependency hell shows up 

The real challenge isn't just the number of images. It's the dependency conflicts that arise when trying to support diverse application needs. Jérôme illustrated this with a relatable scenario:

Imagine you need:

-   **PHP 8.3** (because you're on the bleeding edge)
-   **Python 2.7** (for that decade-old build script you're too lazy to update)
-   **ImageMagick 6.x** (because version 7's breaking changes are too scary to tackle)
-   **LibreOffice** (because some applications genuinely need it for PDF generation)

Try installing all of these together on a traditional system, and you'll quickly find yourself in what developers call "dependency hell." Different packages need different versions of the same underlying libraries, creating conflicts that are nearly impossible to resolve.

Jérôme shared a real example from Upsun's experience: When PHP 8.2 was released, they wanted to upgrade the Symfony.com website. The upgrade broke because their documentation generation tool required Python 2.7, but the new PHP 8.2 image was built on a newer Debian version that had dropped Python 2.7 support entirely.

This led to the familiar XKCD scenario: "I'm maintaining a huge chain of technology solely to support itself."

## Nix: the functional package manager

The solution Upsun discovered is Nix, a functional package manager that approaches dependency management in a completely different way from traditional systems.

### **How Nix works**

Nix treats packages as immutable values in a functional programming sense. Every package is built in complete isolation with these key principles:

1.  **No undeclared dependencies**: Unlike traditional package managers, which can have implicit dependencies, Nix requires every dependency to be explicitly declared.
2.  **Unique identification**: Every package receives a unique SHA-256 hash that captures not only the package itself, but also all its dependencies. This creates a unique identifier for every possible combination.
3.  **Isolation through the Nix store**: All packages live in `/nix/store/` with paths that include their unique hash. This means you can have multiple versions of the same software installed simultaneously without conflicts.

### **The magic of reproducibility**

With Nix, when Jérôme says "it works on my machine," he can actually guarantee it will work on yours too. The functional approach ensures that if a build succeeds once, it will succeed identically anywhere else.

## Real-world demo: The impossible made possible

During his presentation, Jérôme demonstrated something that would be nearly impossible with traditional package management. Using a simple `nix-shell` command, he created an environment with:

-   PHP 8.3 with the SOAP extension
-   Python 2.7 (with appropriate security warnings)
-   ImageMagick 6.x

All are running simultaneously on the same system without conflicts. The demonstration showed how Nix evaluates all the different package expressions and their dependencies, then creates an isolated environment where everything coexists peacefully.

For automation, this can be codified in a simple Nix file:

```shell-session
{

  inputs = [

    php83

    python2

    imagemagick6

  ];

  

  shellHook = ''

    echo "Hello Symfony Conference!"

  '';

}
```

Run it with: 

```shell-session
nix-shell
```

## The business impact

For Upsun, adopting Nix represents a potential reduction from 166 maintained images to essentially one composable image. Instead of maintaining separate containers for every possible combination of runtime and dependencies, they can use Nix to compose the exact environment needed for each application.

This approach offers several advantages:

-   **Reduced maintenance burden**: Fewer base images to maintain and update.
-   **Better resource utilization**: No need to pre-build every possible combination.
-   **Easier experimentation**: Adding new packages or tools becomes trivial.
-   **True reproducibility**: Development, staging, and production environments are guaranteed to be identical.

## Why this matters for everyone

While Upsun's scale highlights the problem, most developers encounter similar issues. How many times have you struggled to compile a tool that needs specific library versions, only to give up and reach for Docker instead?

Jérome points out that Docker, while useful, doesn't actually solve dependency hell; it just containers it. You can still run into the same conflicts within your Docker images.

Nix offers a fundamentally different approach. Instead of working around dependency conflicts, it eliminates them through mathematical precision and the principles of functional programming.

## Questions

A question from the room: 

-   Does Nix lock versions forever? 

You control that. You can track a channel and move forward with minor updates, or you can pin to a specific commit of Nixpkgs to hold versions steady. You can also pin specific packages. To share with your team, commit your `default.nix` or `shell.nix` in the repository. Anyone can run the same build.

-   How do we deploy it?

 Jerome shared what is coming. On Upsun, Nix support is being rolled out as an experimental feature. In your YAML, instead of writing long build hooks, you will be able to declare a Nix stack and packages. The platform will use a Nix image under the hood. Over time, deeper customization with Nix expressions may follow. 

## Getting started with Nix

Nix isn't just for large platforms. Individual developers can use it to:

-   Create reproducible development environments
-   Share exact development setups with team members
-   Generate Docker images programmatically
-   Manage system packages without conflicts

The Nix ecosystem includes over **80,000 packages**, making it one of the largest package repositories in the world. Everything is built from source by default, with pre-built binaries available for common configurations.

## Looking forward

Upsun is integrating Nix directly into their platform, allowing developers to specify their dependencies functionally rather than choosing from pre-built images. This will be launched as an experimental feature in the coming weeks.

For the broader developer community, Nix represents a paradigm shift toward more reliable, reproducible software deployment. While it requires learning functional concepts, the payoff in reduced complexity and increased reliability is substantial.

The next time you find yourself struggling with dependency conflicts, remember Jérôme's advice: there's a better way than maintaining "a huge chain of technology solely to support itself." Sometimes the solution isn't to manage complexity, it's to eliminate it.

### [Platform engineering vs Platform-as-a-Service](https://upsun.com/blog/platform-engineering-vs-the-upsun-paas/)

# Platform engineering vs the Upsun Platform-as-a-Service

Platform engineering aims to streamline software development and deployment processes by providing a standardized system with guardrails and control mechanisms. However, it's a costly endeavor, with experts projecting platform engineering to consume a significant portion of IT budgets into the future. Upsun offers a managed PaaS solution, advocating for its benefits in simplifying infrastructure complexities and accelerating development processes.

### **What is platform engineering?**

Like every new moniker—and this one is barely a year old— it takes time for the dust to settle and for a common definition to emerge. But for platform engineering_,_ we can go straight to the source with a definition from Gartner, Inc. VP Analyst Paul Delory in their 2023 _What is Platform Engineering?_ article: 

“Platform engineering emerged in response to the increasing complexity of modern software architectures. Today, non-expert end users are often asked to operate an assembly of complicated arcane services. To help end users, and reduce friction for the valuable work they do, forward-thinking companies have begun to build operating platforms that sit between the end user and the backing services on which they rely.”

The industry figured out that banging together a few dozen services with a huge impedance mismatch between them and no actual plan leads to chaos. Organizations now want to define some common ground rules.  I’ve shared in previous blog posts about the cycles of chaos and creativity vs standardization and control—see Chapter 1: Upsun and the decades of the web. Platform engineering welcomes a new cycle of IT urbanization. 

As a practice, platform engineering means your organization can define how you develop and deploy, and allows you to wrap up this process into one robust system: 

-   A system that has guardrails.
-   A system that allows for control.
-   A system that reduces the number of choices for developers so they can focus on creating actual value.

More importantly, the idea of platform engineering is that you wrap up the _whole_ system, not only the code but the organization that produces it—from product managers to support staff. This means multiple operational loops that overlap—from code quality to operational excellence. 

In a way, platform engineering is DevOps assuming control. Previously, the assumption would have been that software engineers design a complex system with potentially dozens of services in interaction (internal, underlying, and external). Now, DevOps practitioners are responsible for mechanizing all of that. Automate provisioning, build, deployments, scaling, and security response. DevOps practitioners should also add continuous improvement mechanics (where everything is measured and kept up-to-date) while accepting changes to the underlying system design—agility from end to end. 

The contrast between what Gartner has said about platform engineering today—as quoted above—and what they said about DevOps in their 2015 press release, _Gartner Says by 2016, DevOps will Evolve From a Niche to a Mainstream Strategy Employed by 25 Percent of Global 2000 Organizations__, is striking:_ 

“Organizations with agile development will be slower to embrace DevOps across the entire application life cycle. Cultural resistance and low levels of process discipline will create significant failure rates for DevOps initiatives, particularly when waterfall processes are still a dominant portion of the development portfolio. Nevertheless, a majority of enterprises attempting to scale agile over the next five years will recognize the need for DevOps initiatives.”

At the time, Gartner was right. It had all sprawled out of control. We want to go back to a semblance of order. From the sprawling mess, we define the main patterns. We create a system that can replicate those. And we now tell engineering, “This is your playground, these are your rules.” It has to be automated first. But unlike previous moments of control, the end product wants to be _self-service_. 

Platform engineering proposes a tradeoff. Mechanics and guardrails are a common layer for all engineering efforts. If you stay within those, you don’t need to ask Ops anything. 

### **Engineering a platform is a big undertaking**

I believe platform engineering emerged because of Kubernetes (K8S)—from people mistaking its role in the stack. K8S replaced Linux, the operating system (or at least part of it), but it wasn’t the platform people believed it was. They believed it would be enough to create a Helm chart and things would be fully automated down the line. But K8S never had the semantics for this. It wasn’t built to be a platform. It was built to be a runtime. And because the exposed runtime concepts are low-level and complex, you still need more tooling and processes around it. People want a platform.

### **Engineering a platform is expensive**

According to their 2023 _What is Platform Engineering?_ article, Gartner, Inc. expects that by 2026, “80% of large software engineering organizations will establish platform engineering teams as internal providers of reusable services, components, and tools for application delivery.” Platform engineering will ultimately solve the central problem of cooperation between software developers and operators. But it comes with risks:

1.  You have to make some big bets early on. As a unified system, the base will have difficulty changing and evolving. Anyone with 100% Java in their organization for a decade knows the pain.
2.  You must hire some expensive, rare talent to build a platform that can measure up to the best on the market.
3.  If you can’t make a large enough platform, the tradeoffs you expose to app engineers might not be acceptable. Maybe they _do_ need that shiny new runtime. Maybe it _is_ 3x faster.
4.  Once you start, you’ll probably never be able to divest. If the platform is not kept going forward, the whole system will screech to a halt. If budgets become tight, application development will have to be sacrificed.

### **Upsun: Platform-**_**engineering**_**\-as-a-Service?**

  
At Upsun, we believe platform engineering is not only useful but that the requirements for almost all organizations and workloads vary little. There will be trade-offs but not of the magnitude that DevOps practitioners imagine.

Upsun is a single, fully managed, self-service PaaS, which frees development teams to securely and easily experiment, quickly iterate, and confidently deploy applications at scale. 

We provide a platform that eliminates the complexity of the infrastructure and thereby enables developers to focus on code. They bring their code, we manage the rest. They are less dependent on IT to provide them with a development environment. Their time is not wasted on manual, low-value repetitive tasks. Instead, they can accelerate innovation and time to market.

We provide a platform with which you:   
Have a standardization of languages and services across all environments on a single platform

-   Can deploy anytime with confidence because teams know they've tested and previewed work with an exact copy of production
-   Scale effortlessly from one web application to 1,000+
-   Get up and running quickly with a PaaS that can grow as applications, sites, and teams evolve
-   Monitor all critical applications and infrastructure across the organization
-   Provide consistent security and privacy without service interruption

In the end, it’s about _composable cloud infrastructure_. Platform engineering is basically, “PaaS is dead, long live just the P.” The idea was great, but you can’t get this as a service. So you need to build one. Which will be true, _sometimes_. We’re sharing that you need to figure out within your own use case whether you need to build your own platform, or whether you can use one (hey, like us) as a service—one that already comes with operational maturity.

### [The Rust programming language has arrived | Upsun](https://upsun.com/blog/rust-programming-language-has-arrived/)

# Up(sun) and running with Rust

The popularity of different programming languages has changed throughout the years with each language offering its own unique strengths and limitations. In this article, we’ll dive a little deeper into a number of the most popular languages and their compatibility with our PaaS including Go, Ruby, Python, and who could forget the star of the show, Rust.

## A tale of the programming languages

First up, with its low barrier to entry, very simple concurrency model, and maybe even more importantly, its very simple build chain and distribution model (as a single binary), Go displaced quite a few other languages when it came on the scene.

For those who remember, DevOps used to be a Ruby and Python world. Now most DevOps tooling is written in Go including almost all containers and container runtimes and many of the diverse reverse proxies and API gateways. Not to mention, Go probably displaced stuff that used to run on the JVM as well—there was no stopping it.

Then with the brand power (and actual support) of Google, Go became a popular and widespread programming language and has now become a very productive web application language. A lot of things that used to be written in PHP are projects that are now in Go—a sharp rise in popularity reminiscent of the wildfire growth of Ruby’s glory days.

Meanwhile, the programming language Rust, born in Mozilla but now its own thing, had a much slower uptake—resembling more that of Python’s growth—slow and steady. The reason for this could be that the barrier to entry is evidently much higher than that of Go as you need to learn several new concepts. And as a programming language, it both exposes higher-level abstractions but also more exposure to low-level details than you would get in Go.

Over the past few years, Rust started to establish itself as the de facto “other” system programming language—even slowly making its way into the Linux kernel. Its tooling and ecosystem have grown and become much more accessible. And of all the compiled programming languages out there, it has the most polite and useful compile-time error messages—and who doesn’t love that?

But now we are starting to see Rust in the wild as a reasonable programming language for web servers with frameworks such as Actix Web, Rocket, and Axum gaining in popularity. And there are some very interesting things happening around Rust being used to compile things to WebAssembly (WASM)—see for example MailCrab a very cool mail test server.

Turns out that Rust is a really good candidate for building high-performance backend servers, and for building and running it on your favorite PaaS, of course. We even threw in WASM as a compilation target for good measure.

## How to start using Rust with Upsun

Now that Rust is supported on Upsun alongside other notable languages—such as PHP, Node.js, Python, Go, and many others—you can get to work using it right away.

Take a look at how to get up and running with Rust on Upsun below:

```Python
applications:
  app:
    type: 'rust:1'
    hooks:
      build:
        cargo build --release

    web:
      commands:
        start: './target/release/hello'
```

Don't worry, you don’t need to provide the full Rust version to get started. The “1” here means that you will get all compatible minors and patches of 1.X versions, starting with the current one, 1.74.0. As a modern programming language, Rust comes with a package manager, Cargo, which you can use in the build hook.

## Want to build WASM?

The target `wasm32-unknown-unknown` can be used at build time to generate a WASMpackage. You can start with the following build command.

```Python
cargo build --target wasm32-unknown-unknown --release
```

You can also find more materials on rustwasm.github.io.

## We look forward to your feedback

The support of Rust is currently in beta which means that we’re looking for plenty of feedback. So, please, feel free to share your successes, failures, suggestions, and feature ideas with us.

You can connect with us in our Community. For now, stay tuned for more exciting updates coming soon!

### [Up(sun) and running with Flask | Upsun](https://upsun.com/blog/upsun-and-running-with-flask/)

# Up(sun) and running with Flask

This guide provides instructions for deploying and working with Flask—a lightweight and popular web framework for building web applications using Python—on Upsun. It is often referred to as a _micro_ framework because it provides the essential components for building web applications but leaves many decisions and extensions up to the developer—let’s dive into those within the context of Upsun. 

If you're more of a just-give-me-the-steps type of person, you can jump straight to the step-by-step included at the end of this guide.

### **Setting up the application and repository**

For the purpose of this guide, we'll start by generating a Flask package project from Cookiecutter, and from there we'll walk through the steps needed to deploy the project on Upsun. With all things in tech, there are many ways to accomplish the same goal; the correct way will depend on your specific needs and goals, and the makeup of your project. The following guide is simply one way to accomplish deploying a Flask application on Upsun, but a way that’s been tried and tested by our team. 

From a terminal/command line prompt, first install Cookiecutter:

```shell-session
> pip3 install cookiecutter
```

Next, you need to generate the Flask template from Cookiecutter—if this is your first time generating a Flask template, you will need to point to the full GitHub repository address:

```shell-session
> cookiecutter https://github.com/cookiecutter-flask/cookiecutter-flask.git
```

Otherwise, you can just indicate the specific template you want to generate:  
 

```shell-session
> cookiecutter cookiecutter-flask
```

Cookiecutter will next ask you a series of 10 questions, as you can see below:

```shell-session
[1/10] full_name (): Paul Gilzow
[2/10] email (): paul.gilzow@upsun.com
[3/10] github_username (): gilzow
[4/10] project_name (): my_flask_project
[5/10] app_name (): my_flask_cookie
[6/10] project_short_description (): A demonstration project
[7/10] use_pipenv (): n
[8/10] python_version (): 3.11
[9/10] node_version (): 18
[10/10] use_heroku (): N
```

Answer each question, paying attention to what you use for the `app_name` question as you will need it later. Once Cookiecutter has generated the template, `cd` into the directory it just created; it will be the same name you gave for the `app_name` question. For this example, I named it `my_flask_cookie` and will refer to it throughout the remainder of the guide.   
You need to initiate the contents of this directory as a Git repository so before doing anything else, initialize the repository:

```shell-session
> git init .
```

By default, Git will still use master as the name for the initial branch. If you wish to change the default branch name, you can do so with the `git branch -m` command. I'll rename mine to `main`:

```shell-session
> git branch -m main
```

### **Preparing Flask for Upsun deployment**

Now that we have the repository initialized, and our template generated, we're ready to prepare it for use on Upsun. Before attempting the next command, make sure you have the Upsun CLI tool installed and working, and that you have authenticated the CLI tool with your Upsun account. Once those tasks are complete, you're now ready to have the Upsun CLI tool generate the configuration files we'll need to deploy on Upsun.

```shell-session
> upsun project:init
```

**Please note**: this command is also available as `upsun ify`

The Upsun CLI tool will now ask you a series of questions to determine your project's requirements as you can see below: 

```shell-session
> upsun project:init
Welcome to Upsun!
Let's get started with a few questions.

We need to know a bit more about your project. This will only take a minute!

What language is your project using? We support the following:
Use arrows to move up and down, type to filter
  C#/.Net Core
  Elixir
  Go
  Java
  Lisp
  JavaScript/Node.js
  PHP
> Python
  Ruby
```

Scroll down and select Python, it should then automatically detect your dependency manager: 

```shell-session
What language is your project using? We support the following: [Python]

✓ Detected dependency managers: Pip
```

It will then ask for the name of your application and from there it should prompt you for the services your project needs. Select each one and then hit enter. For this example, I only need PostgreSQL:

```shell-session
                                               (\_/)
We're almost done...  =(^.^)=

Last but not least, unless you're creating a static website, your project uses services. Let's define them:

Select all the services you are using:
Use arrows to move, space to select, type to filter
  [ ]  MariaDB
  [ ]  MySQL
> [x]  PostgreSQL
  [ ]  Redis
  [ ]  Redis Persistent
  [ ]  Memcached
  [ ]  OpenSearch
```

It will then generate a series of configuration files for you:   
 

```shell-session
┌───────────────────────────────────────────────────┐
│   CONGRATULATIONS!                                                                                                                      │
│                                                                                                                                                                     │
│   We have created the following files for your:                                                                         │
│     - .environment                                                                                                                                  │
│     - .upsun/config.yaml                                                                                                                       │
│                                                                                                                                                                     │
│   We're jumping for joy! ⍢                                                                                                                  │
└───────────────────────────────────────────────────┘
        │ /
        │/
        │
  (\ /)
  ( . .)
  o (_(")(")

You can now deploy your application to Upsun!
To do so, commit your files and deploy your application using the Upsun CLI:
  $ git add .
  $ git commit -m 'Add Upsun configuration files'
  $ upsun project:set-remote
  $ upsun push
```

Lastly, you need to add all of your generated files, from both Cookiecutter and the Upsun CLI tool to your Git repository:

```shell-session
> git add .
> git commit -m "initial commit"
```

Before you can deploy your application, you'll need to create a new project on Upsun from the command line:

```shell-session
> upsun project:create
```

The CLI tool will now walk you through the creation of a project asking you for your organization, the project's title, the region you want the application housed, and the branch name (use the same one you set earlier). For now, allow the CLI tool to set Upsun as your repository's remote, and then select `Y` to allow the tool to create the project. The Upsun bot will begin the generation of your Upsun project and once done, will report back the details of your project including the project's ID, and URL where you can manage the project from the Upsun web console. Don't worry if you forget any of this information, you can retrieve it later with:

```shell-session
> upsun project:info
```

And you can launch the web console for your project at any time by doing the following:  
 

```shell-session
> upsun web
```

Now that we have our Upsun project created and our local project generated and associated with the Upsun project, the only thing left to do is add configurations that are specific to the application. To start, we need to add an environment variable for `FLASK_APP` for all environments that points to our `autoapp.py` file. Open the file `config.yaml` located in the `.upsun` directory that the CLI tool generated and locate the commented line that starts with `# Variables to control the environment.`. We need to uncomment the next two lines underneath this line, and add our environmental variable to the list:  
 

```shell-session
# Variables to control the environment. More information: https://docs.upsun.com/create-apps/app-reference.html#variables
variables:
env:
  FLASK_APP: autoapp.py
#     # Add environment variables here that are static.
#     PYTHONUNBUFFERED: "1"
```

**Please note**: when uncommenting a section, make sure you remove both the comment marker `#` as well as the extra space. If you don't remove the extra space, you will end up with an `Invalid block mapping key indent` error when the configuration file is validated.

### **Static assets**

Next you're going to need some writable disk space to hold the static assets that npm builds and flask-static-digest generates. This directory exists under our application package named, `./<application-name>/static`. In `./.upsun/config.yml`, find the line that starts with `# Mounts define directories that are writable`. You'll need to uncomment the line `# mounts:` and then add an entry describing where we want a writable mount added:  
 

```shell-session
# Mounts define directories that are writable after the build is complete.
# More information: https://docs.upsun.com/create-apps/app-reference.html#mounts
mounts:
 "my_flask_cookie/static":
   source: "storage" 
   source_path: "static_assets" 
```

`source` indicates the type of mount: storage, tmp, or service and `source_path` specifies where the mount points inside the external directory. For further information, please see the documentation on mounts. 

The build hook allows us to make changes to the application before it is finalized and deployed. You should notice that when the CLI tool generated the configuration file for me earlier in the process, it automatically added `pip install -r requirements.txt`! This same section is where you'll also instruct Upsun to install your npm packages. But before that, I usually like to upgrade pip before I run `pip install` so I'm going to add a new line above that and add in `pip install --upgrade pip`. Then I'll add another line after the initial `pip install` and add `npm install`:  
 

```shell-session
# Hooks allow you to customize your code/environment as the project moves through the build and deploy stages
# More information: https://docs.upsun.com/create-apps/app-reference.html#hooks
hooks:
 # The build hook is run after any build flavor.
 # More information: https://docs.upsun.com/create-apps/hooks/hooks-comparison.html#build-hook
 build: |
   set -eux
   pip install --upgrade pip
   pip install -r requirements.txt
   npm install 
```

You also need to inform Upsun what should occur when your application is deployed. The deploy hook is similar to the build hook but runs after the application image has been built. At this stage the application image is read-only, but your writable disk space has been mounted and is now accessible. Find the `deploy:` YAML key, add a new line after `set -eux`, and add `npm run build`.

```shell-session
# The deploy hook is run after the app container has been started, but before it has started accepting requests.
  deploy: |
    set -eux
    npm run build
```

Next, we need to configure how Upsun will handle requests to this application image. In `./.upsun/config.yaml` locate the line that starts with `# The web key configures the web server running in front of your app`. Beneath that line there should be a YAML property of `commands:`.  A few lines beneath that line will be a YAML property of `start:`. Once again, the CLI tool already added some information here, but since it doesn't know the specifics of what needs to be used, it simply left instructions for you to replace with your own start command. For now, you only need the basic Flask server, so replace the current contents with `flask run -p $PORT`. 

```shell-session
web:
 # Commands are run once after deployment to start the application process.
 # More information: https://docs.upsun.com/create-apps/app-reference.html#web-commands
 commands:
   # The command to launch your app. If it terminates, it's restarted immediately.
   # You can use the $PORT or the $SOCKET environment variable depending on the socket family of your upstream
   start: "flask run -p $PORT"
```

Since you're using the Flask server (for now), you will also need to change the `socket_family` from `unix` to `tcp`:

```shell-session
start: "flask run -p $PORT"
# You can listen to a UNIX socket (unix) or a TCP port (tcp, default).
# Whether your app should speak to the webserver via TCP or Unix socket. Defaults to tcp
# More information: https://docs.upsun.com/create-apps/app-reference.html#where-to-listen
upstream:
 # Whether your app should speak to the webserver via TCP or Unix socket. Defaults to tcp
 # More information: https://docs.upsun.com/create-apps/app-reference.html#where-to-listen
 socket_family: tcp
```

We've now added all the configuration Upsun needs to be able to build and deploy your application! Let's go ahead and commit these changes:

```shell-session
> git add ./upsun/config.yaml
> git commit -m "adds FLASK_APP env var, adds mount for static builds, build commands, npm run build on deploy, web start command"
```

### **Preparing the application for Upsun**

While we've finished telling Upsun what it needs to do to build and deploy your application, your application still needs to know some things about Upsun. This type of information typically goes into your `.env` file. Upsun generates all of this type of data and exposes it to the application as environmental variables in the deployed image. Since the information is dynamic, and changes from environment to environment, you don't want to commit those static values in a `.env` file. Instead, Upsun supports a `.environment` file that is sourced in the application image, as well as your shell when you SSH into the container. For a list of all the variables that Upsun generates, please refer to the documentation on the provided environmental variables.

  
Open the `.environment` file that the CLI tool generated earlier. Notice it has already created some environmental variables for you to connect to your database service. However, since you will later need to use a tunnel to generate your migration files, you need to replace what the Upsun CLI tool generated, and replace it with the following:

```shell-session
export RELATIONSHIPS_JSON="$(echo $PLATFORM_RELATIONSHIPS | base64 --decode)"

# Set database environment variables
export DB_HOST="$(echo $RELATIONSHIPS_JSON | jq -r '.postgresql[0].host')"
export DB_PORT="$(echo $RELATIONSHIPS_JSON | jq -r '.postgresql[0].port')"
export DB_DATABASE="$(echo $RELATIONSHIPS_JSON | jq -r '.postgresql[0].path')"
export DB_USERNAME="$(echo $RELATIONSHIPS_JSON | jq -r '.postgresql[0].username')"
export DB_PASSWORD="$(echo $RELATIONSHIPS_JSON | jq -r '.postgresql[0].password')"
export DB_CONNECTION="$(echo $RELATIONSHIPS_JSON | jq -r '.postgresql[0].scheme')"
export DATABASE_URL="postgresql://${DB_USERNAME}:${DB_PASSWORD}@${DB_HOST}:${DB_PORT}/${DB_DATABASE}"
```

You'll need to add a few more for our Flask application so Flask has what it needs to be able to function properly. To start, you need to add the remainder of the variables that are defined in `.env`. You already took care of `FLASK_APP` in the `./.upsun/config.yaml` file so that leaves the following: 

-   `FLASK_ENV`
-   `FLASK_DEBUG`
-   `LOG_LEVEL`
-   `SEND_FILE_MAX_AGE_DEFAULT`
-   `SECRET_KEY`
-   `GUNICORN_WORKERS`

Upsun provides us with information about what type of environment the application is running in via an environmental variable named `PLATFORM_ENVIRONMENT_TYPE`, the values of which can be production, development, or staging. Inside of the `.environment` file, add the following line:

```shell-session
export FLASK_ENV="${PLATFORM_ENVIRONMENT_TYPE}"
```

However, several of the other environmental variables also need to change whether or not you are on a production environment so you can leverage the information in `PLATFORM_ENVIRONMENT_TYPE` to not only set `FLASK_ENV` but also several of the other variables. You only want `FLASK_DEBUG` enabled (1) if you're not running in production. Inside the .environment file, add the following line:

```shell-session
export FLASK_DEBUG=$( [ "${PLATFORM_ENVIRONMENT_TYPE}" = "production" ] && echo 0 || echo 1)
```

If the environment you're in is production, you'll return 0 (disabled), otherwise you'll return 1 (enabled). Let's do something similar for `LOG_LEVEL`. Inside the `.environment` file, add the following line:

```shell-session
export LOG_LEVEL=$( [ "${PLATFORM_ENVIRONMENT_TYPE}" = "production" ] && echo "info" || echo "debug")
```

If the environment you're in is production, set `LOG_LEVEL` to "info", otherwise set it to "debug". 

The last environmental variable that needs to be different based on environment type is `SEND_FILE_MAX_AGE_DEFAULT` where we want it to be 0 if we're not in production, but a higher value if we are. Inside the `.environment` file, add the following line: 

```shell-session
export SEND_FILE_MAX_AGE_DEFAULT=$( [ "${PLATFORM_ENVIRONMENT_TYPE}" = "production" ] && echo 31556926 || echo 0)
```

The next environmental variable you need to set is `SECRET_KEY`. It is used for securely signing the session cookie and can be used for any other security-related needs by extensions or your application. It should be a long random string. Again, Upsun provides us with something for exactly this as an environmental variable: `PLATFORM_PROJECT_ENTROPY`. Inside the `.environment` file, add the following line:  

```Javascript
export SECRET_KEY="${PLATFORM_PROJECT_ENTROPY}"
```

Since for now we're using Flask as our web server, you can skip adding `GUNICORN_WORKERS` to your `.environment` file. We'll cover switching to gunicorn in a later blog post.

Your `.environment` file should now look similar to the following:

```shell-session
# Set database environment variables
export DB_HOST="$POSTGRESQL_HOST"
export DB_PORT="$POSTGRESQL_PORT"
export DB_PATH="$POSTGRESQL_PATH"
export DB_USERNAME="$POSTGRESQL_USERNAME"
export DB_PASSWORD="$POSTGRESQL_PASSWORD"
export DB_SCHEME="postgresql"
export DATABASE_URL="${DB_SCHEME}://${DB_USERNAME}:${DB_PASSWORD}@${DB_HOST}:${DB_PORT}/${DB_PATH}"

export FLASK_ENV="${PLATFORM_ENVIRONMENT_TYPE}"
export FLASK_DEBUG=$( [ "${PLATFORM_ENVIRONMENT_TYPE}" = "production" ] && echo 0 || echo 1)
export LOG_LEVEL=$( [ "${PLATFORM_ENVIRONMENT_TYPE}" = "production" ] && echo "info" || echo "debug")
export SEND_FILE_MAX_AGE_DEFAULT=$( [ "${PLATFORM_ENVIRONMENT_TYPE}" = "production" ] && echo 31556926 || echo 0)
export SECRET_KEY="${PLATFORM_PROJECT_ENTROPY}"
```

Since you've made changes to your `.environment` file, you'll need to commit those changes before pushing the repository to Upsun:

```shell-session
> git add .environment
> git commit -m "adds needed flask environmental variables"
```

Now you can push the changes to Upsun and activate your initial environment:

```shell-session
> upsun environment:push
```

Answer `Y` to the question: `Are you sure you want to push to the main (type: production) branch?`

Upsun will now read your configuration files, and begin building your application image. Assuming you have no syntax errors in your configuration files, it should build and deploy your image and at the end of the process, report back the URLs associated with our project. 

### **Setting up the database**

You may have noticed that we haven't done anything in regard to a database. This application uses Flask-migrate and since this is a brand new application, you'll need to set up the initial migrations, and commit them so you can then have them applied to our Upsun database. However, because the migrate command needs access to the database, you'll need to set up a temporary local environment and give it a way to access the database service. Let's first set up a virtual environment to run your project inside of:

```shell-session
> python3 -m venv env && source venv/bin/activate
```

Just like in your build hook, update pip and install your requirements:

```shell-session
> pip install --upgrade pip
> pip install -r requirements.txt
```

Next you're going to set up this local instance so it can communicate with your database service. When you pushed to Upsun previously, it created and deployed your database service. The Upsun CLI tool gives you a method to communicate with your application's services: upsun tunnel

```shell-session
> upsun tunnel:open -y
```

This opens an SSH tunnel to all the services for the application, and you can now use it to allow your local instance to communicate with them as if they were local too. To do that though, you'll need to configure some environmental variables similarly to how you did previously. If you reopen the `.environment` file, you'll notice at the top that we make use of an environment variable named `$PLATFORM_RELATIONSHIPS` to retrieve information about services and their credentials. The tunnel you created gives you access to that same data, allowing you to generate a local `PLATFORM_RELATIONSHIPS` environment variable containing the same information.

```shell-session
> export PLATFORM_RELATIONSHIPS="$(upsun tunnel:info --encode)"
```

If you now try `echo $PLATFORM_RELATIONSHIPS` you'll see it has been set to a fairly large base64 encoded value. This string contains your services, their definitions, locations, and most importantly, their credentials. Because you have this environmental variable set locally, you can reuse your `.environment` file for Upsun to recreate many of the other environmental variables you need to run locally. 

Although, you will have a few that aren't set via `PLATFORM_RELATIONSHIPS` that you still need to be set up.

```shell-session
> export PLATFORM_ENVIRONMENT_TYPE=production
> export PORT=8888
> export PLATFORM_PROJECT_ENTROPY=$(openssl rand -base64 32)
```

Lastly, `source` your `.environment` file to finish setting up all the environmental variables in your current shell:

```shell-session
> source ./.environment
```

You now have everything you need for Flask-Migrate to be able to connect to the database and generate your migration files. First, you need to have Flask-Migrate initiate the migrations directory and prepare for the migrate command:

```shell-session
> flask db init 
```

Now you can have Flask-migrate generate your migrations:

```shell-session
> flask db migrate
```

And then commit your generated migrations:

```shell-session
> git add migrations/*
> git commit -m "adds migrations"
```

You now need to instruct Upsun to run the Flask-Migrate upgrade command when deploying so you know any migration changes are automatically applied. Re-open the `./.upsun/config.yaml` and find the deploy hook where you added `npm run build`. On the next line, add `flask db upgrade`: 

```shell-session
# The deploy hook is run after the app container has been started, but before it has started accepting requests.
# More information:    https://docs.upsun.com/create-apps/hooks/hooks-comparison.html#deploy-hook
      deploy: |
        set -eux
        npm run build
        flask db upgrade
```

Commit the changes:

```shell-session
> git add ./.upsun/config.yaml
> git commit -m "adds flask db upgrade to deploy hook"
```

And finally, push everything up to your Upsun environment!

```shell-session
> upsun environment:push -y
```

**Congrats!** You've now successfully deployed your Flask application to Upsun, take a moment to visit your site and test it out. 

In future posts, we'll explore the different options you have for web servers, a more robust local development environment, adding source control integration, and adding various services to your project. But for now, go forth and deploy (even on Fridays)!

The complete `.upsun/config.yaml` and `.environment` files are available on GitHub.

### **A quick step-by-step**

For those of you who prefer to just get started as soon as possible, here is a quick and simple step-by-step guide: 

\`T:\` - run the line in a terminal/command prompt

1.  T: `pip3 install cookiecutter`
2.  T: `cookiecutter https://github.com/cookiecutter-flask/cookiecutter-flask.git`
3.  Answer questions:
    1.  Name
    2.  Email
    3.  Github\_username
    4.  Project name
    5.  App name
    6.  Description
    7.  Pipenv
    8.  Python version
    9.  Node version
    10.  heroku
4.  Cd into the directory (should be what you answered for 3e)
5.  T: `git init .`
6.  T: `git branch -m main`
7.  T: `upsun project:init`
    1.  Select Python
    2.  Select Postgres 
8.  T: `git add .`
9.  T: `git commit -m "init commit"`
10.  T: `upsun p:create`
11.  Answer questions
     1.  Choose your org
     2.  Give it a title
     3.  Choose a region
     4.  Enter the branch name from #7
     5.  Set the project as the remote (for now)
     6.  Select Y to "continue"
12.  Open `./.upsun/config.yaml`
     1.  Find the section describing "Variables"
     2.  Uncomment "# variables" and the next line "env:"
     3.  On the next line, add FLASK\_APP: autoapp.py
     4.  Find the section describing "mounts"
     5.  Uncomment "# mounts:"
     6.  On the next line add   
           "<name-of-your-app-from-3e-above>/static":  
             source: storage  
             source\_path: static\_build
     7.  Find the section for hooks:build
     8.  On the line before pip install, add the following:  
         pip install --upgrade pip
     9.  On the line below pip install, add the following  
         npm install
     10.  Scroll down to the deploy section
     11.  On the line after set -eux, add  
          npm run build
     12.  Find the section web:commands:start and change it to   
          start: flask run -p $PORT
     13.  Below this find the section for upstream:socket\_family and either comment out both lines, or change "unix" to "tcp"
13.  T: `git add ./.upsun/config.yaml`
14.  T: `git commit -m "adds FLASK_APP env var, adds mount for static builds, build commands, npm run build on deploy, web start command"`
15.  Open .environment file
     1.  Remove everything and replace with:  
         \# Set database environment variables  
         export RELATIONSHIPS\_JSON="$(echo $PLATFORM\_RELATIONSHIPS | base64 --decode)"  
         \# Set database environment variables  
         export DB\_HOST="$(echo $RELATIONSHIPS\_JSON | jq -r '.postgresql\[0\].host')"  
         export DB\_PORT="$(echo $RELATIONSHIPS\_JSON | jq -r '.postgresql\[0\].port')"  
         export DB\_DATABASE="$(echo $RELATIONSHIPS\_JSON | jq -r '.postgresql\[0\].path')"  
         export DB\_USERNAME="$(echo $RELATIONSHIPS\_JSON | jq -r '.postgresql\[0\].username')"  
         export DB\_PASSWORD="$(echo $RELATIONSHIPS\_JSON | jq -r '.postgresql\[0\].password')"  
         export DB\_CONNECTION="$(echo $RELATIONSHIPS\_JSON | jq -r '.postgresql\[0\].scheme')"  
         export DATABASE\_URL="postgresql://${DB\_USERNAME}:${DB\_PASSWORD}@${DB\_HOST}:${DB\_PORT}/${DB\_DATABASE}"
     2.  Add the following lines to .environment:  
         export SECRET\_KEY="${upsun\_PROJECT\_ENTROPY}"  
         export FLASK\_DEBUG=$( \[ "${upsun\_ENVIRONMENT\_TYPE}" = "production" \] && echo 0 || echo 1)  
         export FLASK\_ENV="${upsun\_ENVIRONMENT\_TYPE}"  
         export GUNICORN\_WORKERS=1  
         export LOG\_LEVEL=$( \[ "${upsun\_ENVIRONMENT\_TYPE}" = "production" \] && echo "info" || echo "debug")  
         \# In production, set to a higher number, like 31556926  
         export SEND\_FILE\_MAX\_AGE\_DEFAULT=$( \[ "${upsun\_ENVIRONMENT\_TYPE}" = "production" \] && echo 31556926 || echo 0)
16.  T: `git add .environment`
17.  T: `git commit -m "adds needed flask env vars"` 
18.  T: `upsun e:push`
     1.  Answer Y
19.  At the end of the deploy, you'll be given your project's URL
20.  T: `python3 -m venv env`
21.  T: `source venv/bin/activate`
22.  T: `pip install --upgrade pip`
23.  T: `pip install -r requirements.txt`
24.  T: `upsun tunnel:open -y`
25.  T: `export upsun_RELATIONSHIPS="$(upsun tunnel:info --encode)"`
26.  T: `export PORT=8888`
27.  T: `export upsun_PROJECT_ENTROPY=$(openssl rand -base64 32)` 
28.  T: `export upsun_ENVIRONMENT_TYPE=production`
29.  T: `source ./.environment`
30.  T: `flask db init`
31.  T: `flask db migrate`
32.  Open `./.upsun/config.yaml`
     1.  Find the section for hooks:deploy
     2.  On a new line after \`npm run build\`, add \`flask db upgrade\`
33.  T: `git add migrations/*`
34.  T: `git commit -m "adds migrations"`
35.  T: `git add ./.upsun/config.yaml`
36.  T: `git commit -m "adds flask db upgrade to deploy hook"`
37.  T: `upsun environment:push`

### [What is WebOps? How modern teams build and scale websites](https://upsun.com/blog/webops/)

# What is WebOps?

If your organization is managing multiple websites, you’ll understand the challenges involved in keeping everything updated and running smoothly. Deployment, modification, and approval are time-consuming tasks—but the WebOps approach means they don’t have to be.

So, what exactly is WebOps, and how does it help you scale your websites? Read on to discover more and learn how Upsun can help.

## **What is WebOps and how does it scale your websites?**

WebOps, sometimes styled as web ops, is short for website operations. It’s an amalgamation of practices designed to streamline the creation of web-based applications from development all the way to release and maintenance. It helps development teams build better websites faster and continuously improve the digital experience. 

With cross-functional teams working in parallel, they can deploy and manage multiple websites and apps more effectively—which is ideal for larger organizations or those ready to scale. This is achieved through a dedicated WebOps platform, which streamlines every aspect of development, deployment, and maintenance.

WebOps platforms integrate DevOps capabilities and best practices alongside website creation and may also incorporate web hosting, load balancing, load testing tools, and CDNs. To qualify for inclusion in the WebOps category, a product must include:

-   Developer-focused tools for website creation and maintenance
-   Automation for repetitive processes
-   Web-dedicated content management
-   Support for traditional and headless CMS

Because teams can automate tasks for speed and consistency, they’re able to achieve more in less time. 

WebOps platforms may deliver any of the following:

-   Platform as a Service (PaaS)
-   Infrastructure as a Service (IaaS)
-   Software as a Service (SaaS)
-   Mobile Backend as a Service (MBaas)
-   Database as a Service (DBaas).

## **Why use WebOps?**

WebOps platforms are designed to optimize the performance of websites and apps. The key benefits include significant improvements in:

**Speed:** By  automating manual tasks associated with managing web applications, you can increase deployment times and free up staff to focus on other tasks.

**Scalability:** WebOps allows you to scale your applications quickly and easily, handling sudden traffic spikes and giving you flexibility during slow periods.

**Visibility:** You can view your app’s performance in real time, identify potential problems before they escalate, and gain insights on areas for improvement.

**Collaboration**: By merging the personas of dev teams and web creators within a shared environment, WebOps platforms enable teams to collaborate more efficiently.

**Cost savings:** Cloud computing infrastructure enables you to reduce operational costs and increase your WebOps ROI. Pay-as-you-go pricing models are ideal for low or unpredictable usage.

**Security****:** WebOps platforms typically include encryption and authentication protocols, integrated firewalls, and breach detection systems.

**User experience:** Ultimately, WebOps helps you  provide end users with a better web experience, including faster load times, consistent uptime, and more relevant content.

Upsun delivers on all of the above through automation, built-in continuous deployment, and managed infrastructure. For example, Comic Relief’s technology team turned to us when they needed a more robust development platform. They wanted to iterate faster and create more preview environments, but their WebOps team was busy reviewing multiple features at once.

Our GitHub integration automates that process, giving every feature its own environment. Automation also covers setting up new environments and applying changes from the feature branch. Now, product managers can quickly show features to stakeholders—and the increase in productivity enabled 85% of DevOps/QA resources to be reallocated to other tasks.

## **Features a WebOps platform must have**

WebOps platforms often include unified tools with multiple components. Here are the key features to look out for:

**Automation:** This is crucial for handling those time-consuming manual tasks, such as app deployment and scaling, and fault detection and resolution. Automation reduces the chance of human error, while automated testing helps you find bugs earlier. You can set actions like deployments or incident responses to be triggered automatically when specific events occur, enabling you to respond quickly when needed. Automated backups are a must-have, too.

**Monitoring****:** By monitoring servers and databases, you can spot problems with web apps (such as inefficient or faulty code), respond quickly to outages, and proactively address performance issues. This includes server-side logging, which monitors the app’s behavior on the server side and shows you things like incoming requests sent by a user’s device and how the server handled those requests.

**Analytics dashboard:** Alongside monitoring capabilities, a dashboard helps you make sense of data about the application’s usage and availability, based on metrics like latency and response times. You’ll be able to detect any unexpected behavior and react to anomalies. Over time, you can spot trends or patterns that reveal a need for optimization.

**Website staging****:** WebOps platforms typically include pre-production environments where developers can build and test site updates before committing to deploying them. Doing this without navigating away from the WebOps platform is a real timesaver. Look for performance testing functionality, which ensures that a new app version’s code is up to standard before going live—and helps reveal how different components respond under various conditions.

**Role-based permissions****:** This feature is very important when different teams are working together. It allows administrators to assign different types of tasks by persona, making task allocation and handoff points clearer and building a more efficient workflow.

Other features to look for include:

-   **Website hosting:** Many WebOps platforms offer a full hosting service—in other words, they provide and manage the servers that keep your websites live.
-   **Infrastructure management:** These tools include virtualization technologies such as containers and serverless computing.
-   **Robust security****:** For example, authentication mechanisms, firewalls, and vulnerability management tools.

## **Upsun: Top choice among leading WebOps platforms**

Upsun is a cloud-based WebOps platform in which you can build, deploy, and manage multiple websites and apps—at speed and at scale. In addition to  supercharged web hosting, we provide a secure, fully built, managed infrastructure so your developers and creators can focus on their core tasks.

Automation helps you to deploy faster and more often. Because it’s a unified PaaS package, with all the tools you need in one handy place, you’ll see further cost savings. And you can scale resources seamlessly to meet business demands.

### **Multiple choice**

With us, you can host your apps and websites on the tech stacks or cloud platforms of your choice. Whether it’s PHP, Java, Node.js, Python, Golang, Ruby, Drupal, WordPress, Symfony, Django, React, or Angular, you can build exactly what you want, how you want, experiment with new technologies, and become more future ready.

You won’t find this capability with managed hosting providers, IaaS providers, or traditional DevOps tools.

### **Global cloud hosting**

We provide a single, global, secured cloud infrastructure for deployment, and offer you the option of data regions in North America, APAC, and Europe. This enables you to meet the needs of thousands of customers in different locations and industries, while still complying with local data protection laws.

Case study: BoardSpot provides custom website development for nonprofits via a portal with a set of integrated tools. To bring this vision to life, the BoardSpot team recognized early on that they’d need to develop this portal with a new set of tools and features. These needed to be powerful enough to support the needs of enterprise-scale nonprofits while still being intuitive enough for volunteer board members to feel comfortable with immediately.

They used Upsun to put it together, running multiple versions of the codebase in regions across the world. Their engineers are now able to work swiftly to roll out quick updates and take the time needed to properly plan and build big new features.

### **Git-based architecture**

Because we use a Git-based architecture for managing changes and deployment, you won’t have to learn a new set of commands to deploy applications. All you need to do is set your project remote, then add, commit, and push your application as you’d do for GitHub. You can also create an instant application clone for every Git branch, giving every feature, team, or developer a perfect copy of production to work in, test with, or share with stakeholders.

### **Efficient management**

From the management console, you can scale, run, and deploy your applications right from the browser—while the CLI lets you manage Upsun projects directly from your terminal. We can help you build, launch, and manage your websites and apps, even if there are hundreds of them. Our solution connects all your platforms, tools, and clouds, and reduces your carbon footprint.

### **Continuous integration and development**

Upsun is built around the practice of CI/CD, which keeps your codebase updated and helps your application processes run smoothly—reducing technical debts, incidents, and disasters in your code or applications. Developers have the power to define what happens at every point in the two deployment phases (Build and Deploy), so they can test every idea in full and merge seamlessly into production. Apps and services are automatically containerized and deployed to the Upsun grid.

Case study: Web dev agency Thinkbean significantly improved its WebOps efficiency and stability with Upsun, and reduced technical support resolution times from days to minutes. The firm also leveraged Upsun integrations and automation, including backups, Drupal security checks, SSL expiration checks, and redeployments for certificate renewals. The team can now focus their time on creative thinking and solution building.

### **Top security**

We understand that WebOps requires top-notch security and compliance. Our platform enables you to deliver your applications securely with the use of cryptography, permissions, and access management. Each environment is automatically secured with SSL, plus robust access control to tailor your workflow to your release process. 

We are committed to data security and undergo a SOC 2 Type 2 examination over Security, Privacy, and Availability annually. Additionally, we are PCI DSS Level 1 compliant for our platform hosted on Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). 

You’ll always maintain full control of your data, as well as governance over process, code, and infrastructure for distributed teams. And you’ll be informed instantly if a data breach is detected.

## **Choose the right WebOps platform for your business**

WebOps platforms can vary greatly in terms of price, features, and functionality. But if you want a platform that’s fully flexible and scalable, and can handle high-performance websites, it’s best to choose an enterprise-grade solution—like Upsun.

Our service makes it easy to collaborate (you can share environments with a single click), and increases your overall efficiency with continuous deployment and automated workflows (such as one-click deployment of new apps).

With all your tools in a unified solution, you’ll boost productivity, improve the user experience, and reduce operational costs.

### **FAQs about WebOps**

#### **Who uses WebOps?**

WebOps is used by a wide range of professionals. Web development teams are among the heaviest users, including DevOps specialists who use the platform to automate deployment processes as well as quickly set up environments and test code changes.

As we’ve seen, marketers and web creators also use WebOps to coordinate front-end operations such as managing website content and ensuring brand consistency across sites.

For web developers, web operations platforms make it easier to modify existing systems and deploy updates. IT managers use the software to ensure their operations are up-to-date and secure.

WebOps platforms help to identify inefficient processes and suggest improvements. And security professionals use WebOps to keep organizations safe from cyber threats and ensure they can respond quickly in the event of a breach.

#### **What is the difference between DevOps and WebOps?**

WebOps and DevOps are both about creating a more collaborative approach by getting teams to work together instead of in silos. And WebOps uses the principles and best practices of DevOps, so there are similarities. But when it comes to WebOps vs DevOps, how are they different?

You already know what WebOps does (or you should if you’ve read this article!). But what about DevOps? Short for development operations, it’s an agile approach to creating, testing, and releasing software. It uses continuous integration and continuous deployment to automate development tasks and accelerate the delivery pipeline.

While DevOps combines software development and software operations into a single team, WebOps brings in content creators and marketers to work alongside developers in order to manage websites more effectively.

### [Gevent in practice: Common pitfalls to keep in mind | Upsun](https://upsun.com/blog/python-gevent-best-practices/)

# Python Gevent in practice: common pitfalls to keep in mind

Gevent is a Python networking library that uses libev and libuv for its event loop and greenlet for asynchronous tasks, offering essential abstractions for server development.

Historically, Eve Online adopted Stackless Python for its backend servers, utilizing _tasklets_ or microthreads. These _tasklets_ allowed thousands of requests to run in parallel within a single thread, avoiding the performance and complexity issues tied to threads. Stackless Python later evolved into Eventlet, inspiring Gevent—an asynchronous library ideal for developing high-performance networking applications, benefiting from Python's readability and rapid development. These factors are major contributors to Upsun's choice of Gevent for some internal services like our Project API.

This article assumes that you, our reader, are familiar with Python Gevent's core concepts like cooperative multitasking, event loops, greenlets, and concurrent scheduling. You can find some good articles on these subjects here and here. Allowing us to focus on best practices and common pitfalls in Gevent, often applicable to other asynchronous libraries.

## Common pitfalls

### Monkey patching

In Gevent, monkey patching is an optional technique that replaces the blocking calls in the standard library with cooperative alternatives, and is widely used in practice. If you choose not to employ monkey patching, you'll be responsible for managing greenlets yourself, which could be desirable depending on your use case.

Gevent originated at a time when Python didn't natively support asynchronous programming—no async or await keywords. Traditional web server applications were either built using a pre-fork model or relied on multiple threads for concurrency. Gevent aimed to make existing multithreaded code concurrent without relying on actual Operating System (OS) threads. Sometimes, this could be done even without changing a single line of code in your application.

For example, in a multithreaded environment, when a blocking function like \`socket.recv\` is called, the kernel handles the scheduling of threads. In contrast, Gevent employs lightweight threads, known as greenlets, that run concurrently within a single OS thread. To handle multiple blocking functions within this single thread, Gevent monkey patches the Python standard library. This involves replacing the library's blocking functions with versions that use the event loop to wait asynchronously for operations to complete.

For monkey patching to work effectively, certain guidelines must be strictly followed:

-   The patching should be done as early as possible in the code. If you delay, there's a risk that another part of your code might import a module that uses the original, unpatched functions, leading to conflicts.
-   Monkey patching should be performed on the main thread. This ensures that the patches take effect across all greenlets.
-   The patching process should occur when the application is still single-threaded. This is crucial because Gevent's monkey patching also alters the threading library. If you've already spawned multiple threads using the unpatched threading module, conflicts could arise.

These guidelines are not just best practices; they come directly from the official documentation for Gevent's monkey patching. Not adhering to these rules could result in unpredictable, hard-to-diagnose errors due to conflicts between patched and unpatched code.

### Blocking calls

Even when you've carefully implemented monkey patching in Gevent, a single greenlet can still block the entire process. This is especially true for file read/write operations. Despite the benefits of monkey patching, file I/O operations are still synchronous on some operating systems, which means they can become a bottleneck.

However, there is a strategy to get around this limitation. Python Gevent offers the option to perform concurrent file I/O by utilizing a thread pool. This approach allows the file operations to be handled in a way that doesn't block the rest of the application. So, while monkey patching solves many issues related to asynchronous programming, it's essential to be aware of its limitations and know how to navigate them to ensure a truly non-blocking application.

#### Third-party libraries

Even with Gevent's capabilities, it's crucial to note that it can't make third-party libraries asynchronous if they don't use Python's standard library for blocking calls. If you're using an external library that makes its own blocking calls, you may not discover the issue until your application is in a production environment.

This is where performance regression tests or load testing can come in handy. When a greenlet is blocked on I/O, the issue usually manifests as suboptimal CPU utilization alongside stagnant throughput. Under normal circumstances, you should only hit throughput limits when CPU usage is at or above 100%. Therefore, if you observe low CPU usage and no increase in throughput during load testing, it's likely a sign of a blocking greenlet.

To resolve this, you'll need to identify the problematic third-party library and its specific blocking function. Solutions might involve switching to an alternative library or modifying the current one, although neither is typically straightforward.

#### CPU intensive code

Running CPU-intensive code in a single Python greenlet can block other greenlets from executing, leading to what's known as _greenlet starvation_. Debugging this issue is complex, as you need to observe the context-switching trends to identify if certain greenlets are monopolizing CPU time.

To address this, you have a few options:

1.  Offload CPU-heavy tasks to a separate process or thread, ideally using a pool. This segregates I/O-bound and CPU-bound work, preventing them from interfering with each other.
2.  If separating the workloads isn't feasible—perhaps because you need to perform a CPU-intensive task and immediately return the result—explicitly yield the greenlet to allow other greenlets to run.

It's important to note that Gevent is not ideal for CPU-intensive tasks. This limitation is not unique to Gevent; other asynchronous libraries like Asyncio and Node.js also face similar challenges.

### Greenlet safety

Thread safety is a well-known concept in the multithreaded world. It involves protecting shared resources from concurrent access by multiple threads. While traditional threads can context-switch at any time, requiring manual conflict resolution (using mutexes), one might assume that asynchronous libraries like Python Gevent would automatically resolve such issues. However, that's not the case.

Even though asynchronous libraries like Gevent don't have the same level of complexity as traditional preemptive threads, they still involve shared resources accessed by different greenlets. This can lead to subtle, sometimes hard-to-detect issues.

Think about the following code:

```Python
def withdraw(self, amount):
    if self.balance >= amount:
        withdraw_from_db(amount)
        self.balance -= amount
```

Suppose the above code is called by multiple greenlets and withdraw\_from\_db() is a call that yields execution. Since self.balance is a shared resource, it is highly possible that withdraw can happen multiple times even if the balance is not enough. The issue is balance is read and a context switch might happen and the second self.balance we read might not be the same as we read first.

There is a native lock support in Gevent. But I would suggest that you design the way you access your shared resources so that you minimize this as much as possible because whenever you use a lock, that blocks other greenlets from running, which is exactly the opposite of concurrency. Moreover, it is highly probable that you will use the lock when you have a blocking call, but this might be a recipe for disaster. For example, maybe you can implement the withdrawal logic using a database transaction and remove self.balance from the code. There might as well be other ways to circumvent this problem, it just needs to be thought out carefully.

### Conclusion

Like any framework, Gevent has its ups and downs. While it offers the advantage of asynchronous programming with less complexity than traditional multithreading, it's not a silver bullet for all concurrency challenges. It's essential to be vigilant about these limitations and possible pitfalls to make the most effective use of Gevent in your applications. Let us know what your Gevent pitfalls have been on our Community.

### [How to spot Upsun infrastructure processes on Blackfire timeline | Upsun](https://upsun.com/blog/blackfire-infrastructure-processes/)

# Up(sun) and running with infrastructure processes on Blackfire

Encountering an event that impacts application behavior and performance is inevitable, however, implementing an Observability strategy for production websites which benefits from as much context as possible gives you the best overview of your applications. Helping you to identify potential bottlenecks and ensure a seamless user experience.

Adding infrastructure information to an Observability dashboard lets you understand what was done on the infrastructure side and, if necessary, diagnose problems as quickly as possible. Is this resource consumption spike due to a traffic spike or due to something that occurred on the infrastructure side? Is a request delay due to a newly launched ad or a newly deployed service? Each result requires a different response, so any added context to your Observability dashboard helps you to split apart internal and external causes.

In the meantime, Upsun gives you access to all of the infrastructure processes that occur in your environment/project/integration/maintenance and lets you trigger an action for each of them. For each infrastructure process, you can decide what to do: send a notification to a specific Slack channel, send information to a custom endpoint (webhook), execute a dedicated script, send information to Newrelic, the list goes on. 

An Activity script is a piece of code, written in ES2021 (Javascript) that can be executed to do anything you want. The glue between those two, _Activity scripts_ and _Infrastructure processes_, is done using an integration.

This integration needs to be configured with parameters, defining which **action** you want to execute, on which **environments**, and which **events** and corresponding **states** trigger this Activity script. 

-   **Action:** For the purpose of this article, we will use the action `script` (=execute an Activity script) but you can find the full list of possible actions here. We will also need to define which script (option `--file`) we want to execute.
-   **Environment:** It could be set to all environments, but in our case, let's say we just want to handle infrastructure processes from the production environment (`main`).
-   **Event:** In our case, we want to send to my monitoring dashboard any infrastructure event, but if you want to fine tune it, a complete list of possible infrastructure events can be founded here (= Activity script types).
-   **State:** There are 3 available states, `pending`, `in_progress`, and `complete`. In our case, `pending` operations won’t have any impact on your application (Upsun internal usage) so we will focus on `in_progress` and `complete` states.  
     

Upsun uses Blackfire as its integrated APM/Continuous profiling tool, and its usage is included (as far as I’m writing this article) on all of your Upsun projects. 

Blackfire provides a REST endpoint to add markers, using a simple curl call with your credentials (`blackfire_server_id` and `blackfire_server_token`) and the message you want to display on your Blackfire Timeline.

We now have great ingredients for our recipe: how to send infrastructure processes to your Blackfire monitoring. Let’s add Upsun infrastructure processes in our Blackfire timeline. 

**Please note**: The processes/commands in this article can also be applied to Platform.sh projects by replacing `upsun` CLI by `platform` CLI.

## Spot Upsun infrastructure processes in your Blackfire timeline

To spot Upsun infrastructure processes to the Blackfire timeline, we will need:

-   An Activity script, which will add new markers on your Blackfire environment.
-   An Activity script integration to trigger this Activity script on any occurring infrastructure processes.

These are the minimum steps for your Upsun environment to send infrastructure processes to your Blackfire environment. 

**Please note**: We assume in this blogpost that you already host your application on Upsun. If you don’t, take a look at our Up(sun) and running with Symfony Demo guide and use this project for your test.

Go to the root of your local project source code and follow these steps: 

1\. Create a new Javascript file (our Activity script file) at the root of your source code,  `blackfire-notifier.js` (source here) with the following command line:

```shell-session
curl -L https://raw.githubusercontent.com/upsun/snippets/main/src/blackfire-notifier.js > blackfire-notifier.js
git add blackfire-notifier.js && git commit -m "Add blackfire-notifier.js"
```

**Please note**: This Javascript script is framework agnostic, feel free to customize the marker message (size is set up to 64 characters).

This `blackfire-notifier.js` Javascript file is using 2 environment variables, `blackfire_server_id` and `blackfire_server_token` to send corresponding infrastructure processe info (`state` and `type`, ex: `(start|stop) Florent Huck redeployed environment Main` ) to your Blackfire environment, using the dedicated Blackfire REST endpoint to add markers.

2\. Add an Activity script integration for this new `blackfire-notifier.js` script:

```shell-session
upsun integration:add --type=script --file ./blackfire-notifier.js --events \* --states in_progress,complete --environments main
```

With this integration, Upsun will execute `blackfire-notifier.js` script for all infrastructure processes (with state `in_progress` or `complete`) on your `main` environment.

**Please note**: You will need to copy the `<INTEGRATION_ID>` (id) that is output after the command above and use it with next command lines.

3\. Forward Blackfire credentials, `BLACKFIRE_SERVER_ID` and `BLACKFIRE_SERVER_TOKEN` to your activity script:

From the root of your Upsun project, execute the 2 following command lines:

```shell-session
upsun project:curl /integrations/<INTEGRATION_ID>/variables -X POST -d '{"name": "blackfire_server_id", "value": "'$(upsun ssh 'echo $BLACKFIRE_SERVER_ID')'", "is_sensitive": true, "is_json": false}'
upsun project:curl /integrations/<INTEGRATION_ID>/variables -X POST -d '{"name": "blackfire_server_token", "value": "'$(upsun ssh 'echo $BLACKFIRE_SERVER_TOKEN')'", "is_sensitive": true, "is_json": false}'
```

**Please note**: You need to replace with your integration ID created on step 2.

4\. Test it. 

To test the integration of your Activity script, just trigger an infrastructure process on your project:

```shell-session
upsun project:clear-build-cache && upsun environment:redeploy -y
```

New markers should appear on the Blackfire side to spot the start and the end of the process:

5\. Debug it and update Activity script.

If you want to get access to the latest Activity Script logs, you can use the following command: 

```shell-session
upsun integration:activity:log <INTEGRATION_ID>
```

As the content of the `blackfire-notifier.js` script has been saved in cache when creating the integration, you need to update the integration each time an update has been done on this script, by using the following command:

```shell-session
upsun integration:update --file ./blackfire-notifier.js <INTEGRATION_ID>
```

Et voilà, as soon as an infrastructure process occurs on your `main` environment, this Activity script will add more context to your Blackfire timeline by adding new markers. You will gain a holistic view of your application’s performance and enhance your ability to diagnose and resolve problems swiftly. 

By leveraging the full potential of Blackfire and incorporating Upsun infrastructure processes, you are better equipped to manage and optimize your application’s performance. Embrace this integrated approach to stay ahead of potential issues, improve operational efficiency, and provide a reliable service to your users.

Stay up to date on the latest from us over on our social media and community channels: Dev.to, Reddit, and our Community. Happy monitoring.

### Watch this video

### [GitHub Action: Step-by-step guide - Presentation | Upsun](https://upsun.com/blog/github-actions-presentation/)

# Build your first GitHub action: Step-by-step guide

### Video transcript

_We utilized ChatGPT to enhance the grammar and syntax of the transcript._

All right, welcome everybody. My name is Paul, and I am with Platform.sh, and we are proudly the host for SymfonyCon. So, I'm here today to talk about GitHub actions. Now, in my presentations, I do like to give a series of warnings. For those of you listening in, I've got an animation of a red light flashing to give you a heads up, and in this case, I'm going to start my presentation with some warnings.

The first is that I am in no way a GitHub actions expert. However, over the last 18 months, I have been responsible for building and maintaining a large collection of custom actions and workflows to help automate a lot of the responsibilities that my team has. In that time, I came across many areas of frustration and confusion on the platform, and so that's what kind of prompted this presentation. My goal, or my hope, is that I can help you navigate around those more confusing areas and jumpstart you on your way to automating inside of GitHub.

The next warning I'll give you is that I expect you to interact with me. I'm going to ask a lot of questions during the presentation, and I need you to respond to me. The last warning is that I'm going to talk really quickly because this is actually a three-hour workshop that I'm trying to condense down into 35 minutes.

So, with that said, what I want to cover in this quick 35 minutes is: I want to talk about the actions platform and what it is. I then want to move through the different components and pieces of GitHub Actions that you're going to use to build out your automation. I'm then going to talk about one of those pieces called the workflow, and we'll dig into the workflow and talk about the pieces and parts of the workflow that are required and that you'll be utilizing. Then, together, we're going to build our first workflow—so that's a hint that that's where I need you to interact with me. Next, we'll move into actions and building out custom actions, talking about the pieces and parts that are inside of a custom action and those things that are required for you to build a custom action.

I need to move to the right—sorry, keep moving to the right, I have to go all the way to the right. Okay, is that better? All right, sorry, I like to walk, so I didn't know I had to stay over here. Then along the way—oh, sorry—then we're going to build our first custom action together, see that in use. As we go through, I'll give you more warnings, some caveats, and gotchas—things to watch out for. Lastly, hopefully with enough time, I'll kind of show you how all these things come together to actually build out true, in-life automation.

So, the first thing is: **what is GitHub Actions?** Well, GitHub Actions is a service from GitHub. It is a continuous integration and continuous delivery platform for you to automate things surrounding your codebase, whether that's building or deploying or testing. It's what gives you the ability to automate, and it doesn't just have to be code-related. It could also be project management. So, anything that you need to do when something happens to your codebase, we can utilize this platform in order to automate things.

So, what are the pieces and parts that you're going to use? Well, you're going to work with things called workflows. We've got events, runners, jobs, steps, and GitHub actions (but with a lowercase 'a'). If you're listening in, I've got a gentleman saying, "Wait, what?" Yeah, so GitHub Actions with a capital 'A' refers to the platform—the whole entire automation platform. If you see GitHub actions with a lowercase 'a', that refers to a singular modular, self-contained piece of automation that you can use in your automation. Now, sometimes they are referred to as custom actions—look at that there—and sometimes just as actions. But just be aware that this happens. In fact, the entire platform—it's unfortunate the way that GitHub decided to name certain things—they often will use a word, and then depending on where the word is used, it will have a different meaning. If English is not your first language, that's exceptionally hard. One case is "status" versus "checks" versus "status checks," and those are three different things, not necessarily related.

So, if you find yourself in a situation where what you're seeing—do I need to scoot over again? I'm sorry—if what you're seeing doesn't match what you're reading in the docs, you may have come across one of these similar situations. All right, so we've got workflows, runners, jobs, steps, and actions. How do these pieces all fit together? Well, we configure our automation in a workflow file—that's where we define all the automation that we want to have happen. Those workflows, those automation pieces, are going to be triggered by some event—something happening to our codebase—that then kicks off a series of jobs. Jobs are where we define a bunch of steps, and those steps are what actually perform our business logic, whether they're calling other shell commands or shell scripts, or they're calling one of those actions that I mentioned earlier.

So, what I want to do now is dig into each of these components and kind of define them and explain them a little bit more. So, the workflow—I mentioned that the workflow itself is the automation. We configure it in what is called a workflow file. A workflow file has to be a YAML file—its name does not matter, it just has to be a YAML file—but it does have to be contained inside of a `.github/workflows` directory at the root of your repository. Now, your repository itself can have multiple workflows. You can have a workflow triggered on the same—you can have a ton of workflows triggered on the same event; they can each be triggered on different events; one workflow can be triggered by multiple events; whatever your particular situation is—it just has to be YAML and it has to be in that directory.

An event then is some activity that occurs to your codebase, whether that's a push, a pull request, it could be somebody labeled something—whatever, it's just something that occurs. Now, you have a whole bunch—I'm gonna flip over real quick—you have a whole bunch of events, and I've got those here. You can see here on the right-hand side a ton of events to give you fine-grain control of exactly when you want those workflows to be triggered. Now, I will mention that in the docs, they occasionally switch from using the word "event" to "workflow triggers." So, if you see a workflow trigger, it's just the same thing—it means the exact same thing as an event.

Now, a runner is simply a virtual server instance—it's where your automation is going to be performed when that workflow is triggered. You can utilize either the public runners that GitHub provides, or if you have a very special use case, you can also set up your own self-hosted runner. If you choose the public runners, you can choose from macOS, Windows, and Ubuntu in various versions. One thing to watch out for—be aware of with the public runners—is that they are public, meaning that when you want to run your workflow, it may not occur immediately because you may be placed into a queue waiting for a public runner to become available. So, just be aware of that.

A job then is simply a collection of steps—it's where we're going to define all of our business logic and automation that we want to have occur. They are going to be executed in that runner—in the same runner—so you're not going to have one step perform on one runner and then the next on a different runner—they're always going to run on that same runner. We tell the GitHub Actions platform which runner we want to run on via the `runs-on` property for the job. So, we say, we've got this job, I want this to run on macOS 10.12. Now, jobs by default inside of your workflow are going to run in parallel—they're all going to run at the exact same time. If we need to, we can define dependencies between those jobs, but it's important to remember—by default, until you set up that dependency—they're all going to kick off at the exact same time. Now, technically, a workflow can have an unlimited number of jobs. There is an asterisk next to that "unlimited" because there are limits on how long a job can run and how many jobs you can run in parallel, so with those limitations, you might not be able to truly have an unlimited number.

A step then is simply a shell script or a call to an action that we want to have performed. They are executed in order—they do not run in parallel—but they are executed one at a time and are dependent one on the other. So, by default, if an earlier step fails, it's going to fail out all the rest of the steps in that job. Again, if we need to, we can change that default behavior, but that's how it operates by default. And again, all those steps—and this is important—all the steps run in the same runner. You don't have step one run in Ubuntu and step two run somewhere else—that's not going to happen. We can set up jobs to run on multiple versions of runners, but by default, those steps are all going to run on the exact same one.

As I mentioned earlier, an action is simply that self-contained piece of automation, like a Lego block, that we can then combine with other actions to build out complex automation tasks. So, digging into the configuration of that workflow file - there are some things that you have to have to build out this automation. You have to have an event. So, inside of that - inside of your workflow file - we have to define at least one event to let the platform know when we want or how we want this workflow to be triggered. Inside of there, we have to have at least one job defined, and then that job has to have at least one step. The steps themselves either have to run a shell command or utilize some action.

So, we're going to build out our first workflow. Let me flip over here to my screen, and this is where—if you can't see the script, please let me know, and I'll try to blow up the font a little bit more. So, what is one of the things we have to have? An event. Okay, so I'm going to use the `on` keyword. Now, I'm going to give a shout-out to JetBrains for making a wonderful collection of IDEs. I have a plugin to help me build out workflows, so you can see as soon as I start that keyword, it automatically pre-populates it, and now I have a ton of different events that I can utilize. For today’s, I'm going to utilize the `workflow_dispatch`. The `workflow_dispatch` allows me to run a workflow manually, so I can go in and trigger it on my own whenever I need to, instead of having to try to recreate an existing event. What's another thing we have to have? We have to have a runner. But where do we define the runner? What's that? I think I heard it—jobs. Okay, so I'm going to do `jobs`, and I’ve got to create a job. So, I'm going to say this one's called "say hello," and then what do you say—we need a runner? So, I'm going to say `runs-on`, in this case, I'm going to say `ubuntu-latest`. Then, what else do I need inside the job? Steps. So, I'm going to define some steps, and in this case, I'm going to say `run: echo “hello there”`—not "Jello there," how about "hello there"? Yeah, there we go. All right.

Now, to run your actions—oops, that's the wrong tab. Let's try this one—there we go—that is also the wrong one. Hey, there we go! To run these, you're going to run these inside the actions tab in your repository. If you have your computer out and you'd like to see this, the repository itself is pinned up here to the top of my profile. My profile is at github.com/gillo—my last name. I have an unusual last name. So, inside that repository, over here, I have an actions tab, and this is where all of my various actions—there on the left—are going to be defined. We just created one called "first." Now, I'm not going to run it because I don't want to wait for a public runner to come up, but I'll show you it being run. By default, it'll show you the workflow's name of the file inside—it will then list out all the jobs—so there's that "say hello" job. Then inside of that, as we dig down, it will list out the steps that are running—we just ran one, which was to say "hello there." No applause—yay! We did it! We built our first workflow—fantastic.

So, let's dig a little bit deeper, because I did utilize some pieces that I haven't talked about yet. One of those is the job ID. So, every job has to have a job ID. In the example we just did, I called it "saycore hello." That's because one thing it has to have is it has to be alphanumeric characters, dashes, or underscores. They have to be unique inside the workflow. So, we can have as many jobs as we want, but they all have to have unique IDs, and then they must start with either a letter or an underscore. And again, inside those steps that we have, it's just an array of tasks—each one of those that we want to run. It is important to remember that each step is going to run inside of its own process. So, just like if you were to create a subprocess in a shell command, it's going to be in its own process or start up a new session—they're each going to run inside their own process. But they all have access—because they're running on the same runner—they all have access to the same file system. So, if an earlier step writes to a file, a later step will have access to that because it has access to the file system.

Each step individually then has to include either the `uses` property, which says, "Hey, GitHub Actions, I want to use an existing action—I want you to pull that in and execute that," or, like we did, we used the `run` property, which says, "Hey, I want to run this shell command," or "I want to run this shell script." All right, so let's look at our second workflow. So, flip back over here—and that should be—oops, scoot over—I'm on the wrong one—there we go. So, in this case, I've got my event, so on `workflow_dispatch`, I've got the same exact job, "say hello," but notice I've given it a name. So, one of the pieces that you can utilize inside your workflows is you can give the workflow a name, so it has a nice label in that actions tab. You can give each job a `name` property, so again, you have that nice job name instead of just the ID—you can even give your steps names. But now, in this case, I'm running one "hello there"—I then say, "Hey, use some action." So, I'm showing you this one because, by default, unlike GitLab, GitHub Actions does not check out your repository into the runner when you start it up. If you need access to your repository's code, you have to use the `checkout` action to say, "Check out my repository into this file system." So, in this case, I've actually checked out this repository into the file system, which is what allows me, in the third step, to `cat` out that list of files—and then in the fourth step, I'm just running—"I am step four." So, let's take a look at that one. Come back over here—come back—I will go back to my actions. Now, notice on the left—there it is—"welcome to the party," second there on the left—click on that. If I dive into it, now notice the job is no longer the job ID, but that nice label. And now inside here, I've got my four steps, with that third one having that nice, more human-readable label. You are a tough crowd—no applause for each of these—wow, all right. Man, there we go—that's what I'm looking for.

All right, so you may be asking yourself, "All right, Paul, we're halfway through this presentation, and so far, you've spent half of it talking about workflows. I thought this was about actions—why is that?" Anybody wondering that? Yeah, okay, so even if we were to build an action in the beginning, you cannot use an action directly—you can only use an action through a workflow. So, if you don't know how workflows work, you can't use actions. The second piece is that an action—a composite action, which we'll talk about the different types in a second—a composite action works almost identically to a workflow with the `workflow_dispatch` event. They're very similar—they share a lot of things, such as inputs. So, as you're working, as you're building out your business logic, one of the ideas behind an action is that it's reusable, right? You can use it in multiple instances. So, there's a very good chance you're going to need to be able to ingest or accept information into that action, and that's what the inputs are for. But `workflow_dispatch`can use those too, so we can use either inputs in a `workflow_dispatch` or inside of our action, and we can define all those inputs that we want. And just like with jobs, they have to have unique IDs, and again, be alphanumeric.

Now, inside an action itself, there are some differences. One of those is that you have to include a description for every input inside of an action. `workflow_dispatch`, you can include them, but you don't have to—but in an action, it's required. Another piece that you can utilize is the `required` property—whether or not that input is required in order for the workflow or the actions to run. And last is you can set up some default values, so if they don't provide that value or provide a value for that particular input, you can default to some known good value. You access what is input via something called a "context," which I'm going to talk about next. So, let's look at an input. So, flip back over—there we go. So, now notice here—I've got `on: workflow_dispatch`. Now I have an `inputs` property. Inside the `inputs` property, I've given one of those inputs a name, I've set up the description, and I've also said it's true. I mentioned earlier we're going to access that input via a context—that's what this little piece is down here. This says, "Hey, go back to the inputs—now grab the value from the ID of the input—the name." Make sense? All right, let's see it in action.

So, come back over—I'll come back up to the third one. In this case, I'll actually run this one. I mentioned earlier you can run workflows via that `workflow_dispatch`—that's how this little button on the right shows up. And notice—what does it say? "What's your name?" There's that input, and if I try to run it—what's—hey, thank you, thank you—so if I try to run it, what should happen? Fails, yep—it says, "No, that's required." So, I'll say, "Jerome—hello, Jerome—woohoo!" So, I'm going to run that workflow—hopefully there's a public runner pretty quick. Come on, public runners—I'll know I have a public runner running it because that little check mark will change into a dot—hey, there it went! I can now go into there—have my job listed—it is currently running or waiting—there, it's requesting—come on, finish up, finish up—hey! All right, there it is—there we go, thank you, thank you all.

All right, so, context—contexts are how your actions, your workflows receive information from the actions platform, whether that's about runners, about the job, the workflow itself, the events that are occurring—it's how that information is exposed back to your codebase. Now, you do have 12 types of contexts—I'll show you those here. Here on the right, you can see we've got 12 different types. So again, the runners, the steps, the inputs, the needs, matrix, secrets, variables, etc.—all different types of information available to you. One thing to note, though, is that not all contexts are available in all situations. So, there is something called a "matrix" that you can utilize. If you're not using a matrix, well then, the matrix context isn't available. So, just realize that those aren't all available to you at all times. To access a context, if you're using anything that is not a JavaScript-based custom action using the GitHub toolkit, you will access these contexts with the dollar sign—the, what do you call them, the fancy brackets—the fancy curly braces, I don't know what they're actually called, whatever they're called—the context name, the property name that you want. Then the properties themselves can either be the string values that you're looking for, or they can be other objects, and you can dig further and further and further down until you get to the context that you need, such as accessing a steps context where I access a specific ID of a step, then I target its outputs, which we're going to talk about—outputs in a second—I target its outputs context to get the value contained in the target URL ID.

If you're using JavaScript, they have this nice little toolkit that then exposes those various contexts via methods. Now, there is a quick warning, and this is an important warning—please, if you don't remember anything else about this presentation, please remember this—the contexts that come from user-supplied input are not pre-escaped—they're not prepared for you to utilize inside of shell commands or your code directly. All right? This means they are ripe for code injection. As an example, if I were to try to set a shell variable equal to a request title—a pull request title—pull request titles come from users—then what would happen is if they created a pull request title called `a”;`, then when I set `title=“a”;`, then what happens? That’s a complete shell command, right? That semicolon says, "This is the end of one command—here's the next one." I would end up running this command. So, just be aware that these are not ready for you to use directly.

All right, so outputs—if you've accepted some input, you've done some processing on that information, you may need to output information. In addition, if you're building out a complex workflow, at some point, one of those steps is probably going to do something that you then want another step to be able to access. So, outputs are simply that—that's data or some information that you want to send from an action back to the calling workflow, or from some step out to the next step. So, it's just information that we can then reutilize later on. To set an output—again, from anything that is not using the JavaScript toolkit—you echo the ID equals the value and then send it over to the GitHub output environmental variable. Or, if you're using the JavaScript toolkit, they have a nice `setOutput` method exposed for you to set those values. Then, as we saw earlier, to use those, you're going to access some context—the steps—most likely the steps—the step ID that outputs object from up here, and then that ID that we might have set.

Do you want to see it in action? Yay, there we go! All right, I should be—I was going to say, you should be very awake by now. All right, so we have another workflow here—oh, I'm going to scroll up because I did make the font a little bit bigger. So, notice here in the third—second step, excuse me—the second step, I'm taking the current timestamp of the date—I'm then going to set that to an ID of `currentTime`, send out to the output, and then in the third step, I then can access that value that I set via the steps context—goes back up to get time, grabs `currentTime` to output that. And I'll show you that in action. Flip over here, go back to my actions tab—did I hear a yawn? I'm not that boring, am I? Jeez, you guys are hard. Uh, let's see—is that third—I forgot which—oh, there it is. So, dig into here—here's my "say load" job, and also grab the time. So, here you can see that I have set the time, I echoed that out to the output. Let me grab my pointer here. So, I set `currentTime=` the date—then in the fourth step, I output that via that context. Yay, there we go—that's what I'm looking for.

All right, now we are prepped. We have all the tools—we have all the knowledge needed. We're ready to begin to build custom actions—oh, except not actions with a capital "A"—we have to build actions with a lowercase "a," remember that. All right, so there are three types of actions that you can build. We've got access to a Docker type action, a JavaScript action, and a composite action. The difference is that Docker allows you to be very fine-grained in the environment in which your business logic is running. So, if you have very strict requirements, you're probably going to need to utilize your own Docker image instead of one of the public runners. A JavaScript-based composite action is nice because you can kind of separate that action code—that business logic—from the action service itself, and be more able—more able—easily—no—easily—more easily able—more easily able—I got my words jumbled—more easily able to mock up the environment and test that code outside of the GitHub Actions platform, and it typically runs a little bit faster than a Docker-based custom action. The problem with a JavaScript-based custom action is that you can't utilize or reuse somebody else's public action unless they've also exposed that action as a JavaScript package. So, that's what the third one's available for—the third one's called composite, and it's what allows you to use other people's actions inside of your own action, again allowing you to utilize that more Lego-block modularity to put things together into something more complex.

Now, the actions themselves must be stored in a repository all by themselves, or if you want to store them in an existing repository, they have to be inside their own directory. Now, there are some pieces and parts of actions that you have to have—excuse me—and the first is they all have to have a metadata file. That metadata file has to be a YAML file, and it has to be named `action.yml`, and it must be stored in the root of the repository of the directory where your action is being stored. It has to contain at least three properties—four technically. It has to have a name, it has to have a description, and it has to have the `runs` property with the `runs-using` subproperty. It must have all of those. And it's that `runs-using` that tells the actions platform what type we're going to use—so `runs-using: docker`, `runs-using: composite`. Depending on which type of action you choose, there are other properties that are required inside that `runs` property. In addition, in the metadata file is where we define those inputs and outputs.

So, a sample action—and this is a complete action file—is: I've got my `name` property, "Greets user," I've got `description: Greet user to the GitHub Actions platform`, then I've got the `runs` property with a subproperty `using`, and I'm using `node:20` to designate a JavaScript-based custom action. And then because I'm doing a JavaScript-based custom action, I then have to have the `main` property and point it to my bootstrap or my kickoff file for my business logic inside of that JavaScript package

Now, there are a couple of warnings with the three different types of composite actions or three different types of actions. When you use the `runs-using` property for Docker and composite, you use the words "Docker" and "composite," but for JavaScript, you don't use the word "JavaScript"—you use the node version that you want to use. Right now, only version 16 and 20 are valid for Node inside of a custom action—16 was deprecated as of October 24th. There is no sub-replacement yet, so the only one you really have access to is 20. I believe Node 22 is going to be released this coming Spring, and most likely they'll then add Node 22 as an option at that point. The other challenge with a JavaScript-based custom action is you have to commit the entirety of the `node_modules` directory, or all of your JavaScript dependencies, into that repository in order to use them, or use something like Vercel's NCC to bundle all of your dependencies into a single JavaScript file.

The warning with the composite-based custom action is because you're using those runners, the binaries and programs inside the runners may not be the version that you need, so you may find yourself needing to update versions before you can utilize some shell command. And at that point, you know, if you're spending the bulk of your custom action—that composite action—updating dependencies, that may be the point at which you need to switch to that Docker-based. So, you ready to build a custom action? Yay, there we go—that's what I like to hear.

All right, so what do I have to have—oh, oh, you're good—all right, for an action, what do we have to have to build the action? Metadata file—what do we need? A name—okay, so I got my name. What else? Description—what else? `Runs-using`. All right, so I got composite. In this case, composite is going to utilize other actions, so it's going to have a requirement of steps. In this case—forgot to mention this—I'm building this action over here inside the `.github/actions` directory, and then it has a directory all its own. Now, it doesn't have to be "actions"—I just made that—it just made sense to me—I was going to store them all in a similar location, but my metadata file is in the root there.

So, what do I have to do in order to be able to utilize the repository that we saw earlier? Oh, I have to check it out, right—oops, I skipped a step—oh, I skipped all the way—I'm sorry, I skipped my steps. So, we're not going to—we're going to do that in the workflow, sorry. So, one of the things—we're trying to recreate this action into that workflow we did earlier. So, what I want to do is I want to do the same thing—I want to say "hello" to somebody, so I'm going to have an input. This time, I'm going to call it `who_to_greet`, set up the description. We can skip the type—only act—every type inside of an action is a string. Inside workflows, you have multiple types, so in this case, I've just reused that. Now, in my step, I've given it a name, I've given it an ID—in this case, I've said I want to use the bash shell instead of some other type of shell, and then I'm going to `run: echo "Hello" ${{ inputs.who_to_greet }}`.

Now, can we run this action directly? No, what do we have to have? A workflow—all right. Inside the workflow, what do we have to have? An event. All right, so there's my event—what else? Jobs. So, there's my job—then what else? Steps. Now, because I have stored this action in the repository itself, now I need to check out the repository and be able to use that action. Then I can say, "All right, I want to use the action that is stored in this repository," but this action that we just created has a—has a what? An input. So, I'm going to use the keyword `with` and then I'm going to use that same input ID and then give it some value. Because I want to run this as a dispatch, I'm probably going to need to provide an input, so I'll also include an input on the workflow itself. So, the workflow is going to run, it's going to have an input, I'm then going to take what is input there and send it to the action that we just created.

Are you ready to see this in action? Yeah? All right, so let's go back—back to my actions tab, and we'll say, "V, an action" going—I hit run. Notice there's who we should greet—again, I'll say "SymfonyCon 2023," but I'll put some more exclamation marks in here—no, right there—oh, go all the way over—why won't it let me select it? There it goes—we'll say, "Super excited"—run that workflow—come on, public runners—because I know I'm close on time—come on, come on, come on—there we go—click on that. Now, that's our workflow—we dig into the workflow—we can see that it checked out our repository—it then ran our greet user—and then if I run that, I should have—there we go! Yay!

All right, so what did we cover? We covered the actions platform, right? We talked about the different components of the actions platform that we can use. We talked about the workflow file and how we define the workflow file and the pieces that are parts that are required of it. We then built our first workflow together. We talked about custom actions and the parts that are required for it. We then built that action together with that workflow and talked about some warnings, right? But, hello worlds are always a little, um, not quite as useful, correct? So, let's put everything together. Let's put all this together into a real-world example. And the goal is—in this particular case was a real goal—is we needed on every pull request—we needed to be able to run a visual regression test. Is everybody familiar with visual regression testing, where you take a screenshot of your production site and then a screenshot of some other site, and then you diff them and see if there's any regressions in that visual aspect, right? Good, yeah? Okay, so let's take a look at that action—oops, scroll over—Is that the action? No, that is not the action. Ah, there's the action—sorry, the wrong one.

All right, so what are—what are the minimum of two things that I need for a visual regression test? Two—I need a screenshot—I need the production URL—a production site—and a test site. So here, I've got my name and my description—we have to have those. I've got inputs—one is the test URL, so give me a URL that you want to test against some new stuff. The reference URL is that production site. Let me scroll so you can see this—I've got the `runs-using: composite` and `run-steps`. First one is—I probably want to make sure the URL—the string that I was given—looks like a URL, and I probably want to make sure the site is responding. So, in this case, I'm going to use an action—there it is—I've got an action, and I'm going to send it the test URL, and all that action does is say, "Does this look like a URL? Now let me call the site and make sure it responds." So, I do that once with the test URL, and then once with the reference URL.

Then I'm going to utilize a package called Backstop, and Backstop is a visual regression tool, so I install it. Now, in a minute, I'm going to need to change the configuration of Backstop to give it these new URLs. To do that, I need to use jq, a JSON query inside the shell, but the version that came in the public runner was 1.6, and I needed 1.7. So now I can use another action inside my action to update jq inside the runner. I then update that configuration for Backstop to include my new URLs, then I run Backstop's reference that goes out and takes those screenshots. Then I can come down and run the test.

Now, what does a test usually do if there's a failure? It fails, there's one—but what else? It creates a report, right? So, two things: One, it fails—and I said earlier steps are always dependent on each other—if one fails, everything else fails out. I don't want that to happen. So, in this case, notice I've set `continue-on-error: true`—so that says, "Don't fail out if one of these steps fails." I suppress the message, and I capture it—there it is—`test_results=$?`. And then I come down and—I—oops, it's not on screen—let me scroll down a little lower—I set the output of the test itself to another environmental variable that I can then utilize down lower.

Now, I did say earlier that each of the steps are dependent—in this case, notice you also have conditionals for steps. I can say, "Only run this step if that environment variable has been set to false." So, if the test failed earlier, I'm now going to utilize yet another action to store the report and attach it to the calling workflow, so that way somebody that's utilizing this in a pull request can see that failure and actually utilize or view that visual regression test. Then, lastly, if it fails, then I'm going to exit out with a non-zero, so that fails the step in the calling workflow, and then we'll fail out the rest of those steps in that job.

To see it—flip over here—here is the attached workflow that goes with it. So now I'm going to say, on pull request target to main—so if there's a pull request against main, I'm going to run on Ubuntu's latest. I'm then going—oh, I almost forgot—one of the great things about Platform and Upsun is we have those integrations with GitHub, and one of the things that it does is when you create a pull request, it will actually clone your production environment. It then overlays that PR code into that environment and then brings it up. With the integration, it will contact GitHub and say, "Hey, I've successfully finished this—here is your new ephemeral PR environment URL." And so that's what this first action does—it says, "Hey, have you received a success yet, GitHub? Oh, you have? Okay, now give me that URL," and it sends an output called `target_url`. So then, the second step is to run that action I just showed you, sending that URL we got from the first action. And then I've stored—because your production URL usually doesn't change—I've stored that as a repository variable inside GitHub, passing that over.

To see it in action, let me flip back over because I know I'm short on time. Where is my pull request—no, that's context—there it is—here's my pull request. You can see down below, there's that integration—it was successful—it gave back my URL. I've got some other tests running, then the workflow for the pull—the visual regression testing ran, but you can see it failed. If I hit the details, now it'll say—there it is—you see, oh, visual regression testing failed. Then if I look in the summary—if I scroll—if it'll let me scroll all the way down at the bottom—there is that stored visual regression testing report. And now I can take a look at that report and see I had two passed, two failed—oh goodness, yes, this definitely was not good. Oh, looks like maybe the font size changed or something—oh yeah. And now I know in my pull request, “Hey, something's wrong—I need to go check to see what happened.”

Thank you all. All right, I think I am out of time—might have two, three—I don't know if I have time left or not—I didn't see what time it is. Well, this is my contact information. I'm kind of easy to find—there's not many Gilzow in the world. But the best way to find me is linktr.ee/gilzow—that's got all my social media accounts—every single one, profiles everywhere, and I'm almost always "gilzow" at everything. So, feel free to contact me—I'll also be at the booth the remainder of the day—happy—I love talking about this stuff, so would be happy to entertain any questions you have either now or later.

### [Django Girls: Community, Python, and Open Source - Podcast | Upsun](https://upsun.com/blog/django-girls-community-open-source-podcast/)

# Django Girls: community, python, and open source - Podcast

Join DjangoGirls board members, Aisha Bello and Leona So, for this week’s episode of Change Mode as we celebrate 10 years of this incredible non-profit.

Created to inspire women from all backgrounds to get interested in technology and enter the world of programming, Aisha and Leona share their journeys into open source and their roles in DjangoGirls today. Dive into how they built their own Python communities, ran their own local events, and the importance of creating safe, welcoming spaces for women in tech. 

* * *

### Podcast transcript

_We utilized ChatGPT to enhance the grammar and syntax of the transcript._

**Marine:** Aisha, Leona, I'm so happy to have you both. It's been hard to synchronize our agendas because we're all in different time zones and busy women, but I'm glad to have you both here. Can you introduce yourselves? What do you do, and why you're invited here? Aisha, maybe you can start.

**Aisha:** Hi, Marine. I'm Aisha. I'm a Django Girls board member. I've been a previous organizer and coach. On the other side, I work as a solutions architect for AWS, and I'm happy to be here today. I'm based out of Toronto currently.

**Leona:** And I'm Leona. I'm based in the UK, near Manchester. I was an attendee of Django Girls to start with, then became an organizer, and now I'm also a board member. I work as a product manager at Pearson.

**Marine:** Awesome. Thank you both. My first question is, how did you discover the technology that made you want to be involved in open source, specifically Django Girls? How did you both start getting into Python and then Django, and what made you want to get involved in the Django Girls user group? Leona, maybe you can start.

**Leona:** I wasn't a developer, and I'm currently also not a developer, but I've been in tech setups before. I have always been a math teacher, and computing was something the government wanted to promote a lot. One aspect of the math curriculum I was teaching needed knowledge of computing to understand the math involved. I started looking into how I could link math with computing. The last time I did any computing was in university, studying C++. When the government promoted computing, Python was chosen as the language, which is relatively straightforward. It's probably the best programming language to introduce in school.

I started going into Python-related professional development courses. One time, I planned to go to PyCon UK in 2015, where they had an education section. I realized there was Django Girls happening on the same day, so I applied for Django Girls instead of the education track. That's how it started. At the same time, I was already attending Python user groups in Manchester, the North West group. That's how it all began.

**Marine:** Interesting. I love that your background is in math and not computing, but Python is such a scientific tool. Aisha, what about you? How did you get into Django?

**Aisha:** It's a long story. I studied at an IT university where we did some C and C++, but Python wasn't part of the curriculum. Programming felt hard, and I thought it wasn't for me. While studying for my master's in the UK, I was doing a data science project using R. I started looking for job opportunities and stumbled upon EuroPython, which offered sponsorship for women. I applied, got approved, and attended Django Girls. It was my first introduction to Python and Django. I had an amazing mentor and felt a sense of belonging, even though I didn't understand everything.

When I returned to Nigeria, I organized the first Django Girls workshop, which led to the formation of the Python Nigeria community. It has grown to host conferences and events all over the country. Although I'm not a developer, I contribute to the community and work as a solutions architect.

**Marine:** That's really interesting. You're both not the typical profiles we expect in these communities. Usually, we expect developers. But the community made a difference for both of you and made you interested in the language. Leona, you also started your own local Django Girls group and events. How did that change your life?

**Leona:** After attending Django Girls at PyCon UK, I wanted to bring it to Manchester. I spoke to a friend who is now also a board member, and we started organizing events. This involvement helped me transition from teaching math to being a computing tutor. It also opened opportunities to make Django Girls bigger. The support from the community and hearing success stories from attendees kept me motivated.

**Marine:** That's wonderful. For me, the story is similar with the PHP and Drupal community. Open source communities give a lot but also bring a lot in return. Aisha, do you think events are necessary for building this sense of community?

**Aisha:** In-person events fuel online interactions. Although we've had impactful virtual events, nothing compares to the connection you feel at in-person events. The relationship begins in person and continues online. Both have their pros and cons, but if I had to choose, in-person events make a bigger impact.

**Marine:** You both host the Django Girls podcast. Can you tell me more about it? How did it start?

**Aisha:** When we joined the board, we had a blog called Django Girls Stories. I thought, what if we gave it life and let people tell their stories in their own voices? Leona and I partnered to start the podcast. Leona handles the editing, and I find people and set up meetings. It brings the stories to life and helps us connect with the community.

**Marine:** That's great teamwork. What are your plans for the podcast and Django Girls?

**Leona:** We're recording the next series of podcasts, focusing on how people in the industry got to where they are and tips for others. Our team has also grown, and we plan to promote the podcast more.

**Marine:** It's important to make the world aware of your work. Lastly, if you could get permission to do anything for a day, what would it be?

**Aisha:** I would take a self-care day with no guilt, completely switching off.

**Leona:** I would like the permission to do something I've never done before, like an adventure.

**Marine:** What do you think is your greatest power?

**Leona:** I've been told I'm very organized.

**Aisha:** I think my ability to bring people together for a common purpose.

**Marine:** You make a great team. Thank you both for sharing your time and insights. I hope we can do a follow-up someday. Thank you so much.

**Leona:** Thank you. It's lovely being here.

**Aisha:** Same.

### [Chapter 1: Upsun and the decades of the open web | Upsun](https://upsun.com/blog/chapter-1-upsun-and-the-decades-of-the-open-web/)

# Chapter 1: Upsun and the decades of the open web

I get easily excited by new stuff. I don’t know how many trials of cool and interesting things I start every week. Getting a feel for the product, understanding the pricing, and testing out the features. But I also always think about how the people building the product consider their place in the universe. What’s their frame of mind? How do they see their future? 

Well, in this article I’ll answer those questions for Upsun by telling you a bit of the story of how we think of ourselves and our new PaaS offering in the context of the changing relationship between modern organizations and their digital infrastructure. 

### **Long story short**

The short version of our story could be that we are a bunch of people with a bunch of love for the web. And maybe even more so for the “open web”, having witnessed its creation and tremendous impact on the world, and seeing it grow from a haphazard, joyous thing to what now structures much of the current economy. But this blog series isn’t about short stories, instead, I’ll share our vantage point on where we think the open web is now, where it’s going, and where we see our place in it. Immersing you in a journey through the decades of the web over a series of 3 chapters. 

The main message of this series is that automated, composable infrastructure that leverages open source is the only way organizations can remain competitive and hedge their bets in times of uncertainty. Our ambition for Upsun is to be the most effective PaaS in supporting companies to do that. 

### **Outsourcing vs. the new digital-native approach** 

Regardless of what type of organization you are, computers are likely to be handling many of your core business functions and most people will interact with whatever you do through a computer. This has led many companies to outsource some of those core functions, particularly in maintaining their software production capabilities and digital infrastructure. Adopting the mindset: let the professionals handle it. Outsourcing takes two major forms: using external companies, integrators, or agencies to develop and maintain code, or through the usage of Software-as-a-Service (SaaS) offerings. 

While few companies in their right minds would choose to build a new data center for internal applications: the digital-native giants, on the contrary, have gone for full vertical integration. They develop in their own programming languages—think Google with Go, Apple with Swift, Microsoft with C#, Facebook with Hack, and now Amazon with Rust—on their own silicon, that runs on their own land, connected to their own fiber, sometimes even with their own power sources.

These fully vertically-integrated beasts have generated such economies of scale that they are now capable of renting out this capacity to other companies. And they can do so at a quality and cost that companies that don’t have the same level of integration cannot achieve. They are at the same time companies that offer a wide array of product offerings and Infrastructures-as-a-Service (IaaS), a platform for all other players. Interestingly part of their capacity to leverage economies of scale depends on the fact that the infrastructure code they are running is mostly open source: from Linux itself to virtualization, DevOps tooling, and observability. Through this, they are capable of mutualizing their costs because so much of the code that is not part of the vertical integration is actually open source, co-maintained by others. To a point where everything has become open. At least by name. Even things as totally opaque and closed as OpenAI.

### **Outsourced and locked in: Can you strike a balance with how you develop and maintain your software?**  

Open can mean quite a few things in our industry: open source, public APIs, and free services. Essentially everything that allows for engagement and adoption with the lowest possible barrier to entry. This is true for Infrastructure-as-a-Service (IaaS) providers as they are easy for users to get in, and if you are a startup, easy to get a considerable amount of resources for free**.** When you are in, you get the benefits of scale immediately and those benefits continue to expand. IaaS providers can leverage their own integrated systems to allow you to add capabilities (from their closed offerings) that would otherwise be exceedingly costly to create. Meaning users tend to stick with their providers as they can’t afford to move on to another strategy. 

It seems like a damned-if-you-do and damned-if-you-don’t kind of situation: you can’t build everything by yourself and it’s cheaper to outsource. Then once you outsource it's cheaper to continue as it becomes too expensive to change. You get locked in. 

### **A PaaS can set you free** 

The idea behind Upsun is that it doesn’t try to fight against the stream. We won’t be building our own data centers any time soon and we are not going to try to sell you on “open” but open with a bunch of asterisks. We don’t have a free tier. You need to pay us money to use our services. But the contract is clear: Upsun gives you the freedom to move whenever you want, with no vendor lock-in. 

We don’t try to infect you, and we won’t and can’t bait and switch. If you have heavily invested in Terraform and Docker infrastructures or on Gitlab to try and build your own platform engineering practice, you may see how it might make sense to bet on someone whose long-term goals are aligned with yours.

Upsun tries, like Platform.sh, to be a general contract between developers, software, and infrastructure with very little that is specific to us. The Platform.sh PaaS allows you to describe how you build a piece of software, how you deploy it, what its infrastructure level dependencies are, how it interacts with storage, and how it interacts with the network. The cherry we added on top is a strong abstraction about how software changes. These days there are a lot of GitOps services and preview environments as a service, but none take it as far as we have. 

Platform.sh allows you, on one side, to leverage underlying IaaS and their own economies of scale but we break that vendor lock-in. We allow you to automate so much of the lifecycle of your applications that it becomes reasonable to actually spend some time on developing your value-add, and only your value-add—**like the giants do**.

Upsun adds a new element to that promise. Upsun allows you to describe how the application scales. We kept the very hard constraints we put on the Platform.sh system from the beginning: you can still deploy arbitrarily complex apps in multiple languages, leverage multiple data backends, and do all of this with zero DevOps involvement. But now, with Upsun, we are also helping you with your applications’ dynamic behavior with much more built-in observability, an integrated global edge layer, and most importantly flexible scaling on both vertical and horizontal dimensions.

Upsun empowers development teams with the flexibility to build—and the firepower to run—diverse applications on a single, self-service PaaS. By fully managing infrastructure and security, Upsun frees every developer to easily experiment, quickly iterate, and confidently deploy applications at scale. Discover more about all of the features currently available on the Upsun PaaS on our dedicated features page available now. 

We don’t expect the pendulum to swing back from using SaaS and outsourcing software development to companies betting on doing everything in-house. That doesn't make sense. But Upsun allows you to make bold bets on keeping some of your capabilities in-house. It also allows you to change the way you work with your outsourcing partners when you do. You are still in the loop. Still in control. You can still choose to internalize some. Talk to your developer. 

Keeping your capability to produce just the code that you need is a huge competitive advantage. Losing it is a risk. Being a beholder to open players that may close the gates at any time is the result.

Upsun is useful, really useful when you are leveraging existing open-source technologies. Both in terms of the infrastructure level elements including the data fabric and the actual software frameworks that make us productive. It brings you the capability to have bespoke capabilities at a cost structure that is close to leveraging SaaS. For some of your core functions, I believe that is the most reasonable tradeoff. You still outsource all of the undifferentiated menial heavy lifting, but you are actually capable of developing your own capabilities—like the vertically-integrated beasts we talked about. That’s cool.  

This is something that will become paramount in the coming years thanks to large language models (LLMs) and machine learning. A topic I’ll talk about in this blog series but I think before we get there, we need a bit of a historical perspective. Stay tuned for chapter 2, coming soon, where we dive right into the decades of the web we’ve witnessed so far and the technologies that have been inspiring, infuriating, and instrumental in leading us to where we are today.

### [What is serverless architecture? | Upsun](https://upsun.com/blog/serverless-architecture/)

# What is serverless architecture?

## What is serverless?

Serverless computing lets you run applications without managing any infrastructure. Your code runs when needed, automatically handles any amount of traffic, and you only pay for what you use. While actual servers still run your code, the cloud provider handles all the complex management tasks, letting your team focus purely on building features.

This approach delivers three essential business advantages: 

-   Pay-as-you-go pricing that matches actual usage 
-   Instant scaling that handles any workload 
-   Faster feature delivery with zero infrastructure overhead

For your technology teams, this means focusing purely on creating value through code while the provider handles all the complex infrastructure management behind the scenes.

## Understanding serverless computing

Serverless computing simplifies how you run applications in the cloud by removing infrastructure headaches. Think of serverless as a skilled technical architect - one that handles infrastructure complexities in the background while your team builds distinctive features and innovative solutions.

Here's what makes it valuable: 

-   Your applications run in separate spaces that grow or shrink based on actual use 
-   You only pay for the computing power you actually need, cutting unnecessary costs 
-   Developers spend time writing useful code instead of managing servers 
-   Getting features to users happens faster since the technical setup is automatic

The real benefit? Your team can put all their energy into building things that matter to your business, while the cloud provider handles the rest.

## How serverless works: Core components

Let's break down how serverless actually runs your applications, focusing on three key parts that matter for your business. 

In the essence of serverless architecture lie **Event-Based Functions** - the heartbeat of Function as a Service (FaaS). In this setup, developers craft functions that spring into action in reaction to specific events, like handling user requests or engaging with databases. When a particular action is carried out in response to an occurrence, it is referred to as an "invocation." The cloud provider is responsible for managing these functions, either by utilizing an existing server or creating a new one as needed for function execution, without any developer intervention.

**Event-driven actions** Your application responds automatically to real business events - like customer purchases, file uploads, or data changes. Each action triggers exactly the right amount of computing power, right when you need it. No waste, no waiting.

When a function is first activated or reactivated after a period of inactivity, it experiences a brief "cold start" delay as it sets up and starts running. The "Concurrency Limit" refers to the maximum number of function instances allowed to run at once within a specific region, as determined by the service provider. If a function exceeds a set "Timeout" period on the provider's platform, it gets terminated.

**Smart resource handling** 

The platform takes care of the heavy lifting: 

-   Scales up or down based on actual use 
-   Prevents overspending with built-in limits 
-   Keeps your apps running smoothly with constant monitoring

**Business results** This setup changes how you deliver value to customers: 

-   User management and notifications happen automatically 
-   APIs handle any amount of traffic without breaking 
-   Process data and media files without infrastructure hassles 
-   Keep customer data secure without extra work

### How businesses use serverless today

Let's look at how companies are using serverless functions to solve real business challenges. 

When it comes to dealing with tasks like processing data or resizing images in the background without any set timeline to be followed precisely, serverless systems can handle them efficiently. Serverless functions are also commonly used as the core of APIs, leveraging platforms such as Amazon API Gateway for efficient scalability in API backend development.

Security Automation is another area where serverless functions excel, as they can initiate security checks or manage authentication procedures without impacting the performance of the application.

**Customer engagement** 

Handle user signups and send personalized messages automatically. Your customers get quick responses while your team focuses on building better features.

**Online sales** 

Process orders and track inventory without worrying about server load during busy periods. The system grows with your business, handling both quiet days and sudden sales spikes.

**Content delivery** 

Upload and transform images, videos, and files without infrastructure headaches. Your content reaches users quickly while the platform handles all the technical details.

**Daily operations** 

Take care of routine tasks like data checks, reports, and connecting different systems. Your developers can build new features instead of managing servers and background jobs.

**Comparing Serverless vs Containers:** 

Serverless and container-based architectures both handle server management at a level, but cater to distinct requirements. Serverless design is a fit for applications that experience fluctuating demand levels, like sporadic or uncertain workloads, since functions can adapt automatically to scale accordingly. 

Container Architecture, on the other hand, is great for applications with predictable traffic patterns, as it allows you to effectively manage the underlying environment. However, to scale container-based applications efficiently, it's essential to utilize orchestration tools such as Kubernetes.

### Making serverless work: Common challenges and solutions

Let's talk about the real challenges teams face with serverless, and how to handle them effectively. Serverless development tools streamline deployment and optimize performance. Deployment frameworks like Serverless Framework and AWS SAM simplify serverless app rollouts. Performance monitors like Datadog provide real-time insights on metrics such as cold starts and function errors, helping teams maintain reliability.

**Keep things reliable** 

Yes, you depend on your provider's infrastructure. The fix? Build your apps to handle hiccups gracefully and run across multiple regions. This keeps your business running smoothly even if one area has issues.

**Stay secure** 

Modern serverless platforms come with strong security built in. Use features like encryption and strict access controls to protect sensitive data while keeping the speed and flexibility you need.

**Avoid vendor lock-in** 

Take a balanced approach - use standard practices where possible while still taking advantage of helpful platform features. This gives you flexibility for the future without sacrificing benefits today.

## Where serverless fits in your cloud strategy

Serverless computing delivers key advantages for businesses, while requiring careful consideration of platform dependencies.

To help illustrate the key benefits of serverless computing, let's consider a few real-world examples:

**Accelerated innovation**

A startup quickly sets up a serverless backend to automatically process user sign-ups and send notifications for their new mobile app. This frees the team to focus on building core features.

**API efficiency**

Automatically build and scale API backends. Applications can handle varying loads while maintaining performance and cost optimization.

**Automated processing** A media company employs serverless functions to automatically resize and optimize user-uploaded images before storing them. This eliminates the need to manage a dedicated image processing service, saving time and costs. The functions scale seamlessly as upload volume increases.

**Enhanced security** Leverage built-in security controls for authentication. Maintain compliance and protect user data without added complexity.

These examples demonstrate how serverless can drive innovation, improve performance, and optimize costs for various business use cases. Understanding these real-world applications can help envision how serverless may benefit your organization.

## Wrapping up

Serverless computing delivers impressive advantages for modern businesses - boosting innovation, enhancing security, and automating critical processes. By understanding these real-world applications, you're now better equipped to evaluate how serverless could benefit your organization.

When considering serverless, keep in mind both the upsides and potential platform dependencies. While great for variable workloads, you'll want to plan ahead to avoid vendor lock-in. The key is aligning serverless with your specific business goals while maintaining flexibility for the future.

Take a moment to think about a particular challenge your business faces, like managing unpredictable API traffic or processing heavy user content. Visualize how a serverless approach could streamline and optimize that workflow. With strategic planning and the right implementation, serverless can be a transformative solution for your team.

The path to serverless success comes down to understanding your unique needs and staying agile as requirements evolve.

### Useful links

-   SaaS startup Witty Works delivers AI-augmented DEI solution at scale

### [What is .env? A guide to understanding the .env file | Upsun](https://upsun.com/blog/what-is-env-file/)

# What is .env?

`.env` files are increasingly popular as a way to configure an application by securely storing configuration settings, environment variables, and sensitive information. This loose standard offers a number of benefits, most of which are fully realized on Upsun. However, `.env` files also need to be used correctly; misuse, as with anything, can be worse than not using them at all.

To understand the best way to use `.env` files, we first need to understand what is meant by "environment."

## **Putting the .env file into context**

Whatever language it's written in, your application is ultimately a pile of code. That pile of code is static and unchanging between the different times and places it runs.

When it runs, though, it’s going to care about other "stuff." That stuff could be a database, a cache server, a file system, a remote authentication gateway, or a thousand other things. That other "stuff" is the context in which the application runs. Or, alternatively, its _environment_.

That environment could be variable. Your application may require a PostgreSQL server, but _which_ PostgreSQL server it connects to, and the data in it at any given point in time, is all part of the environment and could change independently of your code. You want your application to talk to a payment gateway, but which credentials it uses may vary depending on the context you're running in. (Building production payment API keys into your application and then sending it for testing tends to end badly. Trust me on this...)

When building an application, it's important to keep a clean separation between "stuff that is the same in all environments" and "stuff that changes in each environment." The former is your code. The latter is your environment configuration.

Unix-like operating systems have had a mechanism for handling that environment-specific configuration for decades: environment variables. Environment variables are system-global string values that any application can read at any time and use that to make decisions about what code to run.

### **Configuration files in varying application behavior**

That's not the only way that applications can vary their behavior, of course. Most applications have some kind of "configuration file," which contains other settings that can cause the application to behave differently. These could be executable files (PHP, Javascript, Python, etc.) or non-executable files (YAML, XML, ini, JSON, TOML, etc.), and the details vary as widely as the applications.

The important distinction is that some of that configuration should vary with the _install_ of the application, while others vary with the _environment_. Remember, any given application may be run in multiple instances for testing.

For example, if you're building an application that users can install and configure themselves, the "company name" that the application is for is going to vary depending on which user is running it. But the database it connects to is going to vary for every instance of the application that user runs. Think production, testing, local laptop, etc. Those should all have the same company name, but different database credentials.

That is the first important step: separating your application's per-install configuration (company name) from per-environment configuration (database). Putting those in the same file makes it substantially harder to vary per environment without also making the per-install configuration vary.

An executable configuration file sometimes has a backdoor option to allow the environment to vary. Depending on how the file is written, it may be possible to modify it manually to read certain values from somewhere else: an extra include file, environment variables, etc. That's still a hack, though. You want to be able to put the consistent configuration into Git, so its changes are updated across all instances, but not the environment-specific configuration.

And that's where environment variables come in.

### **Maintaining consistency with environment variables**

The ideal place to store environment-specific configuration is in environment variables. The mechanisms for setting them are well-established. The APIs for reading them are universal. While two different applications may not use the same variable name, there are many simple ways to set one environment variable based on another.

For production and testing, therefore, the best place to manage environment-specific configuration is environment variables. Either design your application to read from them directly, or design it to have a user-modifiable executable configuration file that can be modified to read values from the environment rather than hard code them directly. That way, when you move the application from production to staging to your other staging to a branch-specific environment, you need only update the environment variables for those new environments and the application will keep on chugging.

### **.env files: Your solution to local development challenges**

The caveat with that approach, however, is local development. Odds are you don't want to set a global variable across your entire computer just to tell your application's dev copy what fake credentials to use or where your test database is. Even if you're using a containerized environment locally, you may not want to fiddle with environment variables directly.

This is where the `.env` file comes into play. `.env` is a de facto standard for an ini-like file that contains fake environment variables. An application that supports `.env` files will, on boot, run through each line in that file and read `key=value` pairs. For each, it will run "IF an environment variable with this name doesn't already exist, set it based on this file." That will set the variable only within the scope of your application's process, without impacting any other processes on the computer. Then the rest of your application can proceed and read from the environment as it would anywhere else, entirely ignorant of that switcheroo. (Don't write that code yourself. There are `.env` support libraries in every language that all do exactly the same thing. Use one of those.)

That, and only that, is the purpose of `.env` files: values that change per-environment, and thus are not part of your code base. Which brings up the most important thing to remember about `.env` files: _they_ _do not belong in Git_. Anything in Git is going to be the same on every environment, by design, which is exactly the opposite of what environment variables and `.env` files are for.

Values that do not change between environments also do not belong in the `.env` file. The site name, admin email address, and so on should either be in a read-only config file that is committed to Git or in the database, depending on if you want those configuration values to be end-user modifiable. (Either way is valid, as long as you do it deliberately.) But those values do not belong in the `.env` file, because they are not environment-specific.  
  
An exception to this rule applies to framework-specific configuration templates, such as .env.example. Modern frontend environments often utilize these template files to define the non-sensitive keys your application requires. While tracking these structural templates in Git is standard practice to help onboard team members, the actual local .env files containing true secrets must remain strictly ignored.

### **Handling build modes**

Sometimes you may want to vary the code itself with the environment. Generally that doesn't mean the source code, but the compilation process. In a compiled language (C, Rust, Go, Java, etc.) you may want to leave debug symbols in the compiled code in development but not in production. Even in interpreted languages (PHP, Javascript, Python, etc.) you may want to compile your CSS or aggregated Javascript differently, stripping out whitespace only in production so it's easier to debug, for instance.

That presents a problem on Upsun, as by design the build step is run independently of any environment-specific values. That's because the build output can be reused in a different environment, such as production. Specifically, in the case of a fast-forward merge to production, we don't need to rebuild your application. The built version from a branch is reused, which means what you were testing in a branch is _exactly the same bits on disk_ as what gets deployed to production. That is the only way to minimize "works on my branch" type errors and is part and parcel of the whole idea of containerized deployment.

But what if you want to "develop" on a branch? This is where `.env` file naming convention becomes important. Don't think of the non-production environments as development. Development is where you write code, which is your local computer. On your local computer you can set whatever environment variables (or `.env` files) you want. Instead of thinking of every branch as a development environment, think of every branch as a staging environment. _Staging_ should be as close to production as possible, including its build modes.

When viewed that way, it makes no sense for the build mode to vary depending on the environment, because that variation is a place for heisenbugs to appear. You don't want heisenbugs. (Trust me on this.) "Debug mode" should happen in the location you're debugging and writing code, that is, your local environment.

Which is the only place you can, and should, be using a `.env` file.

### **The .env-elope please . . .**

So to recap:

-   Values that are the same across all environments should be in Git.
-   Values that are different between environments should be read from environment variables.
-   Mapping host environment variables to application environment variables is fine, but your application needs a place to do so.
-   Static config files for environment-specific information (like database credentials) are a terrible idea and will come back to haunt you.
-   `.env` files are a surrogate environment variable for local development only, but should never be committed to Git.
-   Framework prefixes (such as `NEXT_PUBLIC_` or `VITE_`) dictate variable visibility. Ensure you restrict sensitive credentials to backend-only variables to prevent build tools from accidentally bundling secrets into the public client-side code.
-   Understand your application! That's always step 0.

#### Useful links

-   Variables overview | Upsun documentation
-   Use variables | Upsun documentation
-   Set variables | Upsun documentation

### [Faster project API with the Blackfire profiler | Upsun](https://upsun.com/blog/making-our-project-API-faster-with-blackfire-profiler/)

# Git’s getting fit: making our project API faster with the Blackfire profiler

Upsun has a unique architecture. One of the most interesting aspects of that architecture is that, while some of our APIs are multi-tenant, our most important API—the one controlling each project and its environments—is actually a single-tenant daemon.

Even more interestingly, this single-tenant daemon is a multi-protocol API within which the main API speaks Git. It also exposes a REST API which in turn exposes all of its Git capabilities and augments them with some others like answering the command to map a domain name to an environment, configuring access permissions, or scaling up a container in a preview environment. Essentially, any change to a running cluster happens through the custom daemon.

## What’s so good about a single-tenant daemon?

When we say single-tenant, we mean that every Upsun customer project has its own fully-isolated daemon. Each with its own datastore which contains absolutely everything the project needs to run—all from one place.

This provides a whole variety of benefits for our users. Including reducing the fault zones to the extreme, allowing the movement of projects between regions, and enabling continuous deployment of new features. All with no risk as a performance issue in one project, cannot affect another, thanks to this architecture. And even better, Git is not in the request path of a running application; meaning it could be down and the configured clusters will continue to run without a problem.

## How to monitor performance with single-tenant apps?

We’ve said a lot of good things about single-tenant applications, but there are some difficulties to consider, particularly concerning performance observability and optimization. After all, a project with hundreds of branches and a deep history will behave quite differently from a project with a single commit. So, if you don’t determine a way to prioritize performance optimization work, it's easy to let this important, but not necessarily critical component, fall to the wayside and allow your application performance to gradually get slower and slower. All production applications need observability, and as systems grow more complex, the demand for performance insights deepens.

While many engineers see observability as merely traces, logs, or metrics, its essence is in querying the system and delving deeper into potential bottlenecks or areas for optimization. Consider this: an engineer should seamlessly shift from wondering, "Which endpoints lag?" to querying, "What occurs within the code during the slowest 1% of HTTP requests, or what is unique about these slowest instances, endpoints, or even users?" Genuine observability offers both depth and breadth—especially when using a powerful observability tool, like Blackfire

## Enter Blackfire, the monitoring and profiling expert

Blackfire supports both application monitoring and profiling to maximize performance insights and optimization. Monitoring refers to an overview of system metrics: HTTP status, request delays (P50 and P99), top transactions, response times, and memory metrics, all organized by HTTP attributes and time. Blackfire profiling, on the other hand, is all about on-demand application analysis. To activate profiling, all you need is a specific HTTP header or manual code instrumentation. And as Blackfire was created to be a powerful profiling tool, it excels at visualizing data, take a look here:

Above is a traditional callgraph visualization, which shows the graph representation of all caller-callee relationships. While timeline, on the other hand, shows the function calls that happened during profiling on a time axis.

As you can see, Blackfire presents wall/time, CPU usage, and memory in a single profile. Allowing you to see a function's wall/CPU time and memory use—even network data in certain languages—in a single profiling session. Thanks to its deterministic profiler—which makes measurements when a certain event like a function call, function leave, or an exception happens—there is some overhead, but nonetheless Blackfire delivers unparalleled profiling depth. Learn more about Upsun and Blackfire profiling features.

Using both Blackfire monitoring and profiling simultaneously offers continuous opportunities to identify and address bottlenecks. Monitoring highlights system areas with the most time lags, while profiling lets us delve deep into those emerging, yet-to-be-explored bottlenecks, providing a powerful mix for superior performance.

## Dogfooding and implementing _the_ Git service

We take dogfooding very seriously. By using our own tools, we catch issues before they reach our users and continuously improve our offerings. Being able to self-test is a unique advantage for observability tools, and at Upsun, we fully embrace this—it's a beneficial cycle. For instance, we consistently test every service we provide, regardless of size.

Git sits at the heart of Upsun's user interactions. Whether it's environment setup or code deployment, Git built on Python's Pyramid framework plays a crucial role in our workflow. And given Blackfire's Python capabilities, coupling it with Git was an intuitive decision.

Our internal Git group fashioned a WSGI middleware for seamless Blackfire interaction. As of version 1.17.0, Blackfire natively supports Pyramid, streamlining integration. But how exactly do you integrate Blackfire with Git? It all starts with this command:

```shell-session
blackfire-python gunicorn --workers=2 test:app
```

This command ensures seamless integration with supported frameworks, just ensure you're equipped with a valid Blackfire environment and the right credentials. Then once you’ve configured our Git service's internal environment and activated monitoring, our dashboard will be displayed, like this:

From looking at this data snapshot above, it's evident that the majority of our Git commands hover around 50ms which is a good sign. Yet, we can still focus our attention on those four requests exceeding 1.6s as they represent our system's slowest transactions. A prime example of how Blackfire observability can highlight areas for optimization—but the solution to this particular optimization find isn’t the topic for today.

### Performance optimization in action

Our internal Git group pinpointed several performance issues occurring uniquely in certain environments. The exact nature of these environments remained unknown, making local reproduction challenging. This is where Blackfire's on-demand profiling proved invaluable. The team profiled specific HTTP requests and then analyzed the results with Blackfire. Below is a screenshot of the profiling of a slow Git endpoint:

A quick glance at the top metrics reveals equal wall time and CPU time, suggesting a CPU-intensive process within the application. In contrast, if the bottleneck were I/O-based, like a laggy microservice call or extensive file read, wall time would mirror the I/O time.

Diving deeper, Blackfire's callgraph visualization identifies performance drags by highlighting the most time-consuming call chain in red, indicating the _critical path_. This path showcases functions ripe for optimization. The Git team's analysis exposed a redundant function in this critical path, processing a large array and conducting unnecessary isinstance checks. Eliminating this redundant function resulted in ~40% faster execution time.

With this optimization, the callgraph no longer displays a critical path, meaning no obvious areas for immediate performance improvements remain. In other words, this means further optimizations are possible, but the returns might be less fruitful.

## Wrapping-up Blackfire profiling

Blackfire allows us to easily focus on low-hanging fruit optimizations, but it doesn’t need to stop there. With integrated profiling and monitoring, you can identify various bottlenecks in production systems, addressing them only when the fixes are easy to implement and cost-effective.

You might be amazed at the opportunities you miss with a tool like Blackfire, especially with legacy production code that previously lacked monitoring capabilities. Find out more details on our observability features or start a free trial today.

### [Introduction to automated end-to-end testing | Upsun](https://upsun.com/blog/automated-end-to-end-testing-with-cypress-presentation/)

# Introduction to automated end-to-end testing

### Video transcript

_We utilized ChatGPT to enhance the grammar and syntax of the transcript._

Good morning, everyone. I’m glad that you’re all here, and I hope you’re caffeinated. If we haven’t had the opportunity to meet yet, my name is Paul. I used to work at the University of Missouri for a couple of decades, where I was in charge of building and maintaining their processes and workflows for managing their fleets of WordPress sites. So, I have a deep history in both higher education and WordPress. I’m now a Developer Relations Engineer at Platform.sh. If you’re not familiar with us, we are a secure, enterprise-grade Platform-as-a-Service provider. We remove the complexities of cloud infrastructure management so you and your teams can spend more time responding to the changing needs of your institution and supporting your institutional missions, and less time fighting cloud infrastructure. Whether it’s on-site or remote, whether it’s WordPress, Drupal, Django, Gatsby, or whatever you need to run, you can manage all of that from one central location. We can play a crucial role in your end-to-end testing.

Now, before I get started, I do want to give you a couple of warnings. The first is that I am not a testing expert. This presentation, like most of my presentations, came about because I was given a task. I was told to add end-to-end testing to some of the things that we support. I didn’t know much about it, so I had to learn. In that process, I thought maybe others could learn from it too. I asked the WordPress channel if anybody was interested, and I got a great response back. That’s how this presentation came about.

The second thing is that I’m going to do all of this live today, and you know how live demos go, so wish me luck. I’ll probably take up the full 45 minutes.

My goals for you when you leave here today are:

I want you to be able to define what end-to-end testing is.  
I want you to be able to remember at least one advantage that end-to-end testing brings to your workflows as well as your organization.  
I want you to understand what Cypress is, how to install it, how to configure it, and how to write at least your first test.  
I want you to be familiar with the strategies and best practices and have all that foundational knowledge that you need in order to build the second, third, and fourth tests.  
So, how many of you here are already doing some form of automated testing in your workflows? Wonderful. How many of you are doing end-to-end testing? A couple? Okay, so for everybody else, if you were given a task or you needed to write some new feature or new functionality, how would you go about verifying that what you’ve written is working the way you expect?

\[Audience member response\] "Visit the site."

Exactly, you visit the site and do it manually, right? Well, that’s all automated testing is. End-to-end testing mimics the real user and tries to replicate the steps that they would take and then verifies that the application has done exactly what we expected. That’s all end-to-end testing is—it’s just the automation of that manual process.

Now, it does bring some great benefits. In a lot of cases, we can’t surface problems with our software until it is working in that real-world scenario where it’s actually interacting with the database, has the user interface in front of it, and is connecting to all those third-party services. We really can’t surface those problems until we’ve tested it just like the user would. But that takes time, so that’s where automation benefits come in. Additionally, because we can catch those bugs before they occur—before we release them into production, it’s much less costly to fix them. Once we get our test passing, we then have a very high level of confidence that what we’re introducing or deploying to production is going to work exactly as we expected, and it’s not going to negatively affect the user experience, ultimately increasing our quality assurance. Lastly, if you’re working with departments where they’re giving you a set of features that they want, and you can write your test to verify those features, then you can ensure that you’re in alignment with those business requirements.

Now, how does end-to-end testing differ from other types of testing? Well, if you’re familiar with the automated testing strategy pyramid, we do unit tests at the bottom. We do a whole bunch of them, but they’re isolated, just testing individual pieces. Then we move into integrated testing, where we begin to test our code with external services. We do fewer of those because they’re a little harder to do. At the top, we do end-to-end testing, where we’re testing everything. But because we’re testing everything, it’s much more complex, so we do fewer of those, with the goal being that those manual tests are very few and far between.

Now, if you’re not familiar with the other two, unit testing is the idea that in an ideal world—and I know higher ed is not ideal—but in an ideal world, you actually write a test to test the smallest piece of functionality you can. Then you actually write the test before you write the functionality. So, in your programming language, that’s usually a function or a method. As you write that function or method, you continuously test it over and over again, but you isolate it from all its external requests so you’re only testing that functionality. That’s why we do it very often because it gives that immediate feedback. Now, once we start getting greens—we’re passing all those unit tests—then we move into integrated tests. So, we might take individual units that we’ve been testing and now group them together and begin to test them as a group. We might take our code and begin testing with external dependencies or external services with the goal of surfacing any issues in the communications between our code and those external dependencies. Then we come back to end-to-end testing again, where we’re mimicking everything from start to finish and trying to verify, exactly as a user would, that our features are working.

Now, with that said, the reason we have to do it far less often is because it’s more expensive. That can be both monetarily because we’re going to have to have an environment or server set up in order to run these tests, and also in terms of human resources—it takes time to write out all of these tests. Occasionally, I’ll mention brittleness. It can also be a bit hard to maintain. So, as an example, let’s say you write a feature where you’re going to add a menu item to the admin bar. Then you’re going to have the user go somewhere, they’re going to have a panel, fill in some information, and do something. We can write the test, verify it’s all working correctly, and then in the next iteration, someone decides to change the ID on that menu item. Well, now suddenly we can’t go to that menu item in our test like we did previously, and the test breaks even though the functionality is still there. So that’s just an example of a brittle test. We have to be aware that these can be a bit brittle.

So, Cypress. How many of you have heard of Cypress? Anybody played with it? A couple? Okay, so for everybody else, Cypress is an open-source automated testing framework whose main goal when they designed it or began to build it was to expedite the time between when you install it and, as a developer, start writing your tests. In previous times—the dark ages, I guess—there was a lot of configuration and setup involved in building automation of the browser. Their goal again was to get you in there and writing those tests as fast as possible.

Now, it does bring some specific advantages. It is open source; they have an optional SaaS product. It doesn’t use Selenium, it doesn’t use WebDrivers; it uses an Electron app and it embeds your application—your web application—inside that Electron, meaning it’s all running inside the browser, so it’s very, very fast. Now, they support all the browsers except Safari, which is on the roadmap. The other cool piece is time travel and test replay. So, when you run a test, you can go back and replay the test and watch your application state change as it moves through all the steps. Time travel then allows you to go back to an individual step and see your application state, how it’s performing, and look at exactly what’s happening at any step as you move backwards and forwards. Additionally, anything that you output to the console will be available in that step, and it provides a whole host of debugging tools for you to be able to debug your test and find out exactly why it’s failing.

Some other cool parts are auto-waiting. So, when you visit a site, it’ll automatically follow redirects until it gets to a 200. Then once it gets the page, it’ll wait for that page’s load event to fire before it continues on. If you’re asking for a DOM element, like in a dynamic application, it’ll automatically wait until that DOM element is available or until it times out. So, auto-waiting is a great feature for you to make sure that things have loaded in the way you want.

Network traffic control is also really cool. You can intercept any request—so any request to an endpoint or a location—you can intercept that, inspect it, change the data that it’s sending out, and when the payload is returned, you can catch the payload and manipulate that data, or you can catch it and return your own data, never allowing it to go back out. Lots of incredibly cool features.

Now, Cypress is not the only game in town. There are several alternatives to Cypress, including Playwright, Nightwatch, WebDriver, Codeception, etc. I’ll tell you that the Go team—and don’t quote me on the dates, but I think it was 2019—was on Cypress. Then sometime around 2021-2022, they moved to Puppeteer, which is backed by Google, and then as of February of this year, they’re now on Playwright, which is backed by Microsoft. Personally, coming out of my 20-plus years in higher ed, I have great respect and value for those tools that I can depend on for a long time, right? I never had the opportunity to change my tooling in 18 months; that was not an option. I needed something that I could depend on for 3 to 5 years, so I am sticking with Cypress because their documentation is excellent. They have not only thorough documents but also guides, tutorials, videos, and tons of example code, again with that goal of getting you to writing your test as quickly as possible.

That said, maybe next year I’ll be back and talking about Playwright, I’m not sure, but for now, it’s Cypress.

Alright, so installing Cypress, again, as fast as possible, right? It’s as simple as an npm install. And this is where we switch to the live code, so start wishing me luck that we have some internet here. So, I’m going to go ahead and start that. \[Pause for action\]

That is not clicking. There it goes. What’s going on? Oh, it’s back here. That’s interesting. Let’s try and clear npm install, and that is it. That’s all you have to do to get it installed. It automatically downloads the dependencies and builds the Electron app based on your operating system. It should actually be… there it is, it’s done.

From there, to configure Cypress, all we have to do is open it. So, I’ll open this up. It goes and builds that app. The first time it runs, it says, "Hey, you don’t have any configuration files. What are we doing today? Are we running end-to-end tests or component tests?" We’re going to focus on end-to-end. So, as soon as you click on that, it says, "Okay, I’ll configure things for you in the background." Now, once it updates, notice I’ve got a configuration file and a collection of supporting files, and that’s it. That’s all you have to do to configure it. From there, you just pick which browser you want to start testing in. I’m running my presentation in Chrome today, so I’m going to use Firefox. Go ahead and launch that. And then, just like with the configurations, as soon as it comes up, it says, "I don’t see any testing files." Testing files in Cypress are referred to as spec files. It says, "Do you want me to give you some scaffolding files, some examples so that you can start building your own, or would you like to go ahead and write your first test?" Let’s go ahead and write our first test. I’ll call this one "first" and then create that.

In the background, it has written that file in a directory called e2e. Can everybody see that code? Is that big enough? That’s big enough? Alright. What I’d like to do is, as we go through this, kind of break down all of these parts.

The very first part we have is called "describe." The `describe` block is simply an organizational tool for you. You can have multiple `describe` inside a single spec file. You can nest `describe` inside of a `describe`. It’s simply an organizational tool. It takes two parameters: a title that you want to have show up in the testing tool to identify your group of tests, and a callback function. We put our tests inside the callback function.

So then, notice the next piece down is "it." `it` blocks contain two things: it’s where we put our test, and it takes a label, again, to show up in the testing tool so we can identify the test we’re running, and then another callback function. That callback function is where we put our actions and our assertions, where we’re actually going to start doing some things.

So, if we’re testing a web application, what is the first thing you probably need to do? You’ve got to get to the application, right? So, usually, one of the first things you’re going to do or use is `cy.visit`. That is going to load a URL. It’s going to default to a `GET` request. It’s going to follow any `300` redirects until it gets to a `200`, and once it gets that `200`, it will wait until the page is loaded and fires. So, I’m going to go back into our code. I’m going to update this. It’s a little hard to see with all this other Zoom stuff, so if I misspell something, we’ll just go with it. \[Pause for action\]

It says, "Page has valid title." I don’t think I totally missed that. We’re going to go ahead and run this. Let’s run this. \[Pause for action\]

Oh, I forgot to mention, I am running DDEV. Anyone familiar with DDEV? A couple of you? DDEV is a local development environment. I use it a lot because we have an integration with it, which allows me to clone my production site, which I also forgot to tell you about. I have a production site. This is my production site. So, this allows me, from Platform.sh, to clone my production site locally into DDEV. I’m going to go grab that, so I’m going to say DDEV. That’s the right one, there we go. So, this is the URL assigned to my local instance. I’ll go back into my test. Let’s update this. Save that and run our test. \[Pause for action\]

Go. Now we can see that we have… hopefully, you can see that. There’s the homepage. That was the title I gave the `describe`, and then you name the test itself. The test body currently just has visiting the site.

Alright, once we have visited somewhere, what do we need to do next? In other words, I want to verify that this page is what I expect it to be.

\[Audience response\] "Check the page title."

Yes, check the page title, right? You need to get some DOM element and then verify that it contains data, has a class, or is visible. We need to, in some way, validate that the page is what we thought it was going to be. So, `cy.get` allows you to get one or more DOM elements from the page. It’s going to yield back that DOM element to the next thing that we chain to it. It’s always going to start—this is important to remember—it’s always going to start from `cy.root`, which is typically the document root. So, if I do `cy.get("main")` and then another chain with `cy.get`, it’s not going to limit the searches to that; it’s going to go back to the root. Now, there are other ways to do that, but just not with `cy.get`.

So, `cy.get` is how we’re going to get our elements, and just like the others, it’s going to automatically keep retrying to get that DOM element until it either exists or we reach some timeout. So, I’ll go back into our code, and I’ll add in `cy.get`. Let’s get the title—there it is. And then, what do we need to do? Tell it what it should be, right? So, the method we use is `should`. We use the `should` method on that DOM element, and that is what’s going to create our assertion or our validation. Now, it accepts a Chai-compatible string. Chai is a Behavior Driven Development (BDD) testing and Test-Driven Development (TDD) assertion library. It lets you use plain English words to describe the assertion or validation you’re trying to make. It’s always going to yield back the same subject it was given, so if I give it the title element and make some assertion, if it passes, it’ll yield it to the next, which means I can chain assertions. It’s automatically going to keep retrying to get a positive assertion until it either reaches a timeout or ultimately fails.

So, in this case, I’m going to break this the first time just so we can see it. I’m going to say `should` contain "WP Campus 2023." Let’s run that test, and notice it fails because this isn’t 2023, right? So, I’ve got a nice little red check mark— you might not be able to see the red check mark there—up next to the test, indicating the test failed. The assertion did not pass. Now, I’ll come back in and hopefully, I can fix that. There we go. Now it’s actually... it also watches, so it’s going to watch your test and automatically rerun it. It’s probably already rerun that test, and it did. So now I’ve got a nice green assertion. I’m also colorblind, so if that’s not green, somebody please tell me. I’m assuming it’s green. Okay, so we’ve got a green assertion and a green check mark, which means that you have now just completed your first test. There we go.

I know that’s a very simple test, but for me, the hardest part about learning some new thing is just getting the thing installed, getting it configured, and then doing something. So, if you can go back now and install it, configure it—which is basically just opening it—and then write just a simple test of "go to my homepage and make sure the title is right," you’ve now incorporated it into your workflow. The next one will be that much easier.

In fact, as you begin working towards writing your next set of tests, there are some things to keep in mind. One is that writing the hardest part about tests is knowing what to test. That’s the hardest piece. So, my suggestion would be that the next time you’re given a task, a feature that’s supposed to be incorporated into your site, write down all the steps that you take to manually verify it. Go in and say, "Okay, I clicked here, I clicked here, I clicked here, I clicked here," and at the end, "This is what should be on this page. This is how it should react." Keep breaking those down into smaller and smaller steps, and then convert those steps and actions into a test. Then keep running that test until you figure out—as long as the feature is working—how to make sure you’re writing it correctly. Make sure you’re testing both the happy paths and the unhappy paths.

What I mean by that is, if we were testing a login form, for example, a happy path would be: I put in a username and password that’s correct, I click submit, I get somewhere in the admin area, and in the upper right is my username. That’s the happy path. An unhappy path would be: I put in a username and password that aren’t correct, I click submit, I come back to the form, and now I have an error message. So, we want to make sure we’re testing the unhappy path to ensure the application is still acting and performing the way we expect it to, even if the user doesn’t follow the correct steps.

Now, a good test should cover three phases. One is setting up the application state—we’ll talk more about application state later. The next is to take those actions, again mimicking the user, performing the steps necessary to test this feature. And then the last is to make an assertion about that resulting state. Now, you may see this referred to as "arrange, act, and assert," or you might see it referred to as "given, when, then." So, if we think back to the first test, given I’m an anonymous user, when I visit the homepage, then the title of the page should be "WP Campus 2024." Make sense? So, be thinking in those terms: given some state of the application, when I do these steps, then the application should be this way.

The other piece to think about as you’re writing these tests is you should try to make them such that they are independent of each other. What I mean by that is, if I have four tests, I don’t want test three to be dependent on the state that test one created. Because one: test one may pass incorrectly and leave me with improper state; or two: it might fail and leave me with a state that is going to negatively affect test three. So, we want to make sure that any test can run independent of the others.

Are you ready to write the second test? That’s what I’m aiming for. Okay, so I’m going to come in here and create a second file. Get up there. We’ll do a new JavaScript file, and I’ll call this one `auth.cy.js`. Let’s say I’ll describe, and we are going to describe this as `auth test`. Then we have our callback. And then I’m going to do it `can auth`. So far, nothing too complicated. Callback function, lots of callbacks. And then, what’s the first thing I need to do if we want to test the login form? I need to visit the login form, right? So, I’m going to go `cy.visit`. I’m going to go back to `DDEV`, I’m going to grab my address again, come back in and say, “Go visit there with `wp-login.php`”. Now, can anybody foresee an issue that I have just created between `auth.cy.js` and `first.cy.js`, specifically in the `visit`?

Where is that URL right now? "Homepage." Homepage of where is it running? "Local." What if I need to run my end-to-end test on a shared development environment? What if I need to run them in a staging environment, or PR environment, or somewhere else? All right, so we need to talk briefly about configuration. One of the options in the configuration file is something called `baseUrl`. `baseUrl` allows us to define a domain, and then any calls to `cy.visit` or `cy.request` that are relative will have that prepended. But the really cool thing is that it can be overridden by other environment variables. So, Cypress does have a processing order for environment variables. And so, for that special `baseUrl` variable or any other environment variables we need to create, we can either put them in config, but we can also write an `.env` file that overrides those. Or, if the system where we’re running `cypress run` or `cypress open` has environment variables that are prepended with `CYPRESS_`, it’ll automatically parse all those and override any of the others. Or, at the time we run Cypress, we can also pass in overrides for the config or those environment variables. Or—it’s not even on the slide—in an individual test, you can override a config or those environment variables, giving us a lot of flexibility. So, that means we can write our tests such that we can run them anywhere and not have to worry about changing the test for any specific environment.

So, I am going to go in here and open up the configuration file, and I’ll add that `baseUrl` in it. I’m going to say maybe normally everybody else on the team uses `https://local.site/`, and I’m the oddball out. Alright, now if I run that right now—watch, Cypress closed out—come back and it says, "Hey, I can’t get there because there’s nothing there," right? So, if I come back in, close Cypress out first - close Cypress—I’m going to rerun this. Come back into my testing environment. Can you see down at the bottom? Hopefully. I’m going to do an export where I’m setting `baseUrl` equals that address I used earlier. Okay, I’m going to go ahead and do that. I’ll do `npx open` again. \[Pause for action\]

Oops, over too far. There we go. And then in my tests here, I will update those two tests. \[Pause for action\]

Update these tests. \[Pause for action\]

That one, and my auth test. There it is. And if we save those and go back out to Cypress, relaunch the testing environment. \[Pause for action\]

Go. And now if I run `first.cy.js`, we still go back to our local instance. And if I run `auth.cy.js`, we end up at the login. Now, I need to do a PR request, and I have a workflow that builds a copy of that environment. I don’t have to change my test; it’s all going to work. I’m going to be able to run those directly on that environment without having to change my test.

Now, if we’re testing the login form, what do we need to do next? Type the username? We need to type in a username and password. One of the cool things about this environment is if you notice this little button up next to the URL, it will give you an element suggested selector—a lot of words. So, I’m going to hit that, and as I hover around in here, it’s going to say, "Hey, here are all these different elements you can select." I click on it, then it gives me an option to copy it into my clipboard. So now, I can go back into my test and say, "Alright, we are going to go in here and get that element." Now, one thing I’ll suggest that I’ve learned is go ahead and do a `clear()` on the element. That just clears out the element in case there was placeholder text or anything else. And from there, I can type "bob." And what’s the next piece we need? Password. Sometimes it doesn’t rerun it; it doesn’t always redo the select. Let’s grab that again. Go in here, and we’ll drop you pasted. Here we go. And another `clear()`, and another type "123." Save that. Come over to our test. Now, we’ve got "bob" and "123." What’s the last thing we need to do?

\[Audience response\] "Enter."

I heard two things. I heard "enter" and I heard "click." You can do both. So, one thing you can do is simulate button presses or key presses using the curly braces and a short tag for that key. So, I’ll go ahead and do that. Or, if we want... I wiped that all out—oops—"123". Let me come back over and grab that button name. Come back in here, get that, and do a click. Wow, you’re a tough audience; you’re not laughing. I think it's pretty cool.

So, can anybody foresee a problem with what I’ve done here? "SSO." Oh, well, SSO might be one thing, which highlights… yes, you’re highlighting the problem. What is wrong about this? It’s hardcoded, right? We don’t want that. But we have the ability to start add environment variables, right? So, I can go back into my config, and I can say, "Hey, I want to add environment variables." Oops, that is not the right key. Let’s try that one. There we go. And I can say, "Hey, I want `test_user`, and I want `test_user` to default to `bob`." Oh, we’ll do "bob2" to change, and then I need `test_userPass`, and I want that default to "4567". Right? Now, if I update that and I come back into my test, I can get rid of those static values, and I can say, "Hey, I want to use `Cypress.env` and I want you to go retrieve `test_user`, and I want you to go here and I want you to go retrieve `Cypress.env('test_user_pass)`." And if we save that, assuming I didn’t make any typos, it’s using `bob2` now. Which means then, in another environment, I can add those environment variables and it’ll automatically pick those up.

Alright, now there is one piece I want to mention real quick, and that is you do need to decide on a strategy for managing state. Now, this particular slide is about the state of a user since we’re testing a user, but this applies to the state of the application itself as well. So, one strategy is you can stub requests. Remember I mentioned the intercept? So, we could intercept a request to wp-login, catch that, and then return back static information about the cookies and the session information. It’s nice because it’s really fast, and I don’t have to have an environment—I don’t have to set up a database. But notice he’s grimacing because it requires fixtures. Fixtures are the static data that you want to return back. If the cookie information and the session information change in the app, I’ve got to remember to go back and update that static information I’ve saved. But it’s also not a true end-to-end test, right? In an end-to-end test, we really want to try to mimic as close to real-world as possible what the end user is experiencing.

So, the next strategy is a static user, where we go into our system and actually create a user that we’re going to use in our tests. It’s nice because then it is a real end-to-end session, right? We’ve got a database, we’ve got a real user. But that means we have to have an environment where we can put a database, and we’re going to have to set up the database—whether that’s exporting from some other system and then importing it there, or maybe automating the installation of WordPress and setting up that space. The downside, though, is that - particularly in WordPress - your user, as they do things, the state of what is associated with them changes and is stored in the database, right? So, we end up with dangling state or stacking state, which could affect reruns of the test or future tests because we’ve got that saved state with the user.

So, the last type is a dynamic user, where you’re going to delete and recreate the user before every test. This is a true end-to-end test because now we’re recreating exactly the experience that the user would have. We don’t have to worry about any of that state mutation or dangling state, but we do have to do the whole teardown and rebuild of that state with the database every time, which means it is a bit more slow, a bit more complex.

Well, for the purposes of today, I’m going to _—_ if I can find the right keys _—_ I’m going to have DDEV create a user for me, and I’ll have it create bob2. I’m going to take this password so we have a real  live user. Copy that, come back over to Cypress, I’ll close out my test, close Cypress, and come back. And before I launch it, I’ll do an export of those values. Alright, so I’m doing an export of `test_user`, so now we’re going to use bob2 and that password. Now, let’s relaunch Cypress. Let’s relaunch our end-to-end testing.

\[Pause for action\]

Now, if we go to the auth test, TA-DA!, we have a real user. You can validate this worked because if you don’t put in the correct username and password, you go back to the login, but it does send a 200, which technically means it passes. So, how can we validate this worked? Grab the username. So, I’m going to go up here, I’ll use that picker, I’ll say, "Hey, give me this." I’ll grab that, go back into my test and say, "Okay, after you click it," it’s automatically going to wait until the next page loads, so then I can say, "Get that." I’m going to drop down because it’s getting a little long, and I’m going to say, `should` contain, and then I’ll go back and say `Cypress.env('test_user')`. If I spell it correctly. Now, if I save that, we run the test. Yay, there it is. There’s our assertion. It’s nice and green. We passed. Good? Everybody good so far?

Okay, so now let’s say we want to extend the test. We just did the writing of the second test, but we want to extend it. Don’t look at that; forget you saw that. I’m sorry, I went too far. So, we want to extend this test. Let’s say now we want to have a second test where we can add a custom post type post. Maybe they have a custom role—this user has a custom role—and we want to verify that they can create that post type and see it. One thing I have not mentioned is that when you run Cypress, when it runs each test, it’s just like it is using incognito mode or private mode for every test. This means it brings up an instance, it runs it, it finishes, it closes it, which means if I try to go here and do `cy.visit` and then maybe do something like `wp-admin/edit.php`, what’s going to happen? It’ll succeed in that it’ll get a 200, but it’s not going to go to the right place, right? So, should I copy all of this content and paste it into the next test?

\[Audience response\] "No."

Okay, the shaking of the head is the correct answer. Right, instead—remember I said it gave us a bunch of supporting files? One of those files is called "commands.js." That allows us to create our own custom commands. So, I can use `Cypress.commands.add()`. The first parameter is the name of the method, this new command you want to call, so I’ll say "wplogin." The second is—guess what the second one is? Callback function, right? Callback function. And then, inside of here, we can put in that code.

Now, do I still want to use these environment variables? Probably. Maybe? What if I want to test multiple users? Instead, I could say, "Alright, the callback function will accept a username and password." Now I can go in here and wipe this out. Then this— \[Pause for action\]

All of it, there we go. And say, "Username, username here." Oh, that was password, sorry—that’ll fail. Try "Password," here we go. And then, down here, do "Username." Then back in my auth test, what I can do is say `cy.wplogin()` and then hand it—wrong key there—`Cypress.env('test_user')` and `Cypress.env('test_user_pass')`. One downside of live demos is that I am not a fast typist. All right, now let’s go see if that worked. There’s our auth test. The first one said, "Yeah, look, it ran all the code, and we..." Oh, this is a good time to show you—remember that time travel? Here are all the different states. You can see it got the input for the username, typed it in, cleared the next one out, and the password was typed in. Click submit, follows, follows, follows, all the way there, and there’s our assertion.

Cool. Alright, so now let’s say I do want to make that next test. Should I copy this line and paste it in?

\[Audience response\] "No."

No. So, just like with WordPress, Cypress gives you hooks. One of those hooks is to run something before each test. Guess what it takes? Whoops, that’s too many—callback function. Yeah, everything’s a callback. And so now, I can take this line—actually, let’s do it this way; it’s running off the side of my screen, I can’t see it—cut it from there, put it up here. Now, if I run that, notice not only did it do it on the first one, it also did it on the second one. And now, at the end, it actually did the edit page.

Alright, but it is going to the form, getting the elements, and putting in the information every single time. Two tests, probably not a big deal. But what if we have 15 tests? Wouldn’t it be nice if, instead... this is what I wanted you to see earlier—if we could save the session data? Yeah. So, we have that ability in Cypress. It will take a session that we’ve created and store it based on some ID. Now, it takes four arguments. I bet you can guess what a couple of them are. The first one is an ID on how we want to identify that session. The next one is a callback where we run our setup code. The third option is another callback where, if we restore a session, we can validate the session and If validation fails it will rerun the setup callback. And the fourth is whether or not we want to share this saved session with additional spec files.

So, I'm going to add this to our code. I'll go back into the commands, grab all of this, cut it out, and say `cy.session`. I'll use the `username` as our ID, set the callback, and then paste our information back in. Now, if I save and run these tests, the first time it says, "Hey, I need to create the `bobby2` session," and it runs through all those steps, just like earlier. But the second time it says, "I need the `bobby2` session, but I'm going to restore it," so it doesn't have to repeat that process.

This is huge and really important because many of you will likely need to perform authenticated session tests. This was one of the hardest parts I came across, and the reason is that between version 12 and version 13, Cypress introduced a feature that made it much easier to save session information. If you search online for how to do this, you'll often find outdated articles and blog posts that no longer apply. 

In the last few minutes, I want to give you some best practices to keep in mind as you start writing these tests. First, if you don’t need to test a login form, don’t bother bringing Chrome into the process. Instead, handle it programmatically. By that, I mean instead of visiting the page, do a `POST` to the wp-login.php page. Everything else remains the same, including the method name and session setup, but I'm posting that information programmatically, so I don't have to bring up Chrome.

The next point to consider is one of the trade-offs when using Cypress, especially if you're already a JavaScript developer, you can’t assign the return values from a Cypress command to a variable or constant; you can only access those returns via closures and aliases. Some people find this jarring, but it's the trade-off for speed. To quickly dive into Cypress, you have to work within their opinionated framework.

I mentioned this earlier, but try to set the state before each test, so that any test can run independently at any point. Also, try to avoid using brittle selectors. IDs and classes may change, and even the location of an element could change without being visibly noticeable. Cypress suggests using data attributes where possible, setting unique data attributes that don’t change, to ensure your tests are not brittle.

OK, pop quiz: who can define end-to-end testing? Anyone? This was one of my goals and I don't want to fail my goal! Somebody!

\[Audience member\]: test from end-to-end

Test all the parts, from beginning to end! We're going to try to mimic a user walking through the paths of our application and then validate from what they did, our application responded correctly. Can anybody tell me one benefit of end-to-end testing?

\[Audience member\]: save time!

Save time! right? Way faster. Basically doing manual testing but a lot faster, because the computer is way faster than you. All right, does everybody feel comfortable with what Cypress is, installing it, configuring it – which you're just opening it – and maybe writing your first test?

\[Audience member\]: I have a question

Sure.

\[Audience member\]: So in the code you wrote  `Cypress` with a capital and then `cy`.  What's the difference?

Cypress refers to the global application, and you use it for accessing environment variables and other global settings. For other commands, you use `cy` within your tests. You can check the docs for more details.

So does everyone feel comfortable writing that first test? Do you feel fairly comfortable with the best strategies on how to write your second and third tests?

Now, I want to show you a real-world scenario to give you an idea of how this all fits together. One of the reasons I love Cypress is that they have a well-documented and stable GitHub action. This means that in my GitHub workflows, when I create a pull request, Cypress can automatically run all my end-to-end tests. At Platform, we also have GitHub integration. When you create a pull request, it sends that code to us. We then clone your production environment into an isolated environment with that pull request code, bring up the cloned environment, generate an ephemeral URL, and send that URL back to GitHub.

When I run the Cypress action, I can pass in that URL of the cloned production environment. So, when I run the end-to-end tests, they're exactly what I would expect in production. This boosts confidence in the code before deployment.

I'll show you this in practice. I have a pull request open for my production site, and down at the bottom with my checks, I can see the Platform integration completed, and it deployed that PR environment. Opening it up, I can see a clone of my production environment assigned to the pull request. I also see that my end-to-end testing failed. Looking into the details, it says six tests passed and one failed. If you integrate your project with Cypress Cloud, you can replay the tests when something fails. You can rerun the test, see the steps it performed on the left-hand side, and view the state of the application on the right-hand side. In this case, the test failed because the trash can icon was missing, preventing a user from deleting their post. Now I can use the testing tools to debug the issue.

Alright, I think we have 15 minutes for questions. Does anyone have any?

### Q&A

_Please note: these are best-guess due to poor audio quality_

\[Audience member\]:  When you're deciding what to end-to-end test, is it always some sort of frontend functionality you're testing? or How do you decide broadly what to test?  
 

\[Paul\]: This tool is for web based applications which most always will be inside some web interface. There are other tools that can do API testing directly. You could fake API testing if you really need to but this isn't meant for that. When you need to mimic a user's Behavior through the application and validate some feature or function, this is what you use.

\[Audience member\]:  When you're working with WordPress you're often modifying a lot of core so is it helpful, or is there like a base package to actually test core before you go in and test your individual parts of the application? Is there a library you can pull to make sure regular WordPress works first and then test our layered-on functionality?

\[Paul\]: Core switched to Playwright so they have the Playwright tests; they abandoned the Cypress test years ago so "no" unfortunately. I would say if that is a crucial piece then I would look into Playwright and then that way you've got their test that you can run. It's not like Playwright is bad. I don't want anybody to think that, you shouldn't use it. It's just it's new; it's only a couple years old, the documentation is there but not as extensive. So if that's an important feature I'd say check out Playwright and then that way you've got their test that you can run.

\[Audience member\]: Well, I mean I don't know if you like actually need to test like everything that core is testing. You know, just overview. Like, oh WordPress is here.  You know what I mean?

\[Paul\]: That's another example. We manage, when you do the one-click deploys, right?  We manage those and so I have all the updates for those automated. And as part of the test, I do a quick check of core features to make sure the most important features are there so that none of our custom code has negatively affected any of the core features. So, yes. I mean I've done that and no reason you can't.

\[Audience member\]: Can you interact with that clone? If you want to do your own manual testing or something?

\[Paul\]: No, you can't. It's going to save the state of each one but you can't click and do additional things.

\[Audience member\]:   
You can't log in as yourself and try stuff? You'd have to write a test for it?

\[Different audience member\]:   
I think you're just asking: can you as a human visit the platform PR environment?

\[Original audience member\]:  
Yeah.

\[Paul\]: Oh,absolutely! I thought you meant the screenshots of the testing environment that we saw that Cypress brought up to show us the test.

\[Audience member\]: No, no. I meant the clone using the new code. It'd be cool to be able to interact with that.

\[Paul\]: Yeah, you can absolutely do that. In fact, you can use that to help write your test too. When you go and check it, use that as where you're recording all the steps that you're taking. I'm sorry, I didn't understand. Anybody else?

\[Audience member\]: Do you have any visual regression in your stack that you do with these tools?

\[Paul\]: So that's a separate tool I use and I'm going to forget its name… It's got a monkey face… oh I forget the visual regression testing name… and I will remember about two seconds after you all leave what the name of that is… There is an open source - backstop!  Backstop, we use backstop for visual regression testing to make sure there's no visual regressions. If you're not familiar with visual regression testing, what it does is: you give it a production site or a baseline site that should be correct and then you give it your testing environment, your development, staging, PR, whatever environment. It takes screenshots of locations that you identify and it diffs them. If the diff is greater than some percentage that you define, then it flags it as a false or that there has been some regression. So, yeah, absolutely you can add it in and I would encourage you to add in as many of these kind of automated tests as you can to reduce the number of man hours that you're having to put into this stuff, because I know in higher-ed you don't have the time; you just get more responsibilities, not more people. So anytime you can automate these kinds of things the better. Any other questions?

\[Audience member\]: Someone mentioned SSO. We tried behat like years ago and had trouble with logging into WordPress to do any of the inside stuff. We were able to do frontend, but not like log in, post, so…

\[Paul\]: Assuming you have a test user in the single sign-on system where you can have the password somewhere to actually use, you should be able to do it. I don't foresee any problems with SSO. I can't say I've tested it recently with SSO but it should work.

\[Another audience member\]: We haven't done that with Cypress but we've done it with Puppeteer with AWS. The same thing, and yeah… it  actually works the right way.

\[Paul\]: That's a good point. Whether you do Cypress or you use Playwright the concepts are all basically the same. It's just the specifics of maybe how you write the test, right? So if you start playing with Cypress and you decide this isn't going to work for us, it's not like you really lost anything except maybe a little bit of time to learn the specifics.  But you can just take that same testing ideology and move it over to the next product. Any other questions? Everybody ready for lunch?

\[Room moderator\]: There is one online. One question online.

\[Paul\]: Oh, so the tear down and setup. Yeah, so in the app state. So when I mentioned I test the users for WordPress core, what I have to do is I have functions that I've written in Cypress that will connect to that environment and create the dynamic user just like I did. Actually, first it deletes the user, deletes all the posts, deletes everything about the user. Then it creates the user, retrieves back the password, then sets that as a Cypress environment variable and then kicks off Cypress. So that's how I manage that and you'll have to do a similar thing. You can do it in the GitHub actions if you want, there's no reason you can't but since Cypress has those hooks you can do a `before` hook and say before I run any of these authenticated tests, run all this setup stuff or the `beforeEach`, where with GitHub actions it's going to have to be mainly before and after.

I believe that's all the questions online. Are there any other questions? Again I'll be here the rest of the time until Saturday. Feel free to grab me, ask me any more questions about anything. I love automation so if it's testing, DevOps, any of that stuff I love it.

### [How PaaS Simplifies Cloud Adoption for Developers | Upsun](https://upsun.com/blog/cloud-adoption-challenges/)

# Customer transformation: from AWS struggles to seamless scaling

If you’re an engineer in a non-tech industry, managing a cloud infrastructure can feel like an endless cycle of putting out fires. I know the frustration—site crashes during critical promotions, complex cloud setups that demand expertise you don’t have, and the sinking feeling of realizing the solution you bet on isn’t delivering. 

In this article, I’ll walk you through my journey, from battling AWS’s complexities to finding a better way with Platform.sh and then Upsun. By the time you finish reading, you’ll have insights on how to avoid the same mistakes I made and discover a cloud platform that lets you focus on what really matters: scaling your business.

## The Struggle with Cloud Complexity

When I joined a century-old food and beverage company as their lead engineer for all things web, I had a clear mission: deliver exceptional value to our customers by ensuring our e-commerce platform remained solid, especially during peak-traffic times. While the company had a strong technical team for local network management and line operations, the realm of web infrastructure was completely new territory. 

Key Challenges We Faced:

-   **Scalability Issues:** Our web application setup was overwhelmed with challenges.  Despite our efforts, true scalability felt out of reach. Replicating our production environment seemed nearly impossible, making troubleshooting a nightmare. 
-   **Staging Environment Woes:** Without an efficient way to create a reliable staging environment, we lacked confidence in our code’s performance in production.
-   **Security Concerns**:  Security was another major concern–both in terms of code integrity and access management. We’d often build solutions locally, only to encounter unforeseen issues once they hit production. 

Searching for a solution, AWS seemed like the obvious choice. The buzz around it as a trending IaaS model promised control all the way up to the OS level, with the industry promoting its scalability and stability. I was convinced it was the silver bullet we needed, and I pushed hard for our company to invest in cloud infrastructure. But after making the switch, I quickly realized it wasn’t as simple as it seemed.

### The Tough Reality of DIY Cloud Infrastructure

Managing an IaaS platform like AWS turned out to be far more complex than we anticipated.  Instead of focusing on development, we were caught up in the demands of infrastructure maintenance—covering everything from security to scaling.

AWS is powerful, but it’s also complex. Setting up auto-scaling groups, managing load balancers, and configuring firewalls became a full-time job. And despite the countless hours spent, our site’s performance didn’t improve—in fact, it got worse. We struggled to reproduce bugs, making them nearly impossible to fix, and I never managed to get AWS’s scalability features to work properly.

  
I assured my boss that AWS was the solution, but soon things started falling apart. Instead of delivering features, I was stuck firefighting—development didn’t align with staging, staging didn’t align with production, and our bug backlog kept growing. Our big plans to scale BTC efforts faltered as we struggled to support our current audience. Deadlines were missed, and the stress of managing the infrastructure was taking its toll. It was clear that we needed a different approach.

### Discovering a Better Way with Platform.sh

After several months of fighting with AWS, I had to admit to my boss that our approach wasn’t working. That was a tough conversation, but thanks to a recent conference, I had discovered Platform.sh—a PaaS (Platform as a Service) that promised to handle all the heavy lifting without the steep learning curve of AWS. Unlike the various IaaS cloud providers I'd investigated, Platform.sh offered the perfect middle ground: allowing us to focus on development while it took care of all the infrastructure. It just worked. All that was needed from me was a little YAML.

We transitioned everything over to Platform.sh in a matter of weeks. The setup was straightforward, and I was blown away by how easy it was to deploy our applications. Creating a new staging environment was as simple as creating a Git branch in our code. Syncing data between production and development environments was automatic, eliminating the manual steps that used to slow us down. Suddenly, all the issues we’d been struggling with—scalability, stability, security,  and deployment headaches—were no longer problems.

While on AWS, we often struggled to support our doubling traffic— experiencing performance degradation and often significant downtime, but most importantly lost revenue. But after switching to Platform.sh, we handled 900% increases in traffic seamlessly, ensuring consistent sales and customer satisfaction.

### The Power of Upsun: Taking Platform.sh to the Next Level

Now, Platform.sh has evolved into something even more powerful with Upsun. Upsun takes Platform.sh self-service to the next level by offering additional features and even more streamlined deployment processes. For companies like ours, transitioning from an IaaS to a PaaS model meant that we no longer had to manage the complexities of infrastructure. Instead, we could focus on what truly mattered: building and deploying efficiently. With PaaS, we gained the flexibility to scale and deploy without the need for a large team of infrastructure experts. 

Upsun benefits from the same great features as Platform.sh and tacks on even more features to enable companies, especially in the non-tech space like the food and beverage industry, to spend more time on innovation and less time on maintenance.

Upsun gives us vertical scaling with Explicit Resource Allocation, providing precise control over CPU, RAM, and storage, which makes scaling incredibly flexible. The usage-based pricing model is a big win for us, ensuring transparency by charging only for what we actually use. Horizontal scalability means we can easily expand containers as needed, and everything is accessible through the Upsun CLI, which really streamlined our operations.

Here’s a quick comparison of what we dealt with before and what Upsun offers:

###   
The Real Impact

With Upsun, I could  finally focus on what I was hired to do—innovating —rather than getting bogged down by infrastructure challenges. We didn’t have to worry about whether our site could handle the next big spike in traffic or if our staging environment was out of sync with production. Upsun handled all of that, so I didn’t have to.

Post-migration, leveraging tools like Blackfire (now built as an Upsun product!), our page load times improved by 35%, directly enhancing user experience and conversion rates. Our development team could finally focus on innovating rather than troubleshooting, leading to a 20% increase in feature releases over six months. We also experienced fewer unexpected downtimes, boosting our customers’ trust in our brand and leadership confidence in our ability to innovate for the customer.

## The Takeaway

Deploying to the cloud can be daunting, especially for companies that don’t have a dedicated tech team. My experience with AWS taught me that the promises of scalability and stability often come with hidden complexities that can be overwhelming. But with Upsun, you can bypass those challenges and focus on what you do best.

If you’re tired of wrestling with complex cloud infrastructures and want to reclaim your time for true development work, consider exploring what Upsun can offer. Take it for a test drive and experience seamless deployment and scalability firsthand. Trust me, I’ve been there—and Upsun is the solution I wish I had from the start.

### [Web application deployment best practices | Upsun](https://upsun.com/blog/web-application-deployment-best-practices/)

# Keep pace with evolving web application deployment best practices

\[This post is heavily inspired by Christopher Skene's 2017 "What is best practice in web application deployment."\]

"Best practices" are often talked about in the tech world, but rarely is it acknowledged that they can and do change over time. All "best practices" are nothing more than a distillation of the challenges of a given situation to a usually optimal set of trade-offs.

As technology advances, however, those trade-offs change. What once was hard and expensive can become easier and cheaper. (And, sometimes, what was once easy and cheap can become hard and expensive.) That means "best practices" have to evolve with them. What was once leading edge is now a losing strategy.

## The 3-tier web application deployment model

One example of such evolution is development workflows. In the olden days, server environments were expensive and time-consuming to build and maintain. They took physical hardware, manual installation of software, and manual maintenance to keep updated.

Once upon a time, that was justification for having only a production server, nothing else. That led to a common development model of "my desktop and production" (or "just production" if you weren't lucky). Anything more robust was too expensive and labor-intensive for all but the biggest installations.

Over time, we as an industry realized that it was a bad trade-off. "Hack it on production" got replaced with the famous 3-tier model (or sometimes a 4-tier model if you had the budget):

-   Development is where code is edited, usually on each developers' local laptop.
-   Testing is the first time multiple developers' code see each other. This is where integration testing, user-acceptance testing, and other QA happens. Sometimes this is merged with Staging.
-   Staging is a pre-release holding area, to test code against a production-similar environment.
-   Production is, well, production. The live site.

The advantage of the 3- or 4-tier model is that code has a chance to be reviewed and tested by multiple people before it reaches the live site. (As the joke goes, everyone has a testing server; some people are lucky enough to have a separate production server as well.) That's a step up from hacking on production, to be sure. It also means there is a discrete step where certain activity happens: code writing happens in dev; merging of code happens in Testing; QA happens in Testing; final review happens in Staging, sometimes with a snapshot of production data; and production is where customers actually view the site.

### The catch with the 3-tier model in real-world web application deployment

The 3-tier model also has a number of drawbacks, however. In particular, it's really easy for local development to get far behind the Testing instance, leading to Testing becoming a mass of merge conflicts. The longer you wait to merge code to Testing, the harder it is to do. On the other hand, the more frequently you merge to Testing, the harder it is to test. The thing being tested can change every time some new code gets merged, leading to a moving target. That becomes an even bigger challenge when you have multiple testers, as their efforts may bump into each other. (That's particularly true when testing with end-users or tests that involve modifying data.)

The other major drawback of this model is that it is linear. For code to get to production, it must go through Testing and/or Staging, of which there is only one (each). That may be fine when everything is working, but of course, something always breaks. If you discover a bug in production, it's bad form to go around the test/stage pipeline and deploy straight to production without verifying that the fix doesn't break anything else. If you go through the proper test/stage phases, however, your simple emergency fix could get blocked by some other not-yet-ready feature that's already merged to Testing or Staging but yet approved for release.

That led to the idea of a "hotfix," which is developer-speak for "the process is getting in the way of fixing the bug, so I'm going to abandon the process." That may sometimes be the correct course of action, but it also demonstrates where the process is flawed.

Another problem is data. While code flows upward through the pipeline, you want to be able to test new code with current production data. Depending on the setup, the process for getting a snapshot of production data to Staging could be difficult and time-consuming. If it is, it's going to be even worse also replicating it to Testing or development. That means you may not find out how new code interacts with real data until the last minute, which is usually several weeks later than you'd like.

## CI/CD for a faster process

The standard solution to the challenges of a 3-tier model is to push changes through it faster. That led to two twin concepts:

-   Continuous Integration (CI), which roughly translates to "get code **integrated** into Testing as fast as possible."
-   Continuous Deployment (CD), which roughly translates to "get code through the pipeline and **deployed** to production as fast as possible."

CI/CD, as it became known, tries to address the challenges of the 3-tier model with automation in order to get code through the process faster. That could entail a number of different options.

-   Automatically running code-level tests on new code before it even gets deployed anywhere.
-   Automatically running some QA or UAT tests in Testing, cutting down on the need for slow and over-busy humans.
-   Automatically advancing code through the pipeline when certain criteria are met (such as tests passing).

That helps reduce the time it takes to push code through the pipeline, but it doesn't remove the core problem: The 3-tier model is linear, but code development is not. It also introduces its own challenges, namely more moving parts to have to set up, manage, and keep working. There are even specific job roles for CI/CD engineers, "DevOps engineers," or various other titles that essentially mean "care and feeding of all of this automation." That doesn't seem very automatic, and it can be costly.

## Git and containers: CI/CD automation game-changers

Two technological advances made CI/CD automation tolerable.

The first was the widespread ubiquity of Git as a version control system. Git excels in many areas, but in particular, the extremely cheap and fast ability to branch code and merge branches greatly improves the "integration" part of the equation. Newer developers may not remember the days of Subversion or CVS, but before modern distributed VCSes "make a branch" used to be a hard, time consuming, and therefore rare task. Git solved that handily, and a straightforward API made it well-suited to scripting and automation.

The second was the advent of virtualization, first through virtual machines and then, even better, through containers. Containers allow you to abstract the idea of a computer "system" away from physical hardware. That meant building new environments didn't need to involve building new hardware, just sufficient coding.

For a long time, containers were used primarily for cheap Testing environments. CI services sprung up that used containers to build temporary mini-systems in which to run code-level tests, or sometimes full UAT tests. Combined with Git-based automation, that made the "Testing" stage of the traditional pipeline vastly simpler and more productive. In the ideal case, every Git branch, on push, gets any available automated tests run on it. If they fail, the developer knows immediately. If they pass, human reviewers can skip over the automatable parts and just evaluate the qualitative aspects of the new code.

Such services did not, however, resolve the core issue with the 3-tier model: its linear nature. It still just made it faster.

In addition, in most cases, the production system was still not in sync with development or Testing, and sometimes not with Staging, either. The closer Testing and Staging are to production, the more bugs can be caught early and the fewer variables there are to go wrong. Different versions of the operating system, dependencies, resource profiles, add-on libraries, language runtimes, and so forth all have their own subtle bugs lurking in each combination. If the combination in production is not the same as on Testing and Staging then those validation steps are just well-educated guesses.

## The era of cloud computing

What virtualization, and containers in particular, really enables is the ability to not think about hardware at all. A computer "system" is no longer a hand-crafted artisanal thing that you maintain and have to manage. It's a logical, ephemeral, disposable creation in software.

Upgrading no longer involves changing software in place, but building a brand new "system" (container) and replacing the old one, a process that a good orchestration system makes completely transparent.

Ideally, the file system in each container is read-only, possibly with some white-listed exceptions for user data. That prevents both accidental customization and malicious security attacks. Rather than modifying the file system to make a change, you build a new file system image, throw away the old one, and activate the new one.

Being able to think about systems in a strictly software way is today called "cloud computing," a nod to the marketing term "The Cloud" to refer to hosted solutions generally. While not the same, they do go hand-in-hand. And as cloud computing environments are different from older, hardware-based systems, they have a new, different set of best practices.

## Containerization: the best practice from start to finish

Each step along the way, the conventional "best practices" have changed. With the advent of widespread containerization, the leading "best practices" today are based on containerizing the entire process from start to finish. That, in turn, blows up the traditional 3-tier model.

Instead, today's best-practice web deployment strategy looks like this:

Every step from development through production is built with containers and managed through Git. Every branch corresponds to a container-based environment.

While development still happens on a developer's local computer, which may or may not be using the same container images, every other step involves bitwise identical containers. The version of PHP or Node.js or Java being used is guaranteed the same, down to the patch release and compilation settings. The version of your SQL database is identical. The version of your search server is identical. The third-party dependencies of your own code are identical.

And if they're not, it's because you have deliberately changed them. The configuration of the environment is itself code stored in Git, which makes testing infrastructure changes (upgrading a dependency or a database or your language runtime) the same as testing code changes.

You don't deploy new releases of your code; you deploy new releases of your entire system, of which your code is but one part.

All new updates to a Git branch can and should cause the corresponding environment to be rebuilt, from scratch, so there is no "update in place" question to consider.

### App deployment scalability with Git-and-Cloud

This Git-and-Cloud model has a number of advantages over the 3-tier model.

1.  It's non-linear. One change cannot block another, because all changes have their own independent pipeline. A feature release, a critical bug fix, a routine update, all of them can proceed in parallel and deploy independently of each other, whenever they're done.
2.  The number of parallel lines of work is limited only by the number of containers you can create. Assuming you're using a virtualized cloud environment, that means your incremental cost for more environments is low and scales approximately linearly.
3.  Because every environment is disposable and built on the fly from repeatable instructions, your pre-release environments can be truly identical to production.
4.  "Integration" becomes just a question of how you want to use your Git branches. When a new change is merged to production, any other branch can easily merge updates from production, because Git makes that easy. If there's a conflict it will get caught immediately.
5.  Alternatively, you can also have a Git branch for pre-release testing that you merge other branches to in order to do integration testing there. That is, this model allows you to simulate the older 3-tier model if desired. That's usually not necessary, but available if it makes sense. The possible workflows are limited only by your team's skill with Git.
6.  Because the file system is read-only, you have guarantees that no changes can be made without going through Git and an extra layer of security to protect against intruders.

There are many possible tools to build a Git-and-Cloud hosting and deployment workflow for a modern application. Some are self-hosted while others are a hosted service. In most cases, a hosted service, such as Upsun.com, will offer better cost savings in the long run. The major drawback of the Git-and-Cloud model is the complexity of the underlying tooling that enables it, and that complexity is best handled by dedicated teams that can manage that tooling en masse.

### **New testing standards with Upsun.com**

The icing on the cake, offered by only a few providers such as Upsun.com, is data replication. To really make a Git-and-Cloud model shine requires not just cheap environments and simple forward-flow of code, but also cheap backward-flow of data. The closer the data in your Testing environments are to production, the more accurate your validation and testing efforts. Upsun.com allows you to, with the click of a button, perform a copy-on-write clone of arbitrary data from one environment to another—no slow SQL dump and restore that could take tens of minutes or hours, potentially locking up the production instance in the process. It takes roughly constant time, in the range of one to three minutes on average.

That allows testing a new change—whether a small bug fix, a large new feature, or a dependency upgrade—with production data and production configuration for a few minutes or a few days. It provides the most precise "staging is like production" experience possible, while avoiding the concept of a "staging" server entirely.

That is today's leading-edge web deployment process.

## **Future-proofing the web application deployment process**

As technology improves, the optimal use of technology changes along with it. 10 or 15 years ago, a 3-tier or 4-tier architecture was the industry standard process and what most organizations should have been doing. That was the "right way" at the time.

The tools have changed and so have the "best practices." Today, with the widespread availability of Git and cloud-computing environments, continuous deployment means something different than it did in the days of artisanal build processes. It means having an arbitrary number of parallel environments, non-linear workflows, and cheap, disposable containers that can be built from scratch on demand.

What will be the best practice in another 10 years? We'll find out when we get there.

### Useful links

-   Build and deploy | Upsun documentation

### [Techniques for high-performing DevOps teams - Presentation | Upsun](https://upsun.com/blog/high-performing-devops-teams-presentation/)

# Techniques for high-performing DevOps teams

### Video transcript

_We utilized ChatGPT to enhance the grammar and syntax of the transcript._

Hello, everyone. Thank you for coming. I'm Branislav. I'm an engineering leader at Platform.sh. I'm also an engineer, a father, a husband, and a waste reduction nerd, which will come in handy in this presentation. Today, I’m going to talk about performance optimization and what strategies organizations can apply to optimize their processes.

Before we start, how many of you are managers? How many of you are engineers who tend to become managers? And how many of you are DevOps? Great! You're in the right place.

Now, how many of you know who this is? This is Bruce McLaren, born in 1937 and passed away in 1970. He was a pioneer in racing sports and created some of the most amazing, advanced cars in history. Even after his death, McLaren continued winning, with eight constructors' championships and 12 drivers' championships in Formula 1. They know a thing or two about making highly performant machines.

There’s a problem, though—these machines are absolute snowflakes. What does that mean? Think about starting a Formula 1 car. You don’t just turn the key. Instead, you attach the car to an external machine that heats the oil. Once the oil is at the right temperature, they start pumping it into the car, slowly lubricating and heating the engine. This process is managed by numerous technicians using powerful computers, all supervised by an engine-starting supervisor—a real job title! Only then are they ready to start the engine. As I said, it’s a highly specialized machine, a snowflake.

What’s the best-selling car in the world? It’s not a McLaren; it’s the Toyota Corolla. Since its inception in the 1960s, more than 50 million units have been sold. Toyota as a producer does much better than McLaren. When you think about it, Ford, Volkswagen, and pretty much every car manufacturer perform better than McLaren. Why?

Meet this man, Eiji Toyoda. Born in 1913, he lived for 100 years. He was a Japanese industrialist and the chairman of Toyota. His story is fascinating. After World War II, he was invited by Americans to visit Ford’s production facilities to understand mass production and factory organization. He returned to a struggling Toyota, which was producing sometimes more than 1,000 cars monthly, and he tried to implement better processes. He invented what they call "The Toyota Way."

As part of The Toyota Way, he introduced two techniques. One is Kanban. Who here doesn’t use Kanban? One, two, three people. He co-authored this process. The second is Kaizen, and I’m going to talk about Kaizen today. "Kai" means change, and "Zen" means good. It’s a good change or an improvement. This methodology focuses on continuous improvement in small steps, without huge innovations or revolutions, and without drastic changes.

Why? It’s obvious. A huge company introducing a massive change stops the production line, halts the process, and complicates things for everyone. Then, you must slowly restart everything from scratch. This methodology also emphasizes processes, meaning familiarity. If you have good documentation and a familiar environment, that’s where creativity can thrive. Finally, Kaizen promotes automation, which is key to performance.

Kaizen is built on 10 principles, all about making informed decisions. It’s important to disrupt the status quo in small, incremental steps. Perfectionism has no place here; the focus is on reaching the goal one step at a time. This approach fosters analytical thinking and taps into the collective knowledge of everyone in the organization. It prioritizes the economics of change, meaning you find the smallest, easiest leverage to get the best possible result. And, the tenth principle is "never stop implementing," which means the process is perpetual and cyclic—it never ends. Each cycle should bring a little more improvement to the organization.

In practice, it looks like this: First, you plan—define the problem, suggest solutions, and identify measures to track success. Then, you implement the plan and test small changes to ensure you’re on the right path. Once done, you check and evaluate all the data to ensure deviations between what you expected and what you got are minimal. Finally, you standardize the changes across the organization.

The goal is to increase performance by reducing waste. What is waste? Think about wasted time—meetings where you weren’t needed or had other priorities. Think about work that had to be scrapped because it was duplicate or irrelevant. For those in manufacturing—although it seems no one here is—think about wasted materials. For the rest of us, it’s wasted electricity, CPU, RAM, storage, bandwidth—everything that makes hosting more expensive.

So, we’re trying to increase performance, but how do we know if we’ve actually improved? How can we measure if we’re in a good place? According to the State of DevOps report—how many of you read that, by the way? Hands up. Alright, you know what I’m talking about. According to the State of DevOps report, which is released every year, deployment frequency is one of the key indicators to watch. Every year, for the past seven or eight years, they’ve said the same thing: Deployment frequency and lead time to recovery are the two most critical metrics.

What does this mean? You shouldn’t be deploying every month, or even every week. You should deploy whenever it’s needed—on demand. Avoiding failure isn’t the goal because the best way to avoid failure is to do nothing. Instead, you need to make sure that when failure does happen, you can recover quickly. High-performing teams are those that can recover in less than an hour.

The latest State of DevOps report also introduces the concept of "balanced teams." These are teams with high performance, high organizational effectiveness, high job satisfaction, and low burnout—something new in this year’s report. Balanced teams use technology sustainably and, as a result, they perform better.

Let me repeat this: High performance is associated with deploying more frequently. This is the metric you need to watch. The meantime between failures isn’t as important. What matters is how quickly you recover from a failure.

If you want to categorize all the capabilities needed for high performance, you can divide them into three groups: technical capabilities, process optimization, and a culture of psychological safety. I’m going to talk a bit more about each of these, but let’s start with technical capabilities.

The first point is cutting ties with legacy technology. It seems obvious, but if you’re running on unsupported runtime versions, you’re already in trouble. Who here runs on PHP 8 or less? If you are, you have a problem. Unsupported application versions, dependencies, or redundant technologies can also drag you down. Or imagine you have a data model that no longer fits your needs—how many times have you had to tell your business stakeholders, “I can’t do that because the database doesn’t allow it”? That’s a problem. Tight coupling is another issue, as it limits your flexibility.

All these things—unsupported technology, obsolete systems, tight coupling—they create technical debt. Technical debt usually happens for many reasons, but one key reason is sticking with outdated technology stacks. Instead, we should be thinking about modern architecture.

Think about adopting cloud-friendly, cloud-native designs or patterns. Start with loosely coupled architectures. I’m not necessarily talking about microservices, but microservices could be one solution. The idea is to focus on making small, incremental improvements rather than deploying one massive update that could fail miserably. You want to test smaller changes and minimize risk.

Of course, continuous integration, delivery, and deployment are vital if you can manage them—that should be your goal. I want to emphasize one specific thing: immutable containers. Who here hosts on immutable containers? A handful of you. Do you like it? Some of you probably don’t. But immutable containers are crucial because they guarantee the integrity of your application once it’s live.

Also, think about APIs that connect applications and design them to be anti-fragile. What does that mean? It means the system can handle individual failures and still function. Even when something goes wrong, it allows you to recover quickly.

The next step is reducing waste through standardization. What does that mean? Consider the operating systems your organization uses—think about the licensing and maintenance costs. Also, think about development standards. If they differ from one application to another, you’ll have a hard time moving people between projects, creating cross-functional teams, or onboarding new staff. Longer processes for onboarding, slower code reviews, and adapting to different standards all waste time.

Standardization should have one ultimate goal: automation. Once you’re standardized, you can automate, and that’s vital. Automate everything. In hosting and DevOps, this means having production-like environments for testing purposes.

To achieve this, we introduced "infrastructure as code," which is already a relatively well-known concept. The idea is to have the recipe for provisioning infrastructure in a file, in code. That code can be version-controlled, allowing you to track changes and fine-tune your infrastructure as needed. Think about events like Black Friday, where you may need to adjust your infrastructure quickly.

Now, here’s a crucial point: Your first deployment to production should not be the actual first deployment to production. Who knows what that means? One person? Okay. This means that before deploying to production, you need to test everything in an environment that mirrors production exactly. You need a one-to-one, byte-for-byte copy of the production environment where you can safely test everything—code, infrastructure, databases, caches, etc. Testing in such an environment is essential to avoid surprises when you go live.

It’s all well and good to have such a testing environment, but it can be difficult to maintain. Some of you might already be thinking of Kubernetes or similar tools. The end goal here is commodification. What does that mean? It means being able to get whatever infrastructure you need on-demand, in a self-service manner.

At Platform.sh, the company I work for, we provide that for you. It’s platform-as-a-service, and our newest product, Upson, is designed to meet these needs. This ties into the first pillar—technical capabilities. Now, let’s move on to the second pillar: lean processes.

What are lean processes? You need your rituals and processes, but they should be designed to focus on bringing value to the customer. That’s the main goal. Anything you do that doesn’t directly add value is waste.

So, how do we focus on the user? There are multiple techniques, but what works well for us is cross-functional initiatives. These allow teams to make decisions when needed without having to escalate everything to higher management levels. This approach avoids the “escalation game,” where decisions have to pass through multiple layers of approval before action can be taken.

Let’s look at this in detail. For the first time, the State of DevOps report says that teams with a strong user focus have 40% higher organizational performance. Forty percent is a huge number. Cross-functional initiatives are one way to achieve this. They allow organizations with rigid structures or divisions to bring together people from different teams, give them a task, and provide them with the infrastructure necessary to get the job done.

At Platform.sh, we’ve introduced the concept of a "product trio." This means that a product manager, a product designer, and a lead engineer work together to bring a new feature to life. Who wants to know more about that? Stay after this session, and we’ll go into more detail. The idea is to gather whoever you need to get the job done.

In this product trio, the product manager ensures the team stays focused on the user. The product designer ensures that whatever you’re building is both functional and aesthetically pleasing. The lead engineer ensures that the solution fits into the overall engineering architecture.

I’ve provided a description, but I won’t dwell on these slides too much—you’ll have a link to the slides at the end of this session. The goal here is to make decisions at the right place and avoid the organizational “telephone game,” where messages get passed from one person to another, losing clarity along the way.

How do you do this? You ensure the team has everything they need to deliver. This includes dedicated development environments, the ability to test infrastructure changes, and the ability to ensure everything works before merging to staging and, finally, production.

This gives people time to work on important things, like documentation. Documentation is the foundation of a successful organization. There are several tools you can use—Confluence, GitBook, Read the Docs, Sphinx, and Guru, among others—to manage documentation within your teams. Proper documentation helps make code reviews more efficient and fosters a culture of feedback.

Now, let’s talk about the final pillar: generative culture. Culture is the key driver of employee well-being, and I’ve listed some important aspects you need to focus on when designing or fostering a good culture. You need to care about psychological safety, ensuring that people feel safe to express their ideas and concerns. You need to promote open and quality communication, and you must ensure your colleagues have the opportunity to learn and exchange information.

This all ties into generative culture, a concept that’s very important but could take a whole session to cover on its own. Briefly, Westrum categorizes organizational cultures into three types:

1.  **Pathological** – driven by fear and threat, where people are more concerned about personal survival than organizational goals.
2.  **Bureaucratic** – where the focus is on following rules and protecting individual turfs (my team, my department).
3.  **Generative** – focused on the mission of the organization, where everyone works together to deliver value.

In a generative culture, the lead measurement is the performance of the organization, not individual performance. This is a key difference that promotes collaboration and shared responsibility.

In reality, generative culture reduces burnout, which is one of the main causes of decreased team performance. According to the latest State of DevOps report, burnout is reduced by 61% in organizations with high levels of job security and psychological safety. To continue supporting your colleagues in doing their best work, you need to make sure the mission of the organization remains the focal point.

It’s much easier to keep everyone aligned with the mission when management operates based on trust, not control. This is also done by promoting others within the organization, rather than promoting oneself. Remember this: High-performing teams are not composed of single, amazing stars. They are made of constellations—teams of people that work together seamlessly.

Thank you so much.

### [Insights on PostgreSQL and Open Source - Podcast | Upsun](https://upsun.com/blog/postgresql-and-open-source-podcast/)

# PostgreSQL and open source contribution insights - Podcast

Episode 2 of Change Mode! Sit down with us as we chat with Lætitia Avrot, Practice Leader, Postgres and Security at EBD, Postgres Europe Treasurer, and founder of Postgres Women. Lætitia shares her journey in building such an impressive resume, her thoughts on why developers need to get better with databases, and provides insider insights on the Postgres community—including SQL norms, how to submit your feature, and when to expect the next update.

* * *

## Podcast transcript

_We utilized ChatGPT to enhance the grammar and syntax of the transcript._

**Marine:** I'm very excited to talk to you today because I've been following you for a few years now and I'm excited to talk about your work. First of all, do you want to introduce yourself in a few words?

**Laetitia:** Yes. My name is Laetitia Avrot. I'm French, and I work at EDB as a field CTO. EDB is a company providing products and support for Postgres and has the highest number of Postgres contributors on their team. I’m a recognized Postgres contributor, the PostgresQL Europe treasurer, and the founder of Postgres Women.

**Marine:** Wow. Impressive resume. So, what do you do exactly? I know you're now a field CTO, but your job title used to be more like DBA, right?

**Laetitia:** No. My job title was consultant, database consultant. I was a senior database consultant, then I became an architect, and now I'm a field CTO. As a field CTO, I help my customers' CTOs understand the implications of their choices. I don’t make decisions for them, but I help them understand what their choices mean.

**Marine:** Okay. But still in the database field?

**Laetitia:** Yes. I’m dedicated to databases and Postgres.

**Marine:** What does a database admin do in general? As a developer, I've always worked with databases, but not on projects big enough to require someone like you.

**Laetitia:** A database administrator’s job often happens in the shadows. If everything works smoothly, it means the DBAs are doing an amazing job. There’s a special day, the first Friday of July, called DBA Appreciation Day, where you should thank your DBAs. Most of the time, people only notice DBAs when there's a performance problem.

**Marine:** It just works. That’s amazing. I'll remember that for sure. So, I was wondering about your journey. How did you get into Postgres? Did you do specific studies?

**Laetitia:** I attended an IT engineering school in Lyon. After graduation, I was hired because I could communicate with both IT and non-IT people. They put me in support, where I identified bugs and ran big queries to fix data issues. One significant moment was when a customer claimed we overbilled them by €5,000,000, but it turned out we underbilled them by €10,000,000, so they owed us €5,000,000.

**Marine:** Intense. So that’s when your passion for good database structure was born?

**Laetitia:** Yes, during my engineering school years, I had intensive courses on databases. After working as a support engineer, I moved into development and discovered Postgres. I was asked to develop a function in C to find a French term name even if it was misspelled, which was fun.

**Marine:** Why did you stick with Postgres? What’s different about it?

**Laetitia:** Postgres is stable. You can have an uptime of 10 years without any problem. It’s reliable, similar to how Linux is to operating systems.

**Marine:** I remember the first time I saw you speak, I realized I knew nothing about databases. Developers often know superficial stuff and use ORMs, which you said are bad because you should know what’s happening inside the black box.

**Laetitia:** Yes. ORMs generate code of varying quality, similar to how FrontPage generated HTML. It’s that bad. You should know how to write SQL yourself.

**Marine:** Ouch. Sorry, ORM. So we need to know how to write SQL ourselves, right?

**Laetitia:** Yes. Even I found myself saying I knew nothing about SQL when I tried to solve the Advent of Code in SQL. It was hard, but I was proud to have gathered half the stars.

**Marine:** That’s impressive. I always give up after two days. You mentioned Postgres is good at implementing the SQL standard. Can you explain that a bit?

**Laetitia:** The SQL standard originated in the late 80s, created by Oracle and IBM to standardize SQL. Like HTML standards, no RDBMS implements it 100%. Postgres tries to be as close to the standard as possible, but sometimes it’s difficult or the standard is impractical.

**Marine:** Interesting. So, did you look at the new SQL standard release?

**Laetitia:** The standard is expensive (€400), so I rely on free draft versions online. Postgres aims to comply with the 2016 standard, which is already good. Remember, if you learned SQL at university, you probably learned only a small portion of what SQL can do.

**Marine:** Did you look at the new standard? Any exciting changes?

**Laetitia:** No, but the standard evolves every few years. It’s a standalone set of books, not an additional layer.

**Marine:** Can anyone join the SQL standard committee?

**Laetitia:** It’s not easy. You have to know the standard well. People like Markus Winand, an SQL international expert, compare how well different RDBMS adhere to the standard.

**Marine:** So how does governance work in Postgres?

**Laetitia:** Postgres is a true open-source project with no single company behind it. Many companies contribute, including mine, which is responsible for one-third of the changes in the latest release. We have no project owner or manager. Decisions take time because a patch needs several approvals and no disagreements.

**Marine:** How do companies support this?

**Laetitia:** Companies often give free time to their employees to contribute. Some people, like myself, started contributing on their own time. Postgres is written in C, and though it’s not my favorite language, it’s well-written and understandable.

**Marine:** How can developers suggest changes or offer patches?

**Laetitia:** We’re not on GitHub or GitLab. We have our own git at git.postgresql.org. If you want to suggest a change or report a bug, the documentation explains how. For patches, you send a plaintext git diff to the public mailing list with documentation.

**Marine:** That’s old school. Is there a template for presenting patches?

**Laetitia:** Yes, anyone can join the mailing list, but it’s very active with technical discussions. Instead, I suggest going to Commitfest, which happens several times a year. During Commitfest, people review patches already written. It’s not a strict code freeze, but we have a feature freeze in April to ensure stability for the major release in October or November.

**Marine:** That’s a strict process. What’s the release cycle?

**Laetitia:** We don’t have strict deadlines, but we release in April, and the major version comes out in October or November. We aim for minor versions every quarter.

**Marine:** How many people contribute actively?

**Laetitia:** Thousands are involved, but around 100 contribute the most. Contributors come from all over the world, with many from the US, Russia, Japan, India, and Europe.

**Marine:** You founded Postgres Women. Can you tell us about it?

**Laetitia:** There aren’t many women in the Postgres community or the database world—around 5%. I want to show that Postgres is a safe place and help women attend events, which are important for technical learning and networking. My goal is to get more women on stage, as it’s important for their careers and personal growth.

**Marine:** That’s a great plan. I’ve seen you on stage, and you’re an impressive speaker. You’ve spoken at various conferences, not just Postgres or database conferences.

**Laetitia:** Yes, I try to step outside my comfort zone and attend other events, but Postgres events are still the majority. I’ve spoken at AFIP events for the French PHP community and MixIt in Lyon, among others.

**Marine:** How about the relationships between different projects? Does the Postgres community mix with others?

**Laetitia:** There is some relationship between the HCD community and the Postgres community, but generally, people tend to stick to their communities. My first DBA job involved managing three RDBMS: Postgres, SQL Server, and Oracle. It’s challenging to switch contexts between different systems.

**Marine:** Do you contribute to any other communities or open-source projects?

**Laetitia:** I don’t contribute code to open source because it takes time to dive into the code. I help with Cloud AIPS, women in IT associations, and the Avro project.

**Marine:** You mentioned you have two children. How do you manage everything?

**Laetitia:** Each time you have a child, you realize how much free time you had before. I enjoy the free time I have by not having a third child.

**Marine:** Smart. So, if you could get permission to do anything for a day, what would you do?

**Laetitia:** I don’t like constraints, so I would ask for permission to do anything I want every day of my life.

**Marine:** Fair point. If you could invent a new permission, what would it be?

**Laetitia:** I’d like the permission to become invisible at will. Sometimes, it’s comfortable to be in your own bubble and not be seen.

**Marine:** I can see that. For the listeners, Laetitia has bright red hair, so she’s easy to spot in any room. What is your greatest power?

**Laetitia:** My greatest power is I can go to sleep in less than five seconds whenever and wherever I want.

**Marine:** Really? Now I’m jealous. Do you give lessons?

**Laetitia:** No, I’m not joking.

**Marine:** Thank you, Laetitia. It’s been fun talking to you. I hope this inspires people to look into the SQL norm and Postgres. You’re very inspiring.

**Laetitia:** Thank you.

### [How to create and manage great documentation - Podcast | Upsun](https://upsun.com/blog/create-and-manage-great-documentation-podcast/)

# How to create and manage great documentation - Podcast

Our first-_ever_ episode of the Change Mode podcast is kicking things off nicely with a wonderful guest from the Symfony core team, Ryan Weaver. The Symfony docs lead and SymfonyCasts writer keeping us all in check when it comes to Symfony development. Join us for this episode as Ryan shares how to get started in open source, his methods for creating and managing great documentation and screencasts (including those dreaded translations), and how to balance open source and family life.

Donate to Ryan’s GoFoundMe page to support him in his battle with cancer. 

* * *

### Podcast transcript

_We utilized ChatGPT to enhance the grammar and syntax of the transcript._

**Ryan:** I work on the core team of the Symfony Framework. Symfony is a PHP framework used to build web applications, but it also consists of independent libraries. Even people who don't directly use Symfony, like those working with Drupal or Laravel, benefit from its components.

I focus a lot on documentation and create tutorials for SymfonyCasts, the screencasting site for Symfony. I also contribute to other parts of the open-source PHP and Symfony ecosystem.

**Marine:** Nice. I'm interested in that. How did you begin working in open source? Was it an accident or a definitive moment?

**Ryan:** It's usually kind of accidental for everyone.

**Marine:** Yeah, usually someone ropes you in.

**Ryan:** Exactly. A long time ago, I was writing blog posts about Symfony because that's what you do as a nerd figuring things out. When Symfony 2 came out, it was a major rewrite. The lead developer, Fabien, needed someone to write the documentation. Somehow, he noticed me through my blog posts and asked if I wanted to write the documentation for Symfony 2. Of course, I said yes. In hindsight, he was probably relieved to hand over the task to someone else.

**Marine:** Amazing. So it was Fabien Potencier who asked you.

**Ryan:** Yeah, in English, we say "voluntold." You're not a volunteer; someone voluntells you to do it.

**Marine:** Smart. It's his fault.

**Ryan:** Yeah.

**Marine:** Okay, duly noted.

**Ryan:** And then it snowballs.

**Marine:** Exactly. You start with a little thing and then you get known for it. It's too late.

**Ryan:** Yep. And then you get excited because you know.

**Marine:** So you were already contributing by writing blog posts. Is that not open-source contribution?

**Ryan:** Yeah, it is open-source contribution. I should remember that because many people ask how they can contribute to open source, thinking it's all about code. But that's not always easy, especially with something as robust as Symfony. Sometimes, contributing can be as simple as posting solutions on your blog or social media. I wish we had more people doing that because it helps the community.

**Marine:** Yeah, that's something I love about PHP and Drupal. You don't only care about code but also about any type of contribution, like documentation, which is often overlooked but so helpful. It’s the entry point for new people. If you're writing a blog post, you're doing open source. Good for you.

**Ryan:** That blog post can be one paragraph and two code blocks.

**Marine:** Yes, major contributors sometimes find solutions from their old blog posts. It's helpful for you too.

**Ryan:** Exactly.

**Marine:** So, blog posts, then documentation for Symfony 2, which must have been a huge task. Did you have help? How did it work?

**Ryan:** Not at first, but it didn't matter because I didn't have a kid yet. Over time, others started contributing more and more, and now there's a Symfony team of about 40 people working on documentation. Initially, I was a young, inexperienced developer, and Symfony's great documentation was crucial for me. I wanted to make Symfony 2 accessible and inviting for new developers.

**Marine:** Did it start as giving back for you, or were you already passionate about sharing and education?

**Ryan:** I like giving back because it feels good, but it’s also about the fun of opening up code and seeing how things connect. If everyone had to figure out everything on their own, it would be a waste of time. Sharing what you know helps build a foundation for others.

**Marine:** So you started contributing code as well?

**Ryan:** Yes, it bothers me when things are repetitive and inefficient. I started contributing more around Symfony 3, creating the maker bundle to generate code and improve the developer experience. It's pain-driven development—removing friction to create a smoother experience for developers.

**Marine:** I love this because you're still doing documentation, just in a different way.

**Ryan:** That's a good point.

**Marine:** If you want to explain something and realize it's too complex, is that when you contribute code as well?

**Ryan:** Yes, if you're writing documentation or creating screencasts and find something painful, that's when you realize it needs to be fixed. Users experience pain points that maintainers might not even know about. If you can articulate and solve these issues, it’s powerful. Even opening a ticket can be a useful contribution.

**Marine:** Opening a ticket for documentation works too?

**Ryan:** Yes, opening an issue with details and possible solutions is a good way to contribute. It’s less intimidating than creating a pull request directly.

**Marine:** Interesting. How did you go from core contributions to SymfonyCasts?

**Ryan:** When Symfony 2 first came out, we did in-person training, but it wasn't accessible to everyone. We needed to package that experience affordably for smaller companies. SymfonyCasts was born out of that need, and it's great that it also helps fund Symfony's open source.

**Marine:** Your wife helps with that?

**Ryan:** Yes, she’s our front-end developer. I want to give everything away for free, but she makes sure we can also pay for our house and food.

**Marine:** Balancing giving back and making a living is a big question in open source.

**Ryan:** Yes, it’s the classic problem. Projects like the PHP foundation and the Drupal foundation help by paying developers to work on important initiatives.

**Marine:** Companies should give back too. We at Platform.sh sponsor Symfony and other open-source projects. It makes a big difference.

**Ryan:** It does.

**Marine:** You brought your kid to SymfonyCon. How does having a child affect your open-source contributions?

**Ryan:** It changes everything. Before kids, you can do open source in your free time. With kids, you need monetization to make it part of your workday. I do my open-source work between 9 and 5 because SymfonyCasts supports it.

**Marine:** Do your kids show any interest in development?

**Ryan:** Not at all. But bringing my son to conferences is about giving him a worldly experience and meeting people from different backgrounds.

**Marine:** That's amazing. How about contributing to other projects?

**Ryan:** I mainly focus on Symfony, but I’ve started contributing to some JavaScript tools used in both Symfony and Ruby on Rails. It’s great to learn from another community and apply those insights to Symfony.

**Marine:** Is it possible to contribute to SymfonyCasts?

**Ryan:** It’s hard to create screencasts. While we welcome contributions, it’s a specialized task. We do have scripts and code blocks available for free to make the content more accessible.

**Marine:** What about translating documentation?

**Ryan:** Translation is challenging because documentation changes frequently. However, automatic translation tools are improving. We translate our scripts and subtitles on SymfonyCasts into Spanish and plan to add more languages.

**Marine:** Local communities also create knowledge bases in their languages. It’s about making information accessible.

**Ryan:** Yes, passionate independent communities play a crucial role.

**Marine:** What have you learned about teaching and sharing knowledge?

**Ryan:** It should tell a story, building something real that solves a problem. Take people through the steps you took to solve it, not just the end result.

**Marine:** Understanding the logic helps reproduce it, not just follow steps.

**Ryan:** Exactly.

**Marine:** If you had permission to do anything for a day, what would it be?

**Ryan:** I’d go to Cedar Point, an amusement park, and ride roller coasters all day. It’s not realistic with a 7-year-old, but it would be fun.

**Marine:** What if you could invent a new permission?

**Ryan:** Faster-than-light travel. I love space and sci-fi. We need to explore the universe without the depressing effects of time dilation.

**Marine:** What’s your greatest power?

**Ryan:** Playing with kids under seven. I love causing trouble and having fun with them. It’s a superpower.

**Marine:** Parents, don’t leave your kids unattended with Ryan!

**Ryan:** We’ll have a good time, but there will be a riot.

**Marine:** Thank you, Ryan. It was great to have you. Looking forward to the future of SymfonyCasts.

**Ryan:** Me too. Thanks for having me.

### [Why code documentation is key to success | Upsun](https://upsun.com/blog/code-documentation/)

# Code documentation: why it matters, examples, and best practices

It’s no secret that the software development industry demands speed. Decision-makers and developers are under constant pressure to release new products, add new features, and deploy more efficiently.  But with this rushed approach comes the risk of missing something critical: code documentation. 

Truthfully, writing code documentation isn’t as exciting as pushing new features and improvements. The upside is that properly documenting code helps your team work more efficiently—and lets you onboard new team members to your project more quickly, too.

So here’s why documentation is a vital component of all your software development projects, along with best practices for code management.

## What is code documentation?

Code documentation is the written reference for how your code works, including why your team made certain decisions during the development process. It may include links to external resources or source code you've used to build your codebase.

There’s no required format for code documentation, and multiple approaches may be necessary, so choose what works best for each project! If your documentation delivers thorough context about the format and decision-making process behind your code, you’re doing it correctly.

### Common formats for code documentation

#### Internal documentation

These are methods of documenting code within the code itself. 

-   **Code comments:** In-line notes directly within your code, clarifying specific decisions for code snippets without heavily detailed context
-   **Documentation strings (docstrings):** Docstrings also live within your code, but they're specifically structured to describe modules, functions, or classes and can be extracted for autogenerated API documentation
-   **API documentation:** Used to describe the purpose and interactions between classes and modules within your codebase, as well as the input parameters of methods and functions
-   **Integrated development environments (IDEs):** Some IDEs, such as Visual Studio Code, feature extensions for code documentation

#### External code documentation

These forms of documentation exist separately from the code and may be public-facing.

-   **Configuration files:** Depending on the programming language or languages you've used, these may be JSON, YAML, or XML files clarifying a project's configuration details in more depth
-   **README file:** This plain-text file details the origin and purpose of the project along with key context, installation instructions, implementation details, usage examples, and links to other external documentation
-   **AI and other automated tools:** AI tools, such as ChatGPT, can generate a README file or other forms of automated documentation

### Why is code documentation important?

#### 1\. Usability: ensuring code readability and maintainability

Imagine troubleshooting a decision with your team, spending hours brainstorming and testing ideas. When you finally find the best solution, you’re excited to implement it right away—and you do. Then it’s on to the next challenge, right?

You can expect to make modifications frequently throughout the software development process. You’ll add new features, squash bugs, and revisit old code along the way. So give credit to your best ideas: let them live on through excellent code documentation.

When teams understand why you made the decision you did, it improves code reusability while reducing unnecessary modifications.

#### 2\. Efficiency and accuracy: reducing time and preventing errors

Without proper documentation, both current and future developers may have trouble understanding the original intent behind your code—why the decisions you made were the right choices for the project.

As a result, they can spend excess time troubleshooting errors. They may end up fully rewriting the code or developing inefficient patches that require more maintenance.

Taking an extra moment to document code can provide valuable context, preventing hours of wasted time for project managers and developers later on.

#### 3\. Teamwork: promoting collaboration

We all think differently. If you give the same challenge to a room full of software developers, you'll get a variety of different solutions.

So, by documenting your thought process, you create a strong foundation for team collaboration. Every developer will work from the same set of expectations; these parameters can empower them to solve software project challenges more quickly.

#### 4\. Troubleshooting: debugging and updating

During routine code review and for any obvious issues, clear project documentation helps developers detect, identify, and fix bugs in your source code more easily. After implementing a solution, you can write documentation related to the new fix.

#### 5\. Compliance: security, privacy, and industry standards

Proper documentation helps you track and verify compliance as you code. By taking a proactive approach and keeping documentation updated, you'll always be prepared for any updates or audits required to remain in compliance.

#### 6\. Onboarding: helping new developers understand your software projects

A new developer joins your team. They’re about to jump into your project—but after just one look at the codebase, they’re already nervous. It’s complex and doesn't provide any context about how or why the team built it that way.

Without documentation, your future developers will spend hours or even days just trying to understand the logic and structure of your project. That’s bad for your budget, timeline, and the morale of your new dev.

But with proper code documentation, you can welcome them to the team with a clear guide outlining the purpose of functions, modules, and the overall picture of your software's architecture—along with inline details for more specific context. This lets them get on the same page as the rest of the team and dive into the project more quickly.

#### 7\. Preparedness: mitigating knowledge loss

Just as code documentation helps you onboard new devs, it also prepares you for offboarding. This way, even if a key developer leaves the team, their documented knowledge stays with the project.

Despite changes to your team, code comments and other types of documentation will provide strong reference points for everyone involved. This software documentation practice will preserve the context behind your code's functionality and why important decisions were made.

### Best practices for high-quality code documentation

Now that the importance is clear, let’s learn the essential components of good documentation.

#### 1\. Start writing documentation early

It’s far easier to start documentation from day one of your projects, rather than trying to work backward.

Why? For the same reason code documentation is important: after some time has passed, it’s difficult to remember exactly how and why you made certain decisions.

You don’t have to explain every line of code! Just write a brief description, focusing on key components, functions, and processes that could be tough to understand without context.

#### 2\. Write for all levels of expertise

Anyone, from a basic user to an intern to a lead developer, may rely on your documentation. So it’s important that all types of developers understand your notes. There's no need to define basic words or concepts; just write clean code, simplify, and add context to the reasoning behind your decisions.

If there's any doubt about whether your documentation is clear to a newcomer, clarify further.

#### 3\. Document intent, not just implementation

Don’t just explain what the code does. For effective project documentation, remember to share why you decided to write it that way. With this context, other developers won’t have to try to reverse-engineer your thought process.

You may also need to revisit your own decisions one day. In that case, this context could be surprisingly valuable for you, too!

#### 4\. Update documentation regularly

Outdated documentation can add confusion and slow down your team. Don’t let it get to that point!

Try establishing a daily or weekly practice of reviewing your source code and updating documentation. Include any major code changes affecting features, architecture, or dependencies. 

A comprehensive documentation practice will simplify code reviews and improve efficiency at all stages of development.

#### 5\. Use a documentation tool for efficiency

Documenting may add some time to your day, but it shouldn’t derail you.

You may already be using integrated development environments (IDEs), which simplify the process of writing code and may even automatically generate documentation. 

You can also try code documentation tools like these:  

-   Docusaurus (Free): This static site generator integrates with GitHub. It offers simple version control, letting you collaborate effectively.
-   Sphinx (Free): Sphinx generates API documentation using code comments and docstrings. Often used for Python projects, it works with JavaScript code, HTML, LaTeX, and more.
-   Swagger (Free/Paid): Great for API documentation (especially documenting RESTful APIs), Swagger lets you describe API structure directly in your code.
-   MkDocs (Free): MkDocs is a customizable static site generator for documenting code. It’s simple to use and supports Markdown.
-   Read the Docs (Free/Paid): Perfect for open-source projects, this tool builds and hosts documentation straight from your version control system (such as GitHub). 
-   Confluence (Paid): Confluence is a collaborative documentation tool from Atlassian. Use it to centralize project wikis, design documents, and more.
-   GitBook (Paid): GitBook integrates with your CI/CD pipeline for collaborative work and supports Markdown.
-   Apiary (Paid): Designed for documenting APIs, Apiary supports multiple API frameworks with helpful testing tools.

Play around to find the right tool for your team. When you generate buy-in on the tool, you encourage participation and collaboration, helping make documentation a natural part of your team’s workflow.

Hosting documentation platforms on flexible infrastructure—like a scalable PaaS, such as Upsun—also supports effective code documentation. That way, your documentation will be consistently available, easily accessible, and scalable as your projects and teams grow.

### Writing code documentation: FAQs

Here's a summary of critical things to know about good code documentation.

**Why is code documentation important?**  
Whether through code comments, documentation tools, a README file, or all of the above, documentation matters because it helps ensure the lasting usefulness and simple modification of your code.

As your software evolves, missing documentation adds complexity to the process of fixing bugs, adding patches, or building on your existing code.

But when you write good documentation using straightforward language and clean code, other software developers understand the history of your project—even with complex logic.

**How do you write code documentation?**  
There are many ways to write code—and almost as many ways to write code documentation! The method you choose will depend on the type of code you're using, the extent and complex logic of your project, the requirements of your IDEs or code editors, and more.

You may choose one or more methods, but be sure to use each for its intended purpose, and don't overcomplicate things. 

**What is an example of code documentation?**  
For a comprehensive code documentation example, you may use a README file for basic details and installation instructions, inline comments (also known as code comments) to clarify specific code snippets, and YAML configuration files to detail the setup and use of your programming language.

### Writing documentation for your code is an investment in your future

Clear documentation lets developers focus on their strengths—solving problems and building great software. And that could mean happier, more efficient teams.

So if you’re tired of retracing your steps, repeatedly facing the same challenges, and struggling to onboard or offboard developers without stalling your projects, your worries are over. With effective documentation, you can solve all these issues and more.

### [Experience PHP 8.1 new features and speed boost | Upsun](https://upsun.com/blog/key-features-PHP-8-1/)

# Key features and improvements in PHP 8.1

Just days after its official release, we are thrilled to announce the immediate availability of PHP 8.1 for all Grid plan projects. The new PHP foundation releases a new main version every year at the very end of November, and it’s some kind of early Christmas for us developers and application makers.

## **Sparks and acceleration**

PHP 8.1 comes with many new and long-expected features such as Enums, Readonly properties, First-class callable syntax, and `new` in initializers.

It also provides some nice performance improvements estimated at around 5 to 8%. Dmitry Stogov, the author of this impressive feature, describes this as a new transparent technology that eliminates the overhead of PHP class inheritance.

And finally, Fibers could constitute no less than a groundbreaking shift in the PHP ecosystem by adding a low-level mechanism to manage parallelism.

Those functionalities and many more are available now. And you can give them a try today.

## **Enums**

This is a feature I’ve expected for years, and I cannot wait to use it as it is such a convenient way to manage collections of constant values.

```php
enum Status {
  case Draft;
  case Published;
  case Archived;
}
```

Copy the snippet

```php
class Post
{
    public function __construct(
        private Status $status = Status::Draft;
        // ...
    ) {}

    public function getStatus(): Status
    {
        return $this->status;
    }

    public function setStatus(Status $status): void
    {
        $this->status = $status;
    }
}

$post->setStatus(Status::Active);
```

Copy the snippet

Enum can even have methods and Interfaces. How cool is that?

```php
enum Status
{
    // …

    public function color(): string
    {
        return match($this)
        {
            self::Draft => 'grey',
            self::Published => 'green',
            self::Archived => 'red',
        };
    }
}
```

Copy the snippet

```php
interface HasColor
{
    public function color(): string;
}
```

Copy the snippet

```php
enum Status implements HasColor
{
    // ...

    public function color(): string { /* … */ }
}
```

Copy the snippet

## **Readonly properties**

Class properties can be marked as read-only. This means they can only be written once, and an Exception will be thrown otherwise.

```php
class Post {
    public function __construct(
        public readonly string $title,
        ...
    ) {}
}
```

Copy the snippet

```php
$post = new Post(title: ‘PHP 8.1 is available’, /* … */);
// All good, life is great.

$post->title = 'Some other and less fancy title';
// Error: Cannot modify readonly property Post::$title
```

Copy the snippet

## **First-class callable syntax**

PHP 8.1 introduces a new syntax in creating a callable. You can now make a closure from a callable by calling that callable and passing it `...` as its argument:

```php
function love(Human $a, Human $b) {
    /* What is love … */
}

$love = love(...);

$love(a: $someone, b: $someoneElse);
```

Copy the snippet

## **new**

This feature allows wider use of the `new` keyword that can now be used in function definitions as a default parameter and attribute arguments.

Along with the Constructor Property Promotion that came with PHP 8.0, this may considerably reduce the size of the classes. Less noise and more signal: more headspace for zen developers.

```php
class FooController {
    public function __construct(
        private Logger $logger = new BarLogger(),
    ) {}
}
```

Copy the snippet

## **Fibers**

Fibers are a new and low-level mechanism to ease concurrency. They allow the creation of full-stack, interruptible functions that can be used to implement cooperative multitasking in PHP. These are also described as green threads since they execute code concurrently without relying on a multithreaded environment.

```php
$catFiber = new Fiber(function (): void {
    // …
    $value = Fiber::suspend('taking a nap');
    echo ‘Cat fiber resuming its activity because of: ‘ . $value;
});

$value = $catFiber->start();
echo ‘Current value from this cat fiber: ‘ . $value;
// Current value from cat fiber suspending: taking a nap

$catFiber->resume(‘some random noise’);
// Cat fiber resuming its activity because of: some random noise
```

Copy the snippet

If this is not genuinely asynchronous or multithreaded functionalities, Fibers may still lay new ground for the PHP ecosystem as they introduce a shift in PHP historical paradigms. Learn more about Fibers with the RFC.

## **Try it out today**

PHP 8.1 does introduce some breaking changes that may affect older code. You may want to test your application before updating the PHP version. Great news: testing PHP 8.1 couldn’t be easier. First, create a new branch in your repository. Then update your `./.upsun/config.yaml` file in that branch and change the type key to:

```yaml
type: php:8.1
```

Copy the snippet

Git commit and deploy: that branch is now running on PHP 8.1. Give your application a try, run your integration tests, and check if anything needs to be updated. Once you’ve made whatever changes are needed, merge that branch back to your main branch. Congratulations, you’re now running PHP 8.1 on production.

Happy Deploying, PHP!

### [Strategies to scale and optimize apps for Black Friday | Upsun](https://upsun.com/blog/reinforce-your-app-and-infrastructure/)

# Essential tips to reinforce your app and infrastructure

### Video transcript

_We utilized ChatGPT to enhance the grammar and syntax of the transcript._

**Greg:** Welcome to Upsun live stream! Today, we're diving into some essential tips to ensure apps, infrastructure, and everything related to DevOps and the development world are rock solid, especially with the holiday season approaching.

For some of us, it's like, "Wait, it's too early for this," but with 80 degrees Fahrenheit outside, and going up into the hundreds, it still feels early for the holidays. I don’t know the exact Celsius conversion, but that’s probably up into the 32-degree range on that scale. I should probably have my little Santa Claus hat on, or whatever holiday you celebrate, because the season is coming.

We’re going to focus on stability, how to handle traffic spikes, and more. We might even have a special guest joining us to share their horror stories from Black Friday, along with some tips. But all that aside, my name is Greg Qualls, and I'm a wannabe developer based out of Texas.

And with me, as always—well, because this is our first time—Thomas is here. I’m terrible at pronouncing names, so I’ll let him introduce himself.

**Thomas:** Hi, I’m Thomas di Luccio. It’s an Italian name, though I’m French. I’m a developer advocate and a designer-developer, and I’m really excited to talk about this topic today.

**Greg:** Before we dive in, we want to explore a few different segments. For anyone joining us for the first time, we’ll be covering a few topics, starting with emerging news.

First up, we’re diving into our emerging news segment! I love these little bumpers—shout out to Kirby for making them. Thomas, it looks like you're first. What’s been making headlines for you?

**Thomas:** Yeah, I've come across a few articles lately discussing the idea that maybe the AI bubble is finally bursting. To be clear, AI is here to stay. It’s an amazing technology, but there’s a sense that it’s time to cool down. A lot of startups have raised significant funds simply by adding AI to their pitch decks.

**Greg:** Really? I’ve never heard of that. I mean, all the AI on every site is 100% authentic and absolutely necessary, right?

**Thomas:** Exactly. I mean, do we really need an AI-powered toothbrush? Maybe we’re entering the phase where people ask, “Do we really need this?” It’s about figuring out how to add value for users, not just tacking on AI at a huge cost.

**Greg:** What fascinates me about this AI bubble is, as someone who lived through the dot-com bubble (even though I wasn’t heavily involved), there were similar jokes back then. It was like, "Oh, now everyone has a website. What could anyone need a website for?" Then the bubble burst, but now, if you don’t have a website, you don’t have a business.

I’m curious what the future holds for AI. After the hype dies down, I wonder how AI will actually integrate into the ecosystem. Ten years from now, AI might be as common in apps as websites are for businesses today, but it will be used in the right context—focused on productivity and functionality.

**Thomas:** Absolutely! I think the same thing could happen with AI—after the initial hype, it will find its proper place. Moving on from the AI bubble, there’s something that caught my attention this week: ChatGPT’s transition from Next.js to Remix.js. This has been all over my feed and TikTok.

**Greg:** OpenAI hasn’t directly explained why they made the move, but from what I’ve gathered, and I agree with Wes Bos on this, it seems like they’re moving away from server-side rendering and focusing more on client-side rendering to make things faster. It’s interesting because ChatGPT is such a huge app, and making a framework change like this is a big deal. What’s impressive is that, as a user, the transition was seamless—I didn’t even notice it until people started talking about it.

What do you think, Thomas? Should they have waited until after Black Friday to make this switch?

**Thomas:** Honestly, I’m always puzzled by this framework frenzy. People are so passionate about their favorite frameworks that they track who’s using what. As an active user of ChatGPT, I don’t really care about which framework they use, as long as it serves its purpose. If they’re happy with the switch, maybe I should spend more time learning how Remix works.

**Greg:** For me, what’s fascinating is the speculation about why they did it. Sometimes it’s as simple as someone trying it out over the weekend, noticing things run faster, and deciding to switch. Or, maybe one person just likes Remix more and has enough pull within the company to make it happen. There’s always the hunt for some deep technical reason, but sometimes it’s really just about personal preference.

And with that, we’ve covered the emerging news for today. Now, we’re moving into our "Stash of the Day" segment, where we share some tools or resources we’ve found useful recently.

I’ll kick things off! Here’s something fun I found—a Visual Studio Code plugin called Indent Rainbow. As the name suggests, it adds a rainbow of colors to your indents. It’s probably hard to see on screen, but it makes the indents more visually distinct. As I’ve been getting older, it’s harder to track which div belongs to which section, and these colors make it much easier. Plus, it just makes my code look happy!

**Thomas:** I tried it after you shared it with us, and it definitely fuels my OCD. If you struggle with keeping everything perfectly aligned, this plugin is a game changer, but it can also make you obsess over it even more!

**Greg:** Exactly! That’s why I combine it with Prettier. Prettier handles the formatting automatically, and then the colors help me quickly scan the code to find what I need. It’s simple and makes coding a bit more enjoyable.

Now, Thomas, I’m excited to hear about your stash of the day.

**Thomas:** Sure! My stash is Locust.io. I recently worked on a piece for the Blackfire.io blog, and I was exploring options for load testing. That’s when I discovered Locust.io, an open-source project for load testing with Python. I’m not the best Python developer, but I was able to set up load testing scenarios for an application in just a couple of hours. It’s super user-friendly and powerful.

**Greg:** That’s awesome! I’m familiar with Gatling for load testing, but it’s great to know there’s an open-source alternative like Locust.io. I’ve dabbled in Python too, so this sounds right up my alley. I’ve never actually run a load test myself—only been on the receiving end—so I’ll definitely have to check this out.

**Thomas:** It’s really straightforward! I ran the tests locally, and it was hitting a remote server. A few simple commands and everything was set up and running. Locust also offers a cloud version if you don’t want to handle the infrastructure yourself.

**Greg:** I love that it’s open source. You don’t always come across open-source tools for load testing, so I’ll definitely be giving it a try. Now that we’ve shared our stashes of the day, it’s time to dive into the main topic: prepping your app for the holiday rush!

As we mentioned earlier, with the holiday season fast approaching, it's crucial to ensure your app is ready for the increased traffic and demands. Today, we’ll discuss strategies to reinforce your app's stability and keep everything running smoothly during peak times, like Black Friday and Cyber Monday.

This isn’t necessarily a formal webinar; we’re just discussing some key ideas. Some of these might be no-brainers, but they’re worth revisiting, especially as a reminder to start implementing them now. Joining us for this segment is a special guest, Guillaume, who has over 25 years of development experience. He’s worked with various e-commerce companies and has weathered several Black Friday events. Some people have experience, and others have scars, and I think Guillaume might have a few of both!

**Guillaume:** Thanks for the intro, Greg, and thanks for the reminder about my 25 years of experience—always a great feeling. And yes, I started coding when I was 14, not five, but close enough!

**Greg:** So, Guillaume, what would be your first tip for getting ready for holiday traffic?

**Guillaume:** My first tip ties into what Thomas mentioned earlier about load testing. You need to run performance tests to see how your system behaves under heavy load. But you also need enough resources to simulate those users. Most major e-commerce platforms are trying to handle tens of thousands of transactions at once, so you’ll need to stress test at that scale. Tools like Locust Cloud are great because they save you from setting up dozens of AWS instances yourself just to generate fake traffic.

The key is preparation. At the e-commerce agency I worked for, we managed 30 to 40 large retailer websites, mostly in fashion. Black Friday was always a stressful time. Months before the event, we would start preparing and running tests. Defining your testing scenarios is crucial. You want scenarios that match what your users are actually doing, which can be difficult because users do all sorts of things—browsing catalogs for hours, adding tons of items to their carts, removing them, etc. We spent a lot of time working with clients and looking at analytics to figure out realistic test cases, but even then, you can’t predict everything.

When the actual Black Friday arrived, the pressure was enormous. Marketing teams, technical teams, and agencies were working 24/7 to keep everything running. Fortunately, with advancements in cloud technology, it's much easier now to provision resources. Back in the day, if a server failed, we’d have to physically drive to a data center and plug in a new one. Now, with cloud providers, you can just spin up new instances. But even that can be tricky. During COVID, for instance, we saw an insane amount of e-commerce traffic, and some cloud providers struggled to keep up with provisioning instances due to hardware shortages.

**Greg:** You mentioned working with a cloud provider—how crucial is it to scale up in advance? Would you recommend testing your infrastructure's ability to scale before Black Friday?

**Guillaume:** Absolutely! A few months before Black Friday, you need to start scaling up and stress testing. It’s important to slow down on new feature development during this time—not necessarily a full code freeze, but the focus should shift towards optimizing performance. This means running tests, identifying bottlenecks, and planning for the worst-case scenario.

During one Black Friday, we had a client who scaled up their resources to 1,200 CPUs just for the day. That’s the level of traffic we’re talking about. And it’s not just about the servers. Sometimes, components like Redis, which is single-threaded, become bottlenecks. You need to anticipate these issues and be ready to respond quickly.

**Greg:** Guillaume, would you say you learned these lessons the hard way through experience?

**Guillaume:** Oh, definitely. I’ve got plenty of scars to prove it. One time, while working for a ticketing company, we secured a deal with a large venue and were thrilled to launch their new season. Everything was running smoothly until the big rush hit, and the entire system collapsed. We had underestimated the load and didn't properly test for those scenarios. That was a harsh learning experience.

Testing under real-world conditions is critical. Create a clone of your production environment and simulate the same traffic levels you expect during peak times. Use observability tools and monitoring to see what’s breaking and where things are slowing down. You might find that parts of your app behave differently under load than in normal day-to-day traffic.

**Greg:** Thomas, I know you have some thoughts on testing and observability. What best practices would you recommend?

**Thomas:** Yes, absolutely! Observability is essential. When you're running load tests, use profiling tools like Blackfire or other observability platforms. These tools give you insight into what's happening inside your app, allowing you to pinpoint issues. You might find that certain database queries or functions are the root cause of performance issues under heavy traffic.

One lesson I learned from working at a ticketing company is that your setup needs to be designed for the worst-case scenario, not just for normal traffic. We had issues where the peak activity, like people scanning tickets at a venue, happened at night, and no one was available to scale up the infrastructure. If your system isn't designed to handle scaling automatically, you could be in big trouble.

**Greg:** That brings up a great point about automated scaling. It sounds like having the right infrastructure and observability tools can make or break your Black Friday.

**Guillaume:** Absolutely. Automated scaling is key, especially if you're dealing with high-traffic events. You don’t want to rely on manual intervention at 4 AM when your traffic peaks. If your infrastructure can scale automatically based on demand, that’s a huge advantage.

And to Greg’s point, it’s not just about scaling your servers—you need to ensure every part of your system, from your databases to your caching layers, can handle the load. Sometimes it’s the things you don’t expect, like caching issues, that can bring everything down.

**Greg:** On that note, Guillaume, can you talk more about caching? You mentioned earlier that it's one of the most important things to focus on when preparing for traffic spikes.

**Guillaume:** Definitely. Caching is one of the best ways to improve performance, especially during high-traffic periods. If you can serve the same page or content to thousands of users from a cache rather than generating it fresh each time, you’ll save a lot of resources and speed up response times.

That said, caching can also be tricky. It’s not just about turning caching on; you need to make sure you’re caching the right things. And when you’re dealing with e-commerce, for example, you want to be careful not to cache dynamic content like user-specific information. But for product pages, category listings, and other static content, caching is a no-brainer.

A lot of performance gains come from smart caching strategies. It reduces the strain on your backend and speeds up the user experience. In fact, one famous statistic from Amazon years ago suggested they could lose millions of dollars for every 100 milliseconds of additional load time. So, you can imagine how critical performance is during a busy shopping event.

**Greg:** Thomas, I know you’re a big proponent of observability. Could you talk more about the role of observability in caching and performance monitoring?

**Thomas:** Absolutely. Observability plays a huge role in not only catching performance issues but also identifying where your caching might be failing or underperforming. With tools like Blackfire, you can monitor your app in real time, see where bottlenecks are, and even get recommendations on how to fix them.

For example, let’s say your load testing reveals that your database queries are spiking during peak traffic. With observability, you can trace those queries back to specific parts of your code. Maybe there's a query that’s not optimized, or perhaps you’re pulling too much data. The key is to use these insights to make data-driven decisions about where to cache and where to optimize.

Also, observability helps you avoid situations where developers make the wrong assumptions. For instance, a developer might think, "Oh, it’s just a couple of extra database queries—no big deal." But over time, these small changes can add up, especially under heavy traffic, and cause significant performance degradation.

With observability in place, you get a clear picture of how your application behaves under different conditions, allowing you to make proactive changes before they become critical issues.

**Greg:** Guillaume, what are your thoughts on the role of testing in this? Is there one key thing you'd focus on if a team has limited time to prepare for the holidays?

**Guillaume:** If you only have time for one thing, I’d focus on caching and optimizing your backend infrastructure. If you can serve as much content as possible from cache, you reduce the load on your servers significantly. But if we’re talking about a second priority, then yes, observability and testing are crucial.

Testing shouldn’t just be about functionality—it’s about performance, too. Every time you release new features, you should be running performance regression tests to make sure they don’t introduce new bottlenecks. Automated tests are great for this because they can run continuously and alert you if something breaks or slows down.

For example, I remember working on an app where a new feature unintentionally added dozens of unnecessary SQL queries. The app still worked fine under normal traffic, but once the load spiked, those queries became a major issue. That’s why testing and observability go hand in hand. You need to know how every part of your app performs under load and have a plan to fix issues before they hit production.

**Thomas:** Start small but think strategically. You don't have to implement everything at once, but begin with observability and performance tests for your most critical paths—the parts of your app that handle the most traffic or have the biggest impact on user experience.

Define performance thresholds. For example, you might set a maximum number of SQL queries per request or a time limit on how long a specific operation should take. Then, use tools like Blackfire or similar platforms to track these metrics automatically. If something exceeds those limits, it’s a red flag to investigate.

Also, focus on educating your team. Not everyone has the same level of understanding about performance issues or caching strategies. Make sure your developers understand the impact their changes can have under heavy load and how to use the observability tools effectively.

If your team is strapped for time, even small improvements can make a big difference. For example, improving the performance of one frequently used function or reducing the number of database queries on a high-traffic page can drastically reduce load on your servers.

**Greg:** Exactly. I think the overall message here is to plan and test well in advance. Whether it's load testing, observability, or optimizing your caching strategy, preparing ahead of time can save you from a lot of headaches when the holiday traffic hits.

That's exactly it—preparation is everything when it comes to handling high traffic during peak times like Black Friday and Cyber Monday. The more you plan ahead, the more you can mitigate those last-minute emergencies that inevitably pop up. One other thing I’d like to add is about the human element in all of this.

When you’re doing load testing and running through your performance checks, you’re not just testing the system—you’re also testing your team. You want to make sure that everyone knows how to handle these situations when they arise. It’s not just about the tech; it's about the processes and communication among your team.

Thomas, Guillaume—do you agree that running these tests helps prep the people as much as the systems?

**Guillaume:** Absolutely, Greg. Running these tests isn’t just about validating your infrastructure; it’s also about making sure your team knows how to respond in real time. For example, if something breaks during a test, does everyone know what to do? Do they know who to contact? The best way to avoid chaos during the real event is to run through these scenarios in advance.

**Thomas:** Yeah, 100%. Black Friday is like a fire drill in some ways. You don’t just want your system to perform under load—you want your team to know what to do if something unexpected happens. The more you rehearse these scenarios, the better equipped everyone will be to respond quickly and minimize downtime.

**Greg:** That’s a great point, and it ties back to the importance of having processes in place. You should have clear backup plans if things go wrong. If something crashes, who’s responsible for fixing it? What’s the backup plan if the primary system fails? These are questions that need to be answered well before the traffic starts hitting your site.

With that in mind, what would be your one last takeaway for teams prepping for high traffic, whether for the holidays or any other major event?

**Guillaume:** I’d say don’t wait until the last minute. Start your load testing and performance optimization now. Even if you don’t have a lot of time or resources, every bit of optimization you do now will save you headaches later. And definitely make sure you’re leveraging caching and observability tools.

**Thomas:** My main takeaway is to invest in observability. It’s not just about monitoring—it’s about understanding how your app behaves under stress. If you can see the warning signs early, you can fix issues before they become catastrophic. Also, use your load tests to identify weak points and reinforce them ahead of time.

**Greg:** Great advice. I’d also add that communication is key—both within your team and with any external vendors you’re working with. Make sure everyone knows what’s happening and has a plan in place. That way, if something goes wrong, it’s not total chaos trying to figure out what to do.

With that said, I think it’s time to move into our poll request segment, where we answer questions from the audience.

Our amazing producer, Celeste, is pulling up questions now. The first one comes from the chat:

“Do you see a frenzy in frameworks, or do you think just a few frameworks will emerge and stick around long term?”

**Guillaume:** That’s a great question. I think there will always be new frameworks coming and going. Right now, React, Angular, and Vue are the big players, and I think they’ll be around for quite a while. But you also have frameworks like Svelte and Remix gaining popularity. The key is to not get too caught up in the hype. Use the framework that best suits your project’s needs and has a solid community and ecosystem behind it.

**Thomas:** I agree. There’s definitely a lot of excitement around new frameworks, but I tend to stick with the tried-and-true ones like React. It’s been around for a long time, has a massive community, and tons of resources. That said, it’s always good to keep an eye on emerging frameworks—just don’t switch for the sake of switching.

**Greg:** Yeah, I’m learning Flask right now, and it’s been great for what I need. For me, it’s less about the framework and more about what you’re comfortable with and what works best for the project at hand.

**Greg:** Awesome. Let’s move to the next question:

“How do you balance the pressure to release features with the need to maintain performance during high-traffic events?”

**Guillaume:** This is always a tough one. I think the key is to communicate with your stakeholders—whether that’s your product team, marketing, or whoever—and explain the potential risks of pushing too many new features right before a major event. Ideally, you should implement a feature freeze leading up to Black Friday or any high-traffic period so you can focus on performance and stability.

**Thomas:** Yeah, I’d say feature freezes are your friend in this case. It’s really tempting to push new features out before a big event, especially if there’s a marketing push behind them. But you have to weigh the risk of something breaking against the potential benefits of the new feature. Sometimes, it’s better to hold off and ensure the system is stable.

**Greg:** That’s great advice. I think the conversation between development and business teams is critical here. Both sides need to understand the trade-offs involved in releasing new features versus ensuring stability.

**Greg:** And with that, it looks like we’re wrapping up today’s live stream. Thank you to everyone who joined us for Upsun Live! We hope you found these tips helpful.

A big thank you to our guest, Guillaume, and of course, Thomas. Thank you as well to our producer, Celeste, and Pablo, who handled the technical side behind the scenes. Be sure to check out Upsun.com and Blackfire.io for more resources on app performance and observability.

Stay safe, keep coding, and we’ll see you next time! Take care, everyone.

### [Exploring DDEV, Open Source, and DevOps with Randy Fay | Upsun](https://upsun.com/blog/code-community-and-ddev-podcast/)

# Code, community, and DDEV: Randy Fay's journey

In Episode 6 of The Change Mode Podcast, host Chad Carlson sits down with Randy Fay, the lead maintainer of DDEV, to dive into the world of development environments, TRS-80 nostalgia, and the evolution of open-source communities. Randy takes us on a journey from his early days in programming to his pivotal role in creating DDEV—a tool that’s changing the game for web developers using Docker. With a dash of humor, Randy breaks down how DDEV offers a consistent, isolated workspace across operating systems and why this is a game-changer for devs juggling multiple projects.

Whether you're a seasoned dev or just tech-curious, Randy’s insights on community-driven development and DDEV’s roadmap for 2024 will keep you hooked. Plus, he shares the importance of financial support from sponsors like Platform.sh, which helps the project thrive. Don't miss out on learning how DDEV is empowering developers worldwide and what exciting new features are coming soon—trust us, it’s a conversation you won’t want to miss.

* * *

### Podcast transcript

_We utilized ChatGPT to enhance the grammar and syntax of the transcript._

**Chad Carlson:** Hello everyone, welcome to a very special episode of the podcast. My name is Chad Carlson, I manage the Developer Relations team here at Platform.sh and Upson, and today I have the pleasure of talking with Randy Fay. Hi Randy.

**Randy Fay:** How are you doing today? Great to see you.

**Chad Carlson:** Yeah, you too. I'm doing well. Would you mind just taking a second to introduce yourself to our audience?

**Randy Fay:** You bet. My name is Randy. I'm R. Fay in most places, R-F-A-Y, and I am the maintainer of DDEV, or the lead maintainer of the DDEV project, and have been doing that for the last seven or eight years. It's loads of fun. I've been doing software for a gazillion years, but DDEV, for the last bit, is really fun. I've been an active, or at least for a long time, I was active in the Drupal community and contributed a lot there. I got involved in core contribution at some point and maintained a bunch of modules. So there's my quick introduction. I live in Palisade, Colorado, the far western side of Colorado, right next to the Utah border, where it's been really hot for the last month.

**Chad Carlson:** Thanks. If we could go back, what got you interested in programming and technology and working with computers?

**Randy Fay:** Oh, it's just so much fun. It's like an infinite video game. Video games predate me, or they post-date me, so I never really got into them. But the ability to have an infinite challenge with infinite building blocks, like an infinite set of LEGO or Tinker Toys or an erector set that you never had to buy, was always fascinating to me. When I finally finished college, my goal was to be a history and social studies teacher. I did that for a while, but I failed pretty badly, mostly because I looked like I was 17 and was teaching 17-year-olds. It might have also had something to do with the fact that I bought a TRS-80 Model 1 Level 2 and started staying up all night writing BASIC programs and saving them onto cassette tapes. That was the beginning. It was just so fascinating to build something that you could think of with no limitations.

**Chad Carlson:** Were there any projects you had in mind when you were working in history and social studies, or was it just purely driven by the desire to build things?

**Randy Fay:** No, it was just amazing to be able to tinker with stuff. I don't remember what I was trying to write or anything like that. I just remember going at it, trying to make things work, and realizing that you could make them work. I had taken two courses in college, which was all they offered at the place I went. If I had any sense back then, I would have changed schools and gone somewhere to get a CS degree. But I thought it was important to become a teacher, so I did.

**Chad Carlson:** And what was the transition after that, from teaching to the next chapter?

**Randy Fay:** I gave up teaching and started looking for a job to support my wife and our newborn daughter. I ended up landing a job where I was supposed to write documentation for a home automation system in 1982, I think. It was a tiny company called CompuHome Systems—basically a guy's living room—and we made a home automation system that was initially written in BASIC on the Apple II. Since there were only three of us, I quickly moved from writing documentation to writing code. We ended up writing a lot of stuff in 6502 Assembler, and I did that for about seven years. It was an amazing opportunity to try new things, but home automation wasn’t really a thing back then. It wasn’t successful, but it was still a great experience.

**Chad Carlson:** That’s interesting! Documentation was your entry point into coding?

**Randy Fay:** Yes, exactly. That was my selling point. Writing is something that comes pretty naturally to me, especially in terms of descriptive writing.

**Chad Carlson:** How do you make, and it might be quite the job, the transition between this initial work into more open source-oriented work and into that world?

**Randy Fay:** Well, there are a few decades in between. In the early nineties, I got into the Linux world, which was great. Before that, I worked on Unix, specifically AIX, the IBM flavor of Unix. We ended up working on the original generation of mobile data, which was called CDPD, Cellular Digital Packet Data. So, you know, we have 5G today, but that was 1G—the very first generation.

I was doing actual kernel programming because we were writing kernel modules that ran in the Solaris kernel, handling this traffic from CDPD. It was amazing fun, very challenging debugging, and a highlight of my career because I got to work with amazing collaborators. Debugging that kind of code is incredibly difficult, but we developed techniques to handle it and worked together. We worked way too hard, but we had a lot of fun and some great memories.

Later on, I started getting into PHP development and websites. This was around 2005-2006, when websites were becoming the cool thing, and everyone wanted to make them. I started making a few personal websites and eventually landed in the Drupal world. Around that time, my wife Nancy and I were doing a lot of bike touring. We were preparing for an epic bike ride from the top of Canada to Argentina, a two-and-a-half-year journey. We wanted to create a website for it, so we built it with Drupal.

After we got back, I wanted to learn more about open source, and Drupal was the obvious place to start. I dived into that community, and they welcomed me. I had many years of fun and contribution there. While I'm no longer technically up-to-date, I’m still connected to the community, especially since they’ve adopted DDEV.

**Chad Carlson:** What is DDEV exactly? What problem does it seek to solve for Drupal or otherwise?

**Randy Fay:** Every website developer needs a place to work on their site. When you’re working with a team, each person needs their own environment. It’s like how artists need their own canvas; they can’t all work on the same one. There was a time when people tried to develop on shared computers, which was a complete disaster.

DDEV allows each developer to work on their own isolated environment. Whether you're working on TYPO3, Drupal, Laravel, or any other project, you can do it in your own space. You can even work on multiple projects at the same time. DDEV makes this possible by using Docker, so all the important pieces run inside containers. This ensures consistency across different operating systems—whether you’re using macOS, Linux, Windows, or WSL2. The idea is that your team members can work on different environments but have the same experience. That’s what DDEV does, and it's a lot of fun.

**Chad Carlson:** Was its origin from the Drupal community specifically, or was there a broader source?

**Randy Fay:** The project came from a company called Drud. They were originally trying to build a hosting product and wanted to compete with Platform.sh. A local development component was part of that product, and they had a command-line tool that could do a lot of things, similar to the Platform CLI tool. Early on, it became clear that the local dev component was really useful, so they split it off, and that became DDEV.

DDEV was the part I was most interested in, and for five years, they let me work on it. It was very generous. Eventually, Drud lost its funding, like many companies do. But they let me continue working on DDEV, even though I wasn't much of a fan of their hosting product. It seemed like too big a challenge for a company of five or ten people to try to do what Platform.sh does with hundreds of people. But they were kind enough to let me focus on DDEV, and I’m very grateful for that.

**Chad Carlson:** That's pretty huge.

**Randy Fay:** Yeah, it was an amazing gift. I had always been the guy who didn’t have trouble setting up a local environment. I knew how to do the Nginx configuration, the PHP configuration, and the MySQL or MariaDB configuration. So, initially, I was pretty skeptical of DDEV. I thought, "Why would you want to do this when you can just run Apache or Nginx and FPM locally? They run fine on Mac, and you can even run them on traditional Windows." But I soon realized that while I could manage one or two projects with different PHP versions or MySQL versions, handling multiple projects with different environments simultaneously was beyond my abilities. That’s when I was sold on DDEV.

Another key realization was that when people have complex local development setups, the lead dev on the team usually spends all their time maintaining everyone else’s environment. DDEV eliminates that problem. You can check in the configuration, and when a new developer joins, they just run ddev start, and their environment is identical to everyone else’s. That way, people like me—who are comfortable with complex configuration—don’t have to spend all their time helping others who find it mysterious and challenging.

**Chad Carlson:** Would you say that making development easier for people was the problem you were most attracted to? Or was it more about managing different PHP versions and the complexity of juggling various configurations?

**Randy Fay:** I think it was both, but mostly I just enjoy making developers happy. DDEV's goal is to make development easier, and from the early days, it was clear that it made some developers really happy. I found that rewarding. When you understand why you’re doing something, who it matters to, and you get positive feedback, it makes the work a lot more fun. That’s what I enjoy about it. And Drud was generous enough to let me continue working on DDEV, which was great for their name as well—they even changed their name to DDEV because people liked it so much.

**Chad Carlson:** How did Docker change the local development space, and what impact did it have on DDEV?

**Randy Fay:** Docker came in like a storm, maybe about 10 years ago. Before that, people were using VirtualBox or configuring things directly on their local machines, which worked on Mac and Linux, but wasn’t as flexible. Docker made it so that the setup could be the same everywhere without needing an additional product. It allowed different configurations for multiple projects, which simplified things a lot. Before Docker, there was a lot of painful setup time, especially with VirtualBox, where you’d have to do a build as it started up. Docker made all of that faster and more reliable, which is why it took over the space.

**Chad Carlson:** That makes sense. And DDEV is a project that’s written in Go, correct?

**Randy Fay:** That’s right. Well, it’s written in Go and about 15 other languages. The main code is in Go, which acts as the orchestrator. It’s a wrapper around Docker Compose, which is a wrapper around Docker, which runs Linux images with scripts in them. So, it’s a hodgepodge of different things. One of the great things about Go is that it compiles into a native binary that doesn’t need any dependencies—no DLLs or external libraries. You could call it a "fat binary," though that’s not exactly the right term. Essentially, everything it needs is bundled into the binary itself.

In one build, we can create the Mac AMD64 version, the ARM64 version, and the Windows version. We typically build them on Linux, but we could build them anywhere, and they would come out the same. That’s one of the great features of Go. It’s amazing. There are a few disadvantages, though. Our community is mostly PHP users, and for them, Go feels strange and unfamiliar. The learning curve makes it harder for people to contribute to DDEV, which is a challenge for an open-source project.

**Chad Carlson:** Do you see Go becoming more common in PHP-adjacent projects? I’ve seen some web servers written in Go that are gaining popularity in the PHP space.

**Randy Fay:** Yes, there’s some crossover. For example, PHP FPM is written in Go, and Docker itself—the client and server—are also written in Go. So, while Go is more commonly used on the operations side, there is definitely some use of it in PHP-adjacent projects. It’s becoming more popular, but it’s still a learning curve for most PHP developers.

**Chad Carlson:** Aside from the DDEV codebase, are there other places where you like to dedicate your time contributing to open-source? I know training is important to you.

**Randy Fay:** Yes, I enjoy teaching people how to use DDEV and how to contribute to it. Over the past year or so, we’ve been doing contributor training and other types of training to help people understand how to use DDEV. We’ve had a lot of fun with it, but I also spend time mentoring contributors because we want to grow more maintainers for the project. We don’t want it to be dependent on just me. We have another fantastic maintainer, Stas Zouk, who often handles our releases. He’s an exceptional maintainer, but we want to get him fully funded and grow other contributors and maintainers. I also participate in mentored contributions at events like DrupalCon, helping people learn how to contribute to Drupal or solve technical problems.

**Chad Carlson:** You brought up something I meant to touch on—you're trying to expand the life of DDEV by supporting additional contributors. How does financially supporting DDEV work these days?

**Randy Fay:** DDEV is supported by the community. Right now, both Stas and I work on it—I'm full-time, and Stas is about one-third of the time. An amazing thing happened a couple of years ago. After Drud went away, I continued working on the project, but people were understandably suspicious about whether it was still a "going concern" and whether I would carry on with it. Despite that, I just kept going.

After a couple of years, Platform.sh decided to step in and solve some problems. They bought the intellectual property from the original Drud company, including the DDEV name and trademark. That was a huge relief because it solved the issue of using the DDEV name. Even more generously, they started paying me a salary to continue working on it. It was an incredible gesture and really built confidence in the project again. It’s been more than two years now that Platform.sh has been supporting DDEV financially, and we're very grateful for that.

However, we’re trying to get more sponsors. While we have some very generous sponsors, we’d like to get more so we can fully fund Stas and create more space for future maintainers. I won’t last forever—I'm an old guy with an expiration date—so we need the project to be community-maintained and sustainable beyond any one individual.

**Chad Carlson:** How did Stas become involved, and how did he take on the lead role that he has today?

**Randy Fay:** It was a classic open-source story. Stas started by taking on important and difficult bugs and features, and he did that consistently over a few years, demonstrating that he was really good at it. He’s a PHP developer, primarily working in Laravel, and he also contributes to Arch Linux—he’s one of those hardcore Linux folks. He kept growing in his contributions, and at some point, I spoke with him about becoming a paid contributor. Last October or November, we introduced him to the community as a full maintainer.

**Chad Carlson:** So, getting more funding is a priority. What about features? What’s directly ahead for the DDEV project that you’re investing energy into and excited about?

**Randy Fay:** We have a plan for 2024. DDEV has always evolved based on community input and involvement. Our community is very active, and because we’re attentive to their feedback, DDEV has become what people have asked for. One of our key goals is ongoing support. We have a Discord channel, and we’re active in other places like Stack Overflow. Listening to people’s experiences and learning from them is critical, and we take that seriously. When people have trouble with a feature or hit an error, we work to improve that feature or error output to make things clearer and easier to use.

In addition to support, we have two big goals for 2024. First, we’re working on a web-based add-on registry. We have an add-on ecosystem where people can create add-ons for things like Redis, Elasticsearch, Solr, and more. This system has exploded over the last few years—there are now over a hundred add-ons. While you can get a list of these add-ons with `ddev get --list` or `ddev get --list --all`, it’s difficult to navigate a hundred of them. So, we’re building a web-based registry to make it easier for people to browse and understand what’s available.

The second goal is to have a Node.js backend. We already have solid Node.js support integrated into DDEV, but we want to have a direct Nginx and Node backend option, in addition to the current Nginx and PHP setup. Those are our two big focus areas for this year.

**Chad Carlson:** You mentioned that the community has a significant influence on what DDEV becomes. How has the add-on system impacted people's sense of involvement and the feedback you receive?

**Randy Fay:** The add-on system has been a huge win in terms of community involvement. Before that, we had a project on GitHub called DDEV Contrib, where people could submit pull requests to share how they solved different problems. The problem with that was things would quickly become obsolete. You know how fast technology moves—something that works today could be broken by tomorrow’s updates.

With the add-on system, each add-on has its own repository and maintainer. If someone has an issue with an add-on, they can open an issue or submit a PR directly to that maintainer. This spreads the responsibility across the community instead of us trying to maintain everything. It’s much more sustainable and allows people to contribute in meaningful ways. From a maintenance and community contribution standpoint, it’s been a huge success.

**Chad Carlson:** I like that. It sounds like a great system. Thank you, Randy, for taking us through the DDEV project. I think we’ve covered most of the main questions. Now, if you're okay with it, we can move into the lightning round with some lighter, more fun questions.

**Randy Fay:** Yeah, you bet.

**Chad Carlson:** Alright, cool. If you weren’t working in software, what do you think you’d be doing now?

**Randy Fay:** Are you asking what I’d do for work, or how I’d spend my time?

**Chad Carlson:** Whichever you'd prefer, but let's focus on work.

**Randy Fay:** I love software and support, so it’s hard to imagine doing anything else. Outside of work, I spend most of my time mountain biking or cycling in some way. Nancy and I have spent many years and thousands of miles bike touring. It’s a huge part of our lives. So, if I weren’t in software, I’d probably be doing more of that.

**Chad Carlson:** Throughout your career, what’s the most important thing you’ve learned about documentation?

**Randy Fay:** One of the fundamental things I’ve learned is that people don’t read it. Everybody says that, but it’s true. The key is figuring out how to communicate effectively through docs or other means. Communication has to be two-way—you learn from the people using your project, and you respond to their needs. Good documentation is part of that overall communication process.

**Chad Carlson:** How do you think your writing has changed over the years?

**Randy Fay:** I’ve always been a pretty dry, descriptive writer. I’m excellent at being specific and clear, but my writing is very prosaic. I don’t typically write anything particularly engaging or exciting, but I believe in being clear and specific when explaining or describing things. I try hard to be precise, but I wouldn’t claim to know how to write a novel or anything of that nature.

**Chad Carlson:** What do you think is your greatest strength?

**Randy Fay:** I would say it's probably that I love doing support. I really enjoy reacting to people and trying to help them solve their problems. That goes back to my Drupal contribution days—feeling like you have something valuable to offer and being able to help people solve problems. One of the most amazing things about open source is that, in some communities, you actually have the opportunity to participate in solving problems. In a community like Drupal or DDEV, if you see a problem, you can contribute to fixing it, and that’s incredibly rewarding.

**Chad Carlson:** What project are you most proud of working on?

**Randy Fay:** DDEV is definitely the thing I’m most proud of, but the project where we worked on CDPD, the first generation of cellular data, is also something I’m very proud of. That was fun and amazing, and it paved the way for the cellular data we have now. But DDEV is definitely the highlight—it's been around for several years now, and people love it. It’s exciting to work on something that’s both useful and well-loved.

**Chad Carlson:** Which project stands out as the most difficult?

**Randy Fay:** The CDPD project was probably the most technically difficult because we were working at the kernel level and had to develop our own debugging techniques. I’ve worked on many projects that were difficult for other reasons, like the people or the organization, but from a technical standpoint, CDPD was challenging and successful. Many software projects never get rolled out or adopted, but that one did. It was great to see it come to fruition. That said, DDEV has also been challenging in its own ways, but it’s going strong, and it’s been a joy to work on.

**Chad Carlson:** It’s really impressive to see the community you’ve built and how you’ve cultivated it. We have one more question, and I may need to share my screen briefly. This is just a fun one to close out—how do you pronounce this command?

**Randy Fay:** I think I’ve always said "chmod." When you brought this up, I looked it up, and there’s a Reddit thread that took years to sort out because everyone has a different opinion. I say "chmod" and "chown," but probably not "chooser"—I think I say "chuser." But yeah, "chmod" is how I pronounce it. What about you?

**Chad Carlson:** I think in my head, I say "chmod" as well, but this is the “chmodcast” this week! Randy, thank you so much for joining us on the “chmodcast.” Is there anything else you’d like to say to our listeners before we go?

**Randy Fay:** Just that it’s great to talk with everyone, and I look forward to seeing you wherever we may cross paths.

**Chad Carlson:** Thank you, Randy, and thank you to everyone listening. See you next time.

### Useful links

-   DDEV for Upsun local development

### [Nix: In-Depth Look at Open Source Contributions - Podcast | Upsun](https://upsun.com/blog/nix-open-source-contributions-podcast/)

# Exploring Nix: an in-depth look at open source contributions

Embark in an unconventional open source journey with Pol Dellaiera in episode 5 of the chmodcast. It all starts with saving every euro to buy his first computer as a kid… Then it goes to Drupal, Symfony, and now Nix, where Pol’s contributions as a maintainer with commits rights make the lives of PHP developers easier than ever. Package manager, operating system and even functional language: Nix does it all. Let’s dive in!

* * *

### Podcast transcript

_We utilized ChatGPT to enhance the grammar and syntax of the transcript._

**Marine:** So I'm here at SymfonyCon in Brussels and I'm joined by Pol. Hey, Pol.

**Pol:** Hey, hello.

**Marine:** Thank you so much for joining me. I'm really excited because I asked you last minute, kind of.

**Pol:** Yeah, indeed.

**Marine:** But you were available and willing, so I'm super excited to talk to you today. Just to start, can you introduce yourself?

**Pol:** What do you do? So I'm Pol Dellaiera I'm extremely excited to be here as well. It's the first time that it took me roughly 25 minutes to come to SymfonyCon.

**Marine:** Lucky you.

**Pol:** Yeah, and I met some really great people for the first time today. We had lunch together and it's an amazing moment for me because I finally put faces on those nicknames. And we can also discuss things that usually are a bit touchy on GitHub or too long to explain through a message so we can make our points lively. And it's so much better to do that than on GitHub. So yeah, amazing moment right now. And I'm happy to be here. Thank you for the invitation. Even if it was made at the last minute, it's totally fine for me.

**Marine:** Thank you for being so flexible. So yeah, what do you do? You're talking about contribution. You obviously are here because you do open source.

**Pol:** So I'm an open source contributor and I started my time in open source with a contribution in Drupal, the CMS Drupal decades ago. And since now four years, I stopped using Drupal for some reason and I am now more working with Symfony exclusively. I'm not into building applications because this is not my strongest asset and it's not what I like to do. I prefer focusing on creating particular libraries and bundles that are fixing a particular problem. And this is what I like to do most. And this is what I do also at work. And this is also what I do during my free time as well. And recently, I cannot say that my career shifted a bit, but basically my free time was mostly into PHP development has shifted more into using Nix, which is a package manager, universal package manager. And I'm having a lot of fun with this tool, which is amazing. I don't know how I only discovered it three years ago. It was released 20 years ago.

**Marine:** No, really? I had no idea.

**Pol:** Yes. And for me, it has completely changed the way I see IT and the way I envision the future in IT. And so this is why this is so disruptive. And I'm really happy to be now a co-contributor of the project. I maintain the PHP stack among other tools as well. I think I have more than 1,000 commits now. And I was surprised how welcoming the community is and how easy it is to get into the project. So this is really an amazing discovery. And I really like it. I wish I could use it more at work, but this is ongoing, let's say. But yeah.

**Marine:** Cool. Wow. You already have a long career in open source. I want to talk about Nix, obviously. But first, I'm wondering how you got into open source, actually. Because, okay, you started with PHP, Drupal. How did that happen?

**Pol:** This is obvious because I started working with computers since I was 10. I am now 42, so 30 years ago. And at the time, we didn't have computers so easily, and it was expensive to buy a computer. So I had to spare a little bit of money here and there. I remember collecting all the pieces of 50, one euro basically at the time. I remember that I had a collection of these coins. And then I bought my computer, but it was a very cheap one and it was not a big computer, obviously. And to run the software at the time, the software were, yeah, it was okay. It was Windows, but I had friends who were using Linux and I didn't know that stuff. And I was like, okay, what is it? And they told me, look, if you have a computer, which is not that big, you can use Linux. It uses less resources. It's another operating system and it's interesting. I am someone who's very curious and I tried. I tried with Red Hat 5, I think, Red Hat 5.2. Then I switched a short time on Debian. Then I switched a long time on Slackware. And then almost 10 years on Gentoo, I think 10 years on Gentoo. I briefly switched one month to Debian and then I used NixOS. And this is the distribution that I use every day now as a daily driver. And this is the best distribution I ever used. A lot of people are saying that Nix is not ready for desktop, but I can tell you that I'm here to say that it's not true. Actually, it works better than other distributions. It's just that setting this up correctly takes a bit of time because you need to tweak a file and then rebuild a new generation of your system. And you have to test like that. And when your configuration is done, you don't have to touch it anymore. The updates are seamless and quite fast and it works. It always works. This is impressive.

**Marine:** So you started by tweaking your own computer because you were exposed to Linux quite early. That's cool. So you were passionate about computers at a very young age and then you decided to work with them, I guess. How did that happen?

**Pol:** Yes, I never had the feeling to work first because I am doing what I like. I've always liked computers. I don't know why. For me, this is fun to work with a computer and to do things that it's going to do 20,000 times if needed later on. And I started by coding stuff on the computer and then it became my work. I do my studies in IT and now I work in IT as an external consultant at the European Commission here in Brussels, five minutes away from here. And yeah, for me, it has always been a passion. And I am wondering when I will be fed up with this. I don't know.

**Marine:** But never, I hope.

**Pol:** Yeah, I hope.

**Marine:** So how did you end up doing Drupal stuff or PHP for that matter?

**Pol:** I ended up starting working with Drupal because during my studies, we wanted to have a corner for the students to exchange information and stuff. And Drupal seemed to be the perfect fit. And I started trying to create a website using Drupal, five at the time. And it was working, but I couldn't understand how people were creating full-blown websites out of it. And I was only able to create a simple blog. And I was like, wow, how do these people are doing? It looks like it has a lot of power, but I cannot basically use it or try to tame it. So I gave up once, twice, three times, four times. And then Drupal 6 has been released. And then Drupal 6 was even better than the 5 and I gave it another try and finally understood how it was working. I started to learn the code to create modules and it was done. I was into it and I could do basically every time someone talked to me about a web application, I was thinking in terms of Drupal basically. Oh yes, there is a module that does that. I can use this for this. I can use that for that. And okay, your website is done. And I did plenty of websites like that and they are still up and running. And my modules that I created at the time for Drupal 6, 7, 8, 9, and 10 now are still being used, except that they are maintained by some other people. For example, the site of the prime minister here in Belgium, the first page that you see when you reach the website is a module that I created out of the blue, just because I wanted to try as a proof of concept something. And it has been created into a module for Drupal 6, 7, 8 and it's still being used now. This is a language selection page which allows you to select your language if nothing has been set previously in a cookie or in the URL or something like that. So this is how I ended up doing Drupal and then doing PHP and then working into this field basically at the European Commission. This is how I got hired basically because I was a Drupal developer and that's basically how it started.

**Marine:** Yeah, people know that by now, but I'm a Drupal girl myself, so I understand what you're saying.

**Pol:** Yeah, I remember your talk.

**Marine:** Yeah, so I really like where this is going. So very smooth evolution. You had a need, you created a website, you were frustrated, so you created the missing pieces basically, and then you decided you would share them with everybody. And then once you're in, you always find something new that is needed, right? There's more than enough work.

**Pol:** Yes, indeed. Indeed, that's it.

**Marine:** And so how did you discover Symfony?

**Pol:** I discovered Symfony because basically I remember that post on the Drupal website saying getting off the island where basically the idea was to use existing components instead of reinventing the wheel in Drupal. And at the time I was not understanding that really well, but now, years later, I fully understand this initiative, which was a good initiative in the end. There's no need to reinvent something that is already existing. It's better maybe to use it and to see how it works internally, to adapt it for our own needs. And this is the reason why Symfony is making most probably components that are basically so flexible that they can be used anywhere else. So that's how I discovered Symfony, and this is where it started. I am not a huge contributor of

Symfony. I've already contributed to small things here and there, and I don't use Symfony very much. I use it only to create bundles, and I don't need to go deeper in the code to do that because I implement my own logic into the bundles. Usually what I do, I create a library which is completely framework agnostic, so it can work on any framework, Drupal, Laravel, or Symfony, and anything. And then I create the bundle that goes around this library. This is what we do also at work. So the stuff that we are doing, which is open source, by the way, can be used and reused by anyone and adapted to any framework.

**Marine:** So how about Nix? Because you mentioned 20 years ago it was released. I had no idea. So I'm very curious, because can you explain to me what it is? I only discovered it quite recently, and it's fascinating.

**Pol:** To put it simply for the people that are listening, I would describe Nix as a package manager, a universal package manager that can work seamlessly in the same way on any Linux distribution, including macOS. So it's nice because it is the same command line that you are going to use on any Linux distribution and macOS. So this is already a big plus. Then it can also be considered as a builder, you know, just like a makefile is using make commands, like taskfile is using tasks, like just usually for a Rust project. Also, Nix is exactly the same, actually. It's a tool which is allowing you to build software, to build things, and that's how I usually see it. That's how I see it myself as well. On top of that, Nix is a bit complex for a lot of people because it embodies multiple things, a language, a programming language, which is functional. So Nix is a programming language. Nix is a deployment tool. Nix is a builder. Nix is a package manager. Nix is a configuration manager. So it's plenty of things at the same time. So when I do Nix, okay, what are you doing?

**Marine:** Exactly.

**Pol:** And on my side, what I do with Nix, I use it as a builder. I use it as a configuration manager, and that's both as a deployment tool. That's true. I use it like a package manager. Yeah, almost all the points. That's what I do with Nix. But yeah, if I stayed a simple user, I would have used it as a simple package manager. But since I am now one of the PHP maintainers in Nix, yeah, I use it in a more technical way and in depth, and I'm still learning. I'm still doing stupid things sometimes as well. But for me, doing stupid things is not an issue because I consider that making mistakes is the best way to learn.

**Marine:** Oh, I was going to say that. Exactly.

**Pol:** So for me, it's okay. You made a mistake. Okay, sorry. I will fix it. But I need to learn what's happening there. And this is it. This is how it started. But yeah, no, this is what Nix is. And how it started now, it started because of work. Because at work, we are using Windows machines, Linux machines, and Amazon machines. And there is no way to align our development environments. So all the people are using their own laptop, the laptop from the commission, Windows, Linux, one is using Debian, the other one is using Ubuntu, the other one is using Red Hat. So how can we make sure that we are all using the same tools? How can we make sure that when running an application on any operating system, it's working? And there is nothing which is currently fixing that at the moment. And yeah, of course, there are initiatives at work who tried to fix the problem by using Docker. And using Docker, we have to admit that it fixed a bunch of stuff, but it's not the best thing. I don't know if you ever tried to develop with Docker. But for me, I don't like to work with inside containers. For me, this is slow. This is adding constraints to the work of developers. And I'm extremely lazy. So for me, things need to be simple, accessible, and documented. And Docker was not that. At least that's my feeling. And there are some other initiatives using Ansible. But I won't talk about that because Ansible is definitely not adapted for what we want to do there. So yeah, some initiatives using Ansible were made, but they are leading to pretty much, they are not fixing the issue that we are having. So this is not really a solution. And I started to investigate by myself. And since I wanted to learn functional programming, I created some PHP package just to learn the concept and to try to do things using functional programming. And then I discovered this Nix. Okay, what is Nix? I never heard about it. And then I tried it. And it was love at first sight, basically. People are saying that if you want to try Nix, you should first use Nix on your own machine, no matter which distribution it is, and then install NixOS, which is the operating build on top of Nix. But I didn't do that. I immediately installed NixOS on top of my old Gentoo, who was completely slow and sluggish on my laptop. I don't know the reason. I haven't investigated what I did. I just bought a new hard disk drive, immediately installed NixOS. And this is still the first installation that I did, which is there.

**Marine:** Really?

**Pol:** Yes. And it works perfectly well.

**Marine:** That's amazing. But you mentioned you have to have a bit of knowledge to actually install it first, right? It's not as friendly as...

**Pol:** When I installed it, you had to read the handbook side by side and type manually the commands. But since then, now we have a graphical installer that has been released. So it's click, click, click, and it's installed and it works extremely well.

**Marine:** Okay, so that's much more friendly to newbies.

**Pol:** If you are curious, I really invite you to test it and to see how it works.

**Marine:** Yeah, I might.

**Pol:** This is amazing, really.

**Marine:** Now I'm curious. Yeah, for sure.

**Pol:** This is amazing, because your configuration is not volatile. It's in a file and that file can be on a Git repository. So if tomorrow your hard disk drive is failing for some reason, you can restore the same machine, the same configuration with just one single configuration file. This is amazing. At home, we have a couple of machines and all the configuration is in a public repository on GitHub. And they are all at the same state, basically. It's the same base. And I have a router using a Raspberry, I have a server in my basement, I have two or three laptops, and they're all sharing the same configuration, except the router, of course. But yeah, I can find my environment, no matter which computer I use. And installing a service is usually adding a line in a file. And then I know that tomorrow when it will be doing the automatic update, it will be installed. So this is super cool. If tomorrow my mother asked me for a computer, I would give it NixOS. Because I can manage it remotely. And if she told me, oh, I need this software. Okay, I can do it really quickly from my own computer and deploy on your computer, which is remote if needed. I would do that immediately.

**Marine:** So I can see the benefits for distributed teams, like you're saying, and different type of machines, you don't really care.

**Pol:** Yes, but this is NixOS. Now, Nix, the tool, can do also a lot of things. And even if you're not using the operating system, Nix on your Ubuntu on your Debian can do pretty much almost the same. For example, let's say that you are running Ubuntu, a clean Ubuntu without any program, and you want to do PHP, you can just run a command with Nix that will spawn a shell containing all the tools you need to develop in PHP. And as soon as you exit that temporary shell, all these programs will be deleted at some point by the garbage collector.

**Marine:** Okay.

**Pol:** So your original operating system stays clean. And Nix, it will never, it has an impact on your operating system, because everything that Nix is installing is installing a specific directory, which is slash Nix slash store. Everything is in there. So if you delete the directory, everything gets deleted, basically.

**Marine:** Very clean. Okay.

**Pol:** It's extremely clean, yes. And so just for that, it's worth it. And this is how I use it on the laptop from the commission. We are using Ubuntu, and I just have installed Nix, the binary Nix. And I have access to many programs in just a blink of a command line.

**Marine:** So, how do you manage so many packages? Because you are one of several maintainers just for the PHP packages, but do you even know how many packages are available on Nix right now?

**Pol:** Yes, it's in between 90,000 and 100,000 packages. This is the biggest package repository available. According to Repology, this is the biggest one.

**Marine:** Wow. So, how does it work? Let's say there's a new tool, how do you decide which packages you offer?

**Pol:** If you want to add a package in Nix, you just have to create a file into a specific directory in the repository. And that file is basically the recipe to build the program that you want. So, you will describe in that file how to build the program. And inside that file, you will have most probably a line that says, this is the version number 1.2.3. And then you will also have what we call the hash. Basically, at the end of the build, it will take a hash of the result. Of course, this is not technically true, but I will put it like that for the moment, even if it's not totally technically true. It will take a hash of the content and that hash needs to be written in the file. So, you can make sure that every time it is compiled on your machine or someone else's machine, it has the same hash and you can compare it, the builds are okay.

**Marine:** They're like integrity check.

**Pol:** Yes. Of course, technically, this is not how it's done, but this is just to explain in rough lines how it's being done. And the cool thing is that on the Nix OS repository, you have a robot which is watching the repository for outdated packages. And every time it discovers something which is outdated, it provides a pull request to the project saying, hey, this package needs an update. Here's the pull request. And usually there are two lines that change the version and the hash. And it's doing that automatically. So, it's the most up to date repository as well that you can find on the internet. Thanks to that thing.

**Marine:** That's amazing. Is it a bot that you also built at Nix or is it a third party?

**Pol:** It's a third party bot that is enabled on Nix since years, I think. And it's updating all the packages like that.

**Marine:** That's awesome.

**Pol:** And it pings the maintainers as soon as it's done. So, we are aware when there is an update, we can test it. And yes, this is amazing.

**Marine:** Cool. Okay. So, this file, is it using the programming language that you talked about?

**Pol:** Yes. This is a recipe written in Nix, of course. Yes.

**Marine:** So, yeah. It couldn't have been done with an existing language. What was the need for creating your own languages?

**Pol:** So, Nix is the outcome of a PhD thesis from Ilko Dolstra in the Netherlands 20 years ago. And inside that thesis, he explained why a language was created for this. Of course, we could question this decision why a particular language has been chosen instead of using something existing. For me, it's not a problem because I think this is a good idea to create a specific language for that, which is functional and lazy. Laziness and functional programming, I found this concept really amazing. And this is something we don't have in PHP, but we can mimic it, but we don't have it. And Nix is using those concepts. And for the deployment and for describing what we want, this is just perfect. I think some people are saying that Nix is not nice, but actually it's just like a JSON file where you add functions. It looks like JSON a lot. And there are initiatives like the Geeks Projects. It's basically the same as Nix, except that instead of reinventing a language like Nix, they reused an existing language, which is based on Lisp, which is GIL. And this is also exactly the same concept. It's a bit more verbose than the Nix language, but it's basically doing the same thing.

**Marine:** Is the language still evolving? You're introducing new things or does it...

**Pol:** In Nix?

**Marine:** Yeah. Is it enough to do what...

**Pol:** Actually, the language is actively maintained. Yes. And there are new things. Maybe not in the language itself because it's pretty stable, but in the libraries around it, there are always new things. And I am not into really the development of the Nix language itself, mostly in the packages. But yeah, this is still actively developed and maintained since 20 years now.

**Marine:** That's amazing. So for example, for you as a member of the core team, what is a typical contribution that you do?

**Pol:** For example, my biggest contribution so far is related to PHP. So basically before doing that contribution, it was not possible to build PHP application in a reproducible way. It means that maybe you already tried. When you try to do Composer install in your application, it will create a vendor directory. And if you take a checksum of this directory, the checksum will always be different. Sure. And it has been fixed in Composer 2.6.4. It was a one single line patch that I did two or three months ago now. So now if you do Composer install, it will always help the same thing. So this is already very good for the package manager, which is Composer. And with Nix, what I did is just a tool which is allowing you to, okay, this is my application, create a package that I can distribute all over the world of that application. So the person using an application in PHP written in Nix, it will maybe probably not know that it is written in PHP, because it will just do Nix run and then the name of the package and the application will be running on this machine. Because the application will describe in its recipe all the dependencies that it needs and how it needs to be run. So this is a very interesting concept. And what I did is that builder, how can we make sure that when I run phpStan, it works. But phpStan is distributed into flavor on the internet, either by the far precompiled binaries or using the sources. And my builder allows you to read the composer JSON, download all the dependencies in isolation, put them somewhere, build the vendor directory and then do the linking with the binaries that phpStan provides. And all of this is done now and working super well. I'm super happy to see a pull request that are removing all the cruft that they were doing before to reach that to do that. And yeah, that was quite a work to do that. Yeah, it was quite a work because I didn't know how to do so. It took time because I wanted to do things correctly. And this is quite touchy, because imagine tomorrow, I discovered an issue into my builder, all the PHP application that are using my builder might maybe need to update their hash. So it's very, I was extremely excited it was merged, I was a bit afraid also to release that. But now it's running and it's working well, actually, I'm surprised I only had to fix one or two small things, but nothing, nothing really important. So yeah, I'm super happy of the outcome.

**Marine:** So you kind of solved a recurring issue with dependencies, which is always a struggle.

**Pol:** Yes, this is something that I do not have since now three or four years I have. Yeah, on my laptop, I can tell you using Nix has completely changed the way I see a software, the building of a software, the deployment of software. This is issues of the past. This never happened anymore, actually.

**Marine:** That sounds like a great life. I'm interested. Yeah.

**Pol:** Yes, indeed. Yeah. And when I see all my colleagues struggling with that, I told them, look, install Nix, and then I will show you how you can create a quick environment using OpenSSL one if you need it. That's what happened last week. We just needed OpenSSL one to test one command. But since they were using a specific distribution, they couldn't compile it and use it. Or else it would break everything. So we just did it in a virtual machine using Nix and it worked immediately.

**Marine:** Yeah. Isolation. Amazing. Wow. So how many people work on the core? Like what you are doing, for example, because I'm guessing Nix OS is kind of different from the rest of Nix, or is it the same team? How does it work?

**Pol:** Here at SymfonyCon of Brussels today, I met one person, which is also a contributor and one user that I didn't know.

**Marine:** Wow.

**Pol:** So we are three. I also went to five conferences and three of them were talking about reproducibility. So I think this is a wave which has not yet eaten us in the face, but it will come at some point. And Nix will be more and more spread into the community. So I guess there will be more and more contributors. But right now on the Nix project, within the PHP realm of Nix, we are six and we almost do nothing because we are being pinged by the robot that says, Hey, there is a new version of PHP and PHP is done. Is it okay for you to tell me if I can merge it? Yes, no. And then it merges and that's it. But this is what I do. This is what we do. And I don't see a huge thing to do right now in PHP and Nix. It works very well.

**Marine:** Automation is key, right?

**Pol:** Everything is written down in a file. So once it's done and it's very well done, I don't need to touch it anymore.

**Marine:** But what about the rest? Because there's not only PHP, of course. Do you know how many people work in total?

**Pol:** Oh no, I can't tell you. The Nix packages repository is in the top 10 of the most active repositories on GitHub. So it can give you an idea.

**Marine:** It blows my mind that I've never heard of it and it's one of the 10 most active projects.

**Pol:** Yes, but I have exactly the same feeling as you. How come in 20 years I've never heard about this project, which is so amazing that I want to show the world how it works. It is so amazing. I wish I could have done a talk here at Symphony about this, but most probably it will be for next year. But yeah, this is an amazing tool.

I can only recommend it.

**Marine:** So how would someone go if I wanted to try it? You told me, okay, there's a Graphic Installer, you can go for the OS or just the package manager. What about contribution? Do you have needs maybe outside of the PHP realm?

**Pol:** It depends on what you're doing with PHP, but since I'm a PHP developer, I already make sure that all the PHP developers' needs are there and you don't need anything. So basically you just install Nix. It takes 55 seconds to install it.

**Marine:** 55, that's precise.

**Pol:** I know exactly the time because I made a presentation in Munich last month and I made small screencasts of the installation. It took 55 seconds.

**Marine:** Wow.

**Pol:** So it's just a binary in the end that you install on your machine and then you use it. Depends on what you want to do. If you want to go with Nix OS, it might take a bit more time to install it. But if you just want to play with Nix and do exactly the same thing that I do on my machine, which is Nix OS, you can use Nix on your machine, no matter which color, no matter which operating system.

**Marine:** Is there documentation? Where do we start?

**Pol:** The documentation in Nix is usually the pain point, but there are a lot of initiatives recently and there's a lot of work that has been done recently to improve that. So documentation is there and sometimes it's missing some parts, but it's being improved every day. There's a lot of people working on that. The people that are working on this are great and they are doing an extremely good job. And there are so many things to document. Imagine a repository containing almost 100,000 packages. There's a lot to document.

**Marine:** So maybe that would be where new contributors might help?

**Pol:** Yes, definitely. We are looking for people helping with documentation, helping with all of these things.

**Marine:** So what's in the future for Nix? Do you have...

**Pol:** Right now, Nix is, how to say that in English properly, he's the middle of a corner. This is my own point of view. I might be wrong from the point of view of someone who's there since the beginning, but this is how I see it as a newcomer into the Nix world. But basically Nix is in a corner, running at full speed into a corner. Imagine you're like in a car and you're in a corner. And why? Because you have basically the traditional way to use Nix, like Jerome presented during his presentation, using Nix-shell and then you declare your dependencies and then you work. And there's a kind of new way now since I think two years now, yeah, since two years, which is called the Flake. And the Flake file is basically a way to describe your local infrastructure for your project. And it's extremely flexible. It's extremely... Actually, it's easy to use. You just need maybe someone to explain it to you the first time and then you're okay. So there are two ways to use Nix right now. Either you use the old way, this is how I call it, even if it's not really the case, or you use the Flake way. The thing is that the Flake way is still considered as experimental. But the thing is that it's totally stable and people are working on making it stable right now. There are companies built around this tool right now with Flake and there are projects built around Flake. So it's not going to go away. This is something extremely stable. People all around the community are saying that it is stable. You can use it without any fear. Yes, use it. You will see the difference. And this is what I use. I immediately started using Flake when I started Nix. I don't know very much the old way. I know it because I know it. But I am using Flake all the time. This is just a wonderful piece of engineering and it has to be discovered by a lot of people.

**Marine:** Well, hopefully now they might. So basically what I'm hearing is you are kind of a lazy developer, but in a nice way. Yeah, it's like if you can automate, if you can make things simpler and share with people, that's what you like, right?

**Pol:** Yeah, kind of, yes.

**Marine:** I can understand that. Well, thank you so much for telling me about Nix. I'm really eager to try it now. I hope people discover something. It's amazing what we discover in open source every day, things that I've been here 20 years. Now I have a few silly questions for you, if you don't mind. Yes, so I ask this to every guest, but if you had permission to do whatever you want for a full day, what would you do?

**Pol:** What would I do in terms of IT or in just my life?

**Marine:** No, in general, just in life, if you had permission to do anything, something that usually you might not be able to do.

**Pol:** Oh, I would spend time with people that I don't see very often and my own family most probably. And I would spend time with people away from computers, not with a computer. I'm spending too much time in front of these screens. So I think I would take a day and leave my laptop somewhere in the house and leave and do something with the whole family.

**Marine:** Yeah, but you can already do that. It's not forbidden, right?

**Pol:** Yes, but there is always something that doesn't work. I'm not there, I'm not available. Can we do that another day? Or yeah, you know how it goes.

**Marine:** So the simple life?

**Pol:** Yes, definitely.

**Marine:** Good, interesting. And what if you could create your own permission? What would you do?

**Pol:** My permission would be to... in terms of a file system?

**Marine:** Anything.

**Pol:** Oh, permission.

**Marine:** Life, whatever. Someone bent physics earlier today when I interviewed Ryan.

**Pol:** I would not call it permission, but I would call it maybe constraint. Make sure that the software that you're doing is reproducible. That would help IT, definitely. Obviously, in the context of IT, this would definitely help. Make sure that when you do something, you can reproduce it for anybody and use open source tools.

**Marine:** Obviously, that's a given. You have no choice in this podcast.

**Pol:** Indeed.

**Marine:** Okay, and finally, what would you say your greatest power is?

**Pol:** Oh, laziness.

**Marine:** I love it.

**Pol:** Laziness. And when I'm in face of a problem, I like to understand it. And to understand the problem, that doesn't mean finding a solution. But for me, that means finding the root of the problem, which also means dividing the problem into smaller problems and fixing them and trying to find a solution for them. For all these small problems, one by one. And this would be maybe a strength. So, laziness plus that thing. I don't know how we can call it.

**Marine:** Yeah, ability to split into manageable tasks.

**Pol:** I don't know.

**Marine:** The step-by-step approach. I don't know how to call it.

**Pol:** I don't know how to call that.

**Marine:** Yeah, so instead of focusing on the global problem, you're able to split it into more...

**Pol:** By splitting it, you can easily explain it to anybody. You can share the problem and get help easily also.

**Marine:** Sure, you're a lazy analytic person.

**Pol:** Yes, maybe. That's a good description, I think. I should put that on LinkedIn.

**Marine:** Yeah, let me know how that goes. Yes. Well, thank you so much, Pol. That was super interesting.

**Pol:** Thank you.

**Marine:** I'm excited to let people know about Nix and to test it by myself.

**Pol:** Yes, thank you very much for the invitation.

### [Exploring JavaScript Security and Open Source - Podcast | Upsun](https://upsun.com/blog/javascript-security-and-open-source-podcast/)

# Exploring JavaScript security and open source - Podcast

Dive into the world of hardened JavaScript, LavaMoat, and JavaScript security with Zbyszek “ZB” Tenerowicz (@naugtur) in episode 4 of Change Mode. From at-home HTML trial-and-error to building inclusive 3D gaming engines, ZB dives into his open-source journey and the incredible projects he continues to work on every day. Including a passion and dedication to organizing and public speaking at international developer events. Let’s get into the episode! 

* * *

### Podcast transcript

_We utilized ChatGPT to enhance the grammar and syntax of the transcript._

**Marine:** Thank you very much for joining me today. I'm with Zbyszek, also known as ZB for English speakers. Thanks for meeting us today. Could you introduce yourself and tell us a bit about what you do and why you're here?

**Zbyszek:** Hi, I'm ZB. You might also know me as Naukter from my online activity. I'm here because I do a lot of open source work, particularly in JavaScript security. I've been involved in open source and Node.js for the last eight to ten years. Currently, I'm working on a project called LavaMoat, which is a fully open-source project available under an MIT license.

**Marine:** Great, thank you. We're going to talk about LavaMoat, but first, I'd like to get to know you better. How did you end up doing open-source work?

**Zbyszek:** I got into open source through JavaScript. I started learning JavaScript many years ago in primary school. My parents bought a PC, and I learned a bit about how it works. Around the age of 13, I started learning HTML by trial and error. Eventually, I made my first website in pure HTML and got fascinated by JavaScript. Over time, I published various things on GitHub and npm. My first significant contribution was to the XHR package, and since then, I've been involved in various open-source projects.

**Marine:** That's amazing. How did LavaMoat come to be? Did you join when it was already made, or did you create it?

**Zbyszek:** LavaMoat was born out of a legitimate fear of malicious npm packages. Aaron, the founder of MetaMask, was concerned about what would happen if one of the dependencies turned malicious. He started working on LavaMoat, and I noticed his work while researching supply chain security. After some discussions, I joined the team to help build LavaMoat further.

**Marine:** So this is your full-time job now?

**Zbyszek:** Yes, I work full-time on LavaMoat and other security-related projects at MetaMask. We develop software to prevent attacks and consult with other teams on JavaScript security.

**Marine:** Can you explain how LavaMoat is made and what it does?

**Zbyszek:** LavaMoat consists of several tools. The first tool prevents malicious packages from using post-install scripts to attack you. Another tool runs your JavaScript software with a policy that prevents dependencies from doing unexpected things. LavaMoat uses Hardened JavaScript compartments to isolate dependencies, ensuring they cannot perform malicious actions. Hardened JavaScript, also known as SES (Secure ECMAScript), is a concept intended to go into the language itself. It's already implemented and working with minimal trade-offs.

**Marine:** That's fascinating. How many people are contributing to LavaMoat?

**Zbyszek:** We have about four people working on LavaMoat directly. We also contribute to Endo, the runtime environment for LavaMoat, which has more contributors.

**Marine:** What should someone do if they want to contribute to LavaMoat?

**Zbyszek:** Get in touch with us. We have weekly Zoom calls that are open to anyone who wants to participate. Join the call, see what's going on, and start experimenting. Reporting issues and helping us figure them out is also a great way to contribute.

**Marine:** You mentioned that you sometimes do demos at conferences. How did you get into speaking in public? Is it because you're passionate about sharing your knowledge?

**Zbyszek:** I just can't stop. It started out super early. The first local meetup talk I gave was in 2011. The organizers would let me know whenever they were organizing another one, and I kept giving talks. I would look into things just for the purpose of learning enough to give a talk about it. I learned web audio just to give a talk about it because it seemed interesting. It's a continuation of this passion of putting stuff in people's heads. I did a lot of role-playing games as a teenager and enjoyed being the narrator of the game a lot. I think this is a continuation of that. I've been talking about JavaScript stuff and Node.js. Especially diagnostics and performance in Node.js. Then switched to a bit more security and been focusing on security pretty much ever since.

**Marine:** That's really cool. I love the role-playing game analogy. I might steal it. I think you also help organize conferences yourself, right?

**Zbyszek:** Yes. This local meetup kind of escalated. At some point, I switched from being the regular speaker to organizing. So I stopped speaking at the local meetup every time and instead started getting other people to speak. I was organizing the local meetup. The meetup family actually grew to multiple cities. At some point, they needed a new coordinator. So I took the role of coordinator. I can't say I did a great job, because it's impossible to coordinate this thing, but yeah, I've been trying. The Meetup family was actually running a conference every year, and we were looking for someone who dares to organize a conference. We don't have a legal entity, we don't have anything, we're just a bunch of enthusiasts around Poland in different cities organizing Meetups. So we tried to convince someone every year to organize a conference that would get people to go into one place and meet across cities. I did the 2014, 2018, and 2022, and helped a bit with a few other ones. It's a lot of fun, especially on the day of the conference, putting out fires, running around, emceeing is also great. I don't know, I'm doing it for fun. But we also managed to get some money out of it. But as I said, we don't even have a legal entity. So what do we do about money? The answer was simple, we give it away. These are charity conferences, and whenever we organize one, we just find a charity organization to work with, and they get all of the money that we have left from organizing the conference. Sometimes it's even some leftovers from what we get from sponsors, if we didn't spend it all, but it's mostly the money we get from tickets. Our tickets are very inexpensive, but if you organize a conference for 500 people, it's still a bit. I kind of specialize in making it low budget, but work for the community. Being able to say, hey, we're doing this for charity helps when negotiating stuff. We can negotiate a discount on food in exchange for a mention of the catering company that's providing it. I don't have the update for this year handy, but I think it was similar. In 2018 and 2022, we gave the charity a bit more than we spent organizing the event.

**Marine:** That's amazing. Wow.

**Zbyszek:** That was fun. Oh, and by the way, the organization is called MeetJS.

**Marine:** Yes.

**Zbyszek:** If you're ever in Poland, look for a meetup or try to get to our conference. It's in English. We want to create an international conference-style experience for our community, because this is not just for the participants. We also try to give the stage to our community. So a lot of people showing up as speakers are also new speakers or people who don't go abroad talking at larger conferences a lot. This is sometimes their first attempt to perform in front of a few hundred people audience. These are people from our local meetups that gave great talks. We obviously try to also bring some people from the outside. We have some folks that like to visit us. There's a little friend of the conference who always gets a slot, and he gives talks whenever available about JavaScript security, because I'm organizing, so I shouldn't. He comes from Israel, and he always makes sure that we don't have to pay for his flight, because the money goes to charity. He always expenses the flight not with us. So that's a nice arrangement. I got to say, I really enjoy doing that. But as you noticed, I do it every four years, because that's how long it takes to rest for organizing one.

**Marine:** I know what you mean. Organizing events is a lot of work. It's good that you have a team that you can take turns and still have the event. So that's great. You really like community. I'm guessing open source is also about community for you, not only code and sharing stuff, right?

**Zbyszek:** Yeah, I got to say, I mentioned Jake, and I explicitly said he was the first person I met through open source and then in person after a few years. This is something that happens a lot nowadays. I meet a lot of people from open source, and then we get to see each other in person at events like NodeConf EU. NodeConf EU is like a holiday for open source people. We gather together and we spend time with each other. We even pay attention to talks, but I dare say these are not the most important bits of the conference. NodeConf EU this year and last year was a great four night, three days event. The four night thing is kind of significant there.

**Marine:** Nice. What would be a dream project for you, professionally or within the realm of open source, something that would be exciting for you to work on? Unless this is what LavaMoat is already. I mean, could be.

**Zbyszek:** Well, yeah, that was my thought going into all this. I can't even believe this is possible. Now I get to participate in it. These people tell me that the thing I'm supposed to be working on for the next two months is actually possible. I'm eager to try it. So, yeah, this is definitely my attitude to LavaMoat and Hardened JavaScript. I would love for it to become something with major adoption. My dream project would be to work on LavaMoat in a bunch of years from now when we already have ESM support and Bundler support finalized and major adoption. At that point, we're working on super interesting security quirks and improving the way we define policy so that even the most sophisticated threats out there in the NPM ecosystem can get it.

**Marine:** That is great. You are working on your dream. Congrats. OK, I have a few silly questions for you.

**Zbyszek:** These are the best.

**Marine:** If you could get the permission to do anything for a day, what would you do?

**Zbyszek:** Sleep.

**Marine:** Come on. Really?

**Zbyszek:** Yeah, I'm a parent. I just moved to a different city recently. I would probably sleep. But I know what you mean. You mean open source.

**Marine:** No, no. I mean anything. If anything was allowed. No, but I get it.

**Zbyszek:** Resting is involved. I have a bunch of project ideas. If you gave me a month, not a day, I might finish my 3D game engine that I once started. The interesting quirk that makes it, you know, because building a 3D game engine is kind of pointless nowadays with everything available in open source already. But the quirk is my 3D game engine that I started working on renders to sound and sound only. So it's like a game, but it's a Bobcast.

**Marine:** Oh, wow. Now you got me interested.

**Zbyszek:** It's a genre. It used to be called games for the blind sometimes, but it's actually for everyone. And it's a genre that's just a bit more inclusive. I stumbled upon a web forum where people with various disabilities were discussing games, but also making games. There were no great tools for that that were easy to use. You have to really do a lot yourself. They were not super experienced game developers. They were doing interesting experiments. That motivated me to come up with this idea. Life happened, work happened. I ended up coding just a bit of it and really struggling with a bunch of things in there. I would love to finish that. The idea was for you to be able to almost entirely declaratively define the whole scene to create an audio experience with collisions and everything. The fun part about this project to me was that the rendering medium of sound means that I don't have to be good at doing any of it. Create this engine myself because 3D audio is already there in the browser. You can just use it. Positional audio has an API. So all of the difficult math is already done. It's finding a good way to organize this stuff into something that makes sense. My favorite fact about rendering to audio is that you can make all collisions, you can implement all collisions as if they were collisions between spheres and no one's going to notice.

**Marine:** I believe you on that. Wow. That's amazing. I did not expect such a deep answer. I love the focus on accessibility. Kudos to you. OK. So other silly question. If you could invent a new permission, like if you could change modes, blah, blah, blah, something, what would your new permission do? Anything in the world. Not just in computers.

**Zbyszek:** It's probably going to be very boring, but my new permission would be like, you know, we have use strict in JavaScript. I would want the new permission to be use lockdown that just does whatever lockdown from hard in JavaScript is doing. That's the boring answer. The more interesting answer is I would introduce something that just takes away all of the powerful references you have available from all of the code out there. You could only give them to anything that wants to use them top down. Like if you have a program that wants to read a file, make changes to it, and write it back like a linter for your code, that linter, when it runs, it has access to your entire system just like the user, you, because you're running it as your own user. I would like for it to be simple. That's a big challenge. I would like for this to be simple to actually run this program with no permissions whatsoever, except the ones that are directly given to it. Like you have access to these files, you can read them, and then you can write to them. That's all you can do. Nothing else is available to you as if it didn't exist. I would love that to be the case. There's even this prize from Foresight Institute. It's called Norm Hardy Prize. It's a memory of Norm Hardy, who kind of pioneered this idea a lot, where they're looking for new research on how to allow users decide how they're going to agree to certain policies with a user experience that doesn't make it easy to trick them. This is my very unsophisticated explanation of this. Do look it up. It's super interesting as a topic, because we have created a situation where our software is insecurable. It's theoretically possible, and there are people working on that. Hardened JavaScript is one of the attempts, by the way. People are working on making software paradigms where it doesn't have the insecurity that's normal everywhere else. It's the same mistake we're making over and over again, mixing commands with input. We don't have separate memory for programs and for data, which if you confuse your C program or your CPU just a little bit, it's going to start executing something that was supposed to be data. This is one of the manifestations of this, but in hardware. The idea here is to create this situation where everything, every permission is denied until you get it. That means we need to come up with human-computer interactions that are going to make that kind of behavior usable for the humans, because an average app that you use, actually, it's not just the 15 things you agreed to when installing the app that it's using. It's using a ton of capabilities that are given to it by default. If we wanted to make it more and more specific, we need to come up with interactions where users would not only be able to give it permissions for specific things, but also be able to comprehend what they're doing and not be easily tricked into giving permissions they didn't intend. While most of software is okay working that way for now, this is a problem that's really important whenever you get into super secure systems or cryptography or electronic money. The whole crypto thing, with all the weird stuff that happens around it, has actually prompted a lot of interesting developments in security, because you can no longer deal with it with existing security. You need to start going beyond that.

**Marine:** Answered like a true security person, right? You're talking about basically accessible defensive programming. That's super interesting. Well, thank you so much for your time. It was super interesting for me to understand a bit more about LavaMoat and what you're doing. I hope you'll get some new contributors. And I'll be super excited to see you on stage soon, I hope.

**Zbyszek:** Oh, that reminds me, I need to do some CFP submissions. I don't have anything lined up for next year yet.

**Marine:** See? Time to get on it.

**Zbyszek:** Yeah. Thank you. I really hope people will try our Webpack plugin and report back with any issues. If you're interested in this stuff and you happen to have a project that builds its front end with Webpack, that's the best place to start.

**Marine:** We'll share all the links. Thank you very much.

**Zbyszek:** Shout out to MetaMask for sponsoring the whole project.

**Marine:** Sure. You're right. Open source can only go so far. It's great that companies actually give time and money for that. I agree with you.

### [To Upsun, a WordPress migration story | Upsun](https://upsun.com/blog/to-upsun-a-wordpress-migration-story/)

# To Upsun, a WordPress migration story

It’s been an exciting time since we launched Upsun, and as you can imagine, we’ve all been doing a _lot_ of experimenting. We’re testing the edges of frameworks we’ve always wanted to deploy, using Upsun as the perfect excuse to take an hour or two to try ‘em out.

We’re also doing a _lot_ of migrations. Taking sites often deployed on Platform.sh and comparing their configuration, performance, and resource flexibility on Upsun.

So we were delighted when a colleague brought a WordPress art portfolio project into our Slack channel which he was trying to migrate with the following specs:

-   Standard Plan
-   A single primary developer
-   20GB of storage
-   Running on PHP 7.4
-   Using MariaDB 11.2

This post sets out to share what I did to help him migrate this project to Upsun from Platform.sh. Feel free to follow along on the experiment, just note that I:

-   Had already installed the Upsun CLI
-   Already created an account and organization on `console.upsun.com`

And the same goes for Platform.sh. Now, let's get into it!

## 1\. Setting up

I started by working from the original project on Platform.sh, which we'll refer to here with the project ID `Xplatform-shX`. We'll migrate it to a project on Upsun, which we'll refer to here with the project ID `YYYYupsunYYYY`. To set up a project for migration from Platform.sh to Upsun, complete the following:

1.  Clone the Platform.sh project repository: `platform get Xplatform-shX`
2.  Create an Upsun project: `upsun project:create`
3.  Configure Upsun as a remote: `upsun project:set-remote YYYYupsunYYYY`

## 2\. Configuring for Upsun

As you may have seen, the configuration for Upsun is more or less the same as Platform.sh. The only differences you may notice in this process relate to either the combining of configuration files or removing attributes used to configure resources on Platform.sh—the new resources API is the major distinguishing factor of Upsun.

Note: The items that we need to change for project configuration—as seen below—aren't specific to WordPress but apply to all Platform.sh-to-Upsun migrations.

To configure our chosen WordPress Platform.sh project for Upsun, I completed the following steps:

1\. The Platform.sh project shared by our colleague contained what you would expect: `.platform.app.yaml`, `.platform/services.yaml`, and `.platform/routes.yaml` files. We now have—from `project:set-remote`—an `.upsun` directory we can add an `.upsun/config.yaml` file to. In this file, I included all of my Platform.sh configurations under some fairly intuitive keys:

```yaml
# .upsun/config.yaml
applications:
  app:
    type: "php:7.4"
    dependencies:
      php:
        wp-cli/wp-cli-bundle: "^2.4"
        psy/psysh: "^0.10.4"
    relationships:
      database: "db:mysql"
    variables:
      php:
        ...
    web:
      locations:
        "/":
          ...
        "/wp-content/cache":
          ...
        "/wp-content/uploads":
          ...
    disk: 19400
    mounts:
      "public_html/wp-content/cache":
        source: local
        source_path: "cache"
      "public_html/wp-content/uploads":
        source: local
        source_path: "uploads"
    hooks:
      deploy: |
        ...
  services:
    db:
      type: mariadb:11.2
      disk: 512
  routes:
    "https://{default}/":
      type: upstream
      upstream: "app:http"
      cache:
        enabled: true
        cookies:
          ...
    "https://www.{default}/":
      type: redirect
      to: "https://{default}/"
            
```

Everything's now in a single file. Services are under `services`, routes under `routes`, and the single app (`app`) is under `applications` (now under the key `app` instead of using Platform.sh's `name` attribute).

2\. On Upsun, as previously mentioned, resources are configured via the API rather than YAML. Because of this, we need to remove `disk` definitions for both the application (`app`) and the MariaDB service `db`.

3\. Lastly, the _\_types\__ of mounts on Platform.sh aren't quite the same as the options on Upsun. That is, we need to update our two mounts to use the type `storage` instead of `local` for the `source` attribute. The reasoning behind this comes down to naming—mounts on Upsun aren't local in the same way. Any app container can be scaled up to multiple instances, requiring data in what was previously a `local` mount to be shared between them. `storage` is just a better name for this behavior, and for a single instance the behavior is identical to Platform.sh. For those of you who are curious, behind-the-scenes this mount type is actually a network storage service.

All of these changes result in a final configuration file, like this: 

```yaml
# .upsun/config.yaml
applications:
  app:
    type: "php:7.4"
    dependencies:
      php:
        wp-cli/wp-cli-bundle: "^2.4"
        psy/psysh: "^0.10.4"
    relationships:
      database: "db:mysql"
    variables:
      php:
        ...
    web:
      locations:
        "/":
          ...
        "/wp-content/cache":
          ...
        "/wp-content/uploads":
          ...
    mounts:
      "public_html/wp-content/cache":
        source: storage
        source_path: "cache"
      "public_html/wp-content/uploads":
        source: storage
        source_path: "uploads"
    hooks:
      deploy: |
        ...
services:
  db:
    type: mariadb:11.2
routes:
  "https://{default}/":
    type: upstream
    upstream: "app:http"
    cache:
      enabled: true
      cookies:
        ...
  "https://www.{default}/":
    type: redirect
    to: "https://{default}/"
        
```

## 3\. Data: completing the migration

With our configuration in place, we can test the project with an `upsun push`.

Now, if you're following along and migrating your own WordPress project to Upsun, just before the deploy hook is run you'll notice something like this:

```shell-session
Configuring resources
  Using default sizes
    Setting 'app' profile size to '0.5'.
    Setting 'app' disk to '512MB'.
    Setting 'db' profile size to '0.5'.
    Setting 'db' disk to '512MB'.
Creating environment main
  Starting environment
  Opening application app and its relationships
  Executing deploy hook for application app
    ...
  Opening environment
  Environment configuration
    app (type: php:7.4, cpu: 0.5, memory: 224, disk: 512)
    mariadb (type: mariadb:10.11, cpu: 0.5, memory: 1408, disk: 512)
```

While the resources API allows you the flexibility to modify the resources available to your containers and environments, Upsun will automatically set some reasonable default values on your first push.

Nothing really to do here, just something nice to point out, I think.

When the activity has completed we have the WordPress install screen—that is, all of our code but none of our data. So let's migrate that data, starting with the following:

-   Retrieve the Platform.sh database: `platform db:dump`
-   Retrieve the files: `platform mount:download`

And since this particular migration project was an art portfolio website with almost 15 GB of art in mounts, I stepped away for an episode of Ted Lasso while the download finished. When it was finished, all of the file uploads were in the resources of our new Upsun project. You can update those resources with the CLI command `upsun resources:set`. Here, I've kept everything the same as it was previously, only bumping up the disk allocated to `app` up to `20048` MB.

Then, the same thing as before in reverse to upload the data:

-   `upsun sql < ZZZZ...ZZZZ--dump.sql`
-   `upsun mount:upload`
-   Another episode of Ted Lasso for the upload

NOTE: You can bypass the intermediate step of downloading, then uploading, user files when you have many GB like this example.

```shell-session
scp -r "$(platform ssh -p Xplatform-shX -e main --pipe)":/app/public_html/wp-content/uploads/* "$(upsun ssh -p YYYYupsunYYYY -e main --pipe)":/app/public_html/wp-content/uploads
```

## 4\. Success!

And just like that, our project—short of adding our domain—has been migrated to Upsun from Platform.sh.

Now that we’re finished we can:

-   Observe our infrastructure metrics to help us determine if we’ve over-allocated resources for the project
-   Use that information to tailor our resources
-   Create a branch and upgrade to a more recent version of PHP and MariaDB

Best of luck with your own migrations! Join our community to let us know how it’s going.

### Useful links

-   Bedrock for modern WordPress development

### [Instant Data-Complete Preview Environments | Upsun](https://upsun.com/blog/instant-data-complete-preview-environments/)

# Outsmarting the competition with instant data-complete preview environments

In the high-demand world of software development, access to dependable test environments is non-negotiable. Traditional staging environments are plagued by numerous obstacles, especially when multiple developers collaborate on the same codebase. Even conventional preview environments miss the mark due to the lack of standardized definitions, leaving each provider with fragmented, inconsistent setups. 

Upsun’s Instant Data-Complete Preview Environments flip the script — a true breakthrough for development teams pushing toward peak performance.

### You don’t want a single Staging environment.

“Staging” is where you test and validate new features before releasing them to “Production”.

However, relying on one staging environment introduces several headaches. It can crash, bringing progress to a standstill. Changes in staging can conflict with other updates due to poor isolation,  forcing teams into bloated releases with too many features and fixes combined.

### You don’t want Preview environments.

Preview Environments vary greatly based on your setup, your PaaS provider, or even your team's practices.

Some providers **only handle static front-end** content in preview environments, which makes working with decoupled architecture a nightmare. They often suggest manual workarounds to connect and update replicas of your back-ends and services.

Others **create empty instances of your services**, and **don’t support full database replication** into preview environments, leaving teams with inefficient, time-consuming seeding processes. These processes either pull data  from production, or load it from external sources like an S3 bucket. But when you seed your database with test data or old production data, the preview environment doesn’t match what’s in production, making it difficult to confidently release changes to your production database. 

These seeding hacks lead to inaccurate, insecure environments that don’t reflect real-world performance, and cause teams to miss critical edge cases during testing.

### What you want are Instant Data-complete Preview Environments.

Upsun delivers Instant Data-Complete Preview Environments that perfectly mirror your production environment, including all apps, databases, services, files, and configurations.

Imagine having every service (databases, message queues, search indexes…), your back-end, front-end, and API server, instantly available in your preview environment as an exact replica of production.

Upsun’s instant data cloning enables exact replicas of your production environment to be created in seconds, thanks to our smart copy-on-write mechanism using Ceph RBDs with RADOS capabilities–leveraging fast snapshots, replication, and strong consistency.

Learn more about Upsun’s unique copy-on-write capabilities in this article.

Also, depending on your use case or industry, Upsun provides deploy hooks that allow for data sanitization and anonymization, ensuring safe and secure developments.

### Conclusion

Upsun’s Instant Data-Complete Preview Environments eliminate the complexities and inefficiencies of traditional staging and preview environments setups. 

With exact, secure, and rapidly deployable replicated environments, Upsun ensures a smooth development experience that truly outsmarts the competition.

### Frequently Asked Questions

**Q1:** What are Instant Data-Complete Preview Environments?  
**A1:** Upsun’s Instant Data-Complete Preview Environments are exact replicas of production environments, including all apps, databases, services, and configurations. These environments can be created instantly, ensuring that developers work with a complete, up-to-date copy of production, reducing release risk and deployment delays.

**Q2:** Why are traditional staging environments problematic for development teams?  
**A2:** Traditional staging environments often suffer from crashes and conflicts due to poor isolation, leading to bloated releases with too many features combined. Additionally, teams may face delays when staging environments break or become unavailable.

**Q3:** What are the limitations of conventional preview environments?    
**A3:** Conventional preview environments vary greatly depending on setup and often lack complete database replication, making them inefficient. They frequently require manual workarounds or time-consuming data seeding processes that result in inaccurate environments not reflective of real production.  
  
**Q4:** How does Upsun’s data cloning mechanism work?    
**A4:** Upsun uses a smart copy-on-write mechanism, powered by Ceph RBDs and RADOS, enabling fast snapshots and consistent replication. This allows instant creation of production-like environments, complete with full data and configuration, ensuring consistency and rapid availability.  
  
**Q5:** What security features does Upsun offer with Instant Data-Complete Preview Environments?    
**A5:** Upsun includes deploy hooks for data sanitization and anonymization, ensuring secure developments by safely handling sensitive data when creating preview environments.

### [PaaS stress testing before Black Friday | Upsun](https://upsun.com/blog/paas-stress-testing-before-black-friday/)

# PaaS under pressure: secrets to stress testing before Black Friday

> _This blog is based on the Upsun live stream with Greg Qualls, Thomas di Luccio, and Guillaume_ _Moigneu__._

As the holiday season approaches, developers and technical teams face a familiar challenge: ensuring their applications can handle massive traffic spikes without breaking. During a recent Upsun live stream, Greg Qualls, Director of Product Marketing, Thomas di Luccio, Product Manager, and special guest Guillaume, Field Chief Technology Officer at Upsun, shared valuable insights from years of managing e-commerce platforms through Black Friday chaos.

## The reality of high-traffic events

Guillaume, with over 25 years of development experience, has witnessed firsthand what happens when preparation meets reality. Working with e-commerce agencies that manage 30-40 major European retailers, he has seen companies scale from normal operations to handling 1,200 CPUs worth of traffic in a single day.

_"We have clients that reached 1,200 CPUs just for the day, getting insane numbers of orders," Guillaume explained. "That's always a challenge because those applications sometimes are not really meant to scale that high."_

The stakes are real. As Guillaume noted, there's no worse feeling than having your CEO tell you that the company missed a million dollars in revenue because the site went down, or hearing about a customer who tried to buy $20,000 worth of jewelry but couldn't complete the transaction.

## Essential strategies for black friday traffic

1.  **Start months ahead**

The most critical insight from these seasoned developers? Start your preparation months in advance, not weeks.

Guillaume recommends a strategic shift in priorities: "Every time you go for Black Friday, especially if that's a new application or something you haven't really battle-tested before, you need to take a few months to actually slow down on new development and new features."

This doesn't mean implementing a complete code freeze, but rather shifting focus from feature development to stability and performance optimization.

### **Master the art of caching**

When asked what single thing developers should focus on if they have limited time and resources, Guillaume's answer was immediate: caching.

Caching can be amazing. Caching can remove a lot of bottlenecks in your application when it's done right. There's a famous saying: there are two things hard in computers - caching and naming.

The benefits extend beyond just performance. Proper caching improves user experience through faster loading times and reduces the risk of overloading backend resources like databases. Guillaume referenced the often-cited statistic that Amazon was losing $1 million in revenue for every 100 milliseconds added to their loading times. 

### **Use observability tools**

Guillaume's second recommendation centers on observability tools that help you understand how your application actually behaves under stress.

Invest in observability - give yourself the ability to witness your application and infrastructure behaving and try to learn from this," he advised. "It will tap you on the shoulder and say, 'Look at this, look in this direction,' and show you processes that keep fetching all the resources or slow requests that need optimization.

### **Create realistic testing scenarios**

Thomas di Luccio learned this lesson the hard way while working for a ticketing company. When they secured a deal with a large venue, everything seemed perfect until the season announcement day arrived.

"Everybody was buying tickets at the same time, big rush on the website, everyone hitting the same API, and everything collapsed," Thomas recalled.

The key insight? You need to create testing scenarios that actually mirror real user behavior. Users don't just browse catalogs - they add 100 products to their cart and then remove them, using it as a wishlist. They hit refresh repeatedly when pages load slowly. These behaviors need to be part of your testing strategy.

### **Test your processes, not just your code**

One often-overlooked aspect of preparation is testing the human element. Regular testing serves two purposes:

-   It helps new team members understand your systems and processes before they're needed in a crisis
-   It reveals how changes in your codebase affect performance under load

As Greg pointed out, “You're not just testing the system, you're testing people against the systems and processes that you've put in place.”

### **Set up automated safeguards**

Thomas advocates for automated testing that includes performance regression testing. "You can test regression - features not working, cosmetic regression - but performance regression is also super important to make sure that some feature you deploy doesn't ruin something else."

However, he warns against the temptation to "fix" failing tests by simply raising the limits. "I was expecting to do fewer than 50 SQL queries, and okay, 52 - I'll fix the test. You have to resist that temptation."

### **Don’t over-customize**

Custom code and endless feature tweaks can be a performance killer.  One unexpected challenge comes from within your own organization. You need to fight some feature requests that might impact performance. I've seen clients asking for completely custom experiences, with numerous promotion rules. Every time you add those features, it uses more resources.

The solution? Work with stakeholders to rework feature requests in ways that satisfy their needs while meeting performance expectations.

### **Communicate with third-party service providers.** 

Don't forget to communicate with your vendors and third-party service providers. Guillaume emphasized the importance of understanding what you can expect from partners when things go wrong: response times, escalation procedures, and backup plans.

"When you rely on independent partners, you need to make sure that they're actually up to the task," he noted. Companies should reach out to clients beforehand to prepare rather than realizing last-minute that something was missed.

## Final thoughts

Black Friday can feel like the “worst-case scenario” for developers. For business leaders, though, it’s the best case, the dream of record traffic and booming sales. The disconnect often occurs when marketing and technology don’t align.

The takeaway? Planning, testing, and cross-team communication are the real Black Friday survival tools. Whether it’s through better observability, smarter caching, or simply running drills, preparation is the difference between celebrating record revenue and explaining outages to the CEO.

As Guillaume summarized: "If one Black Friday went bad, do not wait one year hoping that everything will be better." Now is the time to start preparing for next year's holiday rush.

Hope is not a strategy. In the high-stakes world of e-commerce and high-traffic applications, thorough preparation and testing are the only reliable paths to success.

### [Next.js App Router: common mistakes and how to fix them](https://upsun.com/blog/avoid-common-mistakes-with-next-js-app-router/)

# Avoid common mistakes with the Next.js App Router

The Next.js App Router has introduced a range of useful features, such as support for React Server Components, better caching, streaming responses, and nested layouts. These features let developers create an improved user experience while also enjoying a better developer experience. While these features are helpful and user-friendly, if used incorrectly, they can introduce bugs or performance issues.

In this article, we'll explore the most common mistakes you can make with the Next.js App Router. We'll also present solutions, with code examples, to help mitigate these mistakes and enhance the user experience.

Note that the examples in this article use the Next.js `/src/app` project structure.

## Making redundant network requests within components

Fetching data on the client side has been a common practice in React for many years. So it's easy to fall into the trap of making redundant network requests on the client component, which is not as efficient because of the added network latency and you being required to create different HTTP route handlers.

In the following example, the `<UserComponent>` fetches data on the client side using the `useEffect` hook. While this approach works, it's not ideal because it adds more network requests on the client side and can lead to a slower user experience.

```Javascript
"use client";

 
import { useEffect, useState } from "react";

 
const UserComponent = () => {
  const [data, setData] = useState<{ name: string; email: string } | null>(
    null
  );

 
  useEffect(() => {
    const fetchData = async () => {
      const res = await fetch("https://jsonplaceholder.typicode.com/users/1");
      const result = await res.json();
      setData(result);
    };

 
    fetchData();
  }, []);

 
  if (!data) return <div>Loading...</div>;

 
  return (
    <div>
      <h1>{data.name}</h1>
      <p>{data.email}</p>
    </div>
  );
};

 
export default UserComponent;
```

To fix this, you can create a server component that fetches data on the server side and renders it in the `UserComponentFixed` component on the server:

```Javascript
const fetchUser = async () => {
  const res = await fetch("https://jsonplaceholder.typicode.com/users/1");
  if (!res.ok) throw new Error("Failed to fetch user");
  return res.json();
};

 
const UserComponentFixed = async () => {
  const data = await fetchUser(); // Fetching on the server side

 
  return (
    <div>
      <h1>{data.name}</h1>
      <p>{data.email}</p>
    </div>
  );
};

 
export default UserComponentFixed;
```

This ensures that the client receives an HTML markup, which reduces the load on the client to fetch and render the data, hence improving the overall user experience.

### Rendering dynamic routes as static by mistake

The Next.js App Router implements a static-first approach, which means that pages are always rendered as static unless they explicitly use dynamic APIs. While this approach improves the performance of the application, it can cause issues by misidentifying the page as static when you want to render the page dynamically but aren't using traditional dynamic triggers.

To fix this, you should use the connection function to explicitly opt into dynamic rendering. This ensures the page logic, such as generating a random ID or fetching fresh data, runs on every request:

```Javascript
// src/app/page.tsx

 import { connection } from "next/server";

 export function random(min: number, max: number) {
  return Math.floor(Math.random() * (max - min) + min);}

 export const fetchUser = async (id: number) => {
  const res = await fetch("https://jsonplaceholder.typicode.com/users/" + id);
  if (!res.ok) throw new Error("Failed to fetch user");
  const data = await res.json();
  return { ...data };};

 export default async function Home() {
  // Explicitly opt into dynamic rendering
  await connection(); 
  
  const userId = random(1, 10);
  const data = await fetchUser(userId);

  return (
    <div>
      <h1>{data.name}</h1>
      <p>{data.email}</p>
    </div>
  );}
```

### Attempting to use server-specific actions within client components

Server actions let you execute functions on the server from the server and client components for use cases such as form submission and data mutations.

While you can create a server action directly inside a server component, you cannot do the same for client components. To safely define and use server actions inside client components, you must define server actions in a separate file and import them into the client components. By doing this, you ensure that the server action is executed only on the server and the code is excluded from the client-side bundle.

If you are creating a to-do item client component, it makes sense to create a separate file for the server action and import it into the client component, as shown in the following example:

```Javascript
"use server";
// src/app/actions.ts

 
export async function completeTodo(id: string) {
  // server action to perform todo completion
}
```

```Javascript
"use client";
// src/components/TodoItem.tsx

 
import { completeTodo } from "@/app/actions";

 
export function TodoItem() {
  const id = "todo_23";
  return <button onClick={() => completeTodo(id)}>Complete</button>;
}
```

### Placing Suspense boundaries incorrectly, leading to poor loading experiences

React Suspense lets you display a loading state when waiting for a response. But you also need to know where to place the suspense boundaries to ensure that it improves the application's performance and provides a good user experience.

The following example sets a suspense boundary on the complete page:

```Javascript
// app/page.tsx

 
import { Suspense } from "react";
import UserProfile from "./components/UserProfile";
import RecentPosts from "./components/RecentPosts";

 
export default function Page() {
  return (
    <Suspense fallback={<div>Loading page...</div>}>
      <UserProfile />{" "}
      {/* Both components are delayed if one is still loading */}
      <RecentPosts />
    </Suspense>
  );
}
```

This blocks the rendering until every component in the page has finished loading. It can also lead to slow loading times and negatively impact the application's performance.

It makes more sense to place the suspense boundary on each component that loads data:

```Javascript
// app/page.tsx

 
import { Suspense } from "react";
import UserProfile from "./components/UserProfile";
import RecentPosts from "./components/RecentPosts";

 
export default function Page() {
  return (
    <div>
      <h1>Welcome to the Dashboard</h1>

 
      {/* Place Suspense boundaries around each section */}
      <Suspense fallback={<div>Loading profile...</div>}>
        <UserProfile /> {/* Shows loading state only for this component */}
      </Suspense>

 
      <Suspense fallback={<div>Loading recent posts...</div>}>
        <RecentPosts /> {/* Shows a different loading state for posts */}
      </Suspense>
    </div>
  );
}
```

This way, the user can see the dashboard page with loading skeletons and the components will render as they load without blocking each other.

### Using client-side hooks to access request data, leading to errors

The App Router provides utility functions to access request data, such as headers and cookies, directly in the route handlers and the server components. But you can't use these functions in the client components because they are server-side utilities. Instead, you can use the `usePathname`, `useSearchParams`, and `useParams` hooks in the client components to access information about the current route.

If you need to access the request headers or cookies in the client component, you can access them in a server component and pass the derived value to the client component. In the following example, the `UserProfile` client component needs to access the logged-in user's name, which can only be retrieved from the secured cookie:

```Javascript
// src/components/UserProfile.tsx
"use client"; // Marked as a client component

 
type UserProfileProps = {
  userName: string;
};

 
export default function UserProfile({ userName }: UserProfileProps) {
  // some interactive logic for the client component
  return (
    <div>
      <h2>User Information</h2>
      <p>Logged in as: {userName}</p>
    </div>
  );
}
```

To solve this, you can create a server component that retrieves the user's name from the cookie and passes it to the client component:

```Javascript
// src/app/page.tsx
import { cookies } from "next/headers";
import { UserProfile } from "./components/UserProfile";

 
export default async function Page() {
  const cookieStore = await cookies();
  const session = cookieStore.get("session");

 
  const user = await getUserFromSession(session); // this is a custom function

 
  return (
    <div>
      <UserProfile userName={user.name} />
    </div>
  );
}
```

### Placing context providers in server components where they aren't supported

React Context is a client-only API and is not supported in the server components. So using context directly in the root layout would not work, as shown in the following example:

```Javascript
// src/app/layout.tsx
import { createContext } from "react";

 
//  createContext is not supported in Server Components
export const ThemeContext = createContext({});

 
export default function RootLayout({ children }) {
  return (
    <html>
      <body>
        <ThemeContext.Provider value="dark">{children}</ThemeContext.Provider>
      </body>
    </html>
  );
}
```

To fix this issue, you can create a client component that exports the context and uses it in the server component:

```Javascript
// src/components/ThemeProvider.tsx
"use client";

 
import { createContext } from "react";

 
export const ThemeContext = createContext({});

 
export default function ThemeProvider({
  children,
}: {
  children: React.ReactNode;
}) {
  return <ThemeContext.Provider value="dark">{children}</ThemeContext.Provider>;
}
```

```Javascript
// src/app/layout.tsx
import ThemeProvider from "./components/ThemeProvider";

 
export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <html>
      <body>
        <ThemeProvider>{children}</ThemeProvider>
      </body>
    </html>
  );
}
```

It's better to use the context providers as deep into the application tree as possible to let Next.js optimize as much as possible. So if the `ThemeProvider` is only used in the `/dashboard/settings` route, render it in the nearest `layout.tsx` file for the best performance.

### Inappropriately mixing server and client components, causing functionality issues

Server and client components work in tandem, but each has a specific functionality. Use client components for any state management and interactivity. You can use React hooks inside a client component but not inside a server component, as in the following example:

```Javascript
// src/components/CheckoutForm.tsx
"use client";

 
import { useState, useEffect } from "react";

 
export default function CheckoutForm() {
  const [name, setName] = useState("");

 
  useEffect(() => {
    // some effect logic
  }, []);

 
  return <form>{/* interactive form */}</form>;
}
```

Server components are best suited for data fetching because of the added security and performance benefits. They're also preferred when you need heavy libraries for data manipulation, such as data-management or data-parsing libraries. Here's an example:

```Javascript
// src/components/UserDetails.tsx
import { fetchUser } from "./UserAvatar";

 
const UserDetailsComponent = async () => {
  const data = await fetchUser(5);

 
  return (
    <div>
      No store:
      <h1>{data.name}</h1>
      <p>{data.email}</p>
    </div>
  );
};

 
export default UserDetailsComponent;
```

The following example demonstrates the usage of client and server components on the same page:

```Javascript
// src/app/page.tsx
import UserDetails from "./components/UserDetails";

 
export default function Page() {
  // The Page function is a server component
  return (
    <div>
      <h1>Dashboard</h1>
      {/* Including a client component to handle dynamic state */}
      <CheckoutForm />
      <UserDetails />
    </div>
  );
}
```

### Errors in dynamic routing, particularly migrating from getStaticPaths and getServerSideProps

The latest Next.js version also supports the legacy Pages Router directory structure to provide a smooth transition for existing projects that want to gradually adopt the App Router features.

The `getServerSideProps` function is used to fetch the data on the server side and pass the result to the page component. So, when you're migrating, it can be tempting to convert the function into a route handler and consume it using a `fetch` API call. But by adding React Server Components, you can place the server-side data-fetching code directly inside a server component.

In the following example, the `getServerSideProps` function is used to fetch data on the server side and pass it to the `Orders` page component, and the `Orders` component is then used to render the data on the client side:

```Javascript
// pages/orders.js (Pages Router)

 
import React from "react";

 
export default function Orders({ orders }) {
  return (
    <div>
      <h1>Your Orders</h1>
      <ul>
        {orders.map((order) => (
          <li key={order.id}>
            <p>
              Order #{order.id}: {order.item}
            </p>
          </li>
        ))}
      </ul>
    </div>
  );
}

 
// Fetch data for the page with getServerSideProps
export async function getServerSideProps() {
  const res = await fetch("https://api.example.com/orders");
  const orders = await res.json();

 
  return {
    props: {
      orders,
    },
  };
}
```

In the App Router, you can fetch the orders data directly in the `OrdersPage` server component and render it on the server side:

```Javascript
// src/app/orders/page.tsx (App Router, Server Component)

 
export default async function OrdersPage() {
  // Fetch the data directly in the server component
  const res = await fetch("https://api.example.com/orders");
  const orders = await res.json();

 
  return (
    <div>
      <h1>Your Orders</h1>
      <ul>
        {orders.map((order) => (
          <li key={order.id}>
            <p>
              Order #{order.id}: {order.item}
            </p>
          </li>
        ))}
      </ul>
    </div>
  );
}
```

Similarly, the `getStaticPaths` function in the Pages Router is used to generate a list of paths for a statically rendered dynamic route. In the App Router, you use the `generateStaticParams` function to generate an array of params objects for dynamic routes, as follows:

```Javascript
import PostLayout from "./components/post-layout";

 
export async function generateStaticParams() {
  return [{ id: "1" }, { id: "2" }];
}

 
async function getPost(id: string) {
  const res = await fetch(`https://api.example.com/posts/${id}`);
  const post = await res.json();
  return post;
}

export default async function Post({ params }: { params: Promise<{ id: string }> }) {
  const { id } = await params;
  const post = await getPost(id);
  return <PostLayout post={post} />;
}
```

### Errors due to incorrect module imports or server-side code in client components

While using client components inside server components offers significant opportunities for composition, it can also blur the boundaries between client and server code at times. This blurring creates a risk of unintentionally exposing sensitive server-side code or secrets to the client by mistakenly including them in the client component.

To ensure this never happens, always use the `use server` directive at the top of the server action function declarations. Better yet, make a separate `actions.ts` file to contain all the server actions and use the `use server` directive at the top or module level.

You can also use the `server-only` npm package to declare a server-only module explicitly. For example, if you have a data-fetching module called `src/data.ts`, you can install the `server-only` module and use it as follows to exclude the code from the client-side bundle even if it's imported by mistake:

```Javascript
  import "server-only";

 
  export async function getUsers() {
    const res = await fetch("https://jsonplaceholder.typicode.com/users");

 
    return res.json();
  }
```

### Issues with APIs and slug handling, often due to improper configuration

A significant change in the modern App Router is that params and searchParams are now asynchronous. You must treat these objects as Promises and await them before accessing their properties. Accessing them synchronously will now result in errors during the build process.  
  
You can access the slug from the params prop in your page components as follows:

```Javascript
// src/app/blog/[slug]/page.tsx

// Note the async function and the Promise type for params
export default async function Page({ 
  params 
}: { 
  params: Promise<{ slug: string }> 
}) {
  // You must await params before accessing the slug
  const { slug } = await params;
  
  return <div>My Post: {slug}</div>;
}
```

Similarly, you must await the params in your API route handlers:

```Javascript
// src/app/api/users/[slug]/route.ts

export async function GET(
  request: Request,
  { params }: { params: Promise<{ slug: string }> }
) {
  // Await the params promise to get the slug
  const { slug } = await params;
  
  const res = await fetch(`https://jsonplaceholder.typicode.com/users/${slug}`);
  const data = await res.json();

  return Response.json({ data });
}
```

## Conclusion

In this article, we covered some of the most common pitfalls when using the Next.js App Router and discussed ways to address these and enhance the overall user experience.

If you're developing with Next.js applications, you can deploy them on Upsun, which provides features such as vertical and horizontal scaling, edge caching, and observability out of the box.

### [Getting started with Next.js on the Upsun PaaS | Upsun](https://upsun.com/blog/setting-up-next-js-on-upsun/)

# A quick-start guide on hosting Next.js on Upsun

Welcome to our quick-start guide on hosting Next.js (at the time of writing, the most recent version of Next.js is 14.0.3) on Upsun where we will demonstrate just how simple it is to host Next.js projects on our PaaS. Simply follow the steps detailed below and you’ll have everything set up in no time.

Have you seen the Upsun demo tutorial available to users via the Console? It’s the perfect place to start in terms of figuring out how Upsun works and gaining a better understanding of what we provide. If you’re looking for an alternative method to deploy an application on Upsun—such as with the Upsun CLI—you can find useful information in our dedicated Next.js guide.

Before we get started, for the purpose of this tutorial we will assume that you have already installed the Upsun CLI locally. The following steps are based on that assumption:

### Get started locally

If you already have an existing Next.js GitHub repository with, at least, a Hello world route, please clone it locally using the following command and then jump to the second step: Configure your project.

```shell-session
$ git clone git@github.com:<YourRepoUrl>.git
```

If you do not yet have an existing Next.js GitHub repository, you’re in the right place—the following steps will show you how to set one up and clone it locally.

#### **1\. Initialize your local project**

First things first, if you don’t have a local Next.js project yet, you need to create a new one locally following the Next.js installation guide. Please refer to all of the steps of the installation guide for full details, but to summarize, these are the three commands needed to create a Next.js app locally:

```shell-session
$ mkdir my-nextjs-app
$ cd my-nextjs-app
$ npm install next@latest react@latest react-dom@latest
```

#### 2\. Init your Git repository

Once you’ve created a new Next.js project locally, it’s then time to initialize the local Git repository and commit local files, using the following command:

```shell-session
$ git init
$ git add package.json package-lock.json
$ git commit -m "Init Next.js application"
```

**Please note:** You can ignore adding the `node_modules` and `.next` folders to the Git repository as Node modules will be installed during the build hook later in this process. Use the following commands to do so:

```

$ echo " node_modules"="">> .gitignore
$ echo "/.next" >> .gitignore
$ git add .gitignore && git commit -m "adding node_modules and .next folders in .gitignore file"
```

#### **3\. Add a Hello World route**

To ensure your Next.js application is easily testable, you need to create your first Next.js page. To do so, create a new `pages/index.tsx` file, it will contain a basic Hello world script, as seen below:

```Javascript
export default function Page() {
 return <h1>Hello world, Next.js!</h1>
}
```

Then commit your file using the following commands:

```shell-session
$ git add pages/index.tsx
$ git commit -m "adding a Hello World"
```

#### 4\. Create your GitHub repository

The next step is to create a GitHub repository, to do so follow the official GitHub guide which provides all of the information you need.

#### **5\. Push source code to your remote repository**

The final step of the local setup is to push your source code to your remote GitHub repository, using the following command:

```shell-session
$ git remote add origin git@github.com:OWNER/REPOSITORY.git
$ git push -u origin main
```

### **Configure your project**

To be able to host your Next.js application on Upsun, some YAML configuration files are needed at the root of your project to manage the way your application will behave. See the code below for how to automatically pre-generate them.

These YAML configuration files are located in an `.upsun/` folder at the root of your source code, the architecture of which will look like this:

```shell-session
my-nextjs-app
├── .upsun
│   └── config.yaml
├── [.environment]
└── <project sources>
```

**Please note**: An additional `.environment` file can also be located at the root of your source code, this file can contain Upsun-specific environment variables.

To pre-generate these YAML files, please use the following command `upsun project:init` from the root of your Next.js project and follow the prompts, as you can see below:

```shell-session
$ upsun project:init
Welcome to Upsun!
Let's get started with a few questions.

We need to know a bit more about your project. This will only take a minute!

✓ Detected stack: Next.js
✓ Detected runtime: JavaScript/Node.js
✓ Detected dependency managers: Npm
Tell us your project’s application name: [app]

                                                (_/)
We're almost done...  =(^.^)=
Last but not least, unless you're creating a static website, your project uses services. Let's define them:

Select all the services you are using: []

You have not selected any service, would you like to proceed anyway? [Yes]

┌───────────────────────────────────────────────────┐
│   CONGRATULATIONS!                                                                                                                      │
│                                                                                                                                                                     │
│   We have created the following files for your:                                                                         │
│     - .upsun/config.yaml                                                                                                                       │
│                                                                                                                                                                     │
│   We're jumping for joy! ⍢                                                                                                                  │
└───────────────────────────────────────────────────┘
        │ /
        │/
        │
  ( /)
  ( . .)
  o (_(")(")
  
You can now deploy your application to Upsun!
To do so, commit your files and deploy your application using the Upsun CLI:
  $ git add .
  $ git commit -m 'Add Upsun configuration files' 
  $ upsun project:set-remote
  $ upsun push
```

The `upsun project:init` command (shortcut `upsun ify`) will automatically detect that you’re using a Next.js stack, ask if you want to add any services (please don’t add any for now), and generate the corresponding `.upsun/config.yaml` YAML files, like so:

```yaml
# Complete list of all available properties: https://docs.upsun.com/create-apps/app-reference.html
applications:
 app:
   source:
     root: "/"
   type: "nodejs:20"
   mounts:
     "/.npm":
       source: "storage"
       source_path: "npm"
   web:
     commands:
       start: "npx next start -p $PORT"
     upstream:
       socket_family: tcp
    locations:
      "/":
        passthru: true
   build:
     flavor: none
   dependencies:
     nodejs:
       sharp: "*"
   hooks:
     build: |
       set -eux
       npm i
       npm exec next build
routes:
 "https://{default}/":
   type: upstream
   upstream: "app:http"
 "https://www.{default}/":
   type: redirect
   to: "https://{default}/"
```

Then commit your new files, using the following command, and the project configuration is complete:

```shell-session
$ git add .upsun/config.yaml
$ git commit -m "Upsun config files"
$ git push
```

### **Create a new Upsun project**

Please note: If you do not have an Upsun account yet, please create one to complete the steps that follow.

The next step in setting up Next.js on Upsun is to create a project which is simple to do via the Console. On your console homepage (all projects), in the top right corner, please click on the **create project** button, as seen below:

If you do not already have an organization created to put the project into, you’ll first be instructed to create one. Once you have done so, select that organization from the dropdown, and then select **Deploy with GitHub**, as seen in the screen below:

Then select **Connect with GitHub** from the options provided as seen here:

In the next form that appears which you can see in the screen below, select your GitHub organization from the first dropdown and then select **Install & Authorize** and fill out the GitHub credentials. You will need to select your GitHub organization and previously created GitHub repository and select **Continue**.

You will then be taken to step three of this setup—as seen below—where you will fill in various details including project name, environment name, and region. Once you’ve done so, select **Create project**.

On the next page, while the project creation process is ongoing in the background, you will see on the left some further setup instructions, if you need them. On the right, you can follow the project creation process and you will be informed when it is complete, as seen in the screen below:

Once your project has been created, the GitHub integration process will automatically deploy your application based on your GitHub repository source code. Wait for the integration to finish deployment and it will then display your application information which you can see an example of in the screen below:

### **Time to deploy, right?**

And just like that, it’s time to deploy! But wait…

As you already ensured your GitHub source code was Upsun-ready, your project will have been automatically deployed during project creation and your application will be live—no deployment needed and the first backup of your app will be done automatically. Check out your new **Project URL** which you can find at the bottom of the console interface.

The next step is to access your project console by clicking on the **View project** button at the bottom of the setup page, et voilà, your Next.js application is live and you can start playing around with it and adding lots of cool new features!

### **What about updates?**

#### **1\. Resources allocation**

During the first push of your production environment, Upsun will use the default size for each of your service/app containers. The default setting is set to 0.5 CPU & 0.2 GB of RAM, but that’s more than what is needed for this container so let’s lower it to something more appropriate.

If you need to define custom resources (CPU, memory, and disk) for the various containers, the process is simple. When in the environment view, click on the **Configure resources** link from the notification block at the top. This can also be done via the CLI.

In general, the following resources should be effective but feel free to adapt those values to your application's needs:

-   CPU: 0.1, memory 64 MB
-   1 instance
-   1024 MB of Disk/Storage

After confirming your choices, Upsun will then take your selections, gather the previously built images from earlier, apply your resource selections to them, and redeploy your full application. If you need more information, please refer to our documentation on how to manage resources on Upsun.

#### 2\. Code changes

**Please note**: The same rules that apply to Git workflows, apply to Upsun projects: never update your production environment directly, and always create a new branch to test your local changes.

To update your application, create a new Git branch as usual via your terminal, implement the changes you wish to make, and push the branch to your GitHub repository.

```shell-session
$ git switch -c update-hello
// do some code changes, like changing your Hello world message
$ git add . && git commit -m “Change Hello world”
$ git push -u origin update-hello
```

**Please note**: if you have already installed the Upsun CLI, you can also use `upsun push` command (instead of `git push`) as it will use the upsun Git remote to push your code to, and this remote is defined as the same as `origin`.

It will automatically create a new, inactive Upsun preview environment, based on your branch source code and parent environment data (database and/or assets). This new environment is **not active** by default which means it does not consume resources, so you need to activate it the first time you push a new branch on your repo, using the following command:

```shell-session
$ upsun environment:activate
Are you sure you want to activate the environment update-hello (type: development)? [Y/n] y
Activating environment update-hello
…
```

**Please note**: As we haven’t yet configured resources for our application container, the activation process will fail—but don’t worry, this is expected. The issue will be resolved with the release of Git25 expected in January 2024 as this new Git version will gather and use the parent resource settings as they are. In the meantime, please follow the steps above to configure resources in your preview environment.

At the end of this activation, your preview environment is deployed and you can access it either using the Console by going to the corresponding environment and clicking on its front URL, or by using the following CLI command:

```shell-session
$ upsun environment:url -primary
```

And just like that, you’re ready to host your Next.js applications on Upsun. Keep your eyes peeled for plenty more guides coming soon, with new articles posted on our blog on a selection of topics every single week. Find out more about Upsun's features and capabilities.

### [Master React server components | Upsun](https://upsun.com/blog/react-server-components/)

# Master React server components with our comprehensive guide

React has completely transformed how we create user interfaces by introducing a component-based design that encourages efficiency and reusability. Its declarative method and component-based structure have gained popularity among developers. But as your projects grow in complexity, you might encounter performance challenges because of rendering and data-retrieval methods.

In the traditional methods of rendering on the client side, you depend on the browser to run JavaScript for showing the initial user interface. This may cause delays in loading on devices with limited resources. Fetching data from an application programming interface (API) introduces additional load on these devices, which can cause a lag in displaying content and providing less-than-ideal user interactions.

Server components offer a solution to these obstacles by enabling the rendering of components on the server. This allows the server to stream the components to the client side, which enhances the performance and the data-retrieval processes since all the processing happens on the server and not on the users' devices.

In this article, you will learn how React's rendering methods have evolved over time, as well as the drawbacks of using React Suspense and server-side rendering (SSR). Additionally, you'll learn about React Server Components (RSCs) and how they tackle these issues.

## Understanding traditional React rendering strategies

Before getting into RSCs, it's helpful to understand earlier rendering strategies, such as React Suspense and SSR.

### React Suspense

React Suspense was introduced to handle asynchronous rendering in React applications. It allows components to "suspend" rendering until certain conditions are met, such as data fetching or code splitting. Here are some of the advantages of Suspense:

-   **Improved user experience.** Suspense allows you to have placeholders for your components, which makes it easy to show loading indicators when data is being fetched. This helps in avoiding blank content showing on the user's screen.
-   **Component rendering.** When you have components fetch data from an API, Suspense pauses the rendering of the component until the data is available. This prevents partially loaded pages and helps users have a better experience.
-   **Code splitting.** Suspense works with features like `React.lazy` to enable code splitting and improve performance by loading components only when they're needed.

But React Suspense has some limitations to be aware of as you scale your application:

-   **Incomplete support for server-side data fetching.** Suspense makes client-side data loading easier, but it doesn't support data fetching on the server side. To manage data retrieval from the server side, you need to use tools such as React Query. For instance, with Suspense, you still have to handle tasks like server-side caching and make client-side API requests to fetch data, which can add complexity to SSR.
-   **Increased complexity with nested components.** Working with Suspense in nested components can get quite complex at times. For example, when you're developing a product page that displays reviews, recommendations, and stock information, the coordination between loading the data for these nested components with Suspense boundaries can lead to slower loading times. This can complicate the code as each component's data dependencies and loading states must be managed.
-   **Boilerplate code overhead.** Suspense often requires extra code to handle loading states, errors, and fallbacks. For example, in a large app, you might end up wrapping many components in `Suspense` and `ErrorBoundary`, which adds repetitive code and makes it harder to keep everything consistent and maintainable as your app grows.

### Server-side rendering

When it comes to SSR, React components are rendered on the server, and then the fully generated HTML is sent to the client's side for display. In contrast, with RSCs, individual components are rendered when they are ready instead of waiting for the whole application to load, as is the case of SSR. This approach has multiple advantages:

-   **Improved initial load times.** By pre-rendering the HTML on the server, you allow the browser to show content much faster. For example, if you're building an e-commerce site, users can see product details right away while the rest of your JavaScript loads in the background. This makes your app faster, especially if the users have a slow connection or device.
-   **SEO advantages.** Search engines can easily categorize the rendered HTML code of your website, which enhances its visibility in search results. For instance, if you have a blog or a content-rich website, using SSR assists in guaranteeing that search engines promptly access and evaluate your articles without delay for JavaScript loading. In this case, SSR enables you to have a better SEO ranking.

SSR also has limitations to be considered:

-   **Hydration overhead.** After the server sends the initial HTML, the browser has to "hydrate" it by attaching event listeners and making the page interactive. This can cause performance issues because the browser has to render the page twice—once for the static content and again for the interactive parts. For example, if applications have features like analytics dashboards with graphs and input fields, this multiple rendering of different components can cause delays for users.
-   **Larger payloads.** With SSR, you have to send the entire JavaScript bundle to the client, which can increase the payload size. For example, when you're building a large app with multiple features, the amount of JavaScript sent to the browser can increase significantly, which may slow down page load times, especially on slower connections.
-   **Resource-intensive.** SSR has to generate HTML for each request made to it, leading to increased processing requirements and elevated server expenses. For example, if your application faces a traffic surge, you may need to boost server resources, adding complexity and cost to infrastructure management.

## React Server Components

RSCs are a new type of component in React that operates on the server side, unlike traditional components, which operate on the client side. They help address the issues associated with Suspense and conventional SSR by enabling components to be processed and streamed as HTML from the server to the client. RSCs also handle data retrieval on the server, ensuring that confidential information, such as API keys, is not revealed to the client.

RSCs provide some significant advantages:

-   **Optimized performance.** With RSCs, you move the rendering work to the server, reducing the amount of JavaScript your users' browsers need to run. For example, if you're building a blog, HTML content can be streamed directly, allowing posts to appear almost immediately without waiting for JavaScript processing.
-   **Secure data fetching.** RSCs fetch data server-side, enhancing both speed and security. For example, in an e-commerce app, the server retrieves product data, keeping API keys hidden from the client.
-   **Reduced client-side JavaScript execution.** Offloading rendering to the server reduces JavaScript execution on user devices, enhancing performance, especially on slower devices. In a dashboard, for instance, the server processes data-heavy components, so minimal JavaScript is needed on the client side.
-   **Faster initial page loads.** Since RSCs stream pre-rendered HTML, content loads quickly for users. On a news site, articles and images display instantly, avoiding blank screens while JavaScript loads.

### RSCs vs. traditional React components

Compared to client-side components, RSCs handle execution, data management, and performance in different ways.

Traditional components run in the browser (client-side), where JavaScript is needed to display the user interface (UI). RSCs run on the server by sending pre-rendered HTML to the client device instead of processing everything locally. This approach lessens the workload on the user's device and improves loading speed. Handling layouts and static content server-side is also ideal for noninteractive or data-driven components. Client components can be nested within RSCs where interactivity is needed, such as for buttons or forms, while keeping sensitive data secure on the server.

Traditional components can increase the size of the client-side JavaScript bundle, which could lead to slower app performance. RSCs do not increase the client's package size as they operate on the server side, leading to reduced downloads and quicker page loading times. You can also use RSCs to improve caching. Server-rendered content is easier to cache, which speeds up responses for frequently accessed data, like popular products in an online store, without repeatedly querying the database.

## How to implement RSCs

The simplest way to use RSCs in practice is through the Next.js App Router, which has built-in support for React Server Components without requiring manual webpack or Babel configuration.

Note that the code examples in this section use Next.js 15 with React 19.

### Project setup

Ensure you have Node.js 22 (current LTS) installed, then create a new Next.js project:

```shell-session
npx create-next-app@latest your-app
cd [your-app]
```

When prompted, select the App Router option. This is important because RSCs are only available in the App Router, not the legacy Pages Router.

### **Creating your components**

In the Next.js App Router, every component is a server component by default. Create a file at app/components/UserList.jsx:

```shell-session
// app/components/UserList.jsx
// This is a server component by default - no directive needed

async function UserList() {
  // Data fetching happens on the server
  // API keys and sensitive data never reach the client
  const users = [
    { id: 1, name: "John Doe" },
    { id: 2, name: "Jane Smith" },
    { id: 3, name: "Alice Johnson" },
  ];

  return (
    <ul>
      {users.map((user) => (
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  );
}

export default UserList;
```

  
To add client-side interactivity, you must explicitly mark a component with the "use client" directive. Create a file at app/components/Counter.jsx:

```shell-session
// app/components/Counter.jsx
"use client"; // This directive marks it as a client component

import { useState } from "react";

function Counter({ initialCount }) {
  const [count, setCount] = useState(initialCount);

  return (
    <div>
      <button onClick={() => setCount((prev) => prev + 1)}>
        Increment
      </button>
      <p>Count: {count}</p>
    </div>
  );
}

export default Counter;
```

Now update app/page.jsx to combine both components:

```Javascript
// app/page.jsx
// This is a server component - it can import both server and client components

import UserList from "./components/UserList";
import Counter from "./components/Counter";

export default function Page() {
  return (
    <div>
      <h1>Users</h1>
      <UserList />        {/* Rendered on the server */}
      <Counter initialCount={50} />  {/* Interactive, runs on the client */}
    </div>
  );
}
```

### **Run and test the code**

Start the development server:

```Javascript
npm run dev
```

Your app will be running at http://localhost:3000. The UserList component renders on the server and streams HTML to the client, while the Counter component hydrates in the browser and handles interactivity locally.

The key difference from traditional React is that UserList sends no JavaScript to the browser — only HTML. This reduces your client-side bundle size and improves load performance automatically.

## Best practices for using RSCs

Since RSCs handle most of the rendering on the server, shifting as much of your app's rendering as possible to the server can significantly improve performance while keeping interactive features intact where needed. The following are some best practices that can help you achieve this and enhance your application's speed, flexibility, and manageability with RSCs.

First, use RSCs to fetch data from APIs or databases. If you've already fetched data on the server, don't fetch it again on the client. For example, if you load user data on the server and pass it to the client, there's no need for a second API call on the client side unless the data changes.

Breaking code down into small chunks and selectively loading the needed scripts using tools such as Vite or webpack can help improve load times. Create components that can be reused across your app. For example, if multiple pages need to display a list of users, create a `UserList` component that works everywhere.

Finally, keep server components lightweight by focusing them purely on rendering data as they don't need to manage state like client components do. Focus on making them lightweight and purely responsible for rendering data. Only hydrate the parts of a page that need to be interactive. For example, if the page is mostly static but has a form or interactive button, hydrate only those components.

## Challenges and limitations of RSCs

Although RSCs come with benefits, it's also important to understand the obstacles and boundaries that come with incorporating them into your project.

### State management

Server components cannot interact with lifecycle methods such as `useEffect` or `useState`. This means you can't manage client-side interactivity within server components. For example, if a form is rendered server-side, you'll need a client component to handle real-time input changes.

When you're dealing with both client- and server-side components in your projects, it's important to handle the interaction between these two types of components across your application to avoid any issues. For example, if your application fetches data from the server and lets users edit this data locally on their devices, you might face issues with keeping the data consistent between the server and the client-side components.

### Non-serializable code

Server components can only use serializable props, meaning you can't pass functions, symbols, or any complex objects that can't be serialized. For instance, sending a callback function from a server component to a client component will lead to an error message. Server-side components don't have access to browser APIs such as `window`, `document`, or `localStorage`. If you need to interact with the DOM, that must happen in a client component.

### Hydration mismatches

If the HTML displayed by the server doesn't align with what the client-side JavaScript expects, it may lead to problems during the hydration process. For example, differences in how dates are formatted on the server vs. the client can cause subtle mismatches. Hydration mismatches can be hard to debug because the root cause isn't always obvious.

### Third-party library compatibility

Some third-party libraries may not work well with RSCs, particularly those that heavily depend on client-side rendering techniques or browser specific APIs. For example, libraries such as `react-router-dom` require client side rendering. You may need to replace or adapt some libraries to make them work with RSCs.

## Solutions for common RSC issues

There are practical solutions you can implement to maintain consistency and address common RSC issues.

### Use consistent state management

Use state management tools that work across both server and client, like Redux or Zustand. These libraries allow you to centralize your state so that server-rendered components and client-side components can access the same data. For example, you could use Redux to store a global state that's available to both sides of the app.

Ensure that you maintain a flow of data between the server and client by sharing context. For instance, when moving user data between server and client components, make sure the information is managed centrally to avoid any discrepancies.

### Use non-serializable code and refactor components

Consider using development tools or code linters to identify non-serializable properties that might cause issues with RSCs. For instance​, tools such as ESLint can be set up to detect function props that are transmitted from server-based components.

Make sure to refactor components to ensure that props can be serialized and avoid any issues with SSR. One way to do this is by moving certain operations like event handlers to client components. For example, when passing a callback function from a server component, make sure the code is adjusted so that the operation happens within the client component where it's being used.

### Handle hydration mismatches

Addressing hydration mismatches requires proactive testing and debugging techniques:

-   **Strict mode.** Turn on React's strict mode to catch problems in the development process. Strict mode will point out errors as you work so you can fix them before they become issues in the final product.
-   **Thorough testing.** Ensure thorough testing plans are in place to detect any problems related to hydration. Test automation can mimic server-side and client-side rendering processes to maintain uniformity. Consider using tools such as Cypress or Jest to confirm that the output displayed is consistent across both server and client environments.

### Ensure third-party library compatibility

If third-party software does not work with server components as needed for your project's requirements, explore alternative options that are server compatible. If you use an open source library for your project, you might want to think about giving back by contributing to its development to include RSC support as well. By contributing, you can enhance your own application and also have a positive impact on the broader community that relies on the same library for their work.

By tackling these challenges with proper strategies in place, you can efficiently navigate the limitations of RSCs and build robust, performant applications.

## Conclusion

In this article, we explained React's rendering techniques. We introduced React Suspense and SSR and provided a more in-depth guide to RSCs. You can use RSCs to help enhance the performance of your application by decreasing the need for client-side JavaScript processing and accelerating the initial page loads.

If you want to try out RSCs in your projects, the first step is to pinpoint the components in your app that would gain advantages from SSR. You can then slowly incorporate RSC into your codebase.

Running the infrastructure for SSR and server components can be complex. Using Upsun, a platform as a service (PaaS), simplifies deploying and scaling your React applications. With its built-in Node.js support and automatic scalability, Upsun can help you handle traffic surges smoothly. It also provides monitoring and security tools and allows you to manage multiple applications or microservices in different languages within a single project. This way, you can focus on building your React application while Upsun handles the core infrastructure.

### [PHP 8.2 features and changes | Upsun](https://upsun.com/blog/php-8-2-features-and-changes/)

# PHP 8.2 features and changes

Today is the official release of PHP 8.2.

And you can already use it on all your Upsun projects, with a single code change in your `.upsun.app.yaml`: 

`type: php:8.2`

Try it out today!

PHP 8.2 introduces some pretty cool new features including: 

-   Readonly classes
-   A new random number generator
-   Disjunctive Normal Form Types
-   Sensitive Parameter value redaction support
-   Constants in Traits
-   And the possibility to redact parameters in backtraces. 

Here’s a quick breakdown of each new feature and how they ought to make things easier for you. 

## **Readonly classes**

Previously, PHP 8.1 added support for _**readonly**_ class properties. Now, the new PHP 8.2 supports declaring an entire class as _**readonly.**_

Readonly classes are declared with the readonly keyword before the class declaration:

```Javascript
readonly class MyValueObject {
    public string $myValue;
}
```

Copy the snippet

Abstract classes and final classes can also be declared _**readonly**_. The order of the keywords does not make a difference, which makes things fairly easy.

```Javascript
abstract readonly class Foo {}
final readonly class Bar {}
```

Copy the snippet

It’s also possible to declare a readonly class with no properties in them, which effectively prevents dynamic properties while allowing child classes to explicitly declare their readonly properties.

### **New random number extension**

PHP 8.2 introduces a new PHP extension named _**random**_, which organizes and consolidates existing PHP functionality related to random number generation.

It also introduces a series of PHP class structures and exception classes to provide granular choice of random-number generator and exception handling.

### **Disjunctive Normal Form (DNF) types**

Another new PHP 8.2 feature is Disjunctive Normal Form (DNF), which is a standard way of organizing boolean expressions. 

Specifically, that means you can structure a boolean expression into an ORed series of ANDs. When applied to type declarations, this allows for a standard way to write combined Union and Intersection types that the parser can handle.

### **Sensitive Parameter value redaction support**

In PHP 8.2, it is now possible to mark sensitive parameters with a PHP attribute named SensitiveParameter, which makes PHP redact the sensitive information from the stack trace.

```Javascript
function passwordHash(#[\SensitiveParameter] string $password) {
    var_dump(debug_backtrace());
}

passwordHash('hunter2');
```

Copy the snippet

### **Constants are supported in traits**

Declaring constants in traits is now supported, too. Trait constants can also be declared with visibility modifiers and as final (since PHP 8.1). 

All of the following constant declarations are valid in PHP 8.2 and later:

```Javascript
trait FooBar {
    const FOO = 'foo';
    private const BAR = 'bar';
    final const BAZ = 'baz';
    final protected const QUX = 'qux';
}

class Test {
    use FooBar;
}

echo Test::BAZ; // 'baz'
```

Copy the snippet

## **With PHP 8.2, there are now a few deprecations…**

PHP 8.2 does introduce some deprecations, such as the Dynamic Properties, the ‘${}’ string interpolation, the partially supported callables, and the ‘utf8\_encode’ and  'utf8\_decode' methods.

### **End of ZTS support**

Zend Thread Safe (ZTS) has been supported by our PHP images since the 7.1 version. 

But with a diminution of the usage, and extensions dropping the support, the 8.2 version of our PHP image, and future versions, do not support ZTS.

### **Extensions**

Some PHP extensions might not be available on PHP 8.2. While extensions are already available, you may need to wait for others to arrive, such as newrelic, ioncube, sourceguardian, event, interbase, mongodb, oauth, pdo\_sqlsrv, tideways, and xdebug.

They will roll out incrementally, and once they are available the documentation will be updated accordingly. All you need to do is to update your `.upsun.app.yaml` file to enable them and push the new configuration.

### **Composer 2**

Composer, the PHP dependency manager has been updated to Composer 2. 

But don’t worry, Composer 2 will be mostly compatible with your existing workflows, and it brings with it  great new features, including faster download times and run-time platform requirements checks.

## **Blackfire support for PHP 8.2**

Meanwhile, PHP 8.2 will also work with Blackfire starting on its release date on December 8, 2022! 

You can find out more about PHP 8.2 with Blackfire on our blog.

### **There you have it! Try it out**

As you may figure, PHP 8.2 does introduce some breaking changes that may affect older code. So, as a best practice, you will want to test your application in a development environment.

To do that, first, create a new branch in your repository. Then, update your `./.upsun/config.yaml` in that branch and change the type key. After that, test your application and, if successful, merge the branch.

```shell-session
$ upsun checkout main
$ upsun branch upgrade-php-8.2
```

Change php version in `./.upsun/config.yaml` file from `php:8.1` to `php:8.2`

```shell-session
# ./.upsun/config.yaml
type: php:8.2

$ git add ./.upsun/config.yaml && git commit -m "Upgrade PHP to v8.2"
$ upsun deploy
```

Test your application

```shell-session
$ upsun checkout main
$ upsun merge upgrade-php-8.2
```

Congratulations! You’re now running PHP 8.2 on production.

And if you encounter or simply want to suggest new or improved features, please tell us on our GitHub repository.

You can also start a conversation on any Upsun.com related topic on our community website.

Happy Deploying!

**Useful links:**

-   PHP | Upsun documentation

### [Is Upsun a match for modern Drupal development? | Upsun](https://upsun.com/blog/a-match-for-modern-drupal-development/)

# Is Upsun a match for modern Drupal development?

So you have a Drupal website and you’re wondering if Upsun is a good fit for you. The short answer is: yes, of course! But let’s dig a little deeper and get acquainted with how to get the smoothest experience possible hosting your Drupal applications with us. 

I’m not going to detail how to modify your application to run on Upsun in this post (what we call “upsunifying” your apps), only highlighting some features that I think matter in particular when it comes to Drupal. But we do have a very handy getting started guide and onboarding _upsunify_ guide for you to explore—and you can always take advantage of our free trial to experiment. 

### **A simple, Git-based workflow**

The first thing to understand is that Upsun leverages both Infrastructure-as-Code (IaC) and GitOps to manage and deploy applications. More specifically, we use YAML files to define your application's infrastructure needs: runtime version, memory and storage requirements, and extra services like databases. 

With Git as the single source of truth, any change in both application and infrastructure is just a commit away, and deploying becomes a simple matter of merging into your main branch. This workflow is great for tracking changes, making it easy to test but also rollback if needed—after all, it’s only a matter of `git revert`.

Now, you might be thinking, “Uh oh, are they saying that I need to commit everything, even my vendors?” Let me reassure you right away: no, we are not monsters! Our job is to make your life easy, that’s why Upsun assumes that your _build flavor_ will be Composer, so simply commit your composer.json and composer.lock files and let us worry about the rest.

Once your application is built, the filesystem will be read-only, ensuring that the only thing altering your code will be your next commit. “But wait,  how am I supposed to handle user-uploaded media if I can’t write on the filesystem?” Worry not my friend, we have you covered, simply define mounts for the folders you need write access to, and you’re good to go. For example, with Drupal, you might want to define several mounts for media, cache, logs, and more.  

Take a look at this excerpt of the `.upsun/config.yaml` file for an example of the mounts that Drupal requires:

```yaml
applications:
  drupal-app:
    mounts:
      # The default Drupal files directory.
      '/web/sites/default/files':
        source: "storage"
        source_path: 'files'
      # Drupal gets its own dedicated tmp directory.
      '/tmp':
        source: tmp
        source_path: 'tmp'
      # Private file uploads are stored outside the web root.
      '/private':
        source: "storage"
        source_path: 'private'
      # Drush needs a scratch space for its own caches.
      '/.drush':
        source: "storage"
        source_path: 'drush'
      # Drush will try to save backups to this directory, so it must be
      # writeable even though you will almost never need to use it.
      '/drush-backups':
        source: "storage"
        source_path: 'drush-backups'
```

### **How to commit to production** 

By now, you may be worried about your Drupal config files. After all, you might make changes in production and want to commit these. The standard flow here is pretty simple:

**1.** Create a new environment from the environment you modified, for example, your production environment. This is easy peasy with our Upsun CLI:     

```shell-session
upsun environment:branch [new-branch-name]
```

Note: `upsun branch` is an alias you can use for `upsun environment:branch`

Upsun will then work its magic and provide you with a new preview environment, complete with a byte-for-byte copy of the parent’s data. It means that any code that you change now will be applied to the same context as the parent, so if your CI/CD tests are green, you can deploy.

**2.** Pull your newly created environment locally and do what you have to do

To work locally, we suggest you use DDEV, as it is the preferred option for Drupal, and because we are proud to have DDEV maintainer Randy Fay on our team. To find out more information on this, you can follow our install docs or DDEV’s install docs. 

Please note: we have a dedicated DDEV integration for Platform.sh to make things even smoother. Coming soon on Upsun!

Long story short, once you have DDEV installed and configured, you can switch to the new branch and pull the data in two commands as shown below:

```shell-session
upsun checkout [new-branch-name]
ddev pull upsun
```

And that’s it! You now have your identical local environment up and running and you can do everything you need using `ddev drush` (yes, you’ll probably need to start with `ddev drush cr` anyway). Time to export, commit, push, and open a pull request (PR).

**3.** A new preview environment will be created for your PR, allowing you to review the result before you merge—or should I say, deploy! 

All in all, this is a standard flow for our GitOps approach, as anything that is not versioned would be lost at the next deployment—especially if you use our build and deploy hooks to automate boring tasks, like importing configs or clearing the cache.  
  
Take a look at this excerpt of the `.upsun/config.yaml` file, particularly within the deploy section, which has some comments and action examples that you can perform using our deploy hook:

```yaml
# Hooks allow you to customize your code/environment as the project moves through the build and deploy stages
# More information: https://docs.upsun.com/create-apps/app-reference.html#hooks
hooks:
  deploy: |
    set -eux
    cd web
    bash $PLATFORM_APP_DIR/drush/platformsh_deploy_drupal.sh
```

Below you can take a look at the content of the `drush/platformsh_deploy_drupal.sh` file which was called in the previous code section: 

    `#!/usr/bin/env bash # # We don't want to run drush commands if drupal isn't installed. # Similarly, we don't want to attempt to run config-import if there aren't any config files to import # @todo expand further to pass --uri for all sites, with an eye towards multisite if [ -n "$(drush status --field=bootstrap)" ]; then   drush -y cache-rebuild   drush -y updatedb   if [ -n "$(ls $(drush php:eval "echo realpath(Drupal\Core\Site\Settings::get('config_sync_directory'));")/*.yml 2>/dev/null)" ]; then     drush -y config-import   else     echo "No config to import. Skipping."   fi else   echo "Drupal not installed. Skipping standard Drupal deploy steps" fi`

A little extra tip for you: you can use `drush` on your Upsun environments very easily if you need to (`drush uli`, anyone?), thanks to our CLI command upsun drush. See? We’ve always had Drupal sites in mind.  
  
In my next post, we’ll go a little further and see how you can export Drupal content and more importantly how you can automate these exports. You can check our Platform.sh Drupal 10 template or browse the awesome-platformsh repo for inspiration. Finally, don’t hesitate to ask questions or share your Drupal tips on our community site

### [Revolutionizing SaaS startups | Upsun](https://upsun.com/blog/revolutionizing-saas-startups/)

# Revolutionizing SaaS startups: how Upsun's PaaS model redefines the founder's journey

The landscape of SaaS startups is as exciting as it is challenging. Founders have to navigate a maze of financial, operational, and market challenges while striving to innovate and grow. In this crucible of startup development, the role of Platform-as-a-Service (PaaS) solutions like Upsun cannot be overstated. Let's explore how Upsun redefines the SaaS startup journey, bringing unique and sometimes controversial perspectives to the table.

## Financial planning: a paradigm shift with Upsun

Standard wisdom in startup circles often stresses bootstrapping and cautious spending. This can be tough to do when there is so much overhead involved in engineering a platform for your SaaS product.  Upsun's PaaS model introduces a paradigm shift. By offering a usage-based pricing strategy, it allows SaaS founders to engage in aggressive development and testing without the usual financial hemorrhage. This approach upends the traditional model, encouraging founders to focus on rapid, scalable product development with financial agility.

While we've built Upsun on usage-based billing, we know you need to plan your costs. That's why you can set up your resources ahead of time to see what you'll pay each month. This mix of flexible usage and planned resources keeps your development moving without any cost surprises.

Upsun's model offers you a place for innovation where costs are directly tied to usage. It enables startups to test and develop within the same ecosystem and infrastructure they plan to launch their production. This means no sudden financial shocks or re-investment into different platforms.

This flexibility enables SaaS founders to experiment and iterate without the constant fear of runaway expenses. By aligning financial outlay with development stages, Upsun ensures that financial resources are optimized, empowering founders to invest in crucial areas like market analysis, customer experience, and, critically, in securing top-tier talent.

## Scaling: boldly growing with Upsun

Scaling is often a make-or-break stage. The common advice is to scale cautiously, but Upsun encourages a bolder approach. It enables startups to easily scale not just from an infrastructural perspective with more CPUs and RAM, but also functionally, adding new languages and frameworks as needed. This capability challenges the traditional slow-and-steady scaling mantra, pushing founders to think big and scale ambitiously and effortlessly.

Our full-stack preview environments let you test ideas quickly. You can spin up test environments whenever you need them to check new features, get feedback, and make changes without any extra work on the infrastructure side.

Upsun's infrastructure handles the complexities of scaling, eliminating the need for an extensive operations team. This aspect is liberating, as it allows startups to invest in product innovation rather than operational maintenance. In essence, Upsun enables startups to punch above their weight, scaling rapidly to meet market demands and user expectations.

## Security compliance: mitigating risks with Upsun

In the SaaS startup ecosystem, security compliance is not just a feature—it's a necessity. The risks associated with data breaches, non-compliance to regulations, and cybersecurity threats can not only hinder a company's growth but potentially cripple it. Upsun's commitment to robust security compliance emerges as a critical advantage for SaaS founders, enabling them to navigate these risks with confidence.

Earning and maintaining customer trust is paramount. This trust hinges significantly on a company's ability to protect sensitive data and uphold privacy standards. Upsun's adherence to stringent security compliances—such as GDPR, HIPAA, and SOC 2—provides SaaS companies with a solid foundation to build this trust. By aligning with Upsun, startups assure their customers and stakeholders of their commitment to data security and regulatory adherence.

## Hiring the right people: breaking barriers with Upsun

The challenge of hiring in the SaaS sector often revolves around finding talent that can navigate limited technological frameworks. Upsun dismantles these barriers. By supporting a wide array of languages and frameworks, Upsun empowers founders to hire from a more diverse talent pool. This approach challenges the industry's status quo, where startups are often pigeonholed by their initial tech choices.

With Upsun, the focus shifts from finding candidates who fit the technology to finding the best talent for their vision and culture. This is a game-changer, enabling SaaS startups to innovate faster and more effectively, unshackled by the constraints of their initial technological choices.

## Time management: Upsun's revolution in efficiency

Time management in SaaS startups often translates to a delicate balance between development and operational tasks. Contrary to the traditional approach of dividing attention, Upsun proposes a revolutionary solution: letting developers focus solely on what they do best, innovating. By handling all operational aspects such as infrastructure management, platform engineering, and CI/CD pipelines, Upsun challenges the norm of multitasking in startups.

This approach may be seen as controversial in circles that advocate for a more hands-on approach to operations by developers. However, by freeing up developers to concentrate exclusively on building and refining the product, Upsun accelerates development cycles and can significantly shorten the time to market.

## Competing in a crowded market: Upsun's edge

Upsun equips startups to make bold strides. By enabling developers to spend more time on innovation rather than building and maintaining infrastructure, Upsun provides startups with a crucial advantage: speed. This speed is not just about beating competitors to market but also about rapidly iterating and refining products in response to user feedback and market trends.

In the high-stakes world of SaaS, it's often the boldest moves that define market leaders. Upsun empowers startups to not only enter the market swiftly but to continuously innovate and stay ahead of the curve.

In conclusion, Upsun's PaaS model is more than just a tool; it's a strategic partner for SaaS founders. It challenges conventional wisdom and encourages bold, innovative approaches to financial planning, scaling, hiring, time management, and market competition. For SaaS startups, adopting Upsun can mean the difference between trailing behind and leading the pack. In a sector driven by innovation and agility, Upsun stands out as a beacon for startups looking to redefine their journey and carve out their own path to success.

Start your Upsun free trial, and put it to the test for yourself.

### Useful links

-   Upsun as a SaaS development and management platform

### [Strapi deployment: a powerful decoupled headless CMS | Upsun](https://upsun.com/blog/strapi-deployment-on-upsun/)

# Up(sun) and running with Strapi: a seamless journey to a powerful decoupled headless CMS

As the digital landscape continues to evolve, businesses and developers alike are searching for ways to optimize and streamline their workflows. Headless content management systems (CMS), like Strapi, have emerged as a game changer in this search. And with their power to deliver content seamlessly across multiple platforms, it's no wonder they're quickly gaining traction.

In this blog post, we'll delve into the effortless deployment of Strapi applications on Upsun. Enabling users to build great applications, minimize infrastructure management to support content updates, and shine the best possible light on the content they publish.

## Beyond traditional CMS: the Strapi revolution

Strapi is a leading Node.js open-source headless CMS, providing complete customization and a developer-centric approach. It empowers developers by catering to their specific requirements, enabling them to design their content structure exactly as they envisioned it.

Being open source and API-first, Strapi offers the freedom to modify, customize, and adapt the software to any specific need. You can benefit from the flexibility of a top-notch CMS to manage content that will be displayed in one or more business applications.

Strapi and Upsun share the same philosophy: users should spend less time tweaking, and more time doing what they love most. Strapi believes developers shouldn’t have to reinvent the wheel and recode a CMS from scratch every time they need to inject content into a new application. At Upsun, we are strong believers that developers should be free to work on cool new features and add value to their end users, not constantly managing their infrastructure and deployment pipelines.

## Strapi’s perfect partner in the cloud

All of the above is why we love Strapi so much—even the blog post you are reading now is served to you by a Strapi application.

Upsun empowers development teams with the flexibility to build—and the firepower to run—diverse applications on a single, self-service PaaS. By fully managing infrastructure and security, Upsun frees every developer to easily experiment, quickly iterate, and confidently deploy applications at scale.

As developers, we know the importance of having the leeway to experiment and iterate. Upsun provides just that. With its self-service PaaS, you can build diverse applications and harness the firepower to run them efficiently.

Think about the countless hours spent managing infrastructure, patches, and security concerns. With Upsun, those worries are a thing of the past. You focus on building; Upsun manages the rest.

## Unlocking potential: strategies for scaling your Strapi application with Upsun

Whether you're starting small or aiming big, Upsun is built for growth. Easily scale your Strapi applications with peace of mind, knowing that Upsun is designed for large-scale operations.

### Horizontal scaling: a multi-dimensional approach

Applications come in various shapes and sizes, and so do their scaling needs. Whether you're running a monolith or have embraced a decoupled architecture, Upsun's got you covered:

-   **Multiple technologies and applications**: launching multiple tech stacks for a single project? Upsun is adept at juggling various technologies, ensuring they work in tandem flawlessly.
-   **Effortless worker and service management**: as you grow, you may need more workers to manage tasks and maintain speed. You might also enrich your project with extra services. With Upsun, scaling the number of workers or adding more services is hassle-free and efficient.

### Vertical scaling: precision and control at your fingertips

Scaling vertically can be seen as a daunting process or even an impossible one with a one-size-fits-all approach. With Upsun, that's far from reality as we put you in the driver’s seat:

-   **Fine-grained resource control**: Upsun’s intuitive interface and CLI allow you to dial up or down the resources you allocate to each service and container. This means you can control your cost and can easily adjust resources based on demand.
-   **Seamless experience**: no need for downtime or convoluted processes. Upsun ensures your vertical scaling is a seamless experience, keeping your applications running smoothly regardless of the changes behind the scenes.

## Enhanced observability with Upsun

Every project deployed on Upsun benefits from advanced observability features, ensuring you have a clear line of sight into your application's health and performance.

On the infrastructure front, we provide detailed HTTP metrics and comprehensive infrastructure metrics, giving developers a holistic view of their system's operations.

Diving deeper into the application side, Continuous Profiling offers invaluable insights for performance tuning for NodeJS and Go applications. Additionally, full access to Blackfire is included for all PHP and Python applications allowing for in-depth analysis and optimization.

With Upsun, complete visibility isn't just an option—it's a guarantee. We are here to help you grow. We are siding with you by providing insights to help you and your application reach new heights.

## Embark on your Strapi journey with Upsun

The synergy between Strapi and Upsun promises an unmatched deployment experience. If you're curious to see this powerful duo in action, we warmly invite you to give it a spin.

Our documentation provides a dedicated guide to seamlessly deploy Strapi on Upsun. It ensures you have all the resources at your fingertips. Dive in, explore, and witness firsthand the transformative power of deploying Strapi on Upsun—your next big project awaits.

Application development isn't a solo expedition. It's a collaborative quest, enriched by shared wisdom and collective troubleshooting. We encourage you to connect and share your experiences, queries, or insights in our dedicated Community.

Dive into a community where Strapi developers, just like you, come together to collaborate, discover, and advance in creating the upcoming wave of scalable, modular applications. We're eager to learn about your endeavors and explore how we can amplify your development voyage—see you there!

### [Platform.sh is now Upsun (A note from our CEO) | Upsun](https://upsun.com/blog/platform-sh-is-now-upsun-note-from-our-ceo/)

# Platform.sh is now Upsun

Over the last decade, Platform.sh has grown into a leading cloud application platform trusted by developers and organizations globally. Our mission has remained constant: to inspire forward-thinking teams to build, iterate, and scale applications without the burden of managing infrastructure.

In recent years, application development has become both more complex and more efficient. AI is transforming the speed and efficiency with which applications are built. Today's developers are creating software 55% faster with AI-powered tools, while others are scaling globally and juggling multiple types of workloads that we haven't seen in decades. This means application volume is set to surge as development cycles compress from months to weeks, or even days, and the complexity of building has shifted from application coding itself to the tooling management, cloud deployment, securing, and scaling the application in a way that is sustainable, maintainable, and cost-efficient.

Our ambition is to push the boundaries of cloud and developer experience even further to align with this revolution. Today, we are excited to announce the next chapter in that journey; Platform.sh is evolving and will become **Upsun**. While our mission remains unchanged, we are expanding our commitment to supporting the growing and complex needs of organizations like yours.

## **Why the name Upsun?**

"Up" represents the fundamentals we have consistently delivered: uptime, reliability, and moving upwards to meet new challenges. 

"Sun" hints at our global footprint and aspiration to be the dawn of what's coming next in application development. By definition, "upsun" means the hours between sunrise and sunset, your productive hours. We operate globally, following the sun to provide 24/7 support.

While Platform.sh established our foundation in developer-focused hosting, Upsun embodies our evolution into **the cloud application platform that humans and AI agents love**. We support everything from traditional web applications to AI-powered services, complex microservices architectures, MCP servers, and technologies that diverse teams are building today.

## **What stays the same?**

Practically everything you have come to rely on will remain at the core of Upsun.  For existing Platform.sh customers, here's what this means**:**

-   Your applications and workflows continue to run exactly as they have 
-   The support team you already know and trust continues without interruption
-   Your current pricing plan stays the same
-   Your projects, workflows, and integrations remain untouched
-   Your account, billing, and contract terms are unchanged

## **What's new and better?**

**AI-ready by design**

As AI transforms how applications are built, Upsun is built for teams where humans and AI work together. Onboarding is faster with AI-generated configuration that handles your project setup. Upsun also integrates directly with Claude Code and GitHub Copilot through our MCP server and API, and provides the infrastructure you need to deploy LangChain applications,  custom AI agents, and modern data-driven apps.

**Predictable and more granular pricing**

While the current pricing plan remains available, now you have additional pricing options! We're introducing **Upsun Flex**, a predictable and transparent pricing model that allows you to pay only for the resources you provision. For example, if your app is set to use 1GB RAM and 0.5 CPU cores, you pay for exactly that. When Black Friday traffic spikes, scaling you up to 4GB RAM and 2 CPU cores for those crucial hours; you pay for those extra resources only during this period; then costs drop back to your baseline. Your costs scale linearly with your actual resource consumption, which means your infrastructure spending finally moves in sync with your business activity.

**Preview environments**

Spin up a complete production-grade clone of any branch in minutes. Every git push creates an environment replica that mirrors your production setup, including configuration, code, data structure, and file handling, all defined through a single configuration file. Test your UI, backend, and AI components together with realistic data before going live. 

**Multi-cloud flexibility**

Deploy on any primary cloud provider, anywhere in the world. Upsun supports a range of cloud providers, including AWS, Azure, Google Cloud, IBM, and OVHcloud. Additionally, you can switch regions by modifying a single line in your configuration. Now you can run your API on AWS while keeping ML workloads on Google Cloud. 

**Enterprise-grade security**

We have achieved several independently audited industry certifications from the outset, which demonstrate that your data is handled with appropriate care and in accordance with industry standards. Platform.sh has maintained SOC 2 Type 2 and PCI DSS Level 1 compliance, along with advanced security controls and audit trails.

 Now, with Upsun, we still have all certifications previously available with Platform.sh, but we have also added ISO 27001, FS Cloud certification, and IBM Cloud region availability, and have received Gartner reports.

**Environmental responsibility + green hosting incentive**

High performance shouldn't come at the expense of the planet. Upsun delivers up to 12 times more efficient CPU usage and up to 15 times lower emissions in low-carbon regions, with real-time CO₂ tracking integrated directly into your billing console. With our new green hosting incentive, you can deploy in eco-friendly areas and receive a 3% discount on resource usage.

## **The bigger picture**

This evolution reflects the direction in which software development is heading. Teams are building more complex and diverse applications than ever before. AI is transforming how we code and what we build and organizations need infrastructure that can adapt to new requirements rather than constrain what's possible. We believe technology will change the world for the better, and we're committed to helping development teams focus on what matters most: building applications that matter.

Traditional platforms require you to fit your vision into their boxes. Upsun adapts to your applications, from running PHP alongside Python AI agents to scaling across multiple cloud providers to spinning up environments that mirror complex production setups. The platform grows with your technical requirements.

And now you have pricing options that match this flexibility. Whether you're building content applications, e-commerce platforms, or integrating AI-powered features, Upsun provides the foundation that scales with your ambitions.

## **What happens next?**

The transition to Upsun is completely seamless. We're handling everything behind the scenes, so your applications continue to run without interruption. Platform.sh is getting a new name and expanded capabilities, but the reliable platform and team you trust remain stronger than ever.

You are at the heart of this evolution, and we are immensely excited to embark on this new chapter with you. 

_**A brighter future is upon us. Welcome to Upsun.**_

### [RESTful API design principles: best practices for developers](https://upsun.com/blog/restful-api-design-principles/)

# Understanding RESTful API design principles

RESTful APIs allow client applications to access and manipulate resources (data) hosted on a remote server using a standardized set of rules and protocols. REST stands for **representational state transfer**, which is a set of architectural principles that define how to design and implement these interfaces. Key principles of RESTful design include using HTTP methods—like `POST`, `GET`, `PATCH`, and `DELETE`—to perform CRUD (create, read, update, delete) operations, identifying resources through unique URLs, and transferring data in a lightweight format like JSON. RESTful APIs provide a flexible and standard way for systems to communicate with each other over the internet, making them a fundamental building block of modern web and mobile applications.

This article covers the fundamentals of RESTful API design. By the end, we'll explore key REST principles, how they compare to other paradigms, and best practices for designing RESTful APIs.

## API design principles

Before getting into the details, let's briefly review how RESTful compares to other popular API design methodologies.

### RESTful

As mentioned, REST APIs are structured around resources (nouns) rather than actions, utilizing standard HTTP methods (`GET`, `POST`, `PUT`, `DELETE`) to manipulate those resources. RESTful APIs are built around several key principles for consistent and scalable web services:

-   **Stateless communication.** REST API requests contain all necessary information, with no client context stored on the server between requests.
-   **Uniform interface.** This principle ensures consistent resource identification and manipulation through self-descriptive messages using standard HTTP headers and status codes. It also incorporates HATEOAS (hypermedia as the engine of application state), allowing clients to discover API capabilities dynamically.

### GraphQL

Created by Facebook, GraphQL is a query language and runtime that allows more efficient and flexible data retrieval than traditional REST endpoints. Its core design principles are as follows:

-   **Query flexibility.** This allows clients to specify what data they need in the response. This means that multiple resources can be requested in a single query while eliminating overfetching and underfetching of data.
-   **Single-endpoint architecture.** It routes all requests through one endpoint, differentiating operations by query vs. mutation types. A schema defines all possible operations and types within the architecture.
-   **Strong typing system.** This serves as a contract between client and server, providing built-in type validation and documentation while enabling powerful developer tools and type checking.

### gRPC

Created by Google, gRPC is a remote procedure call (RPC) framework based on HTTP/2. It operates based on the following core principles:

-   **Contract-first development.** Uses Protocol Buffers (protobuf) as a strict interface definition language (IDL), enabling automatic code generation for both client and server implementations.
-   **Streaming support.** Includes unary, server, client, and bidirectional streaming capabilities, making it efficient for real-time communication and large data transfers, particularly in microservices communication.
-   **Binary protocol.** It uses HTTP/2 as its transport layer, which offers highly efficient binary serialization. This results in lower latency and better performance compared to text-based protocols.

### Overview of API design principles

Here's a table that summarizes some of the differences between these designs:

## RESTful API architecture overview

A system using a RESTful API typically includes three key components: the client, server, and database. It also includes additional elements like a load balancer, caching, and authentication service.

### Client

The client is any application or device that consumes the API. This could be a web browser, mobile app, or another server in a microservices architecture. Clients send requests to the server using HTTP methods (\_eg\_ `GET`, `POST`, `PUT`, `DELETE`) to perform CRUD operations on resources—for example, a mobile app that retrieves user data by making a GET request to `https://api.example.com/users`.

### API server

The server hosts the API and is responsible for processing incoming client requests, interacting with the database or other services, and returning responses. The server interprets the HTTP requests, performs the necessary operations (such as creating, retrieving, updating, or deleting resources), and returns the appropriate HTTP status codes and data.

Middleware makes up optional layers that can be integrated into the server architecture to handle additional functionalities. This can include authentication, logging, data validation, error handling, and request/response transformations. Middleware processes requests before they reach the server's core logic and can also modify responses before they are sent back to the client.

### Database

The database stores the application data. It can be a relational database (like PostgreSQL or MySQL), a NoSQL database (like MongoDB), or any other form of data storage. The server uses the database to persistently store and retrieve data, such as user information, product details, or transaction histories.

Within the database, a caching layer stores copies of frequently requested data to reduce the need to access the database repeatedly. It helps reduce latency by serving data from the cache instead of querying the database every time. This is often achieved using in-memory databases, such as Redis or Memcached.

### Load balancer

A load balancer can be used to distribute incoming client requests across multiple server instances. This helps to ensure high availability and scalability, preventing any single server from becoming a bottleneck. It balances traffic among multiple server instances to improve response times, provides fault tolerance by rerouting requests if a server becomes unresponsive, and can also handle SSL termination to offload encryption and decryption from the servers.

On modern platforms like Upsun, this functionality is often integrated into an Edge Layer architecture that sits in front of application containers, handling request routing, TLS termination, WAF, and DDoS mitigation. Load balancing across application instances typically happens at a per-environment reverse proxy downstream of that edge.

## Key characteristics of REST APIs

REST APIs are based on several core principles that define their architecture and behavior.

### Client-server architecture

In a RESTful API architecture, the client and server operate independently. The client (eg. a web browser or mobile app) is responsible for the user interface and initiates requests, while the server handles data processing and responses. This separation of concerns leads to long-term maintainability and flexibility.

For example, a mobile app can interact with the REST server using its API without needing to understand implementation details. If the backend API includes user interface code, it creates tight coupling between client and server, creating dependency issues and making updates harder.

### Stateless communication

As mentioned, in a stateless architecture, each request from the client to the server contains all the information needed to process the request. The server does not store any client-specific session data. This makes it easier for the API server layer to scale horizontally. Since each request is self-contained, servers can handle them independently, which simplifies load balancing. It also means that servers don't need to store session state, reducing memory overhead.

For example, a login API call must include user credentials in each request rather than relying on a session ID stored on the server. This allows any server in a cluster to handle the request without needing prior context. If a server relies on session data stored between requests, it complicates scaling and makes it difficult for load balancers to distribute requests evenly.

### Cacheable responses

RESTful APIs' responses can be cached, allowing clients or intermediaries to store responses for a certain time. This minimizes the need for repeated requests for the same data. Cached data can be served faster than querying the server every time. It also reduces latency and server load, which improves user experience and scalability.

An API response can include caching headers like `Cache-Control` and `Expires`, enabling the client to store the data temporarily and avoid unnecessary calls to the server. For example, a weather API response that is cacheable could reduce the need for frequent updates if the data remains unchanged for an hour. If responses lack caching headers, clients will repeatedly request the same data, adding unnecessary load to the server and slowing down the response time for the end user.

### Layered system

A layered system allows APIs to operate across multiple layers—such as intermediaries, load balancers, and gateways—without the client being aware of these layers. This approach provides added security and scalability. For example, load balancers can help distribute traffic without the client needing to know how the load is balanced. This modularity makes it easier to scale or secure parts of the system without redesigning the whole API.

When a client makes a call to an API, it can be automatically routed through a load balancer and firewall, ensuring optimized performance and security without altering the client code. If a client has to directly interact with multiple backend servers or understand how requests are distributed, it introduces complexity and breaks the layered abstraction.

### Uniform interface

Another core principle of REST APIs is the Uniform Interface constraint, which is a set of standard rules for interacting with the API. This includes consistent use of HTTP methods (`GET`, `POST`, `PUT`, `DELETE`), standard URL patterns, and predictable response formats. A uniform interface improves the API's usability, making it easier for developers to predict how the API will respond to requests. This consistency reduces the learning curve and the likelihood of errors.

A RESTful API uses HTTP methods consistently across resources (eg. `GET /users` retrieves users, `POST /users` creates a user), which ensures uniformity and predictability. An API that uses nonstandard methods or mixes HTTP methods (eg. using `GET` to create a resource) can confuse developers and make the API harder to use reliably.

### Code on demand

Code on demand is an optional REST architectural constraint that enables servers to extend client functionality by transmitting executable code like JavaScript to clients at runtime, such as loading dynamic widgets or updating UI components without a page refresh.

This enables the client to extend functionality dynamically without needing to update its code. It provides flexibility and can enhance functionality by letting clients execute code directly from the server, especially in dynamic web applications.

## Conclusion

This article explored the concept of RESTful API design principles and the essential components that make an API RESTful. This started with an overview of API design alternatives and a topology of typical RESTful system architecture along with a deep dive into the key components of RESTful APIs. Adhering to RESTful API design principles can improve code quality and ensure that your APIs serve users effectively and efficiently, making your application more successful in the long run.

Upsun frees modern development teams to easily experiment, quickly iterate, and effortlessly scale on every dimension. It's a self-service, fully managed, secure, developer-focused cloud application platform with built-in observability, multicloud edge caching, reliable deployment, and the freedom to choose your stack and cloud provider. With Upsun, you can build and run RESTful API applications using programming languages and frameworks of your choice. You have complete control over how to scale applications (horizontally or vertically) while Upsun manages the heavy lifting, including resource allocation and traffic surges.

### [Accelerate software testing | Upsun](https://upsun.com/blog/accelerate-software-testing/)

# Move fast and break things: accelerating testing with Upsun

When Mark Zuckerberg famously said, _“Move fast and break things. Unless you are breaking stuff, you are not moving fast enough,”_ he was setting the stage for a bold approach to innovation. While his words have sparked debates, they resonate deeply when applied to software testing—especially when it comes to leveraging Upsun.

Testing with Upsun isn’t just about catching bugs; it’s about doing it quickly, efficiently, and without derailing your workflow. Let’s explore why breaking things fast is the key to accelerating testing and how Upsun makes it a reality.

## Testing is expensive… or is it?

Here’s a stat to chew on: it’s 30 times more expensive to fix a bug in production than if you catch it earlier. I know, it sounds made up, right? It’s not. Think about it—a bug in production doesn’t just waste engineering time; it damages your brand, erodes customer trust, and pulls your team away from building new features. **That’s why testing isn’t optional; it’s critical**.

But let’s be real: testing can also feel like a bottleneck. Developers want to build cool stuff, not spend their days writing tests. How do you balance speed with safety? By embracing a philosophy I like to call _breaking things fast._

The reality is that while most teams understand the need for testing, they often lack the tools to make it seamless. Without the right support, even the most well-intentioned efforts can falter, creating a cycle of frustration and delays. That’s where Upsun comes into play, transforming the testing experience from a hurdle into a catalyst for progress.

## Breaking things fast: a different philosophy

Breaking things fast isn’t about chaos; it’s about intentional, rapid iteration. It’s about answering two fundamental questions:

1.  **Is it broken?** (Unit tests, functional tests, exploratory tests, etc.)
2.  **When will it break?** (Load tests, penetration tests, scalability tests.)

The goal isn’t perfection on the first try; it’s getting feedback as quickly as possible so you can fix issues before they snowball. Testing, in this sense, becomes less about process and more about curiosity—the desire to see how far you can push something before it breaks.

When you think about it, the essence of testing lies in embracing uncertainty. It’s not about proving that your code works; it’s about uncovering how and where it doesn’t. By shifting the focus to breaking things fast, teams can foster a mindset of exploration and improvement, one that drives innovation rather than stifling it.

## The problem with traditional testing

Let me take you back to 2002. I was a self-proclaimed "webmaster" (yes, that was a real title) at Eastern New Mexico University. My testing process? FTP the HTML files directly to the server, hit refresh, and see if it worked. If it didn’t, I’d tweak the code, FTP it again, and repeat. It was crude, but it worked… most of the time.

Fast forward to today. We’ve traded FTP uploads for staging environments, dev environments, and CI/CD pipelines. These are all good things—but they come with a major limitation: they rarely match production completely. Spinning up a staging environment might only take hours or days, but replicating production’s full complexity is another story. Infrastructure, networking, caching, search, data, dependencies, runtimes, and frameworks all play critical roles in how an application runs—and none of these are strictly tied to your code. Failing to copy these variables faithfully creates gaps that make your tests unreliable and your bugs harder to catch. By the time you’ve fixed a bug, your users have already encountered it. That’s not moving fast; that’s stumbling in the dark.

Consider the complexity involved: configurations, data syncing, permissions, and compatibility checks. Each step adds friction, making it harder to deliver on time. For teams working under tight deadlines, this can feel like running a marathon in quicksand. It’s no wonder developers yearn for a faster way.

## Testing in Production: A Love-Hate Relationship

But what if we could test in production? It’s a provocative idea, and for good reason. Testing in production gives you the most accurate data possible. There’s no worrying about whether your staging or dev environment perfectly mirrors production—it’s the real thing. Every infrastructure detail, networking configuration, caching layer, and runtime is exactly as it should be.  You would be able to get immediate feedback, test performance, and understand environment-specific issues.

But there is one problem with testing in production… users.  The “break things fast” mentality only works if users aren’t involved.  The end goal is for users to have an amazing experience.  That’s far from possible if you are breaking the app for them every time they go to use it.  

So, what’s the alternative? Replicating production—and this is where Upsun shines.

### Upsun’s Secret Sauce: Full-Stack Cloned ~Environments~ Ecosystems

What if you could clone your entire production environment—code, data, infrastructure, services—in seconds? With Upsun, you can. Here’s how it works:

1.  **Branch from Git**: Every cloned environment starts with your Git branch. But it’s not just the code that gets cloned; it’s the entire stack.
2.  **Perfect Replication**: Upsun doesn’t just copy your code; it mirrors your databases, APIs, services, DNS settings, SSL certificates… everything.
3.  **No Users, No Risk**: The one thing we don’t clone? Users. That means you can break things to your heart’s content without fear of angry tweets or support tickets.

With Upsun, you get the speed of testing in production without the risk.

This ability to replicate production environments has profound implications for development workflows. By eliminating the barriers between testing and deployment, Upsun empowers teams to iterate faster, deploy more confidently, and innovate without hesitation.

## Real Stories, Real Impact

Let me share a quick story from SymfonyCon. During a live demo, my colleagues turned a monolithic app into a decoupled app (Next.js frontend with a Symfony backend) all within 30 minutes. How did they do it?  By breaking things fast.  Like any live demo, they had their code all lined up and perfectly running before the event.  But like any live demo, everything fell apart right in the middle of the demo.  Every time they tried to deploy the app, they came up with a different error.  In the span of 30 minutes they tried iteration after iteration after iteration in front of a live audience.  The culprit? A single-character in a YAML file. (Turns out “npm” isn’t the same as “npx.” Who knew?)

Now, imagine trying to do that in a traditional setup. One developer told me it used to take them three weeks to spin up a dev environment. By the time they got everything configured, the data was already out of date. With Upsun, those three weeks become three minutes.

## The Upsun Workflow: Iterate, Iterate, Iterate

Here’s what a typical workflow looks like with Upsun:

1.  Create a branch and instantly clone production.
2.  Make your changes—whether it’s tweaking code, updating APIs, or testing new database configurations.
3.  Iterate until it works.
4.  Merge your branch and promote the environment to production.

It’s fast, it’s seamless, and it’s developer-friendly. No more waiting for Ops. No more guessing if your changes will break in production. You’re free to innovate at the speed of thought.

The beauty of this approach lies in its simplicity. By removing the friction from testing, Upsun enables developers to focus on what they do best: creating solutions that drive value for their users. It’s a game-changer for teams looking to stay competitive in an increasingly fast-paced world.

## Why Breaking Things Fast Matters

At the end of the day, breaking things fast isn’t just about efficiency; it’s about creating a culture where developers can experiment, fail, and learn without fear. Testing should empower you to build better software, not slow you down. With Upsun, you’re not just testing faster; you’re building a better future—one broken thing at a time.

Imagine a world where testing isn’t a burden but a source of inspiration, where teams work collaboratively to push boundaries and uncover possibilities. That’s the world Upsun is helping to create, and it starts with you.

In fact, studies show that identifying and resolving bugs earlier in the development cycle can increase customer satisfaction by up to 40%. Fewer bugs mean smoother user experiences, higher retention rates, and glowing reviews. By prioritizing efficient testing, you’re not just building better software; you’re building stronger relationships with your users.

Ready to move fast and break things? Let’s get started.

### Watch this video

### [PHP 8.0 attributes: a game changer for developers | Upsun](https://upsun.com/blog/php-8-0-attributes/)

# PHP 8.0 feature focus: Attributes

## A history of change

Some PHP changes are proposed, discussed, implemented, and approved in short order. They're uncontroversial, popular, and have a natural way to implement them.

And then there are the ones that are tried, fail, and come back multiple times before they are finally accepted. Sometimes the implementation takes a long time to sort out, sometimes the idea itself is only half-baked, and sometimes the community just hasn't warmed up to an idea yet—"it's not yet time."

Attributes fall squarely into the latter category. They were first proposed back in 2016, for PHP 7.1, but met with stubborn resistance and soundly lost the acceptance vote. Fast forward four years and a very similar if slightly reduced-scope proposal sailed through with only one dissenter. It's apparently an idea whose time has indeed come.

## Getting meta

So what are attributes? Attributes are declarative metadata that can be attached to other parts of the language and then analyzed at runtime to control behavior.

If you've ever used Doctrine Annotations, attributes are essentially that, but as a first-class citizen in the language syntax. The terms "attributes" and "annotations" are used roughly interchangeably in the various languages that support them. PHP went with the term "attribute" specifically to reduce confusion with Doctrine Annotations, since they have a different syntax. Because attributes are built into the language, though, rather than being simply a user-space documentation convention, they can be linted and type-checked by static analyzers, IDEs, and syntax highlighters.

The specific syntax was the subject of far more debate than the feature itself, but I'm going to skip over all of that and just look at the final result with an example of PHP attributes. Attributes in PHP 8.0 borrow their syntax from Rust:

```php
<?php

#[GreedyLoad]
class Product
{

    #[Positive]
    protected int $id;

    #[Admin]
    public function refillStock(int $quantity): bool
    {
        // ...
    }
}
```

Those various #\[...\] blocks are attributes. At runtime, they do ... absolutely nothing. They have no impact on the code itself. However, they are available to the reflection API, which allows other code to examine the Product class, or its properties and methods, and take additional action. What that action is, well, that's up to you as you can customize them to your needs.

As a side effect, attributes are interpreted as comments in older PHP versions and thus ignored, if they're single-line. That's more a useful side effect than a deliberate feature, but is worth noting. It's probably rendering as a comment in your browser, too. It will take a little while for syntax highlighters and IDEs to catch up, but expect that to happen soon enough.

An important note about attributes is that they're not limited to strings. In fact, in the overwhelming majority of cases they will be objects, which can take parameters.

PHP custom attributes can be attached to classes, properties, methods, functions, class constants, and even to function/method parameters. That's even more places than Doctrine annotations.

## A practical example

All of this seems rather abstract, so let's take a practical example of PHP attributes. Most use cases of attributes/annotations in PHP today revolve around registration. That is, they're a declarative way to tell one system details of another system, such as a plugin or event system. To that end, I have updated my PSR-14 Event Dispatcher implementation, Tukio, to support attributes. Here's how it works (somewhat simplified).

Tukio provides a "listener provider" that aggregates and orders "listeners," that is, any type of callable to which an event can be passed. Normally, you can register a listener like so:

```php
<?php

function my_listener(MyEventType $event): void { ... }

$provider = new OrderedListenerProvider();

$provider->addListener('my_listener', 5, 'listener_a', MyEventType::class);
```

Those parameters are the callable to add (in this case the function name) and then optionally a priority for ordering, a custom ID, and the type of event to listen to. The latter two are generally derived automatically, but I'm including them here to demonstrate that you can specify them on the fly. There are also methods to add listeners before or after another listener, based on its ID.

Specifying all of those on the fly is a pain, though. It would be especially nice to specify the ID along with the listener, for instance, so it's consistent. Attributes allow us to do that.

First, we define our new attribute. Attributes are a normal PHP class that themselves have a special attribute:

```php
<?php

namespace Crell\Tukio;

use \Attribute;

#[Attribute]
class Listener implements ListenerAttribute
{
   public function __construct(
       public ?string $id = null,
       public ?string $type = null,
   ) {}
}
```

The #\[Attribute\] attribute tells PHP "yes, this class can be loaded as an attribute." Also note that, as attribute is itself a class, it is subject to namespace rules and needs to be used at the top of the file.

The class then also defines a constructor ... using the new constructor promotion syntax. This is strictly an internal data class, so we'll just give it two optional public properties that are populated from the constructor. (In PHP 7.4, the same code would be twice as long.)

Let's go a step further; it doesn't make any sense to put a Listener attribute on a parameter or a class, just on functions and methods. We can therefore tell the class that it's a valid attribute only on functions and methods, using a series of bit flags:

```php
<?php

namespace Crell\Tukio;

use \Attribute;

#[Attribute(Attribute::TARGET_FUNCTION | Attribute::TARGET_METHOD)]
class Listener implements ListenerAttribute
{
   public function __construct(
       public ?string $id = null,
       public ?string $type = null,
   ) {}
}
```

Now, if we try to put a Listener attribute on a not-function, not-method, it will throw an error when we try to use it.

That also suggests how we'll use the Listener attribute to pass in parameters.

```php
<?php

use Crell\Tukio\Listener;

#[Listener('listener_a')]
function my_listener(MyEventType $event): void { ... }

$provider = new OrderedListenerProvider();

$provider->addListener('my_listener', 5);
```

By itself that does nothing. But once given the name of the function, we can use the reflection API to pull out that information. A (very) simplified version of what Tukio does here is:

```php
<?php

Use Crell\Tukio\Listener;

/// A string means it's a function name, so reflect on it as a function.
if (is_string($listener)) {
    $ref = new \ReflectionFunction($listener);
    $attribs = $ref->getAttributes(Listener::class, \ReflectionAttribute::IS_INSTANCEOF);
    $attributes = array_map(fn(\ReflectionAttribute $attrib) => $attrib->newInstance(), $attribs);
}
```

In this PHP attributes example, $attribs is an array of \\ReflectionAttribute objects. There are a few things you can do with one of those. In particular, the attribute doesn't _have_ to be a class! You can get just the name and arguments (if any) as a string and array, respectively. That can be helpful for static analysis or for simple flag attributes whose existence already tells you everything you need to know.

The getAttributes() method can also filter the attributes on a value for you. In this case, we're limiting it to only return Listener attributes and to allow subclasses of Listener to be included as well. While optional, I strongly recommend doing both as it naturally filters out attributes from other libraries you may not expect, and allowing subclasses or implements means you can cluster a series of attributes together using an interface.

The last line maps over that array and calls newInstance() on each attribute. That directly calls the Listener constructor with the parameters specified, then returns the result. The object that comes back is identical to what you would get had you just written new Listener('listener\_a'). Beyond that constructor call the attribute class can do or have anything any other class can do or have. You could give it complex internal logic or not, handle default values, make certain parameters required, etc., as your situation requires.

Now, Tukio can combine the data from the addListener() method call and the Listener attribute however it wants. In this case, the effect is the same as if you had specified the ID in the method call rather than in the attribute.

A single language item can be tagged with multiple attributes, even attributes from entirely different libraries. Attributes can also allow themselves to be repeated on a single language item or not. Sometimes it may make sense to allow the same attribute twice, other times not. Both can be enforced.

There's a lot more that you can do, and Tukio actually has multiple attributes it supports for different use cases and situations that I won't go into here for brevity, but that should give you a taste of what's possible.

## Coming soon to a framework near you

Attribute support is already appearing in frameworks. The upcoming Symfony 5.2 is going to include attribute versions of route definition, for instance. That means you'll be able to declare a controller and wire it up to a route like so:

```php
<?php

use Symfony\Component\Routing\Annotation\Route;

class SomeController
{
    #[Route('/path', 'action_name')]
    public function someAction()
    {
        // ...
    }
}
```

For the most part, that's just swapping Doctrine annotations syntax for native attributes to achieve the same goal. However, it's also going a step further. You can even control what dependencies get passed to your controller parameters via attributes on the parameters, something Doctrine couldn't do.

```php
<?php

namespace App\Controller;

use App\Entity\MyUser;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\Security\Http\Attribute\CurrentUser;

class SomeController extends AbstractController
{
    public function index(#[CurrentUser] MyUser $user)
    {
        // ...
    }
}
```

That tells the argument resolvers to pass the current user, specifically, to the $user parameter.

No doubt we'll see more use of attributes in other frameworks and libraries as well now that it has first-class native support in the language.

## Promoted arguments

It's also important to note how attributes work on promoted constructor arguments. Recall that in PHP 8.0, it's now possible to specify an object property and constructor argument at the same time when one just maps to the other, like so:

```php
<?php

class Point
{
    public function __construct(public int $x, public int $y) {}
}
```

Both arguments and properties can have attributes, however. So in this example, does the attribute refer to the argument or the property?

```php
<?php

class Point
{
    public function __construct(
        #[Positive]
        public int $x,
        #[Positive]
        public int $y,
    ) {}
}
```

Technically it could be either, but it may not always make sense for one or the other. The engine can't know which one it's supposed to be.

For 8.0, the decision was to do both. The attribute will be available on both the property and the argument. If that doesn't make sense for your application, either filter it out in your own application logic or don't use constructor promotion for that one parameter, so you can attribute it in just one place and not the other.

## Native attributes

In 8.0, there are no attributes that mean anything to the PHP engine, aside from the \\Attribute class itself. However, it's unlikely to stay that way. The RFC called out several possible future attributes that could have meaning to the engine in the future.

For example, a #\[Memoize\] attribute could tell the engine that a function or method is safe to cache, and the engine could then automatically cache the results of that function. Another option would be a #\[Jit\] attribute that could provide hints to the JIT engine that a given function or class is a good or bad candidate for JIT compilation or tweak how it gets compiled. Perhaps even an #\[Inline\] attribute that could tell the compiler it should try to inline a function call, thus saving time on the call itself.

None of these engine attributes exist yet, but they're the sort of ideas that are now available to engine developers to further enhance the language in future versions.

## A long list of credits

Attributes were developed and modified over the course of a couple of RFCs.

The original RFC comes courtesy of Benjamin Eberlei and Martin Schröder and used a different syntax borrowed from older versions of Hack. A follow-up RFC from the same people tweaked the features a bit.

The syntax was changed twice after that, in RFCs from Theodore Brown and Martin Schröder and then from Derick Rethans and Benjamin Eberlei to settle on the final syntax.

## Stay tuned

Next week we'll cover the last of the big-three features that will change the PHP world in 8.0. Just as a teaser, the Symfony samples above I modified from the announcement blog post. The actual syntax they show looks like this:

```php
<?php

class SomeController
{
    #[Route('/path', name: 'action')]
    public function someAction()
    {
        // ...
    }
}
```

What's going on there in that attribute? Stay tuned …

### [PHP match() expressions: cleaner branching logic in PHP 8](https://upsun.com/blog/php-8-0-match-expressions/)

# PHP 8.0 match() expressions

_In our_ _last episode__, we discussed coming improvements to PHP's type system. Today we look at a new construct that makes branching logic more powerful._

PHP has had a `switch` statement since the dawn of time, modeled on the same construct in C. You've surely seen it before:

```php
<?php
switch ($var) {
    case 'a':
        $message = "The variable was a.";
        break;
    case 'b':
        $message = "The variable was c.";
        break;
    case 'c':
        $message = "The variable was c.";
        break;
    default:
        $message = "The variable was something else.";
        break;
}

print $message;
```

While it gets the job done, the classic switch has a number of limitations. Most newer languages like Go or Rust have opted for more robust, less error-prone structures that go by a variety of names. And now, PHP has one, too.

Enter the PHP `match` function. Unlike `switch`, PHP `match` is an expression. That means it evaluates to a value, like so:

```php
<?php
$message = match($var) {
    'a' => 'The variable was a',
    'b' => 'The variable was b',
    'c' => 'The variable was c',
    default => 'The variable was something else',
};

print $message;
```

There are several things to point out here:

1.  With `switch`, each `case` is compared with loose equality `==`. With PHP `match`, each branch is compared with strict equality, `===`. That means the types must match, too.
2.  Each branch of the `match` is a single expression only. No multi-line statements, just a single expression that gets evaluated. If you need complex logic, make it a function or method that you call.
3.  There is no fall-through from one branch to the next, so there's no need for a `break`.
4.  `match` returns a value. That's its whole reason to exist.
5.  Because it's an expression, a closing `;` is needed at the very end, just like with closure definitions.
6.  `match` is exhaustive. If `$var` is not `===` any of the provided values and there is no `default`, an error will be thrown.

`match` branches can also be compound and comma-delimited for "OR" like behavior, like so:

```php
<?php
echo match($operator) {
    '+', '-', '*', '/' => 'Basic arithmetic',
    '%' => 'Modulus',
    '!' => 'Negation',
};
```

PHP `match` was pitched as a modernized, more useful `switch`, but I am not sure that's accurate. Rather, I think of `match` as a more powerful ternary.

In the past, I've often found myself in binary cases where a variable can be assigned to one of two values depending on some condition. The easiest way to write that, I've found, is like this:

```php
<?php
$display = $user->isAdmin()
    ? $user->name() . ' (admin)'
    : $user->name() . ' (muggle)'
;
```

That's completely valid code and quite useful. If the logic in the condition or in either of the branches is too complex to be easily readable, that's a hint the logic should be refactored out to its own function or method. I've found that to be a really good heuristic for situations like this, as well as leading to very readable, compact, and testable code.

That only works for `true`/`false`, however. `match`, in contrast, works for any number of options but has the same incentives to nudge you toward well-factored, clean code.

If you need more complex conditions than simple identity, you can use `match` on `true`:

```php
<?php
$count = get_count();
$size = match(true) {
    $count > 0 && $count <=10 => 'small',
    $count <=50 => 'medium',
    $count >50 => 'huge',
};
```

Note that since there is no `default`, a non-match (in this case if `$count` is 0 or negative) will result in a thrown error rather than silently assigning to null and moving on. That's good, because errors can't propagate to pollute later code.

The match expression RFC comes to us courtesy of Ilija Tovilo.

### [App hosting explained: how to choose the right solution](https://upsun.com/blog/application-hosting/)

# Understanding app hosting

### **How app hosting works: a brief overview**

Developing apps takes a lot of blood, sweat, and tears. It can feel like a marathon that doesn’t even have the courtesy to end once you cross the finish line.  

From managing infrastructure to scaling, operations, and security (to name just a few things), it takes plenty of work to ensure that your cherished creation is loved by users and customers.  

App hosting takes much of this responsibility off your shoulders, and a solid Platform as a Service (PaaS) provider can go even further.

In this article, we’re going to look at what cloud app hosting is and explore the main considerations to bear in mind when choosing a service provider.

### **Hosting applications in the cloud**

When you use an app hosting provider, you’re outsourcing part of that application’s infrastructure to a third party that will let you build, run and support it in the cloud. Hosting applications in this way offers several benefits.  

First and foremost, it can save you money. You don’t need to pay for any hardware, on-premise servers, software, or infrastructure—nor do you need to pay anyone to take care of any of this for you. Moreover, choosing a provider that offers reliable scaling means you only pay for the resources you need while ensuring your app can handle any unexpected surges.

Cloud app hosting ensures that your app is constantly available and that downtime is minimal. As mentioned earlier, the best providers implement systems to manage traffic spikes or increased demand effectively, preventing any disruption or outages. 

You can also be assured of the most vigorous security measures. Reputable app hosting providers will meet the highest compliance standards and take data protection and security deadly seriously.

### **Key considerations when hosting high-performance applications**

Hosting an app doesn’t have to be complicated—but it does require careful thought and planning.  

For example, do you have a step-by-step process in place for your app’s deployment? Is greener hosting one of your considerations? 

There are several crucial considerations to take into account.

### **Is application performance monitoring needed?**

It’s a sound strategy to keep a constant eye on your hosted apps.   

Picking a provider which offers 24/7 application performance monitoring is like having a doctor in the room with you at all times. If anything goes wrong, you’ve got an expert right at your side who can spring into action and keep your application’s infrastructure nice and healthy.   

Upsun tracks available disk space, memory and disk usage, and several other metrics.

### **Are there any restrictions on programming languages?**

You’ve worked hard to develop your app, and you’ve found a hosting service that supports your core development language. Therefore, the choice should be easy, right?

Well, it might seem like a sure thing to simply place your creation in the hands of a provider that speaks your language, but ask yourself if they can keep up with you if you decide to broaden your horizons.  

What happens when you need a new language or framework added to your company’s app ecosystem? Will your chosen hosting provider be as flexible as you need it to be?

Perhaps the easiest thing to do would be to pick a provider proficient in various frameworks and programming languages. You can even deploy API platforms on Upsun.

### **What do the security measures look like?**

It’s no good creating a shiny new app and then leaving the front door open. Ensuring your creation is safe from any threats or malicious outsiders is critical.

A good app hosting or PaaS provider should reassure you that your applications are protected from cyberattacks. Upsun makes it possible to keep your application layer up to date, removing the headache of security updates and allowing you to focus on the more important things while your app remains safe, secure, and available.  

Moreover, we’re committed to data security and compliant with European GDPR (DPA available), German BDSG (DPA available), Canadian PIPEDA, and the Australian Privacy Act. We've undergone an annual SOC 2 Type 2 examination over Security, Privacy and Availability, and have achieved PCI DSS Level 1 compliance for our platform hosted on Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). 

### **How good is the technical support?**

All software developers know that things go wrong sometimes (it doesn’t happen that often, right?). A blip now and then is unavoidable, so it’s vital to ensure you’ve got solid technical support at your disposal.

Hosting service providers should have support teams available at all times. Having your hosted app go down in the middle of the night but only finding out about it over your morning Corn Flakes is not ideal. Having 24/7 support also ensures you can travel anywhere in the world and get the assistance you need when you need it, regardless of time zones or office hours.

Make sure you pick a service with drilled procedures in place so that when a problem arises, the reaction is almost instant.

### **How scalable is the solution?**

We know. We’ve touched on scalability already, but the importance of choosing a hosting provider that can scale to your needs cannot be overstated.

A managed hosting alternative like Upsun is ideal for app developers looking for a scalable solution. Our observability suite means your app or site is monitored for traffic spikes and will be automatically scaled up to the next largest size if your existing resources start to struggle.  

The last thing you want is for your site or app to go down when Christmas or Black Friday rolls around, so pick a solution that allows you to scale with these fluctuations rather than dread them.

## **Upsun: app hosting with a robust multi-cloud PaaS** 

One of the best types of app hosting services is a PaaS. That’s because having a hosting environment already built for you allows you to skip a lot of the foundational work and jump straight to creating your dream apps on an existing and proven platform.

PaaS options are also highly flexible, and since flexibility ranks near the top when it comes to best practices in deploying web apps, this makes them an attractive proposition.  

It’s no secret that Upsun is a cloud application platform. In fact, we’re one of the most user-friendly application hosting services, which makes us perfect for both experienced and first-time users. Plus, we’re secure and feature-rich, ensuring your bases are all covered.

### [Efficient LLM deployment strategies | Upsun](https://upsun.com/blog/llm-deployment-strategies/)

# AI deployment strategies: balancing efficiency and environmental impact

### **Video transcript**

So, the actual title of the talk is "LLM Deployment Strategies: Balancing Efficiency and Environmental Impact." I know—nobody really wants to hear "the environmental talk." But don’t worry, this is going to be a feel-good talk. Here’s a kitten! It only costs about 30 grams of CO₂ emissions to create. And if I’m getting this right, the CO₂ emissions from all LLM applications on Earth currently amount to less than 0.0274% of global emissions. That’s really not much.

In fact, we should give ourselves a pat on the back. The CO₂ emissions from LLMs are probably less than 0.03 megatons per day—barely 11 megatons a year. As an industry, we actually started caring. We got better. I can’t see you all, but show of hands—how many of you know if your company has a climate pledge or is carbon neutral? A few of you, maybe?

The thing is, while we’ve gotten better, we still have a long way to go. We’ve started burning coal again like there’s no tomorrow, which ironically leads to there being no tomorrow. Every ton of CO₂ emitted stays in the atmosphere—it’s just thermodynamics; you can’t argue with science.

This isn’t about being a tech optimist or a progressive. Science doesn’t work like that. CO₂ doesn’t just go away. Right now, LLM emissions are about ten times what bombs emit. And bombs are, well, not great—some people disagree, but we’ll leave it at that. And it doesn’t really matter if you’re sitting next to a hydroelectric plant or not. Most of the emissions are embedded in the processes we use.

So, let’s take a look at the scale here. About two million H100s were sold this year, along with a few Grace Hopper supercomputers, each machine consuming around 700 watts. With roughly 56,000 watts per machine and a power usage effectiveness (PUE) factor, we’re looking at about 12 megatons added to emissions this year alone. And that’s on top of the 11 megatons I just mentioned.

We’re more than doubling our emissions annually, which means, if we keep up this trajectory, we’re looking at around half a gigaton of emissions in the next five years. For context, the world emits about 40 gigatons a year right now. This trend is not sustainable, and it’s clear on the graphs.

Commercial Break! This talk is sponsored by Reality and Wily. So, I actually licensed a cartoon for this presentation—it cost me 40 bucks. And yes, I also pay for a couple of LLM subscriptions, like ChatGPT and Claude from Anthropic, costing around 40 bucks a month. It’s all-you-can-eat, so I could technically ask them to generate a similar cartoon for free, but it wouldn’t be quite the same.

But hey, I did the math, and the CO₂ compensation we’d need for this 12-megaton footprint would cost about 0.7 billion dollars—a number that sounds like “chump change” for some in this industry. The largest direct air capture facility on Earth, located in Orca, Iceland, only manages 4,000 tons of CO₂ per year. Compare that to 12 megatons, and, well, you get the picture.

All right, can I stop yelling about CO₂ for a moment and dive into the technical part? Almost, I promise! Being the scientific, technical person I am, I asked a few LLMs how much CO₂ they generated to answer the question of how much CO₂ they generate. And, of course, they didn’t give me any answers. Reinforcement learning through marketing feedback—RLFM—is what I call it. It’s not about alignment; it’s more about sidestepping. They’re basically trained to avoid talking about their carbon footprint.

Just try it—ask Gemini or another LLM how much CO₂ they emit. They’ll send you to a nice blog post, assuring you that no CO₂ is emitted, at least according to them. But let’s get technical. You need a graph in this kind of talk, right? So, I set up a basic graph with "Predictability to Risk" on one axis and "Legacy to Innovation" on the other. This graph can represent LLM deployment strategies quite effectively.

In terms of machine learning model deployment, we’re talking about everything from simple SQL queries to training our own foundational models. And, for the most part, these applications are about information retrieval: you have some data, you want to ask questions, and you want answers. The beauty of this kind of graph is that you can switch the axis labels, and the dots on it would still make sense.

We can label the x-axis as "Measured in milliseconds" versus "Measured in months" or “Working software” versus “Hardware working really hard.” Or, to put it more bluntly, “I care” versus “I don’t care” about global warming. One of the most interesting dimensions we could label is money. Running SQL is cheap; we’ve been doing it for years. Running your own GPUs, however, costs a fortune.

So, let’s talk about the trade-offs here. As software engineers, you know that everything comes down to trade-offs—optimizing one quality of the system often means sacrificing another. Take training LLMs, for example. It’s a complex process that can fail spectacularly, leaving us with an overfitted model that generalizes poorly. The bad news is, in that case, we don’t get any compression or true learning—what we end up with is essentially a database.

And sure, you could use an overfitted LLM as a kind of database. Say you’ve fine-tuned it to know your customer’s first name. Is it efficient for that? Maybe—for the developer who doesn’t need to request a new datastore from DevOps or a new column in the database. But it adds latency. Every query might take months of extra processing time because it’s not running through an L1 or L2 cache. It could even retrieve incorrect data.

We’ve all been there, though. Back in the day, we used Oracle for everything. Now, we might put data in a Docker layer file and hope for the best. If your only tool is a neural network, then yes, maybe your PyTorch file ends up being your database. It happens, even in production.

When issues arise, we lean on prompt engineering. We try to filter out things the model shouldn’t show, hoping it’ll work fine even if we update the model or switch vendors. This is just a new kind of technical debt—our industry’s latest invention. And let’s be real, there’s a tragic irony to this approach: if you expose an LLM to user input without validation, you’re essentially setting yourself up for disaster.

And it’s not just our input. The whole world’s data becomes the user input for LLMs, meaning we have limited control. Retrieval-Augmented Generation (RAG) doesn’t change that reality much. It’s just another layer on top, another “friendly” abstraction. So, when you’re using embeddings from a big model, remember: it’s not a straightforward representation of the latent layers. These embeddings carry tons of semantic information that can often be used effectively within your vector store.

Using a vector store effectively could save you a significant amount of resources. Many tasks could be accomplished with simple distance queries on data you already have in your vector database. This approach is much cheaper, but here’s the thing: the money will run out eventually. What we’re currently doing—calling massive models hosted on top-of-the-line hardware like Grace Hoppers—won’t be financially viable in the next five years. The science doesn’t support that we’ll suddenly make these processes affordable.

So, what are the green parts of this equation? They represent things we know how to do without GPUs, tasks that can run on CPUs. CPU utilization is well-understood, predictable, and stable. But GPU utilization? That’s still a mystery to most of us.

Your job is to figure out these trade-offs. Yes, it’s more code to write, and yes, it might not be as glamorous as using the latest, cutting-edge features. But what you get in return is a more stable, economical system. Every time you run an uncached query rather than hitting an LLM, you’re saving resources. Think of it this way: every time you rely on an LLM for a query, a kitten metaphorically “dies.” Use the tools you already have—like PostgreSQL and PG Vector—to save the kittens. This isn’t about blaming some mysterious “them”; this is about us, and our decisions.

Thank you all, I’m Ori. Take care!

#### Useful links

-   SaaS startup Witty Works delivers AI-augmented DEI solution at scale
-   PaaS vs IaaS: lower carbon emissions for your applications
-   Upsun is using annual carbon intensities from Electricity Maps

### [File integrity monitoring: how to strengthen data security](https://upsun.com/blog/enhancing-data-security-with-file-integrity-monitoring/)

# Enhancing data security with file integrity monitoring

## Leveraging Watchdog for compliance and risk mitigation

Organizations remain compliant so long as they are able to, among other required things, consistently demonstrate proper handling of customers’ personally identifiable information (PII). One facet of this strategy involves how the integrity of files containing PII within a user-facing application is managed and ensured. 

File integrity monitoring (FIM) is a strategy put in place to enable and define alerting mechanisms that notify security teams when the state of users’ data is at risk and a cyber attack may be occurring. 

### File integrity on Upsun

Upsun (and Platform.sh, for that matter), is built on a strong separation between code and data. Our platform is built on Git, and that creates a relationship for your organization between what is committed to a repository and how that code results in provisioned infrastructure, active environments, and what is ultimately served to your users. 

We tie individual commits – the state of your code and configuration – to unique build images. While these images can be moved between environments, resulting in our central environment cloning capabilities, they cannot be modified once deployed at runtime in any way. 

This feature is made possible through the short list of rules placed upon your projects, which include:

-   Changes to infrastructure must be made via commits
-   Access, whether to projects, environments, applications, services or to the outside world must always be explicitly defined
-   Data and code are different. Code, infrastructure, and configuration should be committed, while data never should be.
-   Read-only access to the filesystem remains at runtime unless explicitly defined otherwise
-   Data flows down to child environments

So long as your projects and team members abide by these tenets, things committed to Git (including infrastructure) should be protected. 

The attack surface is not eliminated completely, however, when we stop to consider your application itself and the things you control. It’s necessary, for instance, that you sanitize user-facing fields and validate inputs in your app to prevent SQL injections and other methods that would allow bad actors to execute arbitrary code that would put PII at risk.

### Watchdog

Protection in this way is only one half of the puzzle of FIM, but even best practices cannot completely ensure that PII will never be exposed and/or altered. For the things we cannot expect, we need monitoring in place that triggers notifications when changes happen to files kept in mounts. 

Notifications allow us to not only respond to attacks that are underway, but also for us to fulfill certain reporting that may be required in order to remain compliant in the event of a breach. 

While such a notification system does not exist out of the box on Upsun, we can put together something using open-source tooling that monitors changes to our directories to build out such a notification strategy. 

Watchdog is an open-source Python library and shell tool for monitoring file system events. We can use Watchdog on top of our access control best practices to set up a notification system to watch for filesystem changes.

Below is a simple app, which in effect contains no code save what is relevant to configure the infrastructure to setup a Watchdog worker to listen to filesystem changes made to a single mount.

```shell-session
mkdir notify && cd notify && git init
upsun project:create

...

touch .upsun/config.yaml
```

Update the Upsun configuration for the worker:

```shell-session
applications:
  notify:
    # This example uses the Composable image for Python, thought simply
    # `type:'python:3.12'` would work just fine as well
    stack:
      - python@3.12
      - python312Packages.pip
    hooks:
      build: |
        set -e
        pip install -r requirements.txt
    # Some best practices for reference
    access:
      ssh: admin
    web:
      commands:
        start: sleep infinity
    # Our mount containing sensitive data.
    mounts:
      user_pii:
        source: storage
```

This configuration sets up a single Python 3.12 container with a single writable directory containing our sensitive user data (`user_pii`). Next, we install Watchdog through a virtual environment

```shell-session
python3 -m venv env
env/bin/activate
(env) pip install watchdog requests
(env) pip freeze > requirements.txt
(env) deactivate
echo "env" > .gitignore
```

Then produce the notifier script that will be run from our worker container:

```shell-session
# https://github.com/gorakhargosh/watchdog
# https://pypi.org/project/requests/
# https://philipkiely.com/code/python_watchdog.html

import os
import sys
import time
import datetime
import requests
import logging
from watchdog.observers import Observer
from watchdog.events import FileSystemEventHandler

class Watcher:

    def __init__(self, directory=".", handler=FileSystemEventHandler()):
        self.observer = Observer()
        self.handler = handler
        self.directory = directory

    def run(self):
        self.observer.schedule(
            self.handler, self.directory, recursive=True)
        self.observer.start()
        print("\nWatcher Running in {}/\n".format(self.directory))
        try:
            while True:
                time.sleep(1)
        except:
            self.observer.stop()
        self.observer.join()
        print("\nWatcher Terminated\n")

class MyHandler(FileSystemEventHandler):

    webhook_url = "https://webhook.site/3cbc9b0d-d2c1-4b95-8576-1e3070f704cd"

    if os.environ.get("WATCH_WEBHOOK_URL") is not None:
        webhook_url = os.environ["WATCH_WEBHOOK_URL"]

    logging.basicConfig(level=logging.INFO,
                    format='%(asctime)s - %(message)s',
                    datefmt='%Y-%m-%d %H:%M:%S')

    def on_any_event(self, event):
        if not event.is_directory:
            event_data = {
                "src_path": event.src_path,
                "dest_path": event.dest_path,
                "event_type": event.event_type,
                "is_directory": event.is_directory,
                "is_synthetic": event.is_synthetic,
                "timestamp": datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S%z")
            }
            logging.info(f'{event.event_type.upper()!r}: {event_data!r}')
            resp = requests.post(self.webhook_url, json = event_data)
            alert_data = {
                "status_code": resp.status_code,
                "url": resp.url
            }
            logging.info(f'{"FORWARDED".upper()!r}: {alert_data!r}')

if __name__=="__main__":
    watchpath = sys.argv[1] if len(sys.argv) > 1 else '.'
    w = Watcher(watchpath, MyHandler())
    w.run()
```

In the above script notice that:

-   A `FileSystemEventHandler` class use used to define `MyHandler`, piped into the primary `Watcher` when the script is run
-   The `Watcher` monitors file system changes recursively a target provided that’s passed as a command line argument (`sys.argv`)
-   `MyHandler` listens for file system changes `on_an_event` and forwards an `event_data` JSON object to either a default webhook URL (in this case to a temporary webhook URL at Webhook.site), otherwise to a user-provided URL via the `WEBHOOK_URL` environment variable.

With the script in place, we can run it in parallel to the man application via a Worker:

```shell-session
    workers:
      watchdog:
        commands:
          start: |
            python watch.py $PLATFORM_APP_DIR/user_pii
```

Before we push, we can include a few (admin only!) runtime operations to test our changes:

```shell-session
    operations:
      init-secret:
        role: admin
        commands:
          start: |
            echo "Oceanic 815 SYD -> LAX, 13C; Status: DEPARTED" > \
              $PLATFORM_APP_DIR/user_pii/austen_kate.txt
      read-secret:
        role: admin
        commands:
          start: cat $PLATFORM_APP_DIR/user_pii/austen_kate.txt
      rewrite-secret:
        role: admin
        commands:
          start: >
            echo "Oceanic 815 SYD -> LAX, 13C; Status: LOST" > \
              $PLATFORM_APP_DIR/user_pii/austen_kate.txt
      destroy-secret:
        role: admin
        commands:
          start: rm $PLATFORM_APP_DIR/user_pii/austen_kate.txt
```

Finally, we commit and push all of our changes:

```shell-session
git add . && git commit -m "Create a simple notifier app."
git push upsun main
```

Once the app has deployed, we can leverage our runtime operations to make sure that file system events that change sensitive data in a mount result in notifications to our desired webhook URL. 

1\. Create a file

```shell-session
upsun operation:run init-secret -y
```

Indeed, the operation (creating the file `austen_kate.txt`) triggers four notifications (open, created, modified, closed):

2\. Update file

```shell-session
upsun operation:run rewrite-secret -y
```

Once again, the action (updating the file `austen_kate.txt`) results in three events (open, modify, close) that we can be alerted to.

3\. Read a file

```shell-session
upsun operation:run read-secret -y
```

We can likewise get notified of the two events (opened, `close_no_write`) that take place when a file containing sensitive data is read (`cat austen_kate.txt`),

4\. Delete a file

```shell-session
upsun operation:run destroy-secret -y
```

Finally, removing the file completely from the filesystem can trigger its own notification for the single deleted filesystem event.

Above is a very simple example of how open-source tools can be used to construct a custom notification system for FIM on Upsun. You could update the `WEBHOOK_URL` environment variable to use a Slack webhook URL in your organization’s security notifications channel, but as is that channel would be flooded with false positives. 

Hopefully, however, you can see how these basic tools could be adapted to listen to:

-   a subset of filesystem events
-   only those filesystem events executed by agents other than known admins or your application itself
-   details of what exactly has been changed to include in the forwarded message
-   links to the most recent backups in storage to shorten time to recovery

Modify this example to your needs, and never underestimate what can be built on an application platform with so few rules baked into it. Best of luck!

### [Debugging techniques for developers: practical guide](https://upsun.com/blog/debugging-techniques-for-developers/)

# Essential debugging techniques for developers: A complete guide

Got a bug that’s giving you trouble? Happens to all of us. Debugging’s just part of the job, whether you’re new to this or have been coding for years.  It’s like maintaining a car—catching issues early keeps everything running trouble-free. Understanding effective debugging strategies and debugging methods is essential for every developer.

In this guide, we’ll cover must-know debugging techniques that save time, reduce stress, and help you create more reliable code. Bugs can range from basic syntax errors to complex runtime issues, but the faster you catch them, the better your code will perform.

## What is debugging?

It’s going through your code, finding mistakes, and fixing bugs. It could be a simple typo (syntax error) or something bigger that causes crashes or weird behavior (runtime error). Minor glitch or full crash—the goal’s the same: keep things running. Debugging? Just finding out why things didn’t go as planned.

It’s key to keeping your program stable. Over time, developers have created powerful debugging strategies and debugging methods that make this process easier. In this guide, we’ll cover strategies to help you crush bugs faster and get your code back on track.

First up in fixing bugs is reproducing the issue. Let’s talk about why that matters and how it helps you nail down the root cause.

### 1\. Reproduce the issue

Start by making the bug happen again. If you can’t recreate it, fixing it gets a lot harder. When someone reports a problem—whether it’s a syntax error or one that only shows up in debug mode—gather as much info as you can. Once you can repeat the issue consistently, it’s way easier to track down what’s wrong using debugging tools or even basic print statements.

Once you’ve recreated the bug, dive into the code. This is where a debugger can really help. Let’s break down how to use it to figure out where things are going off track.

### 2\. Use a debugger

Most IDEs come with built-in debugging tools that let you control your code like a remote, pausing and stepping through it to find errors. Debuggers have features like:

-   **Step-by-step execution** (run your code line by line to see where it fails).
-   **Conditional breakpoints** (pause the code only when certain conditions are met).
-   **Inspecting variables** (check what’s stored in your variables).
-   **Debug console** (interact with the running code and get instant feedback).

Some advanced tools, like time-travel debugging (e.g., rr or UDB), let you step forward or backward in the code to see exactly where things broke. This is a game changer, especially in bigger systems like Java apps or multi-threaded environments where lots of things are happening at once.

### 3\. Print statements (the classic way)

There are plenty of debugging tools out there, but sometimes print debugging just works. Simple and effective. By adding `console.log` or `printf` statements, you can track how your program runs and catch hidden errors. 

But don’t overdo it—too many print statements can clutter your code. Once you’ve found the problem, be sure to clean them up.

### 4\. Divide and conquer

A big codebase can feel like a puzzle with too many pieces. Instead of dealing with it all at once, focus on smaller sections. This "divide and conquer" approach makes it easier to spot key issues, speeding up the debugging process.

Start by working on one part of the code at a time. This helps you narrow down where things are breaking and makes it less stressful.

Sometimes, though, you can’t find the bug just by splitting the code into sections. In those cases, backtracing—or working backward through the code—can help you spot where things started to go wrong.

### 5\. Backtracing (backward debugging)

**Backtracing** through the code can help you debug complex systems, especially when dealing with coding errors or unexpected error messages. This method involves starting at the point where the bug appears and working backward to find its root cause. It’s particularly useful when the issue seems disconnected from the source, as you can retrace the program’s behavior to find how the bug was triggered.

### 6\. Rubber duck debugging

Sometimes the best way to spot a bug is by explaining your code out loud—even if it’s just to a rubber duck. This “rubber duck debugging” walks you through each step, making you clarify what each part actually does.

It’s like you’re teaching someone how it works, and as you talk it through, you usually realize where things went wrong. It sounds goofy, but it forces you to slow down, think it over, and catch mistakes you’d probably miss just staring at the screen.

### 7\. Binary search debugging

When you don’t know where a bug is hiding, binary search debugging is a quick way to narrow it down. You drop breakpoints in the code or add print statements at key spots, then check the output to rule out big chunks of code that aren’t the problem. By eliminating error-free sections, you can focus on the areas most likely causing the issue.

This method works like the binary search algorithm, splitting the code into smaller sections and ruling them out step by step. It helps you zero in on the bug faster, making the whole debugging process more efficient and productive.

### 8\. Log analysis

When working on large-scale applications, you might not always be able to recreate every issue on your local machine. That’s where log analysis comes in. Logs are like your app’s diary, recording everything it’s doing behind the scenes, including performance issues like resource leaks or incorrect values that could cause problems. By going through these logs, you can figure out what went wrong, even if the issue is tough to recreate locally. 

Tools like the ELK Stack (Elasticsearch, Logstash, Kibana), Blackfire, and Graylog help you dig through those logs to find performance issues or bugs that might be hiding. Think of logs as your app whispering, “Here’s what I did, and here’s what went wrong.”

### 9\. Clustering bugs

In complex systems, grouping bugs by their symptoms can make debugging way easier. Bugs often share a common root cause, and fixing one can knock out several related ones. When developers cluster bugs based on similar behavior or the areas they affect, it’s like grouping symptoms that point to the same problem. Focusing on these clusters helps pinpoint the root cause faster than treating each bug as its own issue. It’s like fixing the leak instead of just mopping up the puddle.

This method is super helpful when dealing with lots of bugs, especially in systems with complex dependencies. Fixing one cluster can lead to major improvements across the software, even when the bugs seem unrelated at first.

### 10\. Take breaks

Debugging in code-heavy environments can be mentally exhausting. Regular breaks are key for staying sharp and solving problems faster. Stepping away for a few minutes lets your brain reset—you’ll often return with fresh insights. Breaks not only prevent burnout but also allow your mind to process things in the background, making tough bugs easier to crack when you return.

Many developers find that after a short break, the solution to tricky bugs suddenly clicks. Taking breaks keeps you productive, focused, and helps you get better results during those long debugging sessions.

### 11\. Version control reversion

Version control systems like Git are essential for debugging, letting developers quickly revert to stable versions of their code. Tools like `git bisect` automate finding the commit that introduced a bug. It tests commits between the current and a stable version, helping isolate the root cause efficiently. Using version control reversion streamlines code inspection, saving time and maintaining stability without manually digging through large codebases, reducing the risk of new issues.

### 12\. Automated testing

Automated testing is a vital part of preventing bugs and optimizing the debugging process. By using automated testing frameworks, you ensure your code performs as expected across multiple scenarios, catching issues early before they become major problems. Continuous testing with automated tools provides constant feedback, allowing bugs to be found and resolved much faster than with manual testing alone.

By detecting bugs early, automated testing reduces the need for extensive manual debugging and ensures higher software quality. This approach improves development efficiency, saves resources, and leads to faster, more stable software releases, making it an essential part of modern development practices.

### 13\. Learning from debugging sessions

Documenting your debugging process is a valuable habit that can save time and make future sessions easier. By writing down the steps you took and the solutions you found, you create a helpful guide for tackling similar issues down the road. This log keeps you from repeating mistakes and gives you a clear idea of what worked best.

As you build this habit, your records become a useful resource for speeding up your debugging sessions and handling problems more confidently. It’s a small effort that pays off big, making your workflow smoother and more efficient in the long run.

### 14\. Search for solutions online

Websites like StackOverflow and GitHub Issues are rich resources for debugging. Other developers have likely encountered the same bugs you're facing and have shared their solutions, saving you hours of trial and error. Searching these platforms gives you access to a vast pool of real-world answers and fixes, allowing you to resolve issues quickly and efficiently.

Beyond just solving your current problem, this approach also helps you learn new strategies and debugging techniques from experienced developers. Using the collective knowledge of the online community is one of the most effective ways to speed up your debugging process and broaden your skills.

### 15\. Using AI assistants

AI-powered tools like ChatGPT are quickly becoming essential in the debugging process. When you hit a tough bug, AI assistants can suggest code fixes or alternative ways to solve the issue. They analyze your code and provide potential solutions, saving time and offering new insights to help resolve tricky problems faster.

By offering fresh perspectives and quick fixes, AI assistants are a powerful addition to your debugging toolkit. As they evolve, they’re becoming crucial for developers wanting to streamline their debugging and solve problems more efficiently.

### 16\. Contacting support

When you're stuck with a complex issue, reaching out to the official support team for the software or platform you’re using is often the best way to get a quick solution. These teams have in-depth product knowledge and can provide guidance, especially for issues with poorly documented features or tricky configurations. Instead of troubleshooting on your own for too long, contacting support ensures accurate help, so you can get back to solving the problem efficiently.

### Wrapping up

Debugging isn’t just technical—it’s a problem-solving mindset. Whether you use high-tech tools or classic print statements, having a solid strategy is key. The techniques we’ve covered—from dividing and conquering to using AI assistants—are all meant to help you find bugs faster and with less frustration.

But debugging is only half the battle. At Upsun, we understand that a stable, efficient development environment is key to writing better code. Having preview environments that so closely match production simplifies your efforts employing many of the strategies outlined above in an isolated, production-like space. We offer a powerful PaaS solution with built-in tools to simplify debugging, improve collaboration, and speed up your entire workflow. With dynamic preview environments and top-tier observability, you can focus on fixing bugs without getting bogged down by infrastructure.

In the end, debugging is both a skill and a habit. By using these techniques and streamlining your development process, you’ll not only become more efficient—but also produce cleaner, more reliable code.

### Useful links

-   Troubleshoot development

### [Context engineering for AI-assisted development: why it matters](https://upsun.com/blog/context-engineering-ai-web-development/)

# Why web developers need to master context engineering for AI-assisted development

AI coding assistants are now everywhere in web development. GitHub Copilot has over 1.3 million paid subscribers, while tools like Cursor, Windsurf, and Claude Code are changing how developers write code. Yet many developers struggle to get consistent, high-quality results from these tools. The problem isn't the AI, it's how we interact with it.

Many software development teams are benchmarking AI tools and deciding not to adopt them. They expect AI to work like a smart developer who understands their codebase intuitively. When the AI produces generic code that doesn't match their patterns, generates bugs, or requires heavy modification, they conclude the technology isn't ready. **These teams have the wrong expectations.** They're evaluating AI assistants like human developers instead of understanding that AI needs comprehensive context to perform well.

**The key insight: Context engineering, alongside prompt engineering, determines AI assistant success.** 

As Andrej Karpathy explains, context engineering is the careful art and science of filling the context window with just the right information for the next step. For web developers, mastering this approach transforms AI from an unpredictable helper into a reliable development partner.

## The hidden problem with current AI development workflows

Most developers approach AI assistants like magic tools. You type "create a login page" and expect the AI to understand your specific needs. This approach yields inconsistent results because it misunderstands how modern AI works.

**AI models don't fail because they lack capability, they fail because they lack context.** When GitHub Copilot suggests irrelevant code or Claude generates components that don't match your architecture, the issue isn't model limitations. There is insufficient context available about your project structure, coding standards, existing patterns, and architectural decisions.

The difference becomes clear when you compare typical developer requests. A simple "create a login page" might generate generic HTML with inline styles, basic form validation, and no consideration for your existing authentication flow. But when the AI understands your project's authentication patterns, component library, form validation approach, and styling conventions, it generates a login page that integrates directly with your project. Complete with proper TypeScript interfaces, consistent error handling, and established design patterns.

## How context engineering transforms web development workflows

Context engineering changes how you structure information for AI systems. Instead of crafting perfect instructions, you design comprehensive information environments that set AI up for success.

### Code generation becomes architecture-aware

**Traditional approach:** Ask for a login form and receive generic HTML with inline styles.

**Context-engineered approach:** Provide your component library, form validation patterns, state management approach, and API integration standards. The AI generates a login form using your established patterns, proper TypeScript interfaces, appropriate error handling, and consistent styling.

**Real impact:** Developers report 60-80% reduction in manual code refactoring when AI understands project architecture upfront.

### Debugging shifts from symptom-chasing to system understanding

**Traditional approach:** Paste error messages and stack traces, hoping for quick fixes.

**Context-engineered approach:** Provide the AI with your application's data flow, component relationships, and system architecture alongside the error. The AI identifies root causes rather than surface symptoms.

**Case study:** A developer working on a Next.js e-commerce application was experiencing hydration errors. Traditional debugging involved hours of stack trace analysis. With proper context about the app's SSR configuration, state management approach, and component structure, Claude Code identified the issue in minutes: client-server state mismatch in the shopping cart component.

### Testing becomes comprehensive and consistent

**Traditional approach:** Generate individual test cases for isolated functions.

**Context-engineered approach:** Provide testing conventions, existing test patterns, mock strategies, and coverage requirements. The AI generates complete test suites that match your project's testing philosophy.

**Performance metrics:** Teams using context-aware testing report 40% faster test writing and 75% better test coverage consistency across team members.

## The technical foundation: Building context systems for development

Effective context engineering for web development requires systematic information architecture. The most successful implementations organize context into distinct layers.

**Project-level context** includes technology stack and framework versions, architectural patterns and design principles, code organization and naming conventions, development workflow and deployment processes.

**Feature-level context** covers related components and their interfaces, API endpoints and data models, state management patterns, user experience requirements.

**Task-level context** addresses specific implementation goals, acceptance criteria, performance requirements, browser compatibility needs.

Leading development teams implement this through structured approaches. The Context Engineering template on GitHub demonstrates a systematic method:

```shell-session
project/
├── .claude/
│   ├── commands/          # Custom AI commands
│   └── settings.json      # AI permissions and preferences
├── examples/              # Code examples (critical for patterns)
├── CLAUDE.md             # Project-wide AI guidelines
└── PRPs/                 # Product Requirements Prompts
    └── templates/
```

**The examples/ directory proves particularly crucial.** AI assistants perform dramatically better when they can see patterns to follow rather than creating from abstract descriptions.

## Real-world implementation strategies for web development teams

### Start with documentation-driven context

Begin by creating comprehensive project documentation that serves both human developers and AI assistants. Include technology decisions and rationales: Why you chose Next.js over Nuxt, TypeScript over JavaScript, Tailwind over styled-components. List libraries and extensions. Document architectural patterns: How you structure components, manage state, handle routing, and organize files. Establish code conventions: Naming patterns, formatting standards, comment styles, and error handling approaches. Create integration patterns: How you connect to APIs, handle authentication, manage environment variables, and deploy applications.

### Establish context templates for common tasks

Create reusable context templates for frequent development activities:

**Component Creation Template:**

```shell-session
# Component Requirements
- Technology: [React/Vue/Angular]
- Styling: [Tailwind/CSS Modules/Styled Components]  
- State Management: [Local/Redux/Zustand/Pinia]
- Form Handling: [React Hook Form/Formik/Native]
- Validation: [Zod/Yup/Joi]
- Testing: [Jest/Vitest + Testing Library]

# Existing Patterns
[Include similar components as examples]

# Integration Points  
[List related components, APIs, routes]
```

**API Integration Template:**

```shell-session
# API Context
- Base URL and authentication method
- Error handling patterns
- Request/response transformations
- Caching strategy
- Loading states management

# Related Code
[Include existing API utilities, types, hooks]
```

### Implement iterative context refinement

Context engineering isn't a one-time setup, it's an ongoing process of refinement based on AI output quality. Successful teams establish systematic feedback loops that continuously improve their context systems.

#### Monitor AI suggestion accuracy with specific metrics

Track quantifiable indicators of AI effectiveness. Code acceptance rate: Percentage of AI suggestions used without modification. Refactoring frequency: How often AI-generated code needs architectural changes. Bug introduction rate: Defects traced to AI-generated code. Integration time: Minutes spent adapting AI code to fit existing systems.

**Example tracking approach:**

```shell-session
Weekly Context Quality Report:
- Login components: 85% acceptance rate (up from 60% last week)
- API integrations: 70% acceptance rate (needs improvement)
- Testing code: 90% acceptance rate (excellent)
- Styling patterns: 40% acceptance rate (major context gap identified)
```

#### Identify context gaps through failure analysis

When AI produces suboptimal results, conduct structured analysis to identify missing context:

**Case Study - E-commerce Cart Component:** AI Output: Generated a cart component using Redux when the project uses Zustand Context Gap: Missing state management documentation in project context Root Cause: AI defaulted to more common Redux patterns from training data Solution: Added explicit Zustand examples and patterns to context templates

**Case Study - API Error Handling:** AI Output: Generated try-catch blocks instead of using project's error boundary pattern Context Gap: Missing error handling architecture documentation Root Cause: No examples of existing error handling patterns provided Solution: Added error boundary examples and centralized error handling documentation

#### Update context templates with proven patterns

Continuously evolve context based on successful interactions:

**Before refinement (generic context):**

```shell-session
# Form Component Requirements
- Use React Hook Form
- Include validation
- Handle submit
```

**After refinement (specific context):**

```shell-session
# Form Component Requirements
Technology Stack:
- React Hook Form v7.x with TypeScript
- Zod validation schemas (see /schemas for examples)
- React Query for mutations (see /hooks/useMutations.ts)

Patterns to Follow:
- Field wrapper component: FormField (see /components/ui/FormField.tsx)
- Error display: ErrorMessage component with toast fallback
- Loading states: Spinner in submit button, disabled fields
- Success handling: Toast notification + redirect via router.push

Examples:
- Contact form: /components/forms/ContactForm.tsx
- User profile: /components/forms/ProfileForm.tsx
- Payment form: /components/forms/PaymentForm.tsx (complex validation example)

Integration Requirements:
- Use useToast hook for notifications
- Follow /utils/validation.ts for custom validators
- Implement optimistic updates for better UX
```

#### Share learnings through documentation and team practices

Establish processes for knowledge transfer:

**Context Pattern Library:** Maintain a living document of successful context patterns. Authentication flows: Patterns that consistently generate correct auth code. Component architecture: Context that produces well-structured components. API integration: Templates that generate proper error handling and typing. Testing strategies: Context that creates comprehensive test coverage.

**Weekly Context Reviews:** Hold brief team meetings to discuss what context improvements led to better AI output this week, which areas still struggle with consistency, new patterns discovered through experimentation, updates needed to context templates.

#### Automate context quality measurement

Implement tooling to track context effectiveness:

**Git Hook Analysis:**

```shell-session
# Track AI-generated code modifications
git log --grep="AI:" --oneline | wc -l  # Count AI commits
git log --grep="fix AI" --oneline | wc -l  # Count AI fixes
```

Code Review Metrics: Tag AI-generated code in pull requests, track review feedback patterns, identify recurring AI mistakes, measure time-to-approval for AI vs. human code.

**Context Template Versioning:**

```shell-session
context-templates/
├── v1.0/
│   ├── component-context.md
│   └── api-context.md
├── v1.1/
│   ├── component-context.md  # Added TypeScript examples
│   └── api-context.md       # Added error handling patterns
└── changelog.md             # Track improvements and results
```

This iterative approach ensures your context engineering improves continuously, adapting to your team's specific needs and the evolving capabilities of AI tools.

## Building your own context framework for enterprise scale

Enterprise development teams can't rely on generic context templates or one-size-fits-all approaches. Large organizations have unique architectural patterns, security requirements, compliance standards, and business logic that simply don't exist in public examples or standard templates. Your context framework needs to reflect your specific reality.

Consider a financial services company building trading platforms. Their context framework must include regulatory compliance patterns, audit trail requirements, real-time data handling standards, and risk management protocols. No generic template covers these requirements. The AI needs to understand that certain types of data require encryption at rest, that all financial calculations need audit logs, and that performance requirements are measured in microseconds, not milliseconds.

Similarly, a healthcare technology company has HIPAA compliance patterns, patient data anonymization requirements, and medical device integration standards that are completely foreign to general web development. Their context framework must encode these domain-specific requirements so AI tools understand your organization's way of building software.

As an engineering manager or staff engineer, you're in the unique position to establish this foundation. You understand both the technical architecture and the business requirements that generic templates can't capture. You know which patterns matter most to your organization, which security standards are non-negotiable, and which coding conventions actually improve maintainability versus those that just exist for historical reasons.

Building your own framework requires documenting the knowledge that currently lives in senior developers' heads. You need to capture the architectural decisions that make sense for your domain, the data handling patterns that ensure compliance, and the integration approaches that work reliably in your environment. This isn't about creating more documentation for the sake of it. This is about encoding the practical wisdom that makes your team effective so AI tools can apply that same wisdom consistently.

The framework also becomes a forcing function for clarifying your own standards. When you need to explain to an AI how your team handles authentication, you'll discover gaps or inconsistencies in your current approach. When you document your testing patterns, you might realize some teams are following outdated practices. Building context frameworks often improves human processes as much as AI outcomes.

Without this investment, enterprise teams often abandon AI tools after disappointing pilots. They conclude the technology isn't ready for serious development work. The reality is that the technology works well, but only when it understands your specific context and requirements. Generic approaches produce generic results, and generic results rarely meet enterprise standards.

## Measuring the impact of context engineering

Organizations implementing systematic context engineering report measurable improvements across key development metrics. However, while comprehensive studies specifically on context engineering are still emerging, the available research on AI-assisted development provides strong indicators of potential benefits.

### Productivity and speed metrics

Research from GitHub and Accenture shows that developers using properly configured AI assistants **complete tasks 55% faster** and experience **26% productivity gains** in controlled enterprise studies. Microsoft's study across 4,800 developers found **26% more completed tasks** when using AI tools with comprehensive context.

At ZoomInfo, developers achieved a **33% acceptance rate** for AI suggestions and **20% acceptance rate** for lines of code when proper context was provided, with **72% developer satisfaction** scores. Teams using context-aware AI report **10.6% increase in pull requests** and **3.5-hour reduction in cycle time**.

### Code quality and consistency metrics

The 2025 State of AI Code Quality report found that teams using context-aware AI tools see dramatic improvements. **70% of teams report better code quality** when experiencing considerable productivity gains. **81% quality improvement** when AI review processes are integrated versus 55% without review. **65% fewer context-related errors** when proper architectural context is provided. **2.5x higher confidence** in AI-generated code when context reduces hallucinations below 20%.

### Team and workflow metrics

Context engineering specifically addresses common AI assistant problems. **44% of quality issues** stem from missing context, according to developer surveys. **26% of developers** cite improved contextual understanding as their top requested AI improvement. Teams with consistent AI output report **1.5x fewer frustrations** with style mismatches. **36% vs. 17% quality gains** for teams using AI review compared to those without.

### Sources and methodology

These metrics come from multiple peer-reviewed studies and enterprise deployments: GitHub's research with 2,000+ developers using the SPACE framework, Accenture's randomized controlled trial across enterprise development teams, ZoomInfo's comprehensive 400-developer deployment study, Qodo's 2025 analysis of AI code quality across multiple organizations, Harness SEI's analysis of GitHub Copilot enterprise implementations.

### Important context for measurement

While these metrics show promising trends, successful context engineering implementation requires careful measurement approaches. As GitLab's research notes, simple metrics like acceptance rates can be misleading, developers may accept suggestions but then heavily modify them. The key is measuring downstream impact: reduced code churn, fewer bug introductions, and sustained code quality over time.

Organizations should establish baseline measurements before implementing context engineering and track both quantitative metrics (acceptance rates, code quality scores, cycle times) and qualitative feedback (developer satisfaction, perceived productivity) to get a complete picture of impact.

## Advanced context patterns for complex web applications

As applications grow in complexity, context engineering strategies must evolve to handle sophisticated architectural patterns.

### Microservices context coordination

For teams building distributed web applications, context engineering involves coordinating information across service boundaries:

```shell-session
# Service Context Map
- Authentication service: JWT patterns, refresh logic
- User service: Profile management, preferences
- Order service: Cart management, payment flow
- Notification service: Email templates, push notifications

# Cross-Service Patterns
- Error handling and retry logic
- Service communication protocols
- Data consistency approaches
- Monitoring and logging standards
```

### Multi-framework context management

Modern web development often involves multiple frameworks within single projects (React frontend, Python backend):

```shell-session
# Stack Context
Frontend (React):
- Component patterns, state management, routing
- UI library, styling approach, form handling

Backend (Python):
- API design patterns, middleware structure
- Database integration, authentication
- Error handling, logging, testing

# Shared Context
- Type definitions, validation schemas
- Business logic patterns
- API contracts, error codes
```

## Why enterprise developers can't afford to ignore context engineering

Context engineering is the structured approach that will allow you to move from vibe coding to delivering well thought out code. When you're building software that thousands of users depend on, inconsistent AI output could costs real money, not just developer frustration.

**Vibe coding simply doesn't scale in enterprise environments.** When junior developers randomly prompt AI tools hoping for useful code, they create technical debt that senior developers spend weeks cleaning up. When different team members get different results from the same AI tool, code reviews become time-consuming debates about style and architecture. When AI generates code that doesn't follow company security standards or compliance requirements, the risk extends far beyond productivity losses.

Enterprise teams need predictable, reliable AI assistance that integrates with existing workflows and maintains code quality standards. Context engineering provides exactly that. It transforms AI from a wild card into a standardized development resource that produces consistent results across team members, follows established architectural patterns, maintains security and compliance requirements, reduces time spent in code review cycles.

**The competitive implications are already visible.** Companies that master context engineering are shipping features faster while maintaining higher code quality. Their developers spend less time fighting with AI tools and more time solving business problems. Their junior developers become productive more quickly because AI helps them follow established patterns rather than inventing new ones.

Meanwhile, organizations still relying on vibe coding are experiencing the frustrations that make developers abandon AI tools altogether. Inconsistent results, frequent debugging of AI-generated code, style mismatches that slow down reviews, security vulnerabilities that slip through because AI doesn't understand company standards.

For enterprise developers, the choice is becoming clear. Learn to engineer context properly, or watch your team's productivity stagnate while competitors pull ahead. The tools and techniques exist today. The question is whether your organization will adopt them before or after your competition does.

Ready to transform your development workflow with context engineering? Start by documenting your project's architectural patterns and experimenting with structured context in your favorite AI coding assistant. The productivity gains begin immediately, and the competitive advantages compound over time.

### [PHP 8.0 type improvements | Upsun](https://upsun.com/blog/php-8-0-type-improvements/)

# PHP 8.0 type improvements

PHP 8 has a host of improvements, new functionality, and overall polish to make the web's favorite server-side language even better. We'll cover what you need to know about PHP 8. It's an exciting release, and we're not even going to be covering all of it! There's just that much going on.

First up, we'll cover the various improvements to the type system.

## **Union types**

The biggest type system change is the introduction of _union types_. _Union types_ are a virtual type that are the "union" (a logical "OR") of two other types. For example:

```php
<?php

function mangleUsers(string|array $users): array
{
    If (is_string($users)) {
        $users = [$users];
    }
    // ...
}
```

Previously, if you wanted to support the "one or many" parameter style like that you couldn't type the parameter. Now, you can specify `string|array` and either a string or array variable is acceptable. Integers, objects, and so on will still be rejected.

Union types work on parameters, return types, and property types, and they support any type PHP supports: primitives, objects, user-defined classes, etc. While they can be used to produce all kinds of grody, inconsistent APIs, those were already possible. At least now they can be documented. More importantly, it opens up some interesting use cases that were previously impossible to document in the type system itself.

For example, a function that requires a number but can work on both ints or floats can now say exactly that:

```php
<?php

function doMath(int|float): int|float
{
    // ...
}
```

It's also possible to explicitly say that a function or method may return objects of different types. For example, a function that takes a PSR-7 request object and either returns a new request or a corresponding response would look like this:

```php
<?php

function handleRequest(RequestInterface $req): RequestInterface|ResponseInterface
{
    // ...
}
```

In inheritance, union types follow the same covariant/contravariant rules as any other type. That is, a subclass's method parameters are allowed to accept a broader type definition than its parent (so adding a `|Foo` is OK, but not removing it), while a return value is allowed to specify a narrower type definition than its parent (so removing `|Foo` is OK, but not adding it).

The reflection API has also been updated to support inspecting union types on functions and properties.

More details are available in the original RFC. Thanks to Nikita Popov for this one.

## **Specialty unions**

PHP already has a number of one-off union types defined in the language. `iterable`, for instance, is effectively a union type for `array|\Traversable`. Nullable types, such as `?Product`, are essentially a union type of `null|Product`.

In fact, it is now possible to specify `null` as a type in a union, but only in a union. So `null|RequestInterface|ResponseInterface` is a legal type definition. The `?` nullable flag is now a shorthand for `null|` when there's only a single other value allowed.

Another union-type-only option is `false`. That is mainly to support existing PHP internal functions that, due to errors of judgement made back in the 1990s, return "a value, or false on error." Those functions can now be typed as:

```php
<?php

function base64_decode(string $str, bool $strict = false): string|false {}
```

That capability is only to support legacy code that can't change its API to be less bad. Please don't use it for any new code. Like `null`, `false` cannot be used as a stand-alone type declaration. Also, the `void` type declaration cannot be combined with anything, as it literally means "nothing at all is returned, period," so it makes little sense to combine with other types.

PHP 8 also introduces a new built-in union type. The new `mixed` type is equivalent to `array|bool|callable|int|float|null|object|resource|string`. That's not _quite_ the same as omitting the type entirely. Omitting the type could mean that the developer just forgot, or that the type system is not robust enough to describe the possible allowed values. Using the `mixed` type explicitly says to the engine and other developers, "I accept anything here, and I mean it." There are now extremely few cases where it's not possible to type a parameter, return, or property in PHP 8.

Thanks to Máté Kocsis and Dan Ackroid for this RFC.

## **The Stringable interface**

PHP objects have long been able to define a way that they can be cast to a string, using the \_\_toString() magic method. However, the `string` type hint doesn't accept string-castable objects in strict mode, rendering that less useful since PHP 7.0 introduced scalar types.

PHP 8 now introduces a `Stringable` interface that corresponds to an object having the `__toString()` magic method. It also does so in a clever, backward-compatible way.

As of 8.0, a class _may_ implement a `Stringable` interface that defines a method `public function __toString(): string`. If it doesn't, but still implements that method, _the engine will add the method and return type automatically_. That means any stringable object may now be type-checked, including as part of a union type, like so:

```php
<?php

function show_message(string|Stringable $message): void
{
    // ...
}
```

Boom! `__toString` is useful again.

Because the new interface is, technically, slightly more strict than the original `__toString()` method (since it enforces a string return rather than just assuming it), the Symfony team has included a polyfill for it in their symfony/polyfill-php80 package. That allows developers to start using it now to ensure their types are correct and will be forward-compatible for PHP 8 immediately.

Mind you, just because `__toString()` is more usable now doesn't mean you should go overboard. Most objects should not have a `__toString()` method and should have meaningful methods that return strings instead. Where `__toString()` is useful is for value objects that have one and only one possible meaningful string representation, because the object is essentially just a fancy string. A good example is an `IPv4Address` object, which would only make sense to cast to a string as `1.2.3.4` type strings.

Thanks to Nicolas Grekas for the Stringable RFC.

## **Odds and ends**

Finally, there's two other small improvements to help everyday code.

First, objects now have a magic constant that specifies their class, just as class names do. `$object::class` is a string containing the class name, such as `App\Form\FormDef`. It's the same as `get_class()`, but easier to use. Credit for this feature goes again to Nikita Popov.

Finally, a personal favorite, methods can now have a return type of `static`. That's mainly useful for interfaces with chained methods. That means the following is now possible:

```php
<?php

Interface TaskBuilder
{
    public function addStep(Step $s): static;
}

class  ImportantTask implements TaskBuilder
{
    public function addStep(Step $s): static
    {
        $this->steps[] = $s;
        return $this;
    }
}
```

And now `ImportantTask::addStep()` is typed to return an instance of `ImportantTask`. Previously with a return type of `self` it would only indicate that it's returning `TaskBuilder`.

Credit for this improvement goes once again to Nikita Popov. (We'll be seeing his name a lot in this series.)

**Useful links:**

-   PHP | Upsun documentation

### [PHP 8.0 named arguments | Upsun](https://upsun.com/blog/php-8-0-named-arguments/)

# PHP 8.0 named arguments

In every programming language that has functions (that is, all of them), functions can be called by passing an ordered list of arguments to them as input parameters. That works quite well, but does have some edge cases where it's less than ideal. Specifically, when there's more than one parameter it's easy to forget what the order of them is or what a given parameter means. (And even when there’s just one, it may not be self-evident at the call site what it means.)

There are various workarounds that are possible, such as passing an associative array instead of discrete parameters, but those all introduce their own problems. Passing an associative array, for instance, bypasses all type safety.

A few languages address that problem by allowing (usually optionally) callers to specify parameters by name, rather than by position. PHP 8.0 is now one of those languages.

## **Named parameters**

In PHP, named parameters are entirely controlled by the caller. All functions and methods are, automatically, named-parameter supporting. When the function is called, the caller can choose to use a positional argument, a named argument, or even a combination of them.

As an example, PHP's `array_fill()` function produces a new array of a specified size where all elements are set to the same starting value. Like so:

```php
<?php

$new = array_fill(0, 100, 50);
```

Just from reading that ... what do those numbers mean? Will `$new` be a 100 element array of `50` or a 50 element array of `100`? It's not obvious unless you know how `array_fill()` works.

With named parameters, you can call it like this instead:

```php
<?php

array_fill(start_index: 0, count: 100, value: 50);
```

Now it's clear what we'll get back: 100 array elements, with keys starting at 0, with all values set to `50`. But you can also order the parameters however you want:

```php
<?php

array_fill(
  value: 50,
  count: 100,
  start_index: 0,
);
```

The argument names are matched to the parameter names in the function definition, regardless of order. In this example we've also shown the parameters in vertical form, which is fine, and demonstrated a trailing comma on the last parameter. (Which, as noted, is new in PHP 8.0 and helps support exactly this case.)

Parameter names must be literals; you cannot have a variable as a parameter name.

It's also possible to specify only certain parameters by name and others positionally. More specifically, you can list parameters positionally until you switch to named arguments and then use named thereafter. Thus, this is perfectly fine:

```php
<?php

array_fill(0,
  value: 50,
  count: 100,
);
```

But this is not:

```php
<?php

array_fill(
  value: 50,
  0,
  count: 100,
);
```

## **Named variadics**

One tricky question with named parameters is around variadics. "Variadics" are the fancy name for the ability to pass a variable number of parameters to a function. That is, you've long been able to do this in PHP:

```php
<?php

include_these($product, 1, 2, 3, 4, 5);

function include_these(Product $product, int ...$args)
{
    // $args is now an array of ints.

    $vals = ['a', 'b'];
    do_other_thing(...$vals);
}
```

Here, the `...` operator, affectionately known as "splat," either collects arguments up into an array or spreads them out from an array, depending on the context. But how does that interact with named arguments?

The way they interact is, I would argue, what you'd logically expect. An indexed array that is spread out will spread out as positional arguments. An associative array that is spread out will spread out as named arguments. To continue the earlier example:

```php
<?php

// This is a named array, so the values will map to named parameters.
$params = ['count' => 100, 'start_index' => 0, 'value' => 50];
array_fill(...$params);
```

When collecting variadic arguments, they'll be collected as either numerically indexed array values if passed positionally or as string-keyed array values if passed by name. Be aware that, if you have a variadic parameter, that means you may have an array that is a mixture of numeric and named keys.

That also leads to interesting possibilities to build up a function call dynamically, by first dynamically building an associative array and then calling the function with it using splat.

```php
<?php

$args['value'] = $request->get('val') ?? 'a';
$args['start_index'] = 0;
$args['count'] = $config->getSetting('array_size');

$array = array_fill(...$args);
```

## **Limitations**

The main pushback against named arguments was, and always has been, that making it "too easy" to have functions with lots of arguments would encourage poor API design. For example, this method call is unquestionably hard to understand:

```php
<?php

read_value($object, true, false, false, false, true, true, 7, false, true);
```

Such an API really should be redesigned. The fear is that named parameters would allow API designers to get away with saying "well, just use names on them, then you can even skip all the defaults you don't care about that way." That's true, but also misses the point that the problem is the API is too complicated.

There's no strong preventative here other than "don't use this as a crutch to make bad APIs," which could be said about nearly any language feature.

## **But ... why?**

Named parameters were first seriously proposed all the way back in 2013, but didn't gain traction until now. What really brought them to the forefront again was several discussions around how to make object construction easier. Several proposals were floated in early 2020 for dedicated, one-off syntaxes for easier "struct" objects, that is, objects that are just a collection of probably-public properties.

Languages like Go and Rust make it very easy to create structs with named parameters, because they don't technically have objects the way PHP does. They have a struct with properties, period, that you can define even as a struct literal, and then you can hang methods off of them. The net result is similar but not quite the same as the Java/C++/PHP style of object. Still, plenty of people have been justifiably jealous of how easy those languages make it to create new complex structures.

None of the one-off syntaxes that were proposed really addressed the problem in a way that "fit" with PHP. Several people, however, myself included, noted that a more robust approach would be to solve the underlying problems in a way that allowed a nicer object construction syntax to just "fall out" naturally.

I laid out the argument for that in detail in a blog post back in March. In short, constructor property promotion plus named arguments would, together, effectively give us a struct-initialization syntax. The whole would be greater than the sum of its parts. Fortunately, the ever-busy Nikita Popov agreed with me and picked up the ball and ran with it.

That brings us to one of the few places where named arguments really should be used: constructing struct objects.

To demonstrate, consider a value object for a PSR-7 URL object.

```php
<?php

class Url implements UrlInterface
{
    public function __construct(
        private string $scheme = 'https',
        private ?string $authority = null,
        private ?string $userInfo = null,
        private string $host = '',
        private ?int $port = 443,
        private string $path = '',
        private ?string $query = null,
        private ?string $fragment = null,
    ) {}
}
```

We have already seen how constructor promotion makes that vastly easier to write. Named arguments also makes it vastly easier to use, since many of those parameters can legitimately be absent in a valid URL, including ones early in the list like `$authority`. In PHP 7.4, you'd have to use it like so:

```php
<?php

$url = new Url('https', null, null, 'platform.sh', 443, '/blog', null, 'latest');
```

Which is ... gross, but you have to do that in order to get to the later arguments. With named parameters, that collapses to this shorter and more self-documenting alternative:

```php
<?php

$url = new Url(host: 'platform.sh', path: '/blog', fragment: 'latest');

// Or if you prefer vertical:

$url = new Url(
    path: '/blog',
    host: 'platform.sh',
    fragment: 'latest',
);
```

And you can then put the parameters in any order to boot. The two features complement each other to make working with lightweight objects vastly cleaner than in previous versions. Value object constructors are, I would argue, one of the three key places to use named arguments.

## **Arguments in attributes**

The second key target is in attributes:

```php
<?php

class SomeController
{
    #[Route('/path', name: 'action')]
    public function someAction()
    {
        // ...
    }
}
```

Attributes are syntactically an object constructor call, which gets called lazily through the reflection API as needed. Because it's a constructor call, it can do (almost) anything a constructor call can do, including use named arguments.

In fact, I predict that most attribute usage will use named arguments. The whole point is to make flexible metadata available within the syntax of the language itself. Many Doctrine annotation usages today rely very heavily on named keys, as they are more self-documenting and more flexible when there are many optional arguments. It's logical to expect (and encourage) attributes to follow the same pattern.

## **Named arguments about arguments**

The third place I expect named arguments to see heavy use is on functions where the parameters are legitimately needed, and legitimately confusing, and there's no self-evident way around that. The `array_fill()` example earlier is a good example.

Another good example? Everyone's favorite canard, `$haystack, $needle` vs. `$needle, $haystack`. String functions generally use one order, array functions generally use the other, for reasons that make sense when you're modeling your API on C but not otherwise. Now, you don't need to remember what the order is.

```php
<?php

if (in_array(haystack: $arr, needle: 'A')) {
    // ...
}
```

Is that the order those parameters are in the function, positionally? Who cares? The function call specifies exactly what is being passed, making the order irrelevant. (They're not in order, in case you were wondering.)

At last, we can stop complaining about parameter order and citing that as a reason why PHP is bad. (I'm sure people will still continue to do so; they'll just be even more wrong than they already were.)

## **API implications**

One warning, however. As noted, named arguments work for all functions and methods automatically. That means the parameter names in functions, methods, and interfaces are now API significant. Changing them may break users who are calling them by name. (This would be a good time to revisit your parameter names, while checking to make sure your libraries are ready for PHP 8.0.)

Variable name significance is not, at this point, enforced in inheritance. That's a pragmatic decision to avoid breaking too much existing code, as the vast majority of methods won't be called with named parameters 99.9% of the time, so creating even more breakage for existing code that might be renaming arguments for entirely logical reasons didn't make sense. Python and Ruby take the same approach and haven't run into serious issues, which PHP took as a good sign that it was safe to do the same.

It should be no surprise that named arguments RFC come to us courtesy of Nikita Popov.

### [Understanding SOLID principles in software design | Upsun](https://upsun.com/blog/solid-principles-in-software-design/)

# Understanding SOLID principles in software design

SOLID principles make your code easier to maintain and adapt. These five object-oriented design practices help you write cleaner, more reliable code.

Let's explore each principle with practical examples for building maintainable applications - from single codebases to distributed systems.

## What are SOLID principles in software development?

Writing maintainable code is challenging. SOLID principles give you practical guidelines to write better code. Robert C. Martin created these principles to solve common issues like rigid code, cascading bugs, and complex systems.

Each SOLID principle targets a specific coding challenge:

### S: Single responsibility principle (SRP): simplify code maintenance

The Single Responsibility Principle keeps your code maintainable. Each class does one specific task - no more, no less.

Think of it this way: Keep user authentication separate from logging or notifications. When a class tries to do multiple things, testing and updating become more complex.

### SRP Class Relationships

The diagram uses composition to show how UserRegistration works with other classes. Each hollow diamond arrow means UserRegistration references a class but doesn't control its lifecycle.

Diagram legend:

-   means public methods/properties
-   means private methods/properties
-   Arrows show class dependencies
-   Boxes show class names and their members

Here's how separating code responsibilities creates cleaner, more maintainable applications:

```php
// This example demonstrates the Single Responsibility Principle (SRP)
// Each class has one specific job, making the code more maintainable and testable

// UserDataFormatter: Responsible for converting user data into a consistent format
class UserDataFormatter {
    public function formatUserData($user) {
        // Extracts and formats essential user information
        return [
            'name' => $user->getFullName(),    // Get user's full name
            'email' => $user->getEmail(),      // Get user's email
            'joined' => $user->getJoinDate()->format('Y-m-d')  // Format join date
        ];
    }
}

// UserDataValidator: Responsible for ensuring data meets requirements
class UserDataValidator {
    public function validateUserData($userData) {
        // Performs two validation checks:
        // 1. Verifies email is in valid format
        // 2. Ensures name field is not empty
        return filter_var($userData['email'], FILTER_VALIDATE_EMAIL) 
            && !empty($userData['name']);
    }
}

// UserDataPersistence: Responsible for database operations
class UserDataPersistence {
    private $database;

    // Initialize with database connection
    public function __construct($database) {
        $this->database = $database;
    }

    // Handles saving user data to the database
    public function saveUser($userData) {
        // Performs the actual database insert operation
        return $this->database->insert('users', $userData);
    }
}

// UserRegistration: Orchestrates the registration process
// Acts as a facade, coordinating between other specialized classes
class UserRegistration {
    private $formatter;
    private $validator;
    private $persistence;

    // Constructor injection of dependencies
    public function __construct(
        UserDataFormatter $formatter,
        UserDataValidator $validator,
        UserDataPersistence $persistence
    ) {
        $this->formatter = $formatter;
        $this->validator = $validator;
        $this->persistence = $persistence;
    }

    // Main registration method that coordinates the entire process
    public function registerUser($user) {
        // Step 1: Format the user data
        $userData = $this->formatter->formatUserData($user);

        // Step 2: Validate the formatted data
        if ($this->validator->validateUserData($userData)) {
            // Step 3: If validation passes, save to database
            return $this->persistence->saveUser($userData);
        }

        // If validation fails, throw an exception
        throw new ValidationException('Invalid user data');
    }
}

// EXAMPLE USAGE DEMONSTRATION
// Below shows how all components work together

// Create a mock database for demonstration
$database = new class {
    public function insert($table, $data) {
        // Simulates database insertion and returns success
        echo "Inserted into $table: " . json_encode($data) . "\\n";
        return true;
    }
};

try {
    // Step 1: Initialize all required components
    $formatter = new UserDataFormatter();
    $validator = new UserDataValidator();
    $persistence = new UserDataPersistence($database);

    // Step 2: Create the main UserRegistration service
    $userRegistration = new UserRegistration($formatter, $validator, $persistence);

    // Step 3: Create a mock user object for testing
    $user = new class {
        public function getFullName() {
            return "Jane Doe";
        }
        public function getEmail() {
            return "jane@example.com";
        }
        public function getJoinDate() {
            return new DateTime();
        }
    };

    // Step 4: Attempt to register the user
    $userRegistration->registerUser($user);
    echo "User successfully registered!";
} catch (ValidationException $e) {
    // Handle any validation errors that occur
    echo "Failed to register user: " . $e->getMessage();
}

// Custom exception class for validation-specific errors
class ValidationException extends Exception {}

```

  
Each class has a single, focused job. The formatter formats data. The validator checks data. The persistence layer saves data. The registration class coordinates these pieces cleanly. This structure makes testing and maintenance straightforward.

This clean design aligns with the Open-Closed principle. Want to add new formatting rules or validation checks? Create new classes that follow the existing pattern. Your code stays intact while functionality grows.

### O: Open-closed principle (OCP): write extendable and scalable code

The Open-Closed Principle (OCP) helps you add features without modifying existing code. Your codebase stays stable as it grows. Instead of changing existing code, extend functionality through new classes and interfaces.

### L: Liskov substitution principle (LSP): avoid code breakage in OOP

The Liskov Substitution Principle (LSP) means child classes must work anywhere their parent classes do. If they don't, your code will break in unexpected ways.

Here's a common LSP violation and how to fix it:

```php
// ❌ Violates LSP: This violates Liskov Substitution Principle because
// a subclass (Penguin) changes the expected behavior of its parent class (Bird)
class Bird {
    public function fly() {
        // Logic for flying
    }
}

class Penguin extends Bird {
    public function fly() {
        // This breaks the contract established by the parent class
        throw new Exception("Penguins can't fly!");
    }
}

// ✅ Refactored: Better design using composition over inheritance
// This approach separates flying capability from bird classification
interface Flyable {
    public function fly();
}

// Only birds that can actually fly implement the Flyable interface
class Sparrow implements Flyable {
    public function fly() {
        // Flying birds implement their specific flying behavior
    }
}

// Penguin doesn't implement Flyable, avoiding the forced inheritance problem
class Penguin {
    // Penguins have their own behaviors without being forced to implement fly()
}
```

### I: Interface segregation principle (ISP): design clean and focused interfaces

The Interface Segregation Principle helps you write cleaner code by keeping interfaces small and focused. This way, classes only implement methods they actually use.

Let's look at how to split up bloated interfaces into smaller, focused ones.

```php
// ❌ Violates ISP: Interface forces classes to implement methods they don't need
interface Animal {
    public function fly();    // Problem: Fish shouldn't need this
    public function swim();   // Problem: Birds shouldn't need this
}

class Fish implements Animal {
    public function swim() {
        // Swimming logic
    }
    
    public function fly() {
        // Forced to implement irrelevant method
        throw new Exception("Fish cannot fly");
    }
}

// ✅ Refactored: Following ISP with focused, specific interfaces
// Each class only implements the methods it actually needs
interface Flyable {
    public function fly();    // Interface for flying creatures
}

interface Swimmable {
    public function swim();   // Interface for swimming creatures
}

class Fish implements Swimmable {
    public function swim() {
        // Fish only implements what it can actually do
        // This follows ISP by not forcing unnecessary methods
    }
}

class Bird implements Flyable {
    public function fly() {
        // Birds only implement flying behavior
        // No unused methods are forced upon the class
    }
}

```

### D: Dependency inversion principle (DIP): improve code flexibility with abstractions

The Dependency Inversion Principle helps you write better code by using interfaces instead of direct implementations. Your high level modules work with abstractions not specifics. This lets you swap components without breaking your system.

Here's a practical example:

```php
// ❌ Violates DIP: High-level module depends on low-level module
class EmailNotifier {
    public function send($message) {
        // Logic for sending email
    }
}

class Notification {
    private $emailNotifier;
    
    public function __construct() {
        $this->emailNotifier = new EmailNotifier();
    }
    
    public function notify($message) {
        $this->emailNotifier->send($message);
    }
}

// ✅ Refactored: Depend on abstractions, not concrete implementations
interface Notifier {
    public function send($message);
}

class EmailNotifier implements Notifier {
    public function send($message) {
        // Logic for sending email
    }
}

class SMSNotifier implements Notifier {
    public function send($message) {
        // Logic for sending SMS
    }
}

class Notification {
    private $notifier;
    
    public function __construct(Notifier $notifier) {
        $this->notifier = $notifier;
    }
    
    public function notify($message) {
        $this->notifier->send($message);
    }
}
// This design allows swapping EmailNotifier with SMSNotifier without modifying Notification
```

SOLID principles are simple tools that work together. When combined correctly, they help you write clean code that's easier to maintain and debug.

Here's a clear breakdown of what each principle does:

  
Interface Segregation and Dependency Inversion help build adaptable systems. Interface Segregation lets each microservice expose only essential functions. Dependency Inversion enables component swapping without core code changes.

Dependency Inversion works especially well for plugin systems. Using interfaces instead of hardcoded dependencies makes components interchangeable, enabling easy integration of new tools.

For example, a CMS can switch between SQL, NoSQL, or files for storage. Interface Segregation keeps the connections clean and minimal. Together, these principles create systems that adapt to new requirements.

## How SOLID principles make software design maintainable and scalable

Writing maintainable code is challenging. Quick fixes during deadlines create technical debt that's hard to fix later. SOLID principles offer a solution.

These principles help teams build stable, flexible code that's easier to understand and change. The result: fewer bugs and faster development cycles.

Clear code structure enables better teamwork. When each component has a specific purpose, testing and debugging become straightforward.

SOLID supports growth. With the Open-Closed Principle, you can extend functionality without modifying existing code - essential for evolving projects.

As requirements evolve, SOLID principles ensure your code can adapt. Add features or modify functionality without major refactoring.

While shortcuts may seem efficient now they create long-term problems: slower development, more bugs and developer frustration. SOLID principles lead to cleaner, more maintainable code.

Robert C. Martin puts it clearly: "Good architecture makes the system easy to understand, easy to develop, easy to maintain, and easy to deploy. The ultimate goal is to minimize the lifetime cost of the system and to maximize programmer productivity." SOLID principles make this possible.

## 3\. Breaking Down the SOLID Principles (With Examples)

### Single Responsibility Principle (SRP)

Each class should do one thing only.

Consider a Report class that both formats data and writes to a database. This creates problems - when you update formatting or switch databases, you risk breaking both features.

The solution? Split it into ReportFormatter and ReportWriter. Each class has one clear purpose. Want to change report formatting? Update ReportFormatter. Need to switch databases? Modify ReportWriter.

This separation also simplifies testing since you can verify formatting and database operations separately.

Here's a code example:

```php
// ❌ Violates SRP: One class handling multiple responsibilities
class Report {
    public function formatData($data) {
        // Format data as JSON
        // This violates SRP by mixing formatting and storage concerns
    }
    
    public function writeToDatabase($data) {
        // Write data to database
        // This creates tight coupling between data formatting and storage
    }
}

// ✅ Refactored: Following SRP with clear separation of concerns
class ReportFormatter {
    public function formatData($data) {
        // Format data as JSON
        // This class has a single responsibility: data formatting
    }
}

class ReportWriter {
    public function writeToDatabase($data) {
        // Write data to database
        // This class has a single responsibility: data persistence
        // Decoupling allows for easier testing and maintenance
    }
}
```

-   Key takeaway: SRP makes code simpler by giving each component a clear, single purpose. This reduces maintenance costs and makes changes easier.

## Common mistakes to avoid when applying SOLID principles

Even experienced developers can struggle with SOLID principles. Here are common mistakes to avoid:

### Interface overload

Don't create too many small interfaces. Group related functions together logically. For example, a permissions system works better with a single UserPermissions interface rather than separate interfaces for reading, writing, and role management.

### Misusing helper classes

Avoid dumping multiple tasks into "helper" classes. Break them into focused components instead. Example: Replace a DataProcessorHelper with separate DataValidator, DataFormatter, and Logger classes.

### Unnecessary abstractions

Create interfaces only when they add value. A simple StringFormatter class doesn't need an interface - it adds complexity without benefit.

### Keep balance

Don't overuse any single principle. Too much separation creates unnecessary complexity. Too little makes code rigid. Let SOLID principles guide your design decisions without constraining them.

Following these guidelines helps create maintainable, scalable code.

## Why SOLID principles matter for clean, modular software design

Writing maintainable code is essential. SOLID principles make your code easier to change and scale. Here's how:

Your code needs to adapt as your project grows. With the Open-Closed and Dependency Inversion Principles, you can add features without breaking existing functionality.

For example: Say you're building an e-commerce site that handles tax calculations. Using these principles, you can add new tax rules for different countries without changing your core checkout code.

Let's see this in practice:

```php
// Example demonstrating violation of Open-Closed Principle (OCP)
// ❌ Bad Practice: This implementation requires modifying existing code to add new shapes
class Shape {
    // This method uses conditional logic that must be modified for each new shape type
    // Breaking OCP as the class must be modified to extend functionality
    public function calculateArea($type, $dimensions) {
        if ($type === 'circle') {
            return pi() * pow($dimensions['radius'], 2);
        } elseif ($type === 'square') {
            return pow($dimensions['side'], 2);
        }
    }
}

// Example demonstrating proper implementation following OCP
// ✅ Good Practice: Using polymorphism to allow extension without modification

// Abstract base class defines the interface that all shapes must implement
// This creates a contract that concrete classes must fulfill
abstract class Shape {
    // Abstract method forces all child classes to implement their own area calculation
    abstract public function calculateArea();
}

// Concrete implementation for Circle
// Each shape is responsible for its own area calculation
class Circle extends Shape {
    private $radius;
    
    // Constructor initializes the circle with its radius
    public function __construct($radius) {
        $this->radius = $radius;
    }
    
    // Specific implementation for calculating circle area
    // π * r²
    public function calculateArea() {
        return pi() * pow($this->radius, 2);
    }
}

// Concrete implementation for Square
// New shapes can be added by creating new classes without modifying existing code
class Square extends Shape {
    private $side;
    
    // Constructor initializes the square with its side length
    public function __construct($side) {
        $this->side = $side;
    }
    
    // Specific implementation for calculating square area
    // side * side
    public function calculateArea() {
        return pow($this->side, 2);
    }
}
// To add a new shape, simply create a new class that extends Shape
// This follows OCP as existing code remains unchanged
```

-   Modular by Design - SOLID creates reusable components. A well-structured authentication module works in multiple projects without changes.
-   Team Focus - Clear boundaries help teams work independently. New developers start contributing faster with focused, single-purpose components.
-   Cloud-Ready Architecture - Small, focused components deploy and scale easily in cloud environments and microservices.

## How to use SOLID principles for microservices and cloud-ready systems

Upsun provides the tools you need to write better code, whether you're building monoliths or microservices.

### Modular Testing

-   Test modules in isolated containers
-   Check changes safely in preview environments

### Scale Without Friction

-   Focus on code while infrastructure scales automatically
-   Use Git workflows that support clean, extensible changes

### Code Structure

-   Profile and break down monolithic code efficiently

### Dependencies

-   Keep implementations and abstractions synchronized through version control

## Putting SOLID Principles to Work

Here's how to apply SOLID principles effectively:

1.  Break large classes into focused components: Each component should do one specific task. This improves testing and maintenance.
2.  Make incremental improvements: Refactor your code gradually. Avoid complete rewrites.
3.  Test continuously: Run tests after each change to catch issues early.

Following these practices leads to more maintainable and adaptable code - essential for growing projects.

### [Five questions your platform evaluation is missing | Upsun](https://upsun.com/blog/five-questions-platform-evaluation-missing/)

# Five questions your platform evaluation is missing

Years back I sat in on a platform evaluation with a customer who spent forty-five minutes of the meeting focusing on one thing: their custom PHP content management system.

They had opinions about the CMS. Strong opinions. They had benchmarks, a migration plan, a proof of concept. They had a diagram. They had questions about the deployment pipeline for this CMS that were, for a single application, more thoroughly considered than most organizations' entire infrastructure strategies.

Later in the meeting, somebody asked, almost in passing, about the rest of their stack.

Come to find out, they had three hundred other applications. On-prem, AWS, Rackspace, some of them running on servers nobody had gone into in months. No version control on most of them. Production hotfixes on a weekly basis. A wiki page somewhere that purported to list all the environments and had last been edited in 2018.

The evaluation we were in the middle of was about the one CMS. The elephant in the next four rooms was the other three hundred apps.

I've sat in enough of those meetings to notice a pattern. The questions that decide whether a platform choice ages well are rarely the questions that show up in the evaluation. Here are five that belong in your next platform evaluation.

## 1\. What percentage of your application can actually run on the platform?

Not "does the platform support this framework." Not "does it have an integration for your database." The specific question: if you drew a map of your applications, how much of that map could be managed by the platform you're evaluating, and how much is integrated through marketplace connectors, wired up by your DevOps team, or sitting in a cloud account the platform doesn't see?

Most platforms cover a recognizable slice. The slice is usually the application runtime, the deployment pipeline, and a managed compute layer. Everything else: databases, queues, workers, background jobs, services in languages the platform doesn't run, lives somewhere else.

The percentage of the application on the platform is the percentage of the application that actually gets the platform's benefits. The rest is still yours to run or manage.

## 2\. When a reviewer opens a preview URL, is the data underneath the same as production?

Preview environments are the load-bearing part of modern developer experience. If they work, bugs die in review. If they don't, bugs die in front of customers.

The test isn't "does the preview URL load." Every competent platform gets that right. The test is whether the services and data behind the preview match production well enough that a reviewer can answer "does this work?" without guessing. For most teams on most platforms today, the honest answer is "the code does, the data doesn't, and good luck spotting the difference."

## 3\. If a customer asked you to run on a specific cloud or region, how long would that project take?

Not today, maybe. At some point, if your roadmap includes regulated customers, enterprise procurement, sovereign-region requirements, or a CFO who wants cloud spend to count against a committed-use agreement, somebody will ask. "Can you run in eu-west-1?" "Can you not use AWS, because our biggest customer competes with Amazon?" "Can we pay for this through our Azure marketplace commitment?"

If the answer is "we'd have to replatform," the next conversation is about whether the deal is worth the quarter-long migration. That's a conversation better had before the deal is on the table than during.

## 4\. What's in scope for your next compliance audit, and what's adjacent?

Compliance certifications are scope statements. The question isn't "do we have SOC 2." The question is which controls apply to which systems, and where the boundary runs.

Platforms govern what they manage. The governance boundary for most platforms is the managed compute layer. If your application is larger than that, which most are, the parts outside the platform boundary are governed by whatever else the team has assembled, audited separately, or quietly not audited at all.

The audit scope should match the architecture diagram. If it doesn't, the gap between them is where the audit gets expensive.

## 5\. If you hired a new engineer next week, how many deployment systems would they have to learn?

This is the cultural question. It's also the hiring question, the onboarding question, and the retention question, in that order.

The frontend team almost always has a modern workflow. The backend team often doesn't. The data team usually doesn't. The ML team definitely doesn't. If a new engineer has to learn three different deployment models to ship their first feature, the platform choice isn't just a technical decision. It's shaping the developer experience of everyone you're going to hire for the next three years.

One workflow for every runtime is a team decision as much as a technical one.

## The test for each question

For each of the five, there's a simple test. Can you answer the question clearly, without an "it depends," in under thirty seconds?

If yes, you know where you stand. If no, the question is where the work is. That's not a crisis. It's just the scope of your next internal conversation, before the platform choice hardens into something harder to change.

The customer evaluating that CMS, the one with the three hundred other apps, did not work through these five questions in the meeting I was in. They worked through them later, reluctantly, after somebody on their own team pushed back on the scope. The CMS got a good platform. The three hundred apps got a multi-year project to migrate off the hotfix spreadsheet. The CMS decision was fine. It just wasn't the decision they actually needed to be making.

Most platform evaluations are about the one app in the room. The five questions are about the other three hundred.

Pick your weeks.

## Further reading

If this resonated, the next piece in this series goes deep on question two: why preview environments that look right often aren't, and what byte-for-byte cloning actually changes about the review process.

## **References**

-   Upsun platform overview
-   Upsun environments and byte-for-byte cloning
-   Vercel platform documentation
-   Vercel Security and Compliance

### [Why preview environments need platform ownership | Upsun](https://upsun.com/blog/platform-owned-preview-environments/)

# Why preview environments only work when the platform owns them

Deployments are one of the few moments where software development still feels risky.

Teams may have tests, a staging environment, and careful review processes, yet the final step still carries uncertainty. Will this change behave the same way in production? Will it interact cleanly with existing data, traffic, and infrastructure? Will it introduce regressions no one anticipated?

Preview environments exist to reduce that uncertainty. In theory, they offer a simple promise: see your changes running in a production-like environment before they reach production.

In practice, delivering on that promise is much harder than it sounds.

The question is not whether preview environments are useful. The question is who carries the responsibility for making them reliable.

### **The appeal of preview environments**

Preview environments are easy to explain.

Each feature branch gets its own environment. The application, services, routing, and configuration mirror production. Developers, testers, and stakeholders can interact with real behavior instead of mockups or assumptions.

When this works well, it changes how teams ship software. Feedback happens earlier. Regressions are caught before users see them. Conversations shift from speculation to observation.

The idea feels obvious enough that many teams assume preview environments are just a matter of spinning up extra infrastructure.

That assumption rarely survives first contact with reality.

### **Why “just spin up an environment” does not scale**

A preview environment at Upsun is not just an application container with a different URL.

To behave like production, it needs the same configuration, the same services, and often data that resembles what production actually handles. 

It needs routing, certificates, access controls, and observability. It needs to be created automatically, destroyed cleanly, and kept isolated from other environments.

Each of these requirements is solvable on its own. The difficulty comes from combining them into something that works consistently, every time, without manual intervention.

Most teams discover that the complexity is not in creating one preview environment. It is in creating hundreds of them over time, safely, predictably, and without slowing the organization down.

### **The hidden system behind a “simple” preview**

When preview environments work, they disappear into the background. When they don’t, they become a source of friction and distrust.

To function reliably, preview environments depend on a system that can:

-   Reproduce infrastructure and configuration deterministically
-   Clone or approximate production data without exposing sensitive information
-   Route traffic and manage certificates automatically
-   Apply the same deployment and monitoring behavior across all environments
-   Control access so previews can be shared safely
-   Clean up resources without leaving cost and security debris behind

None of this is developer convenience. It is infrastructure behavior.

When preview environments are bolted onto existing systems, teams end up maintaining a parallel platform just to support them. Over time, that platform becomes fragile, inconsistent, and expensive to evolve.

### **Why ownership matters more than features**

This is where the distinction between tooling and platforms becomes important.

You can assemble preview environments from individual components. Many teams do. But once preview environments become critical to delivery, someone has to own their lifecycle end to end.

That ownership includes deciding how environments are created, how long they live, how they access data, how they are secured, and how failures are handled. It includes ensuring that preview behavior remains aligned with production as the system evolves.

When that responsibility sits with application teams, preview environments slowly lose credibility. When it sits with a dedicated internal platform team, it becomes another product to build and maintain.

A managed platform changes that equation by absorbing the responsibility entirely.

### **Preview environments as platform behavior**

When preview environments are a native part of the platform, they stop being special cases.

Branching becomes the trigger for environment creation. Infrastructure and services are defined declaratively. Routing and certificates appear automatically. Observability behaves the same way everywhere. Environments are isolated by default and removed when they are no longer needed.

The important shift is not technical. It is organizational.

Teams stop debating whether a preview is “close enough” to production. They trust it, because the platform enforces consistency. Feedback loops tighten. Deployments feel routine rather than risky.

The value comes not from the environment itself, but from the guarantees around it.

### **What this changes for teams**

When preview environments are owned by the platform, application teams do not need to:

-   Manually provision infrastructure for each branch
-   Maintain separate deployment logic for previews
-   Copy or sanitize data by hand
-   Configure DNS and certificates repeatedly
-   Police access to short-lived environments
-   Worry about cleaning up after experiments
-   Instead, responsibility is clearly divided.

The platform owns environments, infrastructure, and lifecycle management. Teams own application logic and delivery decisions.

This division is what allows preview environments to scale without becoming a bottleneck.

### **The real reason preview environments matter**

Preview environments are often framed as a productivity feature. They are that, but their real value is deeper.

They reduce risk without slowing teams down. They make collaboration concrete. They turn unknowns into observable behavior before changes reach users.

Most importantly, they create confidence.

That confidence only holds when preview environments behave like a property of the platform, not a fragile construction held together by scripts and conventions.

### **Platforms turn confidence into a default**

Building reliable preview environments is not about clever engineering. It is about deciding where responsibility lives.

A platform that owns environments can make safety the default. Teams move faster not because they are reckless, but because the system absorbs complexity on their behalf.

That is what preview environments are for.

### **Explore further**

-   **Explore instant development environments on Upsun**  
    See how Upsun creates isolated, production-like environments automatically for every branch.
-   **Read the technical deep dive on preview environments**  
    For implementation details and developer workflows, see the original Dev Center article.

### [Artificial intelligence in cloud infrastructure | Upsun](https://upsun.com/blog/artificial-intelligence-in-cloud-infrastructure/)

# AI revolution in cloud infrastructure: the next wave of DevOps evolution

Cloud infrastructure management has reached a complexity threshold where traditional approaches are struggling to keep pace. As organizations deploy increasingly sophisticated applications across multiple services, the challenge of maintaining efficiency, security, and performance has never been greater. Artificial Intelligence is emerging as a transformative force in this landscape, promising to revolutionize how we manage cloud infrastructure across six critical domains: cost optimization, operational efficiency, security, performance, scalability, and sustainability.

## Cost optimization through AI

The complexity of cloud services has made cost management an incredible challenge for organizations. Many enterprises now employ dedicated FinOps teams to monitor expenses and optimize resource utilization, but the sheer scale of modern cloud infrastructure makes manual optimization increasingly difficult. **AI is transforming this landscape** through sophisticated analysis and automation.

Traditional resource management often leads to significant waste, with unused or deprecated services consuming valuable resources. AI systems can continuously monitor resource utilization patterns across entire infrastructures, automatically identifying and flagging resources that are no longer needed. \_This proactive approach to resource management\_ represents a fundamental shift from reactive cost control to predictive optimization.

Perhaps most significantly, AI enables truly predictive scaling by analyzing historical patterns and real-time metrics. When organizations launch marketing campaigns or prepare for high-traffic events, AI systems can preemptively adjust resources based on anticipated needs. This intelligent capacity planning ensures optimal resource allocation without the waste of manual overprovisioning.

## Streamlining infrastructure management

Modern infrastructure configurations have become increasingly complex, with some Kubernetes deployments spanning thousands of lines of code. **DevOps teams often spend countless hours** maintaining these configurations and adapting them to evolving requirements. AI is revolutionizing this aspect of infrastructure management by streamlining the creation and maintenance of complex configurations.

_AI-powered systems can now generate and validate_ configuration files while adapting them to accommodate product updates and compatibility changes. This capability dramatically reduces the learning curve for new tools and systems, enabling teams to implement solutions in hours rather than days or weeks. The impact on DevOps productivity cannot be overstated – teams can focus on strategic initiatives rather than getting bogged down in routine maintenance tasks.

## Enhanced security posture

The security landscape is experiencing perhaps the most dramatic AI-driven transformation. As attackers leverage artificial intelligence to enhance their capabilities, defensive measures must evolve accordingly. _Traditional security approaches are no longer sufficient_ in an environment where automated attacks can probe for vulnerabilities around the clock.

**AI-powered security systems** provide continuous monitoring and instant response capabilities that human teams simply cannot match. These systems can analyze patterns across millions of events, identifying potential threats before they materialize into actual attacks. When vulnerabilities are discovered, AI systems can automatically implement protective measures while alerting security teams for further investigation.

## Performance optimization

In today's complex application architectures, performance optimization has become increasingly challenging. Modern applications often combine multiple technologies – from JavaScript frontends to various backend services and databases. **AI is revolutionizing performance management** by providing unprecedented visibility into system behavior and automating optimization processes.

_Through sophisticated analysis of transaction patterns_, AI systems can identify performance bottlenecks across entire application stacks. This includes monitoring database query performance, cache utilization, and code-level inefficiencies. Tools like Blackfire.io already provide advanced profiling capabilities, but AI takes this further by automatically identifying optimization opportunities and suggesting specific improvements.

## Smart scalability

Traditional scaling approaches often rely on simplistic rules that trigger resource-wide scaling events, regardless of where bottlenecks actually exist. **AI enables a more sophisticated approach** to scalability, allowing systems to scale individual components based on precise resource requirements.

_The future of scaling lies in predictive algorithms_ that can anticipate needs based on historical patterns and real-time metrics. These systems can make scaling decisions in milliseconds, responding to changes faster than any human operator. This granular approach ensures resources are used efficiently while maintaining optimal performance under varying loads.

## Sustainable infrastructure

Environmental responsibility has become a critical consideration in infrastructure management. **The environmental impact of cloud infrastructure** varies significantly by region – from as low as 30-45 grams of CO2 per kilowatt-hour in regions using nuclear and renewable energy to over 600 grams in areas relying on coal power.

_AI plays a crucial role in optimizing sustainability_ through intelligent resource allocation and workload distribution. By analyzing power usage effectiveness (PUE) and regional power grid characteristics, AI systems can optimize workload distribution for minimal environmental impact while maintaining performance requirements.

## Implementation challenges and considerations

While the potential of AI in infrastructure management is immense, **several critical challenges must be addressed**. Infrastructure management directly impacts business operations, and errors can have severe consequences. Organizations must maintain careful human oversight of AI systems, particularly when implementing configuration changes or scaling decisions.

_Data sovereignty and governance present additional challenges_, especially for organizations operating across multiple jurisdictions. AI systems require access to infrastructure data to function effectively, raising important questions about data security and compliance with regional regulations.

## The future of infrastructure management

The integration of AI into infrastructure management is giving rise to new roles and responsibilities. **The emergence of AIOps teams** specifically focused on managing and maintaining AI systems represents a new evolution in infrastructure management.

_The future will likely see a shift_ from general-purpose large language models to more specialized, efficient AI solutions focused on specific infrastructure tasks. These purpose-built models will provide enhanced accuracy while consuming fewer resources, making them more practical for continuous operation.

## What's next?

The integration of artificial intelligence into cloud infrastructure management marks a pivotal moment in the evolution of DevOps and cloud computing. While the challenges of AI adoption – from oversight and security to sustainability – require careful consideration, **the transformative potential of AI-driven infrastructure management is undeniable**.

_Cloud application platforms like_ _Upsun_ are not merely observers in this transformation but active participants in shaping its direction. Through its comprehensive platform capabilities, from Git-driven infrastructure to integrated observability, Upsun provides the foundation organizations need to leverage AI effectively in their infrastructure management.

Beyond providing this foundation, **Upsun is actively developing AI-enhanced capabilities** to augment the platform experience. These initiatives include AI-powered configuration assistance to help developers optimize their infrastructure definitions, intelligent performance optimization recommendations based on Blackfire insights, and advanced scaling and environment management that leverages AI for more efficient resource allocation. Through these innovations, Upsun is working to make AI-driven infrastructure management more accessible and practical for organizations of all sizes.

The future of cloud infrastructure management lies in the thoughtful integration of AI capabilities with human expertise, supported by platforms that understand and embrace this evolution. Organizations that prepare for this transformation now – by developing robust AI governance frameworks, building relevant expertise, and choosing platforms that support their AI journey – will be best positioned to create more efficient, secure, and sustainable technology operations.

As we move forward, the success of AI in infrastructure management will not be measured solely by the sophistication of the technology, but by how effectively it enables organizations to focus on their core mission while maintaining reliable, efficient, and sustainable infrastructure. With the right foundation and careful consideration of both opportunities and challenges, the AI revolution in cloud infrastructure promises to deliver on its transformative potential.

### [Blackfire: A complete monitoring & observability solution | Upsun](https://upsun.com/blog/monitoring-and-observability/)

# Blackfire: a complete observability solution

**Note:** Blackfire is the Upsun observability solution included with every PHP and Python project on the Upsun PaaS and powering the continuous profiling of your Go and Node.js applications.

The quest for perfect performance is a never-ending journey. It is not won as soon as that one bottleneck has been patched, even if that might feel like an epic and glorious battle. It is an ongoing effort to quickly identify issues and squash them before they spiral out of control to keep the performance running as smoothly as possible.

But that raises the question: is perfect performance even possible? Well, perfection in any field isn’t _really_ possible. But you can get very, very close.  

### **Crafting an observability strategy for near-perfect performance**

Let’s come up with a battle plan! Or better yet, an observability strategy. That type of plan is critical for organizations looking to deliver reliable, high-performance software in a fast-paced and constantly changing environment.

Implementing a monitoring and observability strategy allows organizations to take a proactive approach to monitoring their systems, which is a far better tack to take than waiting for problems to arise, then reacting to them.

Blackfire provides a unique and extensive monitoring and observability solution that lets you build your own strategy and the best part is, it’s available with Upsun. 

The following are the factors of a possible observability strategy you can adopt. If you choose to accept it, your mission is to build a plan that fits your organization as well as your coding and deployment practices.

### **Blackfire monitoring**

Blackfire monitoring provides a bird’s-eye view of one application’s performance, including all the HTTP traffic that is monitored out of the box. The CLI one can be instrumented as well with a simple configuration.

Blackfire monitoring lets you know **when and where** a specific issue happened so you can react quickly to it. It allows you to drill down to a specific transaction to explore the contribution of the different services used—such as Redis, Database, HTTP, etc—to the response time.

### **Blackfire alerting**

As you won’t be sitting all day waiting for a crash to happen, you can set up alerts so you can be notified. Accessing critical information doesn’t have to conflict with your existing workflow. Alerts and cooldowns escalate to any channel you are already using, such as  email, Slack, Microsoft Teams, or other web services.

### **Blackfire profiler**

Once a diagnosis is made, you can dig as deep as possible into the application behavior with Blackfire profiler until you locate the exact function or service calls that are responsible for the performance issue. Blackfire profiler also lets you understand **why** your application behaves a certain way.

All your SQL queries and HTTP calls are identified and listed alongside the call graphs and timeline views. To make monitoring and observability insights more comprehensive, the profile also provides Recommendations, an list of actionable insights and detailed information about the cache usage and configuration.

### **Blackfire tests suite**

Once the code of a script is optimized, a good practice is to compare the before and after profiles to ensure our fix doesn’t cause any side effects. 

There’s one more thing to do before pushing to production: writing tests.

Blackfire provides an extensive test suite. Custom assertions are defined in a .blackfire.yaml file, and they are evaluated every time a profile is triggered. This eases the detection of performance regressions.

There are also integrations with PHPUnit, Behat, Symfony Functional Tests, and Laravel tests. Other integrations could be made thanks to Blackfire PHP and Python SDKs.

### **Synthetic monitoring**

The performance of your applications’ critical user journeys can also be evaluated regularly. Those user journeys, as well as the expectations for each of them, can be described in scenarios.

When evaluating, a profile is triggered at every step of every scenario. As for all profiles, the assertions matching the requests are evaluated. A build report is the aggregated results of all those profiles.

A build report is a convenient tool for checking the health of large parts of an application at once. Blackfire builds can be triggered manually, periodically, and through webhooks.

We cannot recommend you enough to plug the latest generation of Blackfire build into your CI/CD pipelines. Such integrations prevent a pull request from being merged or code from being deployed into production if it degrades the performance of your application. It ensures the performance of your applications in the long run.

Then, automated and periodic performance tests plugged into the CI/CD pipelines safeguard the application preventing performance degradations.

Article originally published by Thomas di Luccio on Blackfire.io. 

### Watch this video

### [Gatsby and its benefits for web development | Upsun](https://upsun.com/blog/gatsby-benefits-for-web-development/)

# Learn about Gatsby and its benefits for web development

Traditional dynamic websites have long been associated with challenges of performance, security, and scalability. As sites grow more complex, managing server infrastructure, ensuring fast load times, and maintaining secure systems becomes increasingly difficult. Jamstack, introduced by Netlify co-founder Matthias Billmann at SmashingConf 2016, emerged as a solution to these challenges. The _Jam_ (short for JavaScript, APIs, and Markup) in _Jamstack_ prioritizes performance, security, and a streamlined developer experience.

Gatsby is a React-based framework built on Jamstack principles, bringing together modern web development practices like automatic performance optimization and seamless content integration. Whether you're building an e-commerce site, marketing page, or documentation portal, Gatsby offers tools and optimizations to create web experiences that engage users and perform well in search engines.

This article explores Gatsby's history, key benefits, and real-world applications. It also shows how it uses React and GraphQL to deliver high-performing static sites with impressive built-in features.

## The rise of Jamstack

The concept of dynamic websites first emerged in the mid-1990s. During this era, technologies like ColdFusion, PHP, and Active Server Pages were developed, which helped developers create interactive and data-driven websites. But as the complexity of websites grew, challenges like performance, security, and scalability also increased. Dynamic websites, while powerful, faced several limitations:

-   **Performance issues.** Server-side processing often caused slower load times, especially under high-traffic conditions.
-   **Security vulnerabilities.** The interaction between servers and databases presented more potential for attacks.
-   **Scalability challenges.** Handling increased traffic required complex and costly server infrastructure.
-   **Maintenance overhead.** Regular updates, plugin management, and database maintenance were added to the ongoing workload.

To address these challenges and provide faster, more secure, and more easily scalable websites, Jamstack shifted the workload from the server side to the client side. It uses static site generation, content delivery networks (CDNs), and client-side JavaScript to create dynamic user experiences without the overhead of traditional server-side rendering. Jamstack is composed of three components:

-   **JavaScript.** Handles dynamic functionalities in the browser, manages API calls, and enhances user experience without server-side processing.
-   **APIs.** Serve as a bridge between the static frontend and dynamic data, enabling a decoupled architecture and supporting serverless functions.
-   **Markup.** HTML files are generated during the build process, improving performance and SEO.

By decoupling the frontend from the backend and adopting this modular approach, Jamstack offers improved performance, enhanced security, and easier scalability. It addresses the limitations of traditional dynamic websites while providing a more streamlined development process, making it an attractive option for building modern, efficient web applications.

## The introduction of Gatsby

Gatsby's v1 was launched in 2017. It was introduced as a static site generator, offering the speed of static sites with the features of dynamic websites. By combining the best of two worlds, it became a popular choice among developers. According to the Jamstack community survey of 2022, around 28 percent of developers use Gatsby.

The community support for Gatsby is also enormous; their GitHub repo has more than 55k stars, and almost four thousand people have already contributed to the codebase. Companies like National Geographic and SitePoint rely on Gatsby to power their websites.

## Benefits of Gatsby in web development

Gatsby's unique features have made it a popular choice within the Jamstack community. Let's explore what sets it apart.

### Performance and speed

Page speed directly impacts user engagement—Google's research shows that bounce rates increase by 32 percent when page load times jump from one to three seconds. Compared to other frameworks like Next.js or Nuxt, Gatsby sites load one to three seconds faster. Gatsby also gets a higher Lighthouse score than Next.js or Nuxt.

The framework implements intelligent code splitting, breaking down an application code into smaller chunks and loading only what's needed for each page. Gatsby's image optimization automatically handles responsive images and lazy loading and handles progressive image formats. The framework also employs asset prefetching, predictively loading the next page's resources when users hover over links, while critical CSS inlining embeds essential styles directly in the HTML.

Sites like Jaxxon and Business.com use Gatsby to improve their performance significantly.

### GraphQL integration

One of the most important features of Gatsby is its integration with GraphQL. Gatsby creates a unified data layer that can combine data from multiple sources into a single queryable layer. GraphQL acts as a centralized query layer in Gatsby, allowing you to pull content from multiple sources, including CMSs, APIs, Markdown files, and databases. 

Here’s a sample `gatsby-config.js` file:

```Javascript
require("dotenv").config({
  path: `.env.${process.env.NODE_ENV}`,
})

 
module.exports = {
  plugins: [
// Source data from local Markdown files
{
   resolve: `gatsby-source-filesystem`,
   options: {
     name: `data`,
     path: `${__dirname}/src/data/`,
     // Ignore files starting with a dot
     ignore: [`**/\.*`],
     // Use "mtime" and "inode" to fingerprint files (to check if file has changed)
     fastHash: true,
   },
},

 
// Source data from a headless CMS (Sanity)
{
   resolve: `gatsby-source-sanity`,
   options: {
     projectId: `abc123`,
     dataset: `blog`,
     // A token with read permissions is required if you have a private dataset
     token: process.env.SANITY_TOKEN
   },
},

 
// Optimize images
`gatsby-plugin-image`,

 
// Source data from a custom API (using a custom plugin)
{
   resolve: "gatsby-source-custom-api",
   options: {
     url: process.env.CUSTOM_API_URL,
     // Options for fetching data from your API can be added here
   },
},

 
// Source data from MongoDB collections
{
   resolve: `gatsby-source-mongodb`,
   options: {
     dbName: process.env.MONGODB_DB_NAME || `local`,
     collection: process.env.MONGODB_COLLECTIONS?.split(',') || [`documents`, `vehicles`],
   },
},
  ],
};
```

This configuration above sources data from local Markdown files, a headless CMS (Sanity), a custom API, and MongoDB collections, while also optimizing images using Gatsby plugins.

This unified approach makes it significantly easier to organize and manage content across a website. For example, you can simultaneously query content from a Strapi or WordPress backend, Markdown files, and third-party APIs using a single GraphQL query.

Gatsby's GraphQL integration is especially effective in headless CMS setups, with its plugin ecosystem allowing easy connections to any API-driven data source—from content management systems to e-commerce platforms like Shopify.

### SEO superpowers

Gatsby's architecture is designed to boost search engine optimization, making websites more discoverable and improving search engine rankings. Here's how Gatsby empowers SEO strategy:

-   **Performance optimization.** Search engines favor fast-loading websites, and Gatsby delivers exceptional performance through several built-in features, like automatic code splitting, image optimization and lazy loading, and automated metadata generation and management.
-   **Built-in SEO tools**. Gatsby includes built-in SEO features that make it easier to optimize sites for search engines. The framework supports canonical URL handling, allowing you to specify preferred URLs to avoid duplicate content issues. With plugins like gatsby-plugin-sitemap, Gatsby can automatically generate sitemaps, making it easier for search engines to crawl and index site content effectively. Additionally, Gatsby provides support for structured data and schema markup, helping search engines interpret and display site information as rich snippets. Together, these features help boost the search visibility and ranking of Gatsby-powered websites.

### Plugin ecosystem

Gatsby also offers an extensive plugin ecosystem that helps extend the functionalities of Gatsby sites with ease. Gatsby's plugin library consists of more than three thousand plugins contributed by a passionate community of developers. These plugins cover a wide range of functionalities, from data sourcing to advanced features like image optimization, search, and analytics integration. The plugin library has a wide variety of plugins to fit different project requirements.

## Downsides and considerations

While Gatsby provides powerful tools for static site generation and data handling, it may not always be the best fit. Depending on the project size and requirements, there might be better alternatives.

### Build-time challenges

As projects grow in size and complexity, Gatsby's build process can become a significant bottleneck for a project. Large sites with thousands of pages or frequent content updates may experience build times stretching to thirty minutes or more. This can be particularly problematic for content-heavy sites that require frequent updates as each change triggers a complete rebuild. While incremental builds in Gatsby Cloud help mitigate this issue, they come with additional costs and complexity.

### Overkill for small projects

Although Gatsby's data handling features are impressive, they can be excessive for simpler projects. The framework requires proficiency in both React and GraphQL—technologies that might be unnecessary for straightforward websites. When you're building a simple five-page business website or a basic blog, this technical complexity can slow down development, especially for teams unfamiliar with these technologies.

### Dynamic content limitations

For applications requiring real-time updates or heavy user interactions, frameworks like Next.js, Remix, or Nuxt.js might be more suitable. These alternatives offer better support for server-side rendering and dynamic content handling. While Gatsby can handle dynamic content through client-side JavaScript, its architecture is optimized for static content. Projects requiring features like real-time chat, live updates, or complex user interactions might find Gatsby's static-first approach limiting.

## Alternative solutions

Based on the project size, development team, and other requirements, there are a few other tools that might be more suitable. For instance, Next.js is a powerful alternative for React developers who need to handle dynamic content more efficiently. Its hybrid approach supports both server-side rendering and static site generation, making it more versatile than Gatsby. Through incremental static regeneration\], Next.js enables real-time content updates without rebuilding the entire site. The framework's flexible data-fetching methods make it particularly well suited for applications requiring frequent content updates or user-specific data handling.

If you work with Vue.js, Nuxt.js provides a robust solution for dynamic applications. Its built-in server-side rendering capabilities and support for static site generation improve both performance and SEO. The framework includes a sophisticated middleware system that simplifies the handling of complex routing and authentication scenarios. These features make Nuxt.js an excellent choice for applications that need to maintain real-time content updates while preserving strong SEO performance.

If a project needs real-time updates, complex user interactions, or personalized content through server-side rendering, frameworks like Next.js or Nuxt.js may be a better fit than Gatsby. For example, e-commerce platforms with live inventory updates or social media apps with constant interactions benefit from these dynamic features. While Gatsby is ideal for high-performance static sites, the choice depends on the project needs and the level of interactivity required.

## Conclusion

In this article, we introduced Gatsby, a powerful framework built on Jamstack architecture principles. We also highlighted some of Gatsby's benefits, such as enhanced performance, seamless GraphQL integration, and robust SEO capabilities. While Gatsby excels in delivering high-performance static sites, it's essential to assess project-specific needs as frameworks like Next.js or Nuxt.js may be more suitable for applications requiring dynamic content and real-time interactions.

Upsun is a self-service, fully managed, secure, developer-focused cloud application platform that offers a streamlined solution for deploying Gatsby sites – either in isolation or together with many data sources and frontends all a part of the same project. Upsun supports the use of Git submodules, enabling you to manage complex projects with multiple applications, such as a Gatsby frontend alongside other components. Upsun simplifies the deployment process and ensures that Gatsby sites are efficiently hosted and maintained. Try it out for free!

### [PHP fun with FFI: Just enough C | Upsun](https://upsun.com/blog/php-ffi-and-c/)

# PHP fun with FFI: Just enough C

One of the new and exciting features of PHP 7.4 is its support for Foreign Function Interface, or PHP FFI. PHP FFI provides a much easier way to load code from other, faster languages into PHP than writing an extension. That said, easier doesn't mean trivial. There is some work involved, and it's not appropriate in all situations. 

## **Anatomy of a C library**

The most common language for FFI integration is C, in part because of its ubiquity and in part because it's the most common language for people who want to squeeze the most performance out of their computer. C doesn't work like PHP, though, so let's go over some basics of C.

To be clear, this is not a tutorial on C. It's a tutorial on building C, and covers just barely enough to get you running with PHP FFI. How Stuff Works has a reasonable crash course on C itself if you are interested.

C is a compiled language. That means you write source code in one file and then run a compile command on it, which produces a separate, machine-readable-only file. That's in contrast to PHP and other interpreted languages, which will compile the source file into executable code on the fly and keep it in memory, discarding it when done. 

C source code lives in a file that ends in `.c`. The code can be compiled into several different forms:

-   A stand-alone executable, or "binary"
-   A static library, which can then be combined with other static libraries into a stand-alone executable
-   A shared library, which can be loaded at runtime by a stand-alone executable or several stand-alone executables

A single binary is the easiest to build, but for PHP FFI we need a shared library. We'll build both for demonstration purposes.

Another aspect of C is that the source file alone is not enough. C also has "header files," which end in `.h`, that define the interface of a package. It's a similar concept to interfaces in C, but more general. The header file defines the functions and data types that a library exposes to other libraries. PHP doesn't really have an equivalent, but it's somewhat akin to "exports" for Javascript modules; not every function or data type needs to be made public.

### Write your own

Let's start with a simple header file to demonstrate how it all works. Here's our initial `points.h`:

```shell-session
struct point {
   int     x;
   int     y;
};

double distance(struct point first, struct point second);
```

This file defines one `struct` called `point`. A struct is similar to a class, but it has no methods. (Historically, a class is "a struct with methods" rather than the other way around.) This struct is composed of 2 integers, `x` and `y`.

The header also declares one public function, `distance`, that takes two `point` structs and returns a `double`. That's C-speak for "double-precision floating point number," which PHP developers will recognize as "float.” Just like a PHP interface it does not define the body, just the signature. The point of the header file is to tell other code, "This is what I'm going to look like when compiled."

We'll come back to the header file when we talk about FFI, but that's enough for C.

Now we need a file for the implementation of `distance`:

```shell-session
#include "points.h"
#include <math.h>

double distance(struct point first, struct point second) {
   double a_squared = pow((second.x - first.x), 2);
   double b_squared = pow((second.y - first.y), 2);

   return sqrt(a_squared + b_squared);
}
```

The `#include` lines specify what dependencies this library has. The first, in quotes, indicates the `points.h` file in the same directory. That's what we wrote a moment ago. The second, `<math.h>`, means the `math.h` header file that's available in the system's standard library directory. The standard C library's complex math functions are provided in a separate library from the baseline, because when they were first defined in the 1980s, math features on CPUs were expensive and rare, so people would often skip them and reimplement just the few bits they needed themselves. That's no longer the case, but old standards die hard.

The `distance` method computes the distance between two points using our old friend the Pythagorean Theorem. The `pow()` and `sqrt()` functions come from the math library. (Side note: The `sqrt()` function is pronounced "squirt.” I will tolerate no disagreement on this point.)

Finally, we have a third file that will make use of the `distance()` function. A stand-alone executable needs to have a function named `main()`, which is what gets executed when the program runs. Ours looks like this:

```shell-session
#include <stdio.h>
#include "./points.h"

int main() {

   struct point p1;
   struct point p2;

   p1.x = 3;
   p1.y = 4;
   p2.x = 7;
   p2.y = 9;

   printf("Distance is: %f\n\n", distance(p1, p2));

   return 0;
}
```

It should be fairly familiar at this point. `#include <stdio.h>` provides the function signatures for the standard input/output library, while `#include "./points.h"` gives this file access to the functions from our points library. The `main()` function creates two points and then computes and prints their distance. `printf()` is part of the `stdio` library and works basically the same as in PHP. (Or rather, PHP's `printf()` is just a thin wrapper on C's.)

### Make

Now that we have our source files, we need to build them. This is actually a multi-step process in C. Of course, you'll need a C compiler and other build tools. On a typical Linux system there is a package named `build-essentials` (or similar) that you can install that will include everything we mention here. For other platforms consult their documentation as installing them yourself can be a bit involved.

Because there's several steps involved we're going to use a "make file.” GNU Make is the original granddaddy task runner; Ant, Phing, Grunt, Gulp, DoIt, and the rest are all reimplementations of Make. Make is itself a very thin layer on top of shell scripting, for better or worse. (I would link you to its documentation, but unfortunately its documentation is shockingly arcane given how simple Make itself is.)

We'll start with a file named `Makefile` (capitals matter) with a single "build target":

```shell-session
# Makefile

points.o: points.h points.c
  gcc -c points.c
```

That creates a single build target, `points.o`, which depends on two files: `points.h` and `points.c`. It's typical for build targets to be the name of the file they produce. Indented under that line is one or more shell commands to run. (Note: The indentation _must_ use a tab character, not spaces. Them's the rules, I didn't make 'em.)

`gcc` is the `GNU Compiler Collection` and is the most widely used C compiler, but not the only. It has about 14 million possible options, of which we're going to use about four. The `-c` switch means "Compile this file, but don't do any of the other steps.” The output of that command is a new file named (surprise!) `points.o`. This is the "object file,” or the raw machine code version of `points.c`.

If we run `nm points.o`, it will list the "symbols" in the object file. (`nm` is short for "name" and dates from an era where memory was so tight and keyboards so hard to use that programmers didn't believe in vowels.)

```shell-session
0000000000000000 T distance
             	U _GLOBAL_OFFSET_TABLE_
             	U pow
             	U sqrt
```

That lists four functions encoded into the object file: Our `distance` function has its source code included (hence the T), while `pow`, sqrt\`, and some internal bookkeeping are also mentioned but not defined internally. That's an indication to the next step, "Hey, I need these things.”

We also want a target to compile the `main.c` file:

```shell-session
main.o: main.c
  gcc -c main.c
```

Next we have a choice. We can build a stand-alone executable for `main`, or we can turn our points code into a shared library. For demonstration's sake we'll do both:

```shell-session
main: main.o points.o
  gcc -o main main.o points.o -lm
```

This `gcc` command reads "compile to the output (`-o`) file `main`, using object files `main.o` and `points.o`, and link against library `m`." The target `main` depends on the other targets `main.o` and `points.o` so will run those targets if necessary to produce those files if they don't already exist.

The `m` warrants extra mention; it can be read as "Here's another object file to include, named libm, in the standard library directory on the system." The "lib" part of the name gets dropped in the `-l` command. (That's lowercase L, for those reading this in a sans-serif font.) `m` in this case is the C standard math library we mentioned before. (See previous note about programmers in the 80s being allergic to typing full words.)

The process of taking multiple object files and plugging them into each other is called "linking.” When they're all plugged together into a single executable file, it's called "static linking.”

We can now run `make main` at the command line. That will:

-   Compile `points.c` to a machine code file `points.o`.
-   Compile `main.c` to a machine code file `main.o`.
-   Superglue those two files together, along with the C standard math library, and wrap it up into a format that the operating system knows how to execute.

Now running `./main` on the command line should produce the following output:

```shell-session
$ ./main
Distance is: 6.403124
```

Yay.

There's two more steps we need, though. First, `main` is not useful for PHP FFI. For that we need a shared library. That will take another build target in `Makefile`:

```shell-session
points.so: points.o
	# Wrap the object file into a shared object.
	gcc -shared -o points.so points.o -lm
```

That command reads, "Create a shared library, output to `points.so`, by combining `points.o` and the `libm` library." It's very similar to the command for main, but this time we produce a `.so` file, or "Shared Object" file. That takes the same code as the stand-alone binary, but packages it up differently with hooks for other C programs to load it into memory separately and access it on-demand. It's the `.so` file that we'll need for PHP FFI.

There's also one other target we need to be complete, and that's `clean`:

```shell-session
clean:
  rm -f *.o *.so main
```

Any time you're compiling code, you want to be able to wipe out your compiled versions and start from a clean slate. In this case we just `rm` all compiled files. Make sure you add `.o` and `.so` to your `.gitignore` file, too, since you don't want to commit those to Git.

Here's our final `Makefile` so far:

```shell-session
points.o: points.h points.c
  gcc -c points.c

points.so: points.o
  gcc -shared -o points.so points.o -lm

main.o: main.c
  gcc -c main.c

main: main.o points.o
  gcc -o main main.o points.o -lm
  chmod +x main

clean:
  rm -f *.o *.so main
```

### Onward to PHP!

Building a C program can easily get vastly more involved and complex than this trivial example. The goal today has been to get our feet wet and explain enough of the anatomy of a C library that we can start plugging it into PHP's FFI layer. The most important parts in the end will be `points.so` and `points.h`, both of which we'll need for PHP.

(Many thanks to Anthony Ferrara for his help explaining how to build C.)

### [AI governance migration checklist for IT leaders | Upsun](https://upsun.com/blog/ai-governance-migration-checklist/)

# AI governance migration checklist for IT leaders

Most AI governance migrations fail because they are treated as purely technical exercises, such as moving an API key or a model endpoint from one cloud to another.

If you migrate unmanaged AI usage without fixing the underlying access model, you aren’t migrating; you are just moving risk. For IT leaders, a successful migration is the only opportunity to refactor "shadow AI" into enforceable, governed workflows without freezing developer velocity.

This checklist provides a structured framework to bring existing AI usage under structured control while maintaining delivery momentum.

### **Phase 1: Surface the shadow AI reality**

Before moving a single service, you must bridge the gap between your official policy and actual developer behavior.

-   **Inventory shadow AI usage:** Identify unsanctioned use of third-party LLM providers or unmanaged "vibe-coding" assistants within the dev team.
-   **Map data touchpoints:** Which AI workflows interact with regulated data (GDPR, PCI, or proprietary IP)?
-   **Identify implicit access:** Locate agents or scripts currently running with broad, "all-access" tokens rather than scoped service accounts.
-   **Baseline spend:** Audit the current fragmented costs of AI API usage across disparate team accounts.

### **Phase 2: Refactor governance (decide what to move vs. what to block)**

The goal of migration is to fix what no longer scales. Some patterns should never be carried forward.

-   **Standardize identity:** Replace personal developer tokens with platform-level service accounts.
-   **Define environment scopes:** Ensure AI agents are blocked from production data during testing phases.
-   **Codify the guardrails:** Move from "paper policies" to machine-readable rules.
    -   **The Upsun advantage:** Use declarative, Git-driven configuration (upsun.yaml) to make platform rules explicit and reviewable via PR.
-   **Establish "pause" criteria:** Identify high-risk workflows (for example, autonomous agents with write-access to production databases) that must be refactored before they are permitted to migrate.

### **Phase 3: The migration execution (validating boundaries)**

This is where you move the workflow. The focus here is on automated boundary enforcement.

-   **Validate in staging/development environments:** Deploy the migrated AI workflow into an isolated environment that clones production logic but stays air-gapped from live users.
    -   **The Upsun advantage:** Use production-perfect preview environments to test how AI agents behave under new security constraints without touching production.
-   **Enforce via pipeline:** Ensure compliance checks, such as WAF rules and audit logging, are triggered automatically during the deployment.
-   **Test "failure modes":** Intentionally trigger a governance violation (for example, an agent trying to access an unauthorized API) to confirm the platform blocks the action.
-   **Audit trail confirmation:** Verify that the migration process itself is documented in the Git history, showing who changed which governance control and why.

### **Phase 4: Operationalizing continuity (the "done" state)**

A migration is only "complete" when governance becomes an inheritable capability of the platform, not a manual review task.

-   **Enable inheritance:** Do new AI projects automatically inherit the security posture of the platform?
-   **Shift to monitoring:** Transition from "blocking everything" to proactive observability.
-   **Auditor readiness:** Can you generate a report of all AI environment changes over the last 30 days without manual data entry?
    -   **The Upsun advantage:** The centralized console in Upsun provides a single source of truth for every environment, deployment, and access change across your entire AI portfolio.

## **Why platforms matter during governance migration**

Governance migrations are significantly harder when environments and configurations vary by team. When every project has a bespoke deployment path, introducing a new security control requires a bespoke project.

Upsun makes governance migrations tractable by standardizing the foundation.

By using a platform that treats infrastructure as code and environments as disposable clones, IT leaders can introduce controls once and apply them broadly. This shifts governance from a "policing" function to a "platform" function.

### **How Upsun supports your migration roadmap**

-   **Instant staging/development environments:** Stop guessing if a security policy will break the app. Test it on a clone of your entire production stack first.
-   **GitOps workflow:** Every change to your AI governance is a pull request. It is reviewable, reversible, and auditable.
-   **Multi-cloud portability:** Standardize your governance once and deploy it across AWS, Azure, IBM Cloud, or GCP without rewriting your security model.

## **What to do next**

If AI tools and agents are already embedded in your organization, your migration has already begun. You just haven't governed it yet.

Start by running the phase 1 audit above. Once you understand the gap between your current usage and your required security posture, you can determine if your current platform is an accelerator or a bottleneck.

### [Rethinking digital transformation: Why Upsun is the smarter choice](https://upsun.com/blog/rethinking-digital-transformation/)

# Why "build your own" digital transformation is a flawed strategy

Digital transformation has become a buzzword for organizations aiming to modernize operations, improve customer experiences, and stay competitive. Yet, many enterprises embark on this journey with the wrong approach: building internal platforms from scratch. While the allure of tailoring every detail to your unique business needs is tempting, this strategy often leads to costly, time-consuming, and ultimately unsustainable outcomes.

According to a 2023 McKinsey report, 70% of digital transformation projects fail to achieve their objectives. Why? The root causes include prolonged development timelines, inability to adapt to emerging technologies, and mounting technical debt. Companies that insist on reinventing the wheel may inadvertently sabotage their own success. The allure of starting from scratch often blinds businesses to the realities of resource constraints and technical complexity. Meanwhile, competitors leveraging established solutions gain a critical time-to-market advantage, widening the gap.

## **The Problem with "Reinventing the Wheel"**

1.  Protracted Development Timelines: Building an internal platform can take years. During that time, market dynamics shift, customer needs evolve, and competitors may outpace you with faster, more agile solutions. By the time your platform is live, it might already be outdated. Even worse, delayed launches can erode trust among stakeholders and customers who expect swift innovation.
2.  Resource Drain: Development teams are often stretched thin, trying to balance innovation with maintenance of existing systems. The result? Burnout, ballooning costs, and compromised quality. When resources are diverted toward platform development, critical business functions such as product innovation, customer service, and market analysis often take a back seat. This imbalance can hurt an organization’s ability to stay competitive.
3.  Technical Debt: An internally built platform requires ongoing updates, patches, and evolution to keep up with modern standards. Without continuous investment, the platform can quickly become a liability rather than an asset. Over time, the cost of addressing accumulated technical debt may far exceed the initial development budget, leaving businesses with a cumbersome and expensive legacy system.
4.  Lack of Expertise: Most organizations are not platform companies. Expecting in-house teams to design, build, and maintain a world-class platform is an unrealistic expectation and distracts from core business objectives. Without access to cutting-edge tools and industry insights, internally developed platforms often fall short of delivering the scalability, security, and performance needed to compete effectively.

## **Why Upsun is the Antidote**

Upsun flips the script on traditional digital transformation by providing a platform-as-a-service (PaaS) that’s ready to use, flexible, and built to evolve. Here’s how:

1.  Accelerated Time-to-Value: With Upsun, you can deploy applications in days, not years. Automated infrastructure management, instant preview environments, and Git-driven workflows mean your team spends less time setting up and more time innovating. Rapid deployment ensures you can respond to market changes with agility, allowing you to seize new opportunities before competitors even begin implementation.
2.  Future-Proof Flexibility: Unlike bespoke platforms, Upsun’s architecture supports multi-app environments, multiple programming languages, and seamless integrations. As your business grows, the platform scales and adapts without requiring a complete overhaul. This adaptability ensures that your technology keeps pace with evolving business needs, giving you a long-term edge.
3.  Built-In Expertise: Upsun is designed by developers for developers, meaning it comes with the best practices baked in. From automated compliance to advanced observability tools, Upsun handles the complexities so your team doesn’t have to. Upsun’s features include automated performance monitoring and security updates, enabling businesses to stay compliant and resilient in a rapidly changing regulatory landscape.
4.  Cost Efficiency: Instead of diverting resources to build and maintain an internal platform, businesses can redirect those funds toward strategic initiatives. Upsun’s usage-based pricing ensures you only pay for what you use, avoiding the sunk costs of underutilized infrastructure. This cost predictability helps businesses plan more effectively while maintaining financial flexibility.

## **Opinionated Solutions for Digital Transformation**

### Stop Building, Start Adopting

The common approach to digital transformation is to start by building from scratch. But why start at zero when platforms like Upsun already offer 80% of what you need out-of-the-box? By adopting rather than building, businesses gain immediate access to proven solutions and eliminate months (or years) of development. Moreover, adopting a PaaS like Upsun enables businesses to stay ahead of technology trends without the constant need for re-engineering.

### Focus on Outcomes, Not Infrastructure

The success of digital transformation should be measured by outcomes: customer satisfaction, faster deployment cycles, and reduced operational costs. Upsun allows you to focus on delivering these outcomes by abstracting away the complexities of infrastructure management. By eliminating the need for manual configuration and maintenance, Upsun empowers teams to prioritize innovation and customer-centric strategies.

### Think Beyond IT

Digital transformation is not just an IT initiative—it’s a business strategy. Upsun bridges the gap between technical and business teams by offering tools that simplify collaboration, provide real-time insights, and align technology with organizational goals. When business leaders and developers work in harmony, organizations can unlock unprecedented levels of efficiency and creativity.

### Embrace Continuous Evolution

In today’s fast-paced environment, a static platform is a liability. Upsun’s continuous updates and compliance certifications ensure your digital foundation stays ahead of industry standards without requiring manual intervention from your team. Continuous evolution is the key to remaining agile and competitive in a world where the only constant is change.

### Final Thoughts

Digital transformation doesn’t have to be a decade-long endeavor fraught with risk and uncertainty. By leveraging a platform like Upsun, businesses can sidestep the pitfalls of traditional approaches, gain immediate value, and ensure long-term flexibility. With its ready-to-use capabilities, built-in expertise, and scalability, Upsun represents a smarter, faster, and more sustainable path to transformation. It’s time to rethink the way we approach transformation—not as a one-time project, but as an ongoing evolution that thrives on agility and innovation.

Ready to accelerate your transformation? Discover how Upsun can redefine your digital strategy.

### [DevOps in 2024: Essential Insights from the DORA Report | Upsun](https://upsun.com/blog/insights-from-the-devops-dora-annual-report/)

# Essential Insights from the DevOps DORA Annual Report:  Need to Know in 2025

The annual DORA (DevOps Research and Assessment) report has reached its tenth year, analyzing data from nearly 3,000 professionals worldwide. The 2024 edition reveals significant shifts in how teams approach software delivery and operational performance in a rapidly evolving technology landscape.

_Note: The term DORA is not related here to the Digital Operations Resilience Act!_

## The Changing DevOps Landscape

This year's report highlights several important trends:

-   **AI adoption is accelerating rapidly** across development workflows
-   **Platform engineering** is becoming essential for team productivity
-   **User-centric approaches** continue to drive successful outcomes
-   **Performance metrics** remain critical for measuring development effectiveness

## AI in Development: Benefits and Challenges

AI has firmly established itself in the development workflow. According to the report, 81% of organizations have shifted priorities to incorporate AI more deeply into their applications and services. Notably, this echoes feedback shared in the Stack Overflow 2024 Developer survey, which indicates 79% of respondents plan to use AI tools in their development this year.

Developers now routinely use AI for:

-   Writing code (74.9%)
-   Summarizing information (71.2%)
-   Explaining unfamiliar code
-   Optimizing code quality
-   Generating documentation

While many developers report productivity increases, the report also uncovers complications. AI adoption can sometimes lead to decreased software delivery performance and reduced time spent on tasks developers consider valuable.

This suggests that simply adding AI tools to your workflow isn't enough. You need to:

1.  Evaluate AI's role in your development process critically
2.  Maintain focus on small batch sizes
3.  Prevent AI-generated code from creating larger, more complex changes
4.  Create a culture that encourages experimentation with AI tools

## Platform Engineering: Why Cloud Application Platforms Beat DIY Solutions

The DORA report confirms what many forward-thinking organizations already know: platform engineering significantly improves developer experience through automated, self-service workflows that abstract away delivery complexities.

While organizations using internal developer platforms (IDPs) see measurable benefits (8% higher individual productivity, 10% improved team performance), the report also reveals concerning challenges:

-   Potential decreases in throughput (8%) and change stability (14%)
-   Increased developer burnout when platforms aren't properly maintained
-   Significant ongoing investment in platform development and maintenance
-   Resources diverted from core business objectives to platform maintenance

This is precisely where cloud application platforms like Upsun offer a compelling advantage. Rather than building and maintaining your own platform—requiring months or years of development, continuous security updates, and dedicated team resources—Upsun provides an enterprise-ready solution that delivers immediate value while reducing operational burden.

With Upsun, you get:

-   A thoroughly tested, continuously improved platform built by developers for developers
-   Immediate access to preview environments with instant data cloning
-   Multi-cloud deployment options with comprehensive observability tools
-   Regular security updates and compliance certifications maintained for you
-   Self-service capabilities that empower developers without requiring platform expertise

The DORA report's findings align perfectly with Upsun's core philosophy: successful platforms must prioritize a user-centered design approach, enable developer independence, and continuously evolve based on user feedback. Unlike DIY solutions that can degrade over time as resources are redirected, Upsun remains focused on platform excellence as its primary mission.

## User-Centricity: The Foundation of Success

Amid technological advances, the DORA report confirms that user-centricity remains fundamental to successful DevOps practices. Organizations prioritizing end-user experience consistently deliver:

-   Higher quality products
-   More productive development teams
-   Increased job satisfaction
-   Reduced developer burnout

When you understand and address your users' needs, you can achieve quality without sacrificing stability or throughput in software delivery.

To cultivate stronger user-centricity in your organization:

1.  Avoid assumptions—observe users in their environments and ask questions
2.  Integrate user feedback into feature prioritization
3.  Make user experience a top business priority

## Additional Critical Factors

The DORA report also highlights several other important elements:

### Transformational Leadership

Leaders who inspire and motivate team members significantly improve productivity, job satisfaction, and overall team performance.

### Stable Priorities

Inconsistent organizational priorities decrease productivity and increase burnout—even in organizations with strong leadership and user-centric approaches.

### Cloud Adoption

Flexible infrastructure increases organizational performance. However, migrating to the cloud without embracing its flexibility may be more harmful than remaining in a data center.

## Moving Forward Together

The DORA report provides valuable insights into the evolving DevOps landscape. While AI and platform engineering offer tremendous potential, they require thoughtful implementation. 

By focusing on continuous improvement and fostering collaboration, you can build high-performing teams that deliver exceptional value to your customers.

## Take Your Next Steps

Ready to apply these insights to your development processes? Create a free Upsun account and discover how our platform can help you implement these best practices while maintaining developer flexibility and control.

Want to discuss DORA findings with an expert? Contact our team for a personalized consultation.

### [A brief history of application deployment: from FTP to PaaS](https://upsun.com/blog/a-brief-history-of-application-deployment-with-upsun/)

# A brief history of application deployment

Writing apps is great. If only we could be doing that rather than mucking around with the whole process of getting them up and running, right? I often say that apps are like planes: when they are up and flying in the sky chances are that, if you built the app right, it's gonna keep running smoothly. It's takeoff and landing when you usually get into trouble—a.k.a deployment.

In this blog post, I'll dive into a brief history of how we used to deploy apps, taking a look at what has changed, what worked well, and what wasn’t so great along the way. 

## **A brief history of application deployment**

### 1. **Traditional deployment** (late 1990s to early 2000s)

-   **Method:** manual File Transfer Protocol (FTP) uploads to servers. Webmasters would develop the application locally and then transfer it manually to a production server.
-   **Tools:** standard FTP clients like FileZilla or WS\_FTP, among others.

Today, you'd be shocked to know the huge systems that were deployed like this, and you’d probably think it's crazy—but it was also fun and invigorating! You had a thing to change. You double-clicked on an icon of your favorite FTP client (yes, we used Windows). You'd navigate to a file. Double click. Change a thing. Save. Voilà, change delivered. We didn't use that many frameworks. So chances are you had an enormous PHP file somewhere. And your change was localized. And if it broke? Well, you double-clicked again and corrected that. When cycle times are seconds, that was fine. Well, until it wasn't.

Often enough your app ran on a single server, dedicated to this use. It would have whatever database you needed running on it, or if you were running something more resource-hungry, you'd probably have a separate server for the database—what we called multi-tier deployments. And usually, someone else would take care of that one (the Database Administrator).

By 1998, Apache had something called _virtual hosts_ which allowed multiple sites to be hosted on the same machine, which resulted in people cramming more and more applications on the same server. So if you changed a file in the wrong directory...well.

At the time, you may already have been working with some real pros and were on El Reg and Slashdot, so you already had a semblance of separation of responsibilities. If that were so, you already actually had a test server and you'd do this thing on staging. And then some sysadmin would do the copying to production which was fine—until it wasn't.

### 2. **The introduction of** **version control systems (VCS)** (early 2000s)

-   **Method:** developers started using VCS to manage code versions. Deployment sometimes involved checking out the latest code directly on a production server.
-   **Tools:** CVS and Subversion.

By now the pros had become even more serious, and they actually wanted to be in control of the things they were deploying. And engineers also started to hate folders called _production\_v12\_final\_final\_backup\_charles\_final_. 

So we started using SVN and putting something into production usually meant SVN up which was slow, painful, and often broke. But it was the serious way to do things. The smart people learned how to use Symlinks,  do SVN up first, and then switch over to the web root. It was like GitOps without the Ops, and with pull rather than push.

But still, you were running on a single-base system. Dependency had its best days in that period. And usually, staging and production were by now a long time out of sync. This is when, "it works on my machine," became a thing.

### 3. **Shared hosting and control panels** (2000s)

-   **Method:** the rise of shared hosting made it easy for individuals and small businesses to host web applications. Control panels like cPanel allowed users to manage hosting settings and deploy applications.
-   **Tools:** cPanel, Plesk, DirectAdmin.

You would be amazed by how much stuff is still running like this—going to a web page and being able to select from a deployable template of a bunch of apps (mostly PHP but later much more). And this is where something interesting happened. Application deployment became so much easier. One-click. 

However, as it turns out, this makes application maintenance all the more difficult. When deployment is easy but updating is hard, it’s not great. Usually these tools not only allowed you to edit stuff through FTP, they gave you a web client so you didn't actually need to know how to connect to FTP.

### 4. **Dedicated servers and virtual private servers (VPS)** (mid-2000s)

-   **Method:** as web applications grew in complexity, there was a move towards dedicated servers and VPS for more control and resources. This allowed developers to customize server settings to suit their application's needs.
-   **Tools:** VMware, Xen, and later followed by KVM.

Virtualization had a huge impact, suddenly we could start separating applications from the hardware. Now you could actually _cook_ a machine image and deploy that rather than the application. 

This theme will return in the form of containers much later. More importantly, because you could have different bases. But cooking images was a complex story. Deployments were a slow thing. Some adopted the new tools to adopt new practices. Some continued to treat the VM-based machines as a thing they used FTP with. Or SVN up. With the same results.

### 5. **Automated deployment and continuous integration (CI)** (late 2000s to early 2010s)

-   **Method:** the software development lifecycle saw the introduction of automated deployment tools that allowed code to be tested and deployed automatically to production servers.
-   **Tools:** Jenkins, Bamboo, Capistrano, and Fabric.

At a point, software developers, like me, became very _very_ tired of our exchanges with system administrators. We were mistreated. And we could code. 

So we decided we were going to code the problem away. This is what we call to this day DevOps. There were mainly two versions of this:

1.  Code that ran on your machine and automated what were previously manual actions (such as FTP, SVN up, or switching over a Symlink).
2.  Code that ran on the servers and basically did the same things.

The servers were still owned by system administrators, but by 2006 EC2 had become a thing. You _could_ as a developer actually get access to a running machine without asking for permission. But the state of mind had not changed yet. And developers with little security training, would more often than not get quickly (P)owned. 

Still, if your system administrators of the time were modern enough they started to allow you to directly deploy. At least to staging. Because these were also the years of the trifecta: dev-staging-prod. We were automated enough to maintain (with suffering) all three. Which was better than staging-prod. Still, staging drifted, and dev was almost always at various stages of broken.

### 6. **Platform-as-a-Service (PaaS)** (early 2010s)

-   **Method:** platforms that abstracted away the infrastructure, letting developers focus on the code. Applications could be pushed to these platforms, which would handle the server setup, scaling, and deployment.
-   **Tools:** Heroku, Google App Engine, Microsoft Azure App Service, andPlatform.sh.

This is the phase we are most keen to talk about because we are a PaaS. And while we’d love to talk about ourselves, we have to respect our elders. 

At this point, we had tasted the liberty of deploying directly, and the cumbersomeness of continuous integration. Most of us, being fully accustomed to how ugly computers are, and how all software is broken, accepted this as part of the cost of doing business. Except, in these years something else happened: Ruby and Ruby on Rails. A game-changer with its own unique sense of aesthetics. Ruby people were more attached to beauty and simplicity than anything else. 

At the time we were at the paroxysm of Moore’s law—computers were getting faster and your slow code would get faster with time, so why not focus on its readability and beauty instead? 

Tests in the Ruby world were not thought of as, “the cost of doing business because the language is an unsafe mess,” but as the proof of thinking about the system in simple terms. In the words of the French poet Boileau, “what we conceive well, express itself clearly, and the words to say it come easily”. 

Another huge element was Git which quickly enough came and displaced SVN.

There is a huge difference in intentionality between \`svn up\` and \`git push\`. But the main thing was that Git made branches cheap and fast. The Heroku people, with their love for simplicity and Ruby aesthetics, basically said servers and cloud servers are now cattle. What system administrators do for us, can and should be automated away. We will simplify and give you a single runtime and a single database. Always the same; no painting outside the lines. That way, you can \`git push\` and your code will be running on a publicly accessible server. 

It could have been the end of the line, the final word of the story, but Heroku was bought early on by Salesforce. This isn’t to say Salesforce was a bad steward at all, they even added a few runtimes down the line but the service stayed mostly what it was, ignoring everything around it that was going to pass in the next 15 years. And the failure of Heroku to move with the times made people wary of the idea. 

The PaaS could have been what liberated developers to express themselves without unnecessary ceremony and bureaucracy but painting within the lines doesn’t feel like that.

But even if you did paint within the lines, Heroku and its lesser copy-cats from Google and AWS (AppEngine and Beanstalk) left quite a bit of the hassle for the developer (and now the DevOps team). It could handle production but continuous integration, development staging, and anything but the single runtime and attached managed database were left as an afterthought. Which were most of the things needed by any mature software organization. 

We’ll get to that when we talk about Upsun but that is essentially the bet that we made. That you can wrap up the whole process in one as a true Platform-as-a-Service must be a platform for the full continuous delivery cycle.

### 7. **Containerization and microservices** (mid 2010s)

-   **Method:** applications began to be developed as collections of loosely coupled microservices. Containers encapsulated these services, ensuring they had all the dependencies they needed to run.
-   **Tools:** Docker, Kubernetes, Docker Swarm, and Platform.sh.

Continuing on the PaaS theme, two of the things the early PaaS system did not resolve were running software locally and running microservices. Not running micro-services locally as this was basically impossible at the time.

The early PaaS systems were about simplification, and as we said they centered around the specific use case of the single monolith with the single managed database. 

### 8. **Infrastructure-as-Code (IaC) and serverless** (late 2010s)

-   **Method:**
    -   IaC: infrastructure setup and configurations started to be treated as code, allowing consistent and replicable environments.
    -   Serverless: developers would write functions that got executed in response to events, without worrying about the underlying servers.
-   **Tools:** AWS Lambda, Google Cloud Functions, Azure Functions, Terraform, Ansible, oh and Platform.sh.

### 9. **Progressive web apps (PWAs) and JAMstack** (late 2010s to early 2020s)

-   **Method:** a move towards client-side rendered applications and using APIs for backend operations. Deployment mostly involved pushing static files to content delivery networks (CDN) edge nodes.
-   **Tools:** Netlify, Vercel, Cloudflare Pages, and you guessed it, Platform.sh.

### 10. **Edge computing** (2020s)

-   **Method:** shifting computation and data storage closer to the location where it's needed, to improve response times and save bandwidth.
-   **Tools:** AWS Wavelength, Cloudflare Workers, Akamai Edge Workers, and Upsun.

## **Zooming out: the move towards automation**

Over the years, the shift has been towards more automation, better abstraction, and enhanced developer experience. As the web and its associated technologies evolve, deployment methods and tools will continue to change to address new challenges and opportunities.

In this story, the important part, relating to what is currently happening, is two trends in particular:

#### **The rise of containerization**

-   Before Kubernetes, the deployment landscape was already being transformed by Docker, which popularized container technology. Containers brought a consistent environment from development to production, ensuring that the, “it works on my machine” excuse was a thing of the past. However, as containers began to gain traction, there was a growing need to manage, orchestrate, and scale them efficiently, especially for large-scale applications.

#### **The emergence of Kubernetes** (mid 2010s)

-   Kubernetes was introduced by Google in 2014, drawing from their experience with Borg, an internal cluster management system. Kubernetes addressed the challenges of container orchestration, scaling, and management.
-   Kubernetes wasn't the only player in the beginning. There were other tools and platforms, like Docker Swarm and Apache Mesos, vying for the spotlight in the container orchestration space. However, Kubernetes swiftly gained popularity due to its robust feature set, active community, and backing from industry giants, leading to its becoming the de facto standard for container orchestration.

While Kubernetes started as a tool to orchestrate containers, its influence has extended far beyond, reshaping the deployment landscape. It's enabled patterns like microservices to thrive, energized new paradigms like GitOps, and catalyzed a vast ecosystem of tools and extensions.

## **Where Upsun fits**

Upsun tries to take the whole story above and distill what works into a neat, self-service box:

### 1. **Simplification and abstraction**

-   **Unified toolset:** a modern PaaS abstracts the complexities of the underlying infrastructure, allowing developers to focus on writing code and deploying applications. Instead of juggling multiple tools for container orchestration, scaling, logging, monitoring, etc., developers get a unified platform that integrates these features out of the box.
-   **Streamlined workflows:** developers can define the infrastructure and services their application needs using configuration files. This approach simplifies and codifies the deployment process.

### 2. **Future resilience and flexibility**

-   **Avoid vendor lock-in:** many PaaS solutions, including Upsun, are designed to be cloud-agnostic. This means you're not tied to a specific cloud provider, giving you the flexibility to switch providers or even use multiple providers without significant codebase changes.
-   **Adapt to trends:** Modern PaaS solutions can quickly integrate new tools or adjust to changing best practices, ensuring developers always have access to the latest methodologies and technologies without the overhead of manual integration.

### 3. **Consistency across environments**

Upsun, for example, allows developers to clone their production environment for development, testing, or staging. This ensures that the application behaves consistently across all stages, reducing the chances of unexpected behaviors in production due to environmental differences.

### 4. **Built-in CI/CD**

Many modern PaaS platforms come with integrated continuous integration/continuous deployment pipelines, ensuring that code is tested and deployed seamlessly. This integration reduces the need for third-party tools and streamlines the development-to-deployment process.

### 5. **Scalability and performance**

With automatic scaling features, PaaS solutions can handle varying traffic loads without manual intervention. They can allocate resources as needed, ensuring optimal performance and cost-efficiency.

### 6. **Security**

Modern PaaS solutions often come with built-in security features, including automated patching, secure network configurations, and compliance certifications. This built-in security means less manual configuration and fewer third-party tools, reducing potential points of failure.

### 7. **Economic efficiency**

By reducing the need for multiple tools and services, PaaS can lead to cost savings. Organizations don't need to invest in expertise for each individual tool and operational costs can be reduced thanks to the efficiencies of scale that PaaS providers achieve.

In conclusion, a history of tools has transformed the way we think about application deployment and infrastructure, and each of them come with their own complexities. Modern PaaS solutions, like Upsun, are a response to the demand for simpler, unified, and future-proof deployment methodologies. As technology continues to evolve, the ability to stay agile and adaptive with minimal friction is a key advantage, making PaaS an attractive choice for many organizations.

**Want to give it a try?** **Start your free trial today****.** 

### Watch this video

### [Introducing Vinego | Upsun ](https://upsun.com/blog/introducing-vinego/)

# Introducing Vinego to Upsun

Vinego is a new set of safety-related Go analyzers we use internally. If you're not familiar with the Go linting scene, Go provides official interfaces for developing code analyzers that form the basis of community linter frameworks and bundles like golangci-lint.

What makes the new Vinego linters unique is that they focus on rejecting certain idioms in favor of non-idiomatic but more explicit, and hopefully safer, alternative patterns. Let's dive into those. 

## Zero values and the varinit linter

Zero values refers to how in Go, all variables have valid values even if not explicitly initialized—including strings (the empty string) and structs (a struct with all fields as their zero values). Basically, both of the following are equivalent:

```Javascript
var a int
```

```Javascript
var a int = 0
```

What if a variable must be explicitly initialized? In the general philosophy of Go (don't quote me) you would either:

1.  Write code that either treats the zero value as a sentinel (assumes 0 means uninitialized).
2.  Work in such a way that all values produce OK behavior (zero values are handled naturally through the chosen implementation).

But sometimes that's not possible. For instance, consider this calculation:

```Javascript
var desiredInstances uint32
if using_process1 {
	desiredInstances = process1(currentInstances, 45)
} else {
	process2()
}
adjustInstances(desiredInstances)
```

Pretend this is _real_ code with a complex set of branches determining which algorithm is used to calculate the `desiredInstances` value and not an overly-abstract toy example.

The `else` branch in the above code forgets to set `desiredInstances`, so when taken it will conclude with `desiredInstances == 0` and `adjustInstances` will cause an unexpected shutdown.

The Go compiler won't error on this code because from its perspective `var desiredInstances int` is fully initialized, and if the zero value _does_ cause an issue that's because the code isn't idiomatic Go. But in this example the domain of `desiredInstances` is the full range of `uint32` so there's no value we can use as an uninitialization sentinel, and any default value could cause an unexpected adjustment so there's no safe default.

One way to work around this is to change the declaration to `var desiredInstances *int`, effectively increasing the number of available values by one (adding nil) which we can use as a sentinel. All uses need to be dereferenced first (`*desiredInstances`) but this will panic instead of accidentally destroy all of our instances if we miss a branch which is an improvement.

Panicking is still not great though. It ends up being a runtime safeguard against something that's statically incorrect. (Note that even if we could use `0` as an uninitialization sentinel it'd still be a runtime safeguard).

### Vinego's solution

Vinego provides the `varinit` linter for this scenario. The `varinit` linter rejects the zero-value idiom and considers implicit zero-initializations like `var x int` as actually being uninitialized, and the report _reads_ such values as incorrect. 

```Javascript
var x int
if something() {
	x = 4
} else {
	somethingElse()
}
consume(x)
```

The above alerts that `x` in `consume(x)` is missing initialization in the `else` branch above. It does this by tracing variables through the control flow graph of the code and recording path splits with mixed initialization status.

This allows you to fearlessly branch and perform complex initializations, calculations, and so on and so forth, without having to worry about unexpected zero values sneaking in and designing your code to detect and mitigate damage in such scenarios.

## Struct literal zero values and allfields

But there's another source for zero values: struct literals.

Whenever you partially specify a struct with a struct literal, Go will zero-initialize all the unspecified fields. For example, while `varinit` checks to make sure `x` is initialized:

```Javascript
type MyStruct struct {
	Important int
}
var x MyStruct
x = MyStruct{}
```

`x.Important` is critically missed here, and gets a zero value.

### Vinego's solution

`allfields` introduces a new annotation you can use to tell the linter that all fields must be explicitly initialized in the literal:

```Javascript
// check:allfields
type MyStruct struct {
	Important int
}
x := MyStruct{}
```

The above will cause a linter error communicating that `Important` wasn't explicitly initialized. You can mark fields as optional (allowing zero-value implicit initialization) like so:

```Javascript
// check:allfields
type MyStruct struct {
	Unimportant int `optional:"1"`
}
```

Between `varinit` and `allfields` you shouldn't have to worry about zero-value bugs again!

## Remembering to handle errors with the capturederr lint

There's actually already a linter (`staticcheck`) in `golangci-lint` that checks to make sure all `err`s are consumed, but the linter abandons analysis at function borders.

So if you accidentally capture an `err` from an outer scope the analysis silently stops alerting you about the bad code:

```Javascript
x, err := operation1()
if err != nil {
	...
}
go func() {
	err = operation2() // no error!
}
```

In the above, `err` is never used within `func()` but `staticcheck` won't detect this because `err` was declared outside.

### Vinego's solution

What `capturederr` does in cases like this is it simply flags all use of `error`\-type variables in local function definitions where the `error` variable was captured from the outer function rather than declared locally. In the vast majority of cases this is clearly wrong behavior—errors need to be handled to abort execution locally before dependent code executes, and most callbacks have an error return.

In this example it will give you an error saying that `err` is captured in `go func() ...`. If you fix that by changing it to `err := operation2()` then `staticcheck` will start to work again and make sure you're properly handling the error.

## Accidental type mixups and the explicitcast lint

There's a "newtype" paradigm of using thin type wrappers around existing types, like

```Javascript
type Mebibyte uint64
type Gibibyte uint64
```

These provide better documentation than using `uint64` directly in variable declarations, function type signatures and structure definitions, since the unit is clearly communicated. Ideally these would also be strictly checked so that you can't accidentally pass in `Mebibyte` where `Gibibyte` is expected and vice-versa.

In some circumstances `go` will give you an error if you use the wrong type, for example:

```Javascript
func Resize(newSize Mebibyte) { ... }
newSize := 4
Resize(newSize) // error!
```

However, in other situations, Go implicitly converts to the type, as seen in the following example:

```Javascript
func ResizeAfterDelay(newSize Mebibyte, delay time.Duration) { ... }
ResizeAfterDelay(3600, 256) // Whoops! Mixed up delay and size, delay has wrong units, no error
```

This discards the extra safety of the new unique types.

The way Go distinguishes these scenarios is all about literal values. If you're not familiar with literals, literals are the part of the syntax that introduce non-calculated values: `43`, `true`, `"everything in this article is a lie!"`, `MyStruct{}`.

These values don't have concrete types yet. While `43` is an integer, it could be a `int32` or it could be a `uint64` or any other int type, for example.

When you use a literal in an expression, assign it to a variable, return it, or pass it as a function argument Go assigns it a type from the context.

In the above example, both `Mebibyte` and `time.Duration` are newtypes over primitive integers, so `3600` assumes the type `Mebibyte` and `256` `time.Duration`. When we did `newSize := 4`, since there's no explicit contextual type information, Go used the default integer type `int` (variables always have concrete types).

### Vinego's solution

The `explicitcast` lint detects literals being contextually typed and flags them, requiring an explicit cast to appease it:

```Javascript
ResizeAt(time.Seconds * 3600, Mebibyte(256))
```

This then exposes the type safety issues (wrong time unit, argument transportation) in the above - you'll now get an error saying the first argument should be `Mebibyte` and the second `Duration`.

## The loopvariableref lint

With poor timing I bring to you the final linter: `loopvariableref`.

If you've been following Go version announcements, you'll know that Go 1.22 fixes the root issue and so the linter is no longer needed, but this could still be useful for codebases that can't upgrade for some reason (maybe?).

This linter basically checks for and flags references or captures of loop variables which allow the loop variable lifetime to exceed the loop and exhibit unexpected behavior.

## Caveats

None of these lints have a perfect signal. For instance, `varinit` assumes the worst case in the presence of captures and goroutines, since in those cases the order of initialization can change at runtime so you may have perfectly valid code (e.g., using a `WaitGroup` to make sure a goroutine finishes before using a variable) but the linter would still flag it.

Also, some, like `capturederr`, can flag legitimate code and require extra effort to work around: like if you need to pass the verbatim error from an operation in a callback out and other mechanisms aren't provided.

That said, these should help fill in some fairly large safety holes and give you better baseline guarantees. And the workarounds where required are hopefully not too onerous.

## Go Git it

You can get it at https://github.com/upsun/vinego —the README has installation and usage instructions plus more details on each linter.

It's distributed as a docker image containing the full `golangci-lint` as a total Go-building solution, or you can build it yourself.

For now, keep an eye out for additional blog posts on the Go analyzer architecture, tips and tricks for working with the interfaces and `golangci-lint`, and how the Vinego linters do their analyses.

### [Avoiding the sunk cost fallacy in App modernization | Upsun](https://upsun.com/blog/avoid-the-sunk-cost-fallacy/)

# We all make mistakes: Avoiding the sunk cost fallacy in digital transformation and app modernization

The sunk cost fallacy is a cognitive bias that leads individuals and organizations to continue investing in a failing endeavor simply because they have already put significant resources—time, money, or effort—into it. Instead of making rational decisions based on future potential, businesses become anchored to past investments, fearing that moving on would mean admitting failure.

The term "sunk cost fallacy" originated from economic and psychological research in the mid-20th century and was popularized by Nobel Prize-winning economist Richard Thaler. The concept is closely linked to behavioral economics, which explores how people make irrational financial decisions based on past investments rather than future gains. Closely tied to this is the idea of opportunity cost—the potential benefits missed when one option is chosen over another. When businesses refuse to move on from failing investments, they not only waste resources but also forgo opportunities that could yield far greater returns. This dual effect makes the sunken cost fallacy particularly dangerous in high-stakes decision-making.

A famous example of the sunk cost fallacy is the Concorde project, a supersonic passenger jet developed jointly by the British and French governments. Despite massive cost overruns and clear indications that the project would not be commercially viable, both governments continued funding it for years, unwilling to abandon the investment already made. This phenomenon is sometimes referred to as the "Concorde Fallacy."

Another example of the sunk cost fallacy is companies that hold onto antiquated technology for too long and avoid digital transformation or app modernization. This leads to mounting technical debt, which, if left unchecked, can ultimately cripple innovation and financial sustainability. Too much tech debt can result in operational inefficiencies, security vulnerabilities, and in extreme cases, contribute to a company's downfall—just as excessive financial debt can lead to bankruptcy.

## The cost of holding on: implications for businesses

### Digital transformation

Many businesses embark on digital transformation initiatives only to hesitate when it comes to abandoning legacy systems. The fear of “wasting” previous investments in on-prem infrastructure or outdated processes leads to half-measures instead of bold, necessary change. Instead of embracing cloud-native solutions, companies end up patching together hybrid approaches that create inefficiencies rather than solving core issues. The result? Slower innovation, higher operational costs, and an inability to fully leverage modern technologies like AI and automation.

### App modernization

The software that once served an organization well can quickly become a burden if it is not regularly updated to meet new demands. Yet, many companies resist modernizing applications because of the substantial development costs already incurred and the fear of "will it work?" This uncertainty leads to hesitation, resulting in poor user experiences, security vulnerabilities, and scalability issues. Businesses that fail to modernize their applications risk losing customers to competitors who offer more agile, performant, and secure solutions.

### Tech debt

Technical debt accumulates when short-term fixes and workarounds take precedence over long-term scalability and maintainability. The longer an organization avoids addressing tech debt, the more costly and complex it becomes to resolve. However, many businesses continue to invest in maintaining legacy systems rather than refactoring or rebuilding, simply because they have already spent so much on these outdated technologies. This ultimately leads to slower development cycles, frustrated engineering teams, and increased costs in the long run.

## **The opportunity cost of inaction**

The real danger of the sunk cost fallacy is not just the money already spent but the opportunities missed by not moving forward. Businesses that cling to outdated technology risk falling behind in an increasingly competitive market. While they continue to pour resources into maintaining old systems, their competitors are embracing cutting-edge solutions that enable faster innovation, better customer experiences, and greater operational efficiency.

Startups, in particular, often succeed for this very reason. They are willing to take the chances that larger, more established businesses avoid. Their ability to embrace the future without the burden of past investments allows them to remain agile and responsive to market demands. By quickly adopting new technologies and innovative approaches, startups can outmaneuver legacy-driven organizations, securing competitive advantages in rapidly evolving industries.

However, all businesses eventually risk falling into this mindset if they do not actively work to avoid it. The once-agile startup can quickly become the monolithic industry leader that shies away from risk. A recent example of this is the competition between Deep Seek and OpenAI. OpenAI changed the world with AI innovation, but now Deep Seek has forced OpenAI to pivot, proving that even the most innovative companies can become entrenched in their own past investments. Despite having limited money and resources, Deep Seek's willingness to challenge the status quo of AI model training has put pressure on OpenAI to remain adaptable, highlighting how critical it is for businesses of all sizes to continuously embrace change.

## How Upsun helps businesses break free

Upsun provides a platform that eliminates the constraints of legacy thinking, allowing businesses to embrace change without the fear of wasted investments.

**Flexible cloud-native infrastructure** provides businesses with the ability to migrate seamlessly between environments without the risk of vendor lock-in. Unlike traditional infrastructure, which often binds companies to a single provider with rigid contracts and limited adaptability, cloud-native solutions offer the flexibility to scale resources dynamically and integrate with a variety of platforms. This approach reduces operational risk, allowing organizations to remain agile and responsive to market demands. Companies that embrace cloud-native infrastructure gain a competitive edge by avoiding the constraints of legacy systems, ensuring they can rapidly adopt new technologies and optimize performance without being held back by past investments.

**Preview environments** provide teams with the ability to clone the full stack—including application code, services, and data—allowing for comprehensive testing at all levels. Unlike traditional staging environments that often lack real-world data, these environments enable developers to validate not just functionality but also user experience and performance under real conditions. This significantly reduces the common risks associated with the uncertainty of 'will it work?' by ensuring every component is tested in an authentic scenario before deployment. By catching issues early, teams can confidently roll out modernized applications without the fear of unexpected failures, improving efficiency, security, and overall user satisfaction.

**Automate scaling and orchestration** to allow your businesses to right-size their resources dynamically, eliminating the need to over-provision for peak demand. This is similar to the infinite hotel paradox—where there is always room for one more guest—except here, resources expand and contract as needed without waste. Companies no longer have to maintain costly idle capacity or scramble to meet unexpected spikes in traffic. Instead, they get the perfect balance: the right resources at the right time, ensuring efficiency, cost savings, and seamless performance without being burdened by past limitations.

With Upsun, companies can pivot both technically and strategically at any moment. Instead of being trapped by past investments, organizations can focus on future growth, adapting to new market demands without unnecessary constraints.

## Conclusion

The sunk cost fallacy is a major barrier to innovation in digital transformation and app modernization. Businesses that continue to invest in outdated systems out of fear of losing past investments ultimately pay a higher price in lost opportunities. By embracing a forward-thinking approach with Upsun, organizations gain the flexibility to innovate, scale, and adapt without the weight of legacy systems holding them back.

It's time to stop looking backward and start moving forward. With Upsun, the future is always within reach.

### [Modern WordPress development workflow: tools & best practices](https://upsun.com/blog/modern-wordpress-development-workflow/)

# A modern development workflow for WordPress

To quote my colleague, Chad, WordPress _“remained tremendously popular since its release in 2003”._ For many, WordPress remains by far the Content Management System (CMS) that is easiest to adopt, and that provides a fast time to market in the majority of use cases. There is so much high-quality material out there for WordPress, be it Open Source Software (OSS) or Premium, that one can have beautiful sites powered by an easy-to-use CMS up and running in no time.

## **True, but…**

There was a time in my career when building CMS solutions for enterprise was the main thing I did. In those circles the idea that WordPress was a toy not suitable for enterprise-grade projects was common. This was especially true when I was working with teams that had already been initiated to best practices that later became known as the 12 Factor app methodology. The traditional way of “doing WordPress” couldn’t really espouse the 12-Factor way easily.

## **WordPress, traditionally**

Traditionally, a WordPress project’s codebase would consist of the entire WordPress core, plus all the plugins and themes necessary for the project to work. The entire codebase would then be deployed to a hosting of choice, usually via—_cough_— (S)FTP. The slightly evolved model is that the very same codebase is checked into a source code management system of choice, with a CI tool moving it onto the hosting’s servers.

### **Navigating WordPress Automatic Background Updates**

Automatic Background Updates were introduced in WordPress 3.7 for the WordPress core, and later extended to plugins, themes, and translation files. Whilst a degree of automation for updates is definitely desirable, the way this is implemented in WordPress (i.e., in situ updates) means that if your codebase is in a repository, it’ll quickly get out of date, and you’ll have to manage updates in the repo on the side, to avoid problems and regressions down the road. If instead, you manage everything via FTP alone, it means each update will be very risky anyway. Either way, I can guarantee that things will quickly escalate into a nightmare.

### **Wait, it’s not all**

It gets more complicated. To quote Chad again from the same article:

_“Many hosting solutions, Upsun included, enforce read-only filesystems at runtime. These solutions deploy a highly reproducible build image as a consequence of your codebase and its explicitly defined build process, all committed to version control. \[...\] External code (dependencies) \[...\] and ideally definitions of your infrastructure itself are committed to exact versions so that your entire DevOps process from start to finish is repeatable and reproducible.”_

This is excellent also for security reasons. Yet, as you may have gathered, it clashes completely with the way WordPress handles automatic updates, and these might need to be disabled entirely where a read-only file system is employed.

## Leveraging Bedrock and Composer for modern WordPress development

In his article, Chad talks about how _Bedrock_ leverages `composer` to provide a more modern approach to WordPress development, thanks also to the great work behind WordPress Packagist. Chad shows that combining these efforts with our very own Source Operations, it’s possible to achieve a good degree of automation in updates, with greater control on versions and a greater repeatability of the process.

## Our Goal: Efficient WordPress workflow and development

The goal of this article is to go one step further, and show how to combine Upsun with other tools, to achieve the best WordPress workflow—including auto-updates—that allows also for a greater degree of complexity, control, and configuration.

To do so, I’ll start by following the _Deploy Composer-based WordPress on Upsun_ guide from the Upsun documentation. 

## Maximize automation with a template and WordPress workflow plugins

After following the guide, I modified my experiment to host the codebase for two sites (`ita` and `eng`), where both: 

-   are built using WordPress.org
-   have a rudimentary “distro” support
-   are deployed on Upsun in Multi-App setup
-   have their entire codebase managed via `composer`, thanks to `johnpbloch/wordpress`, WordPress Packagist (for plugins and themes), and `inpsyde/wp-translation-downloader` (a `composer` plugin to manage WordPress translations for core, plugins, and themes)
-   have their dependencies automatically upgraded by Dependabot
-   have their Dependabot PRs automatically merged by Mergify when builds pass
-   have new code deployed to production automatically on every PR merge
-   use Redis as back-end caching
-   use Cloudflare as CDN
-   use GitHub Actions as additional CI/CD and Cron Scheduler

In addition to the above:

-   the `ita` site uses Elasticsearch
-   the `eng` site uses Algolia

Finally:

-   the experiment is meant to be used as a GitHub repository linked to an Upsun project via our GitHub integration.

If you are thinking this experiment was derived from a real-life project, then you’re right!

In the remainder of this article I’ll be focussing on the points that show how this experiment is all about automating as much of your Wordpress development workflow as possible, and I’ll avoid getting into some other details. Thus, if you want more insights into composer-based WordPress development, do refer back to Chad’s article or directly to the code in my repository.

### Automating WordPress installation with Distros and Composer

_Distros_ or _install profiles_ are essentially a way to have your own default installation configuration. Whilst some software have built-in support for that, WordPress does not. My goal was to completely automate the installation on the first deployment, so I decided to take matters into my own hands.

The rudimentary support I implemented for this relies on two things. First, a bespoke section in the `composer.json` file:

```shell-session
  "distro": {
    "default-theme": "lovecraft",
    "enable-plugins": [
      "academic-bloggers-toolkit",
      "akismet",
      "contextual-category-widget",
      "elasticpress",
      "jetpack",
      "really-simple-ssl",
      "redis-cache",
      "series",
      "social-pug",
      "wp-cloudflare-page-cache",
      "wpforms-lite"
    ]
  },
```

Second, a script that uses the information in that section to perform some initial setup:

```shell-session
#!/usr/bin/env bash

cd wordpress
if ! wp core is-installed; then
  WP_URL=$(echo $PLATFORM_ROUTES  | base64 --decode | jq -r 'keys[]' | grep $PLATFORM_APPLICATION_NAME | grep https | grep www)
  wp core install --url="${WP_URL}" --title="Modern WordPress" --admin_user=admin --admin_password=changeme --admin_email=change@me.com
  DEFAULT_THEME=$( jq -r '.[ "distro" ][ "default-theme" ]' ../composer.json )
  wp theme activate ${DEFAULT_THEME}
  jq -r '.[ "distro" ][ "enable-plugins" ][]' ../composer.json |
  while read PLUGIN; do
    wp plugin activate ${PLUGIN}
  done
else
  wp core update-db
fi
```

The script is then executed as part of the `deploy` hook in Upsun, i.e. after the build phase has downloaded and built WordPress and the other dependencies via `composer`. The result will be a fully installed WordPress application, avoiding you from having to go through the default manual (albeit simple) WordPress setup wizard.

If you are wondering why we didn't simply use the `scripts.postbuild` section in `composer.json` to run such a script, the primary reason is that during the `build` phase (when `composer` is executed) the database service is not yet available, since the build phase is designed only to create a deployable artifact.

### Automatic WordPress database updates

We’ll talk about code updates later, but since we have referenced the script above, I wanted to highlight that the same script takes care of updating the database in case there have been code updates that demand such operation to take place.

If you have worked with WordPress before, you know that at the very least, when WordPress core is upgraded, you might be required to run a very simple routine that upgrades the database schema accordingly. This can be done through the administrative UI, which will present you with a simple button to click; or it can be done via the `wp-cli`. The latter is what this script is using (see how the `wp-cli` is installed): if WordPress is already installed, on each deploy it will simply run a database update routine, which will only do something if there is something to do.

  
**Automated dependency updates**

Part of the GitHub family for quite some time now, Dependabot provides a free plan for public repositories, and it supports PHP+Composer. You can configure it to decide what kind of upgrades you want to perform on your dependencies, and the bot will issue pull requests periodically, avoiding stale dependencies. Our configuration looks like this:

```shell-session
version: 2
updates:
  - package-ecosystem: composer
    directory: "/eng"
    schedule:
      interval: daily
    open-pull-requests-limit: 10
    ignore:
      - dependency-name: wpackagist-plugin/really-simple-ssl
        versions:
          - 4.0.10
  - package-ecosystem: composer
    directory: "/ita"
    schedule:
      interval: daily
    open-pull-requests-limit: 10
```

For both apps, we have a daily check on dependencies (remember, WordPress core itself is a dependency!), with a limit of maximum 10 open pull requests at any one time. You can also do clever things like ignoring specific versions of a dependency, if you know they are buggy, for example.

You might ask: ok, but how does opening PRs automatically actually achieve automatic dependency updates? Well, it does not :)

### Enter auto-merge

Opening loads of PRs in an automated fashion is hardly going to make your life easier and keep your dependencies up to date effortlessly. Thus, a tool like Dependabot must be combined with another one that provides merge queues and the ability to auto-merge pull requests that meet certain criteria. I used Mergify, but it is likely that in the near future you might be able to use GitHub merge queues if they decide to implement a system similar to Mergify, where you can define a pattern for the PRs that must be auto-merged:

```shell-session
pull_request_rules:
  - name: automatic merge for Dependabot pull requests
    conditions:
      - author~=^dependabot(|-preview)\[bot\]$
      - status-success=upsun
    actions:
      merge:
        method: squash
```

The configuration above essentially instructs Mergify to automatically squash-merge all PRs issued by Dependabot and that have been built successfully on Upsun.

As I mentioned already, this experiment is meant to be used via GitHub integration with Upsun. This makes it possible for every PR raised by Dependabot to have an associated preview environment where the build and deployment of the application with the updated dependencies will take place. Thanks to the integration with GitHub, this process is added as a status check for the PRs on the repository. That status check is what Mergify uses here to make sure that everything is fine with the PR; if it is, the PR will be merged.

This, of course, is a very basic configuration; nothing is stopping us from using additional `status-success` conditions in the configuration, which could be unit tests run by a CI and other things like this. The more automation and status checks you have, the more confident you can be that the PR can be automatically merged.

## Achieving control and assurance with Upsun and automation tools

Combining tools like Dependabot, Mergify and Upsun gives you a much greater degree of control and assurance over your process of automated updates for WordPress core, plugins, themes, and translation files. This is because for each update you can be certain that a production-like environment will be built with the changes, and additional tests can be run to make sure that everything still works just fine. You can decide whether you want to auto-update just minor versions or also major versions. You can exclude specific versions or specific items (a particular plugin or theme, for instance). And much more. You have fine-grained control, more power, and a higher degree of assurance.

## Further Developments

The WordPress development workflow I’ve shown you here can be applied to extended scenarios. For instance, you can configure Mergify to auto-merge other or even all types of PRs, given the right conditions (remember that even manual peer reviews and other manual steps can be added as status checks). You can also extract this workflow and apply it to other types of applications, not just WordPress.

However, one way one could really take this to another level is by automating infrastructure upgrades! All you’d need is a way to check if there’s a new release of one of the Upsun managed services you use in your project, and then issue a new PR with the update (just like Dependabot does with application dependencies). Once you have that component (which could be implemented within your external CI tool, such as GitHub Actions), then you could configure Mergify to auto-merge those PRs, again, given the right conditions.

## Start WordPress development workflow automation with Upsun

Whilst you wait for the ability to auto-upgrade your infrastructure (in fact, I promise I’ll be updating my template with that very feature as soon as it becomes possible to do so), you can still start using this template and this workflow right now, and begin saving precious time to your development team:

-   Fork this experiment on Github
-   Create a new Upsun project
-   Link your forked repository to the newly created project via our GitHub integration (requires you to install our CLI).

And as usual, you know where to find us, if you need us!

### Useful links

-   WordPress | Upsun Docs
-   Deploy Vanilla WordPress on Upsun

### [Accelerating eCommerce Development Workflows | Upsun](https://upsun.com/blog/accelerating-ecommerce-development-workflows/)

# Accelerating eCommerce development workflows: from staging to production

Last summer, a single security software update brought the Starbucks mobile app to a halt across the globe. Customers couldn't place orders, payments failed, and a multi-billion dollar business was disrupted—not because of an internal bug, but due to a failure in a third-party service. This is the new reality of eCommerce.

Shoppers do not wait. When a site loads slowly, they leave. If checkout fails, they abandon. When a new feature crashes, complaints hit social media before IT can respond. The pressure on eCommerce teams is relentless. They have to ship faster, add personalization, and keep everything running smoothly.

This is why smarter workflows became essential. Manual deploys and late-night fixes could not keep pace with modern demands. Real-time inventory, secure payments, multi-device shopping, and constant A/B testing all require speed and reliability. Businesses want agility. Customers expect perfection. Developers are caught in the middle, asked to deliver both.

This article explores that tension. It is the tug of war between speed and safety in modern eCommerce development services. It is not only a technical challenge but an organizational one. The companies that solve it build systems where agility does not mean instability. The reward is a development engine that moves quickly, learns quickly, and stays safe.

The question now is how teams can keep up the pace without sacrificing stability. Let’s look at how smarter eCommerce development workflows make that possible.

### **What slows down a developer: the workflow trap no one talks about**

Let’s imagine something simple.

A developer rolls out a new feature like a personalized product carousel designed to boost holiday sales. It’s tested locally. Everything runs smooth. But the moment it’s pushed to staging, the carousel breaks. Not because the code is wrong, but because the staging server runs an outdated version of the API.

Slack messages fly. QA gets looped in. Logs are scanned. The issue is traced, but valuable time is already lost: 24 hours of debugging, cross-departmental meetings, and missed deadlines. Marketing wants it live. Engineering wants it fixed. The feature, caught between silos, stalls. And the company loses an entire day of crucial sales!

This is the unspoken truth of most eCommerce development company workflows: they look efficient on paper, but they bleed velocity in real life.

### **What is the traditional workflow in eCommerce development?**

Typically, it goes like this:

-   Code locally
-   Push to staging
-   QA tests it
-   Move to production

Seems clean. But here’s what really happens:

**Environment inconsistencies**

What works on a developer’s machine may break in staging. And what clears staging might behave erratically in production. Without environmental parity, you’re debugging ghosts, bugs that appear only when it's too late to trace them properly.

**Delayed feedback loops**

Developers commit changes. QA queues it up. Business stakeholders review it much later. By the time feedback arrives, context has evaporated and urgency with it. The fix, once a 5-minute change, now costs hours.

**Manual testing and deployments**

Click. Wait. Confirm. Approve. Ship. This slow, brittle routine mimics agility but functions like a waterfall. And in a business built on speed, it’s a luxury few can afford.

**High-Risk Releases**

Even a minor UI tweak can feel like defusing a bomb. Will it impact payments? Break cart logic? There’s no safe space to fail, so everything moves slower, with fear built in.

And that fear? That’s what’s killing innovation.

The problem isn’t the people. It’s the process. You can’t drive a Formula 1 car with the rules of a bicycle race. In eCommerce development services, where time-to-market is everything, the old-school development flow isn’t just slow, but it’s obsolete.

In this landscape, having production-perfect staging environments, automated deployments, and live previews for every branch is not just a technical upgrade. Upsun brings these capabilities together in one place, so teams can move quickly and still feel completely in control.

### **Why do ecommerce teams need safer, smarter workflows?**

In eCommerce managed services, speed is not a luxury. It is the difference between catching a wave and missing it entirely. A holiday sale goes live at midnight. A product launch hinges on a single banner. A small delay can turn into lost revenue, and no one remembers why it happened, only that it occurred.

**Why are time-sensitive campaigns vulnerable?**

The biggest revenue days - Black Friday, Cyber Monday, Prime Day, Singles’ Day - are won or lost by milliseconds. A slow pipeline that adds even 24-48 hours per deployment can derail a meticulously planned promotion. By the time your fix is ready, your customer has already clicked away.

A broken workflow doesn’t just delay features. It kills opportunity.

**Why is safe experimentation so elusive?**

Innovation demands trial. Perhaps you would like to introduce a new recommendation engine. Or test out an alternate payment gateway. But where do you test? Production is too risky. And staging? Often a shadow of the real thing - unreliable, incomplete, and built for simulation, not precision.

Without a true sandbox, you can’t innovate without fear.

**Why do non-developers struggle with the process?**

Modern eCommerce isn't just run by engineers. Marketers want to test headlines. QA teams want to probe for edge cases. Legal wants visibility before launch. These contributors don't live in Git or terminal windows; they need environments that speak business, not just backend.

A dev-first workflow ignores the reality: shipping is now a team sport.

**Why is environment parity non-negotiable?**

In real-time commerce, staging must be indistinguishable from production. Same API versions. Same asset paths. Same data shapes. Otherwise, bugs hide in the gaps and appear only after a deploy has cost you real money.

A safer, faster workflow isn’t a tech upgrade. It’s a business defense mechanism.

The step-by-step path to safer, faster, and low-risk deployments.

### **What separates ordinary workflows from high-performance pipelines?**

In 1981, a pit crew changed a Formula 1 tire in 14 seconds. Today, it takes under 2. The difference wasn’t just better tools, it was better systems. Data tracking. Coordinated roles. Muscle memory refined by feedback loops.

The same pattern shows up in places far removed from racetracks. Especially in eCommerce.

Because speed in digital retail doesn’t just come from fast servers or lean code. It comes from workflows that are precise, predictable, and invisible when they work. What separates struggling teams from high-performing ones isn’t how quickly they deploy, but how confidently they do it.

Let’s look at the building blocks that make that confidence possible.

**What is environment cloning and why does it matter?**

When code works on your machine but fails in staging, the problem is not the code, it is the environment.

Environment cloning fixes this by creating an exact replica of production:

-   Same APIs
-   Same services
-   Same quirks

With tools like Upsun, bugs caught in testing are the same ones you would have faced in production. That means fewer surprises, faster fixes, and a smoother path to launch.

The journey every environment takes from development to production readiness.

**How does branch-based development keep the pipeline moving?**

Traditional workflows move in a straight line. One feature waits for the next, and a single failure blocks everyone.

Branch-based development changes the flow.

-   Every feature lives in its own branch
-   Teams test and review independently
-   CI/CD runs automated checks

No collisions. No waiting. Just steady, predictable progress.

**What are preview environments and why do they help?**

How often have you heard, “Can I see it live?”

Preview environments give every branch a live, shareable link:

-   No screenshots
-   No staging confusion
-   Real, testable builds for every stakeholder

This bridges the gap between technical and non-technical teams. Collaboration stops being a meeting and becomes a shared experience.

**Why Does Infrastructure as Code Make Workflows Safer?**

Over time, environments drift. Settings change, dependencies shift, and suddenly, something breaks.

Infrastructure as Code (IaC) locks your infrastructure into version-controlled code:

-   Spin up production replicas in minutes
-   Roll back instantly
-   Track every change

When your infrastructure is written down, not remembered, deployment speed is matched by certainty. And certainty is what keeps revenue safe.

The core automation features that speed delivery and reduce errors.

### **How do you manage and scale complex commerce architectures?**

Picture a busy kitchen. One chef handles the grill. Another preps vegetables. Someone else manages desserts. If they do not talk to each other, chaos follows. Modern eCommerce is no different. The storefront, the backend, payments, and search tools all have to work together. When they do, everything feels seamless. When they do not, it shows.

**Why orchestration matters**

Without orchestration, each part of the system goes its own way. That is when the late-night emergencies happen. A simple mismatch between staging and production can turn a routine release into a disaster. Platforms that keep every service in sync change that story. They turn unpredictable launches into a steady rhythm that teams can trust.

That is why many high-growth teams look for orchestration platforms that keep every service working in sync. Upsun does exactly that, turning complex launches into a smooth, predictable process.

Upsun in action

This is where Upsun shines. It mirrors every service in every environment. The database in staging behaves just like it does in production. The API gateway in testing acts the same way it will for real customers. That means fewer surprises, faster fixes, and launches that feel calm.

**Simplifying scale**

Growth adds layers. More tools. More services. More chances for things to break. Parity keeps all of it under control. When staging and production match, scaling is not scary. It is simple.

How different architectures impact speed, flexibility, and scalability for teams.

### **Real-world scenarios where workflow speed matters**

Delays do not come from a single feature. They come from the spaces in between. The waiting. The rework. The "it worked in staging but not in production" moments that quietly eat up days.

**When speed makes or breaks a campaign**

Campaigns live or die by timing. If a launch slips, even the smartest idea will miss its chance. Fast workflows keep the window open.

**The hidden cost of slow integration testing**

Payment gateways, search tools, CMS plugins - every one of them needs testing. Slow environments turn testing into a bottleneck. Speed removes the roadblocks.

**Expanding into new markets without losing time**

Launching in a new region is hard enough. New storefronts, new languages, new rules. With fast workflows, teams can build and test in parallel, rather than waiting in line.

### **Final words**

Speed in eCommerce is not a sprint. It is a steady, confident pace. The best teams do not gamble with every release. They repeat a process they can trust.

When parity is in place, launches no longer feel like cliff dives. They become routine. Predictable. Safe. The question is no longer "Can we move faster?" It is "Why would we ever slow down?"

This is where expertise meets technology. The right workflow and the right platform are a winning combination. Ziffity provides the strategic guidance and development expertise to transform your workflow, while Upsun provides the infrastructure engine to make it possible.

With Upsun, the answer is now.  
Spin up new environments in minutes. Test without fear. Launch with confidence.

Start building smarter today with Ziffity and Upsun.

### [Why MCP is becoming part of your product surface | Upsun](https://upsun.com/blog/mcp-is-becoming-part-of-your-product-surface/)

# Why MCP is becoming part of your product surface

AI assistants are quickly becoming a primary interface for how people interact with software.

Developers ask them how to integrate APIs. Users ask them how products work. Buyers ask them how tools compare. Increasingly, the first explanation someone receives about your product does not come from your website, your documentation, or your sales team. It comes from an AI assistant.

That shift has an important consequence that many organizations are only starting to notice.

If AI assistants cannot access accurate, current information about your product, they will still answer. They will just guess.

And when they guess, you lose control over how your product is understood.

## **The visibility gap AI creates**

For years, companies have invested heavily in documentation, APIs, and developer tooling. The assumption was that users would come directly to those resources when they needed answers.

AI changes that assumption.

When someone asks an assistant how your product works, or how to accomplish a task with your API, the assistant does not browse your docs the way a human does. It relies on whatever information it has available at answer time. If that information is outdated, incomplete, or inferred, the response can be confidently wrong.

This creates a visibility gap.

Your product may be powerful, well-documented, and actively maintained, but if AI assistants cannot access authoritative context, that reality is invisible at the moment it matters most.

## **From guessing to grounding**

The Model Context Protocol exists to close that gap.

MCP allows AI assistants to query live, authoritative sources when they answer questions. Instead of relying on training data frozen in time, assistants can fetch current documentation, structured responses, and real product behavior directly from you.

The effect is subtle but significant.

AI stops guessing about your product and starts grounding its answers in reality. Documentation stays current. APIs are described accurately. Product behavior is explained as it actually works today, not as it worked months ago.

This is not just an improvement in answer quality. It is a shift in who controls the narrative.

## **Why this is not just a developer concern**

It is tempting to treat MCP as a developer experience feature. It clearly helps developers, especially those using AI-assisted coding tools. But its impact extends well beyond implementation details.

An MCP server becomes a new product surface.

It shapes how your product is discovered, evaluated, understood, and most importantly utilized in AI-mediated workflows. It influences support load by determining whether answers are accurate or misleading. It becomes a channel through which users learn what your product can and cannot do.

Seen this way, MCP is not an optional enhancement. It is part of how your product presents itself in an AI-first world.

## **Hosting an MCP turns it into a business asset**

Local MCP servers are useful for experimentation, but they do not scale as a strategy.

When MCP servers are hosted, they stop being a developer convenience and start behaving like a product capability. Users can connect instantly, without installation or configuration. Updates propagate immediately. Security policies, authentication, and rate limits can be enforced consistently.

Just as importantly, hosted MCP servers create visibility. You can observe how AI assistants interact with your product, which questions are asked most often, and where confusion still exists. That feedback loop is invaluable for product teams trying to understand how their software is actually perceived.

At that point, MCP is no longer an experiment. It is infrastructure that supports discovery, support, and adoption.

## **The hidden platform question behind MCP**

There is, however, a familiar trap.

Providing MCP servers means operating always-on services that handle concurrent connections, external requests, and access to internal systems. It means managing deployment pipelines, scaling behavior, observability, and security boundaries.

In other words, MCP introduces a platform concern.

Many teams recognize the strategic importance of MCP but underestimate the operational work required to run it reliably over time. What starts as a small integration can quietly turn into another internal system that needs constant attention.

This is where otherwise promising MCP initiatives stall.

## **Where a platform makes the difference**

A cloud application platform absorbs the operational burden MCP introduces.

Instead of designing deployment pipelines, managing environments, and worrying about scaling behavior, teams can treat MCP servers like any other application component. Changes flow through Git-driven workflows. Preview environments make experimentation safe. Built-in observability provides insight without additional tooling.

The result is not just faster deployment. It is confidence that MCP can evolve alongside the product without becoming a maintenance liability.

As with other platform responsibilities, the value is not in what is technically possible, but in how much ongoing effort is required to keep things working.

## **MCP as part of AI readiness**

The broader shift is clear.

AI assistants are becoming default intermediaries between users and software. Products that cannot be understood accurately at that layer will struggle to compete, regardless of how good they are underneath.

An MCP strategy ensures that AI interactions reflect your product as it actually exists, with current behavior, supported workflows, and clear boundaries. It turns AI from an unpredictable external force into an extension of your product surface.

## **The real decision is about ownership**

Adopting MCP is not a question of if, but how.

You can choose to build and operate the infrastructure required to support AI-facing integrations yourself. Or you can rely on a platform designed to absorb that complexity and let your teams focus on product differentiation.

As with container security or Kubernetes, the tradeoff is not about capability. It is about where responsibility lives.

When platforms own the hard parts, teams move faster with less risk.

That is the real advantage.

## **Explore further**

-   **Explore how Upsun supports AI-native workflows**  
    See how Upsun supports AI-native workloads, MCP servers, and rapid iteration without additional operational overhead.
-   **See how MCP enables real AI-driven operations on Upsun**  
    A practical look at using MCP to manage infrastructure through AI assistants, from read-only exploration to safe automation.
-   **Read the technical deep dive on deploying MCP servers**  
    For implementation details, transport options, and code examples, see the original Dev Center article.

### [Source Operations sorcery for WordPress | Upsun](https://upsun.com/blog/source-operations-sorcery-for-wordpress/)

# Source Operations sorcery for WordPress

Source Operations were released on Platform.sh about 4 years ago, but were limited to those customers on Enterprise and Elite plans. On Upsun, access to Source Operations is available on all plans. 

If you're not familiar with Source Operations, it's a feature that allows you to specify commands that can commit changes to your project's repository when called. For example, Source Operations can be used to update your dependencies, even hooking a `composer update` to a cron job so that dependency updates occur automatically on a dedicated environment.

But what if you're not using composer? What if you have something like a traditional WordPress set up? 

## Vanilla waiver

We refer to this case as _vanilla_ WordPress; it’s set apart by its points of incompatibility from the way we normally do things at Upsun. WordPress developers are used to being able to SFTP into a server running WordPress to make edits or use the CLI to get updates. But WordPress's `auto_update_core` function just really doesn't work with the read-only filesystems you get on our app containers.

For that reason, we suggest you disable `WP_AUTO_UPDATE_CORE` and recommend developers use Composer. If you must go the vanilla route, you’re restricted to “update locally, commit, and push.”

But with Source Operations, it's possible to get access to a writable file system, checked out to the current branch, and make these kinds of changes. Should you do this? Well, there are plenty of caveats and edge cases we've yet to discover. Perhaps it's best to think of this as a "look what Source Operations can do" type of article, after which we can figure out together what best practices should be for these operations, as well as their limitations.

## Setting up

To start off, we follow the guide for deploying a WordPress Vanilla codebase on Upsun. If you're trying to migrate your own Vanilla WordPress site, this guide will be the best resource for doing so. Once you've completed the guide, and deployed your site, login to the WordPress admin dashboard. There will be the "Updates" section in the sidebar. When an update for a plugin, a theme, or WordPress core is available, you'll see a counter notification on this tab. Normally it's at this point that we'd advise you to pull, update, commit, and push to a new environment to test those updates.

But let's try it with Source Operations instead this time.

## CLI and authentication

Performing the update is going to require the use of the Upsun CLI within the environment and, therefore, an API token. Obtain a token from your "Accounts" page of the management console, and then (with the CLI installed locally) create a _project-level_ environment variable with that token:

```shell-session
$ upsun variable:create -l project --prefix env: --name UPSUN_CLI_TOKEN --value "API_TOKEN" --json N --sensitive y --visible-build y --visible-runtime y
```

We're still going to add some restrictions that keep the operation from running on your production environment in the next section, but setting the variable project-wide allows us to make it visible at build time, which is the level we'll need for it to be visible during a Source Operation. It's at this point that we have our first big caveat: How safe is it to include an API token in your project like this?

Well, if it's just you working on the project, then there really isn't a problem here. But in practice this rarely happens, and your personal API token—although not visible through the management console—_will_ be visible to anyone with SSH access to _any_ of the environments on the project. Someone could use that token, if belonging to the project owner, and delete the site if they were so motivated. Which is not great.

We generally recommend using API tokens that belong to machine users¹, an Upsun account given restricted permissions to the project and whose only purpose is to run automation tasks like this.

After you've added the token as an environment variable, you can add the Upsun CLI as a build dependency to your `.upsun/config.yaml` file:

```shell-session
dependencies:
  php:
    wp-cli/wp-cli-bundle: "^2.4"
    psy/psysh: "^0.10.4"
    platformsh/cli: "*"
```

In other tutorials we've instructed you to download the CLI in your build hooks, but it turns out that won't really work as expected here. Source Operations take place on file systems at a state _just before_ the build hook runs. So build dependencies are available, but if the CLI was installed later, it wouldn't be. If you'd rather not include the CLI as a build dependency in this way, you can still install it during your build hooks. But you'll also need to run the same installation command within the Source Operation definition.

## The update operation

In your `.upsun/config.yaml` file, add the following block:

```shell-session
source:
  operations:
    update-wordpress:
      command: |
        set -e

        # Open a tunnel to the current environment, which allows us to get database credentials.
        ENVIRONMENT=$(git rev-parse --abbrev-ref HEAD)
        platform tunnel:open -p $PLATFORM_PROJECT -e $ENVIRONMENT -y

        # Export the relationships object and then our database credentials to the environment.
        export PLATFORM_RELATIONSHIPS="$(platform tunnel:info --encode)"
        export DB_NAME=$(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".mariadb[0].path")
        export DB_HOST=$(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".mariadb[0].host")
        export DB_PORT=$(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".mariadb[0].port")
        export DB_USER=$(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".mariadb[0].username")
        export DB_PASSWORD=$(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".mariadb[0].password")
        export DB_HOST=$DB_HOST:$DB_PORT

        # Update WordPress with the WP CLI.
        wp core --path=$PLATFORM_SOURCE_DIR/wordpress update
        wp plugin --path=$PLATFORM_SOURCE_DIR/wordpress update-all
        wp theme update --path=$PLATFORM_SOURCE_DIR/wordpress --all

        # Stage changes, committing only when updates are available.
        git add .
        STAGED_UPDATES=$(git diff --cached)
        if [ ${#STAGED_UPDATES} -gt 0 ]; then
            git commit -m "Gloriously autoupdated Wordpress."
        else
            echo "No WordPress updates found."
        fi

        # Close the connection.
        platform tunnel:close -y
```

Note: if you chose MySQL instead of MariaDB in the Getting started guide, or changed the name of your database service to something other than `mariadb`, you'll need to change the code above to reflect the name you used.

So we've got an interesting block of YAML here—let's pick it apart. When the operation is run, we're actually going to use the CLI to open a tunnel to the environment and use that tunnel to mimic the relationships array locally, same as we would in a tethered local development scenario. Having our database credentials available allows us to then run our update commands with the WordPress CLI.

Once we've done that, we run the update. Then we've got a little catch block here that checks if file changes occurred on the repository after the update. This is here because we've noticed that without it running, an update command that results in no available updates (`nothing to commit, working tree clean` should be great news) will sometimes cause the operation to hang there when we try to commit. This block checks if there's anything staged for commit and just exits when everything is up-to-date. Then we close our tunnel to clean up after ourselves.

After we commit and push the operation to the project, let's create a new branch² where we can dedicate to testing updates.

```shell-session
$ upsun environment:branch update-wordpress
```

Once that's successfully deployed, we can at any time run the operation on that environment³:

```shell-session
$ upsun source-operation:run update-wordpress
```

You'll see that the operation will run and, if updates are available on any plugins, themes, or WordPress core, commit them to the environment, ready for testing.

## Automatic updates

It's great that we’ve created a new endpoint for the project to look for and to apply updates to our vanilla WordPress site. But I'm not going to remember to do this regularly, and since I expect you and I aren't made of different stuff, let's automate this.

Add the following to `.upsun/config.yaml`:

```shell-session
crons:
  auto-update-wordpress:
    spec: "0 1 * * *"
    cmd: |
      if [ "$PLATFORM_BRANCH" = update-wordpress ]; then
          platform environment:sync code data --no-wait --yes
          platform source-operation:run update-wordpress --no-wait --yes
      fi
```

Now we have a cron job that runs everyday at 1am, syncs code⁴ and data from our production site, and then runs our update operation. We've even included some branch restrictions so all of our updates happen in the same place—only on our dedicated updates environment.

Now that we’ve shown you the secrets to this Source Operations trick, we hope you’ll give it a try and then report back to us whether it was a showstopper or just a puff of smoke. 

* * *

_¹ See https://upsun.com/pricing/#user-licenses for user licensing fees_

  

_² Unlike Platform.sh, Upsun charges only for resources used. Therefore, when you create a new environment, you'll be charged for any resources used in that environment while it is active. To keep costs to a minimum, you should consider a resource initialization strategy that best makes sense for your situation._

  

_³ Upsun charges for build minutes and resource usage. A WordPress Vanilla source-operation build takes approximately 2 minutes, and the source operation itself can take a minute or more depending on the number of plugins and themes that need to be updated. Assuming 2 minutes to build and 3 minutes to complete, based on current prices a source operation like the example above will cost 0.006 USD or about 0.20 USD/month if you run it once a day._

  

_⁴ Please note that you can not sync code if you are using a source integration. Code syncs between branches will need to occur at the canonical repository source. Alternatively, consider deleting the branch after every merge, and after every source operation run if there are no updates._

### [PHP 8.0 Just-in-Time Compiler | Upsun](https://upsun.com/blog/php-just-in-time-compiler/)

# PHP 8.0 feature focus: Just-in-Time compilation

## Some background

Computers don't actually understand programming languages; they understand very low-level instructions no human could write by hand. There are many ways of getting from a human-readable language like PHP or Rust to a computer-understandable set of instructions.

The most basic, and usually most performant, way is to compile the human-friendly source code directly to CPU instructions "Ahead-of-Time" (AOT). Those instructions then get saved to a "binary" stand-alone executable file. Some common languages that take this approach include C, C++, and Rust.

The least performant, but usually easiest to write, translation method is interpreted languages, often called "scripting languages." In this case, there's an "interpreter" program that translates each statement of source code into machine code as it's "executed." PHP 3 worked like that, which is why PHP 3 was so amazingly slow compared to modern PHP.

Another approach is to use a "virtual machine." A virtual machine works in a similar fashion to an interpreter, but first it converts the source code into a simpler language, essentially a very low-level scripting language, that can be then interpreted much faster. This approach is very popular these days as it offers a good balance between complexity, ease of development, and performance. Sometimes that "simpler language" conversion happens ahead of time—as in Java, C#, or Go—and sometimes it happens on-the-fly—as in PHP, Python, or Javascript. Java calls that simplified version "bytecode." PHP uses the term "opcodes." It's the same idea.

## Just in Time

The latest trend in compilation is the introduction of a "Just in Time" compiler, or JIT. A PHP JIT compiler starts with the simplified intermediary language, and rather than interpreting it, it converts it on-the-fly to machine code, stores that machine code in memory, and executes that.

PHP JIT compilers are very tricky, because in order to get good performance out of them you generally need to be selective in which parts of the intermediary language are compiled to machine code and which aren't. It's not always faster to convert to machine code, depending on the specific details of the code and the language in question. Additionally, the process of converting the simplified code to native machine code may take longer than just running the simplified code once and being done with it.

For that reason, most PHP JIT compilers analyze the code as it's running to identify what parts would give the best bang for the buck and then compile just those bits. The net result, in theory, is that the program literally gets faster as it runs and as the PHP JIT compiler in the virtual machine learns what parts of the code to bother optimizing.

Java was the first widespread language to include a JIT in its virtual machine. Most major Javascript engines now do as well. And, as of PHP 8.0, PHP has joined that list.

## The PHP JIT

PHP's new JIT has been a long time coming. It's actually been under development for several years and nearly shipped in an earlier form in PHP 7.4. Work toward making PHP JIT-capable was the impetus that led to the major rewrite of the engine that gave 7.0 its massive performance boost.

The PHP JIT is built as an extension to the opcode cache. That means it can be enabled and disabled either when building PHP itself or at runtime, via `php.ini`.

## How to configure it

The JIT extension is disabled by default. It can be enabled in `php.ini` by setting `opcache.jit_buffer_size` to a non-zero value. That controls how much space in memory the JIT can fill up with its optimized machine code. More is not always better, though, as the JIT could also waste time compiling code that doesn't really benefit from being compiled.

The other main setting is `opcache.jit`, which controls four levels of JIT aggressiveness. These levels are represented as 4-digit numbers, although they’re not actually numeric values but four different aggressiveness controls. The RFC and documentation have more details, so we won't go into detail here.

There is no universally best configuration for the JIT. As is often the case with advanced tools like this, you'll need to experiment with your own application and tune it appropriately.

## Will it help?

But will the JIT improve performance? The predictable answer, as always, is "it depends." For web apps, kinda maybe. For PHP as an ecosystem, immensely.

PHP, by design, usually runs in a shared-nothing configuration. After each request is handled, the program exits entirely. That gives the JIT very little time to analyze and optimize code, especially since most code in a typical web request is only executed once as the request is handled linearly. Besides, the largest part of those applications is often I/O (talking to the database, mainly), and the JIT can't help with that at all. The benchmarks that have been published so far show the JIT offering only a marginal boost to performance in typical PHP applications run through PHP-FPM or Apache.

Where the JIT has the potential to be really helpful is in use cases where PHP is often not considered today. Persistent daemons, parsers, machine learning, and other long-running CPU intensive processes are where the real benefits lie. Much like the Foreign Function Interface (FFI) support added to PHP 7.4, the goal here is to allow PHP to break out of being a first-class web language and into a first-class general server language.

PHP-Parser is "a PHP parser written in PHP." It's from the same Nikita Popov we've been mentioning throughout this series and is used by many static analysis tools on the market today, such as PHPStan. Nikita has reported that PHP-Parser runs in some cases as much as twice as fast with the new JIT engine.

Persistent applications like React PHP or AmPHP will likely see a notable improvement as well, although not quite as much as they tend to do a lot of I/O (where the JIT is not helpful).

There are machine learning libraries available for PHP, such as Rubix ML or PHP-ML. They're not as widely used as their Python equivalents, in part because, being interpreted, they tend to be slower than the C libraries with nice Python wrappers. With a JIT, however, these CPU-intensive tasks may end up being just as fast or possibly even faster as those available in other languages.

PHP is no longer just the fastest of the major web scripting languages. It's now a viable high-performance general data processing language, which puts persistent workers, machine learning, and other high-CPU tasks into the hands of millions of existing PHP developers around the world.

We primarily have Dmitry Stogov and Zeev Suraski to thank for the multi-year effort to make this RFC happen.

### [What is a CDN? simple guide to speed and security | Upsun](https://upsun.com/blog/what-is-a-cdn/)

# What the heck is a CDN?

Ask a non-technical professional what the most challenging part of their job is, and you’ll often hear, “Understanding what the heck our developers are talking about.” The “What the heck is . . .?” series explains common development terms in simple language. Today, we’re letting you know what the heck your developers are talking about when they talk about a “CDN.”

## **Website CDNs purpose-built for global reach**

When developers talk about CDN (meaning: “content delivery network”), they’re talking about a linked group of web servers distributed across a wide geographic area. The same way you would set up multiple WiFi boosters in your home to make sure you could get a strong data connection in every room, developers rely on CDNs to provide their website customers fast and reliable access no matter where they live.

When you visit a website, it takes a certain time to load. And when you’re clicking around inside the website, it takes a certain time to react to your clicks. The delay between you asking the website to do something and it doing it is known as _latency_. The farther you are from the hosting server that is shuttling your request to the website and the website’s response back to you, the longer the latency. If you’re on your laptop in a cafe in New York City reading through the contestant bios for your favorite Japanese game show, your mocha might be ice cold by the time you scroll to the bottom of the page.

A CDN seeks to decrease latency by getting you closer to a website’s server. A CDN is built from two types of servers: an _origin server_ and _edge servers_. The origin server houses the original copy of the website. It’s the starting point of the CDN. The edge servers are connected to the origin server and each other, but are scattered far and wide geographically. They store copies, or _caches_, of the website data. When you request information from the website, the CDN will send you to the closest edge server to get it. Closer servers mean quicker website responses!

Content delivery networks not only make website traffic faster, but also more resilient. A common type of cyberattack, a distributed denial-of-service (DDOS) attack, works by flooding a website server with data requests, overwhelming it and causing the site to crash. A CDN cushions the origin server by spreading the flood of data requests among the many edge servers.

## **The benefits of CDNs**

The ability of a CDN to distribute and localize website data provides important benefits:

-   It speeds up website loading times by distributing the content from a server located close to the site visitor.
-   It lowers website hosting costs by reducing resource consumption on the origin server.
-   It increases content availability by boosting traffic capacity and limiting hardware failure.
-   It strengthens website resiliency by storing multiple copies of the website across edge servers.
-   It adds a layer of security and defense against malicious data requests.

## **CDNs and Upsun: A formula for site speed**

Upsun recommends Fastly as the preferred CDN partner for all projects. While self-service projects don't include a CDN by default, you can set up Fastly or Cloudflare at any time to deliver major performance improvements. Projects using a CDN enjoy faster loading times, increased traffic capacity, and enhanced security features.

Setting up a CDN is straightforward: simply configure your chosen provider and set up a custom domain. For Fastly specifically, you'll need your own Fastly subscription and can follow their official setup guide to get started. The process works with any Upsun project, giving you the flexibility to add CDN capabilities when you need them.

CDN providers like Fastly offer helpful features such as Anycast options for handling apex domains, while Cloudflare provides CNAME flattening. Both services include security features like HTTPS enforcement and protection against on-path attacks.

To learn more about setting up a CDN with your Upsun project, check out our CDN documentation or contact our team for guidance on choosing the right solution for your needs.

### [Laravel application development | Upsun](https://upsun.com/blog/upsun-for-laravel-applications/)

# Why Upsun is the superior choice for Laravel applications

Laravel developers deserve a hosting platform that not only understands the framework but provides the flexibility and tools needed for applications to evolve and grow. While Laravel Cloud may seem like the obvious choice for hosting Laravel applications, Upsun offers significant advantages that make it the superior option for development teams who want to maximize their Laravel experience.

## Beyond basic Laravel hosting

Laravel Cloud focuses exclusively on hosting Laravel applications, which might appear beneficial at first glance. However, this specialization comes with significant limitations. Upsun, on the other hand, provides excellent Laravel support while offering much more:

-   **Multi-application architecture**: Unlike Laravel Cloud, Upsun allows you to run multiple applications within a single project. This means you can separate your Laravel backend from your frontend (whether it's Vue, React, or another framework, build static or running server-side rendering - SSR), creating a more maintainable and scalable architecture. 
-   **Flexible service ecosystem**: While Laravel Cloud offers only basic MySQL, Serverless Postgres, and S3 buckets, Upsun provides a comprehensive range of services including PostgreSQL, MongoDB, Redis, Elasticsearch, RabbitMQ, Kafka, and many more. Furthermore, we do provide fast local storage for assets, files or cache. This extensive ecosystem ensures your Laravel application has access to all the services it needs.
-   **Framework evolution**: As your project grows, you might need to incorporate additional technologies beyond Laravel. With Upsun, you have the freedom to add Python, Node.js, Go, or other services alongside your Laravel application without migrating to a new platform.

## Automated preview environments with data cloning

One of Upsun's most powerful features for Laravel development is automated preview environments with data cloning – something Laravel Cloud simply doesn't offer:

-   **Git-driven infrastructure**: When you create a new branch in Git, Upsun automatically generates a complete environment clone including your Laravel application, all necessary services, and even your production data (with sanitization options). Laravel Cloud requires manual environment creation and reconnection of all services without data transfer.
-   **Infrastructure as code:** Upsun allows you to define your entire Laravel application stack, including services and routing, in YAML files within your repository. This ensures consistency across environments and eliminates configuration drift. You can use Upsun's Laravel project templates to get started quickly with a ready-to-deploy Laravel configuration.
-   **Parallel development**: Laravel teams can work simultaneously on different features in isolated environments that perfectly mirror production. This eliminates "works on my machine" issues and allows for thorough testing before merging code.
-   **Instant testing environments**: Instead of waiting for manual setup, your Laravel application is immediately available in a new environment when you create a branch. This accelerates development cycles and improves code quality.

## Laravel-ready configuration with greater flexibility

While Laravel Cloud is designed specifically for Laravel, Upsun provides robust Laravel support with additional flexibility:

-   **Infrastructure as code**: Define your entire Laravel application stack, including services and routing, in YAML files within your repository. This ensures consistency across environments and eliminates configuration drift – problems that often occur with manually configured environments.
-   **Laravel project templates**: Upsun offers ready-to-deploy Laravel configuration that makes getting started just as simple as with Laravel Cloud. You can deploy a Laravel application with just a few clicks.
-   **Laravel-specific documentation**: Our comprehensive documentation includes Laravel-specific guides and best practices to ensure you're making the most of your Laravel deployment.

## Advanced observability for Laravel applications

Understanding your Laravel application's performance is crucial, and Upsun provides superior tools:

-   **Integrated Blackfire profiling**: Upsun includes Blackfire integration, offering code-level performance analysis, automated regression detection, and detailed insights into your Laravel application's behavior.
-   **Comprehensive metrics**: Get detailed information about your Laravel application's performance, resource utilization, and third-party service interactions to identify optimization opportunities.
-   **Cross-environment comparisons**: Compare performance metrics across different environments to understand the impact of code changes before they reach production.

## Enterprise-grade reliability and experience

When choosing a platform for your Laravel applications, reliability is paramount. Upsun delivers enterprise-level stability that new platforms simply can't match:

-   **12+ years of platform experience**: Upsun is built on Platform.sh's 12+ years of experience in cloud hosting. This mature foundation means we've encountered and solved countless edge cases and challenges that newer platforms like Laravel Cloud are still discovering.
-   **10,000+ applications in production**: Currently hosting over 10,000 applications across diverse industries and use cases, Upsun has proven its ability to scale and support critical applications reliably.
-   **Global infrastructure**: With multiple data centers across North America, Europe, and Asia-Pacific regions, Upsun provides robust geographic redundancy and compliance options.
-   **Comprehensive compliance**: Upsun maintains PCI DSS, SOC 2, and GDPR compliance, making it suitable for applications with stringent security and regulatory requirements.
-   **24/7 support and guaranteed SLAs**: Enterprise customers benefit from follow-the-sun support with guaranteed response times and up to 99.99% uptime SLAs.

## Real-world example: Laravel + Vue.js

Consider a common scenario: a Laravel application with a Vue.js frontend. With Laravel Cloud, you're forced to include your frontend within your Laravel project, potentially complicating your build process and limiting your architectural options.

With Upsun, you can:

1.  Deploy Laravel as a dedicated API backend application
2.  Run your Vue.js frontend as a separate application
3.  Configure routing between them automatically
4.  Scale each component independently based on resource needs
5.  Create preview environments that clone both applications and their data

This approach provides greater flexibility, improved maintainability, and better performance optimization – advantages simply not available with Laravel Cloud.

## Pricing transparency and resource flexibility

Upsun's approach to pricing and resources offers significant advantages over Laravel Cloud:

-   **Competitive project pricing**: While Laravel Cloud requires a minimum $20 fee to run just one application in production, Upsun offers your first project with no monthly minimum and additional projects for just $9 each. This makes Upsun more cost-effective, especially if you're managing multiple projects.
-   **Usage-based resource pricing**: Beyond the project fee, Upsun's pricing scales based on your actual resource consumption, giving you complete control over costs as your application grows.
-   **Resource transparency**: Upsun provides clear visibility into CPU, RAM, and storage utilization, allowing you to optimize costs effectively. Laravel Cloud's billing structure makes it difficult to predict monthly expenses.
-   **Independent scaling**: Adjust resources for different parts of your application independently, ensuring optimal performance and cost efficiency without overpaying for resources you don't need.

## Conclusion: the clear choice for Laravel

While Laravel Cloud offers a specialized platform for Laravel applications, Upsun provides a more powerful, flexible, and comprehensive hosting solution that grows with your application. With automated preview environments, extensive service options, multi-application architecture, and superior observability tools, Upsun is the clear choice for Laravel developers who want to maximize their application's potential.

Experience the difference yourself by creating a free Upsun account today and deploying your Laravel application in minutes.

### [Platform.sh (Upsun) - 2025 Gartner Magic Quadrant™](https://upsun.com/blog/gartner-magic-quadrant-2025/)

# Platform.sh (Upsun) recognized for second consecutive year in the Gartner® Magic Quadrant™ for Cloud-Native Application Platforms

**Platform.sh’s Cloud Application Platform, Upsun, acknowledged for its Ability to Execute and Completeness of Vision.**

Platform.sh, a Cloud Application Platform, is proud to announce its recognition for the second year in a row in the Gartner® Magic Quadrant™ for Cloud-Native Application Platforms for its latest Cloud Application Platform, Upsun.

Upsun empowers development teams by simplifying infrastructure management, speeding up software delivery, and enabling scalable, AI-ready applications. As more organizations modernize legacy systems and adopt data-driven approaches, Upsun provides the flexibility, performance, and enterprise-grade control required to deliver meaningful results quickly.

> “We believe our recognition for the second consecutive year in the Gartner Magic Quadrant for Cloud-Native Application Platforms validates the strength of Upsun as an enterprise-ready solution built for the future. As businesses accelerate digital transformation and embrace AI-driven innovation, Upsun helps teams deliver faster, scale seamlessly, and operate responsibly without getting bogged down by infrastructure complexity.” — Fred Plais, Co-Founder and CEO, Platform.sh

Over the past year, Platform.sh has introduced new capabilities to support the growing demands of modern software teams:

-   Performance-guaranteed containers on shared infrastructure, giving teams the ability to run high-performance workloads without requiring dedicated environments
-   Advanced infrastructure metrics dashboards, providing greater visibility into network and application behavior
-   IBM Cloud validation for financial services, demonstrating that the platform meets the strict security and compliance needs of regulated industries

We believe Upsun continues to stand out for its strengths in backend support, compliance, and governance. With features such as full audit logs, role-based access control, and seamless multicloud support, the platform gives organizations the confidence to scale and innovate without sacrificing control.

> "We believe Gartner recognizes the value and necessity of AI software development to accelerate delivery. We are thrilled to support that with an offer that provides both freedom for innovation and guardrails to preserve standardization and security." — Nigel Kersten, Chief Product Officer, Platform.sh

Read the 2025 Gartner Magic Quadrant for Cloud-Native Application Platforms to learn more about how Upsun was recognized for its ability to execute and completeness of vision.

Explore the full report now

* * *

_Gartner, Magic Quadrant for Cloud-Native Application Platforms, Tigran Egiazarov, Mukul Saha, Prasanna Lakshmi Narasimha, 4 August 2025_

_GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally, and MAGIC QUADRANT is a registered trademark of Gartner, Inc. and/or its affiliates and are used herein with permission. All rights reserved._

_Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose._

_This graphic was published by Gartner, Inc. as part of a larger research document and should be evaluated in the context of the entire document. The Gartner document is available upon request from Platform.sh (Upsun)._

### [A new approach to QA and testing | Upsun](https://upsun.com/blog/a-new-approach-to-qa-and-testing/)

# Breaking things fast: A new Approach to QA and testing

_This post is based on Greg Qualls, Director of Product Marketing, presentation, "Accelerating QA and Testing," at SymfonyCon 2024. We utilized AI tools for transcription and to enhance the structure and clarity of the content._

Before we dive in, I have over 18 years of experience in sales. If, at times, I sound like I'm trying to sell you something, please forgive me. I promise I'm not. I just want to share ideas that might help you think differently about testing and QA, particularly if you're working with or considering Upsun.

Also, full disclosure: I'm really good at two things: breaking stuff and asking what some might call "dumb questions." Today, we're going to explore why both of these skills are actually valuable in software development.

## The cost of waiting

Let's start with a sobering statistic: it's 30 times more expensive to fix a bug after it reaches production than it is to catch it earlier in the development process.

This isn't just a made-up number. The reason the cost multiplies so dramatically is because production defects create ripple effects far beyond the code itself. They impact your customers, damage your brand reputation, erode user trust, and force your team to spend valuable time firefighting instead of building new features.

This is why testing matters. But here's where things get interesting.

## The philosophy of breaking things fast

In 2012, Mark Zuckerberg shared a core value in his "Hacker Way" philosophy: **"Move fast and break things. Unless you are breaking stuff, you're not moving fast enough."**

I'd like to adapt this for our context: **Move fast and break things. Unless you're breaking stuff, you're not really testing or moving fast.**

The goal of testing should be to break things as quickly as possible, to determine if something works, so we can either fix it or proceed with building the next feature. This is what we really love doing: creating features, developing functionality, writing code that matters.

## Two fundamental questions

When you think about it, all testing really boils down to two fundamental questions:

**1\. Is it broken?**

This covers your unit testing, functional testing, system testing, and exploratory testing. You're asking: Does this work the way it should?

**2\. When will it break?**

This encompasses load testing, penetration testing, scalability testing, and spike testing. You're asking: what are the limits of this system?

In both cases, you're trying to answer these questions as fast as possible.

## The problem with traditional workflows

Most development workflows follow a familiar pattern: local development → dev environment → staging → production. You test at each stage, iterate, fix issues, and eventually see those green checkmarks that mean you're ready to deploy.

But this process can be painfully slow.

### My testing journey

Let me share a personal story. Back in 2002-2003, I was the "Web Master" at Eastern New Mexico University. Everything was pure HTML—no JavaScript, no CSS (CSS came later, and I thought it was revolutionary).

My testing process was beautifully simple: write the code, FTP it to the server, visit the page on enmu.edu, and see if it worked. If it didn't, I'd fix it and upload again. We'd now call this "testing in production," but back then, there was no distinction—everything was production. There were no dev environments, no staging environments. Just my computer and the live server.

## The hidden benefits of testing in production

Now, before you panic, hear me out. What if you could test in production? Think about the benefits:

-   **Immediate feedback** – You know instantly if something works
-   **Real-world data** – You're using actual servers, databases, and services
-   **No data sanitization needed** – Everything is already where it should be
-   **Quick discovery** – Environment-specific issues reveal themselves immediately
-   **Proper performance testing** – You're testing against real conditions

## The one big problem

Of course, there's one massive issue with testing in production: **users**.

Those pesky users who complain when the site goes down. Then your boss finds out. Then you're in a performance review explaining what happened. And before you know it, you're on LinkedIn posting "Open to work."

Therefore, we cannot simply test in production. Or can we?

## The solution: replicate production

The answer is to replicate production so accurately that testing there is essentially the same as testing in production, minus the users.

However, replicating production properly is an incredibly complex process. You need to:

-   Clone not just code, but data layers and services
-   Handle networking pieces like DNS and SSL certificates
-   Use infrastructure as code and Git-based workflows
-   Manage access control and permissions
-   Ensure everything syncs perfectly

Many companies struggle with this. I once spoke with a large university that needed **three weeks** to spin up a development environment. Three weeks! By the time they had everything configured and the data synced, production had already undergone significant changes.

### Full-Stack preview environments

This is where Upsun's approach becomes interesting. The platform offers full-stack cloned environments—complete replicas of production that you can spin up instantly.

When you create a branch in Upsun, you're not just branching the code. Behind the scenes, the platform replicates:

-   The entire codebase
-   All databases and data
-   Services and configurations
-   Network settings
-   Infrastructure setup

Everything except the users. 

## Breaking things fast in practice

Earlier at SymfonyCon, a live demo featured two developers attempting to decouple a monolithic Symfony application into a Next.js frontend with a Symfony backend. It was a 30-minute demonstration on fire; the kind of live demo where things don't quite work at first.

They deployed. It didn't work. They changed something and deployed again. Still didn't work. They iterated rapidly, testing and breaking things as fast as possible. Eventually, they found the issue: in the configuration file, they had written "npm" instead of "npx"—one character difference.

Here's the remarkable part: they transitioned from a monolithic application to a fully decoupled architecture in 30 minutes, thanks to their ability to iterate rapidly. They knew that if it worked in their development environment, it would work in production, because the environments were identical.

## The collaboration challenge

Of course, development is rarely a solo endeavor. You have coworkers, those other developers who, let's be honest, are never quite as good as you are.

In traditional workflows, when multiple developers push to the same development environment, merge conflicts are inevitable. Someone has changed something, and now your code no longer works. You have that conversation: "Greg, what are you doing? I'm working on this! You need to install this service first!"

## Multiple isolated environments

The better solution is to give every developer their own production-like environment. You work on your code, they work on theirs, completely isolated.

When you're ready, you push to production. Then your colleague pulls down your changes—not just the code, but all the data, database updates, service configurations, and caching. Everything syncs automatically. They test their code against this new state, and the cycle continues.

Everyone works separately but collaboratively, moving seamlessly because you're all developing in production-like environments.

## The real-world benefits

When you can break things faster—especially with platforms like Upsun—you gain:

-   **Faster testing cycles** – You can attempt ambitious changes, like decoupling an entire application, in under an hour.
-   **Faster development cycles** – When leadership asks for something "as soon as possible," you can iterate rapidly, trying new languages, frameworks, services, or machine learning libraries to see what works.
-   **Higher code quality** – You test and iterate until you're confident, knowing that if it works here, it will work in production.
-   **Reduced risk** – You catch issues before users do, avoiding those uncomfortable performance reviews about site downtime and lost revenue.

And here's something for the business side: proper testing and QA environments have been proven to show a 40% increase in customer satisfaction scores. When you trust your testing, you ship better code, which leads to happier customers.

## Three practical takeaways

Whether or not you use Upsun, here are three principles for breaking things faster:

#### **1\. Change your mindset**

Too many developers feel they need to get everything perfect on the first try. Instead, embrace failure as learning. Try it. See if it works. Try again. You'll learn more from breaking things than from getting it right immediately.

From that live demo earlier, I'll never forget: if you build your Next.js app with npx, make sure you run the command also uses npx, not npm. I learned that by watching someone else fail—and that lesson stuck.

#### **2\. Leverage testing environments**

Please don't walk out of here thinking, "Greg said we should just test in production!" If you tell your leadership that, they'll ask, "Who's Greg?" and you'll be in trouble.

You need testing environments. But they must be as close to production as possible. Think through all the variables: infrastructure, data, services, networking, and access control. Cover as many as you can.

#### **3\. Automate everything**

It's not just about breaking things, it's about breaking things fast. Automate your environment creation. Set up CI/CD pipelines. Make it so testing environments spin up instantly and deployments happen automatically when tests pass.

The faster you can break and fix, the sooner you can get back to building new features and moving your product forward.

## Final thoughts

Testing doesn't have to be a chore. When you have the right tools and mindset, it becomes part of the creative process, a way to explore possibilities, push boundaries, and learn quickly.

The goal isn't to avoid breaking things. The goal is to break them as fast as possible in safe environments, learn from those breaks, and ship code you can trust.

So go ahead: break things. Just break them fast, break them safely, and learn something from each break.

_Questions about Upsun or implementing these practices? Visit the_ _Upsun website_ _or check out our_ _free trial_ _to see full-stack preview environments in action._

### [Why secure OAuth needs a managed platform approach | Upsun](https://upsun.com/blog/secure-oauth-managed-platform/)

# Secure OAuth is easy to demo and hard to operate at scale

Most teams think about OAuth the same way they think about logging. It is necessary, familiar, and supposedly solved. Then it hits production.

Suddenly, it is not just one authentication flow. It is a complex web of two or more applications, multiple environments, cookies, redirects, secrets, and route boundaries. 

The uncomfortable truth is that OAuth security is not just an implementation detail. It is an operational system, and that system is only as strong as the platform it runs on.

## **The hidden risk is not the code**

The Authorization Code Flow with Proof Key for Code Exchange (PKCE) is the modern, widely recommended approach for browser-based applications. It is designed to protect the exchange of authorization codes. However, using PKCE is the easy part.

The harder part is making the whole system repeatable and safe when:

-   The frontend and backend are deployed independently.
-   Environments multiply across preview, staging, and production.
-   Redirect URIs must change per environment.
-   Secrets drift across different teams.
-   A minor configuration mistake becomes a security incident.

This is where many teams discover they did not just choose an authentication pattern. They chose a significant platform responsibility.

## **Multi-app authentication flows expose platform gaps**

OAuth is a cross-application workflow by design. Even a standard setup like a Next.js frontend and a Laravel OAuth server forces you to manage:

-   Precise routing and subdomain management.
-   Environment-specific URLs and redirect URIs.
-   Secure token storage and strict cookie rules.
-   Secrets and keys with clear access boundaries.
-   Consistent deployment order and rollback behavior.

If you do not already have a standardized platform, you end up assembling these pieces manually with a mix of ingress rules, secret managers, and custom pipelines. 

That is not free. It is an internal platform project, whether your organization calls it that or not.

## **The buyer question: who owns the operational risk?**

When authentication breaks in production, it is rarely because someone forgot how OAuth works. It is usually because the surrounding delivery system is fragile. 

The wrong redirect URI might be deployed to the wrong environment, or a secret might be rotated without a clear rollout path.

At that point, the question becomes less about code and more about ownership. 

Do you want application teams to own the operational glue, or do you want the platform to absorb that complexity?

## **What platform-owned authentication looks like**

A managed cloud application platform does not replace the OAuth flow. It replaces the accidental complexity around it. 

On Upsun, the core idea is that the platform manages the infrastructure contract so the code can stay clean:

-   Applications, routes, and services are declared in Git.
-   Environments are created automatically from branches.
-   Routing is a native part of the platform.
-   Preview environments are production-perfect by default.

In practice, this means your Next.js frontend and Laravel OAuth server can be deployed as a single, versioned system. It is not just a diagram on a wiki; it is a real, functional environment you can validate before a single line of code reaches production.

## **Why preview environments matter for security**

OAuth diagrams look clean, but production is messy. Upsun’s preview environments give your team a way to validate what actually matters before a release:

-   Testing real routing behavior across domains.
-   Validating cookies under production-like conditions.
-   Verifying real secret handling and configuration injection.
-   Catching integration regressions early in the cycle.

For security-sensitive flows, this is the difference between implementing a feature and being able to operate it reliably.

## **Security best practice is necessary but not sufficient**

There is plenty of guidance on OAuth threat models. 

What those documents cannot do is run your environments for you. Most OAuth failures in the real world are operational: inconsistency, drift, missing guardrails, and a platform that does not make the secure path the default path.

Secure OAuth at scale is not a library choice. It is a delivery choice.

## **The practical takeaway**

If you are building a modern application with separate frontend and backend components, the real decision is how much platform you want to build around it. 

To keep security-sensitive workflows repeatable, the platform must provide:

-   Consistent routing and domain management.
-   Safe secret handling and environment boundaries.
-   Production-like previews for every branch.
-   A Git-driven, auditable delivery model.

That is how "secure by design" becomes a reality rather than a checklist you hope stays true.

### **Explore further**

-   **Read the** **full technical implementation guide****:** Follow the step-by-step tutorial for OAuth authentication between Next.js and Laravel Passport on the Upsun Dev Center.
-   **Explore** **Upsun preview environments****:** See how every branch becomes a production-grade environment for security validation.

### [Scaling software with design patterns | Upsun](https://upsun.com/blog/software-design-patterns/)

# Making software scale better with modern design patterns

Scaling software isn't just about adding more servers—it's about managing complexity as your system grows. When you move to distributed systems and the cloud, you start running into new problems like unpredictable traffic spikes, dependencies that get messy fast, and small hiccups that can snowball into bigger outages if you’re not careful.

Design patterns won't solve these problems for you, but they offer proven ways to structure your code and architecture so you can adapt and scale with confidence. In this article, I'll break down the patterns that have made a difference in real projects, where they work, where they don't, and how to apply them practically.

## **Why design patterns matter in modern development**

As your systems grow, keeping them maintainable becomes just as important as handling more users. Design patterns give you proven frameworks to organize code and architecture so you can break down complexity and implement changes with confidence.

These patterns won’t fix everything overnight, but they give us a reliable toolkit so we’re not scrambling to solve the same problems from scratch whenever something new pops up.

### **Let's look at common scaling issues**

Let’s get into a few scaling headaches we’ve run into and patterns that actually helped us work through them.

-   **Code complexity**: The Facade pattern tames messy legacy APIs by exposing a cleaner interface. It’s a big help for bringing new developers up to speed and keeps folks from misusing the API, but if we’re not careful, some of the old complexity can still lurk behind the scenes.
-   **Distributed system resilience:** External service dependencies are the primary cause of recent cascading failures. The Circuit Breaker pattern is essential, but it must be paired with Automated Service Discovery. On Upsun, this networking is handled at the platform level, ensuring that if a microservice fails, the edge layer can serve stale cache or a graceful fallback without manual intervention.
-   **Scaling components:** Event-driven patterns, typically built with message queues, let your microservices operate and scale independently. That extra resilience is great, but it does mean tracking down bugs or following a request across services can get a lot trickier.
-   **Data handling:** We rely on the Repository pattern to keep our business logic and data access separated. With this setup, we can tweak our data model or move to a different database without tearing apart the whole application.

### **Pattern benefits**

-   **Unified approach**: Teams work more efficiently with standardized problem-solving methods
-   **Proven solutions**: Build on established patterns to address issues
-   **Future-ready design**: Build systems that can grow along with your needs while keeping things simple to maintain

### **Next steps**

Find areas where scaling is a concern in your architecture. From there, match specific design patterns to your challenges. Start with small steps when you put these patterns in place - this helps avoid making things more complex than they need to be.

When you add design patterns to your workflow, you'll build systems that can handle what modern development throws at them - no matter how fast your users grow.

## **Key challenges in scaling software**

When your software gets bigger, you need more than just more computers to make it work well. You need to fix problems that happen as more people use your software. Here are three big problems and how to fix them:

### **Managing high traffic**

When more users hit your app, things slow down. This can happen during product launches, for example. Your app might take longer to respond. Or even stop working.

**How to handle it**:

-   **Load balancing**: Share traffic across servers to keep your app running smoothly when lots of people use it at once
-   **Scale as needed**: Add more power when traffic goes up, scale back when it drops
-   **Smarter database use**: Keep copies of your data ready to handle more readers

Here's what to do when traffic gets high:

-   **Route traffic intelligently:** Sharing load across servers, keeping everything moving.
-   **Scale your resources** **by capacity:** based on what you need in the moment.
-   **Use your database wisely**: Keep data copies ready so more users can access at once.

### **Keeping code clean**

When your app gets bigger, the code can get messy and hard to update. That's going to slow down new features and create more problems to fix.

**How to handle it**:

-   **Organized structure**: Break your app into clear, separate pieces that work together
-   **Regular cleanup**: Take time to tidy up your code to prevent future headaches
-   **Testing**: Ensure robust test coverage to catch cascading issues early.
-   **Testing**: Run comprehensive tests to catch issues early, before they spread through your system.

### **Distributed systems**

Managing data consistency across services, handling communication between them, and preventing errors from spreading are common challenges in distributed systems. For example, if one service has network problems, those issues can affect other parts of your system if you're not careful.

**How we handle it**

-   We handle message queues (like RabbitMQ and Kafka) to keep services communicating smoothly and stop problems from spreading through the system
-   We track how requests move through our system to catch and fix performance issues early on, but sometimes miss things
-   We use reliable tools like Raft and Paxos to keep data consistent when working with distributed systems

### **Building for scalability**

The key to making things scale well is finding the bottlenecks early on. That could mean speeding up slow database queries, cleaning up messy code, or picking tools that fit your needs. Taking care of these issues early has saved us from bigger headaches later on.

## **Helpful patterns that make systems grow better**

Making things scale isn't as simple as it sounds. You need to plan and pick the right tools for the job. Here are some patterns that can help keep your system running well as it grows, while staying easy to maintain.

Beyond technologies, building scalable systems comes down to thoughtful design. Next, we'll take a look at common challenges, like systems that are too tightly coupled, handling lots of user data at once. Or making things just generally easier to manage. Here are some proven approaches to help your system grow while keeping maintainability.

### **1\. Layered architecture**

Imagine splitting your system into three key parts. What users see, the rules running things, and the data storage. That's a layered architecture, and it's a clean way to set up that'll let you maintain and grow your system without running into issues.

**Why it works:**

-   Changes in one layer (e.g., introducing a new database) don’t directly impact others.
-   Clear boundaries make testing and finding bugs easier and help new developers get up to speed faster.

**Example in TypeScript:**

```shell-session
// Service layer separates business logic from data access

class UserService {

  constructor(private userRepository: IUserRepository) {}

  fetchUserData(userId: string) {

    return this.userRepository.getById(userId);

  }

}
```

  
Having these smaller pieces makes it easier to change things without causing problems in the whole system.

### **2\. Microservices: splitting a complex app into smaller, self-sufficient parts**

Microservices help break down applications into smaller parts that can work on their own. Each part runs separately with its own database and lifecycle.

**Why it works:**

-   Individual services can scale based on demand (e.g., only scaling payment processing during peak times).
-   Reduces risk: Changes to one service don’t disrupt the entire system.

Containers (via Docker) and orchestration tools (e.g., Kubernetes) simplify deploying and managing microservices. Similarly, GraphQL federation streams interactions between services when building APIs.

**Example: Simplified GraphQL integration for a microservice**

```shell-session
// Independent user service in microservices  
  
interface IUserService {  
getUser(id: string): Promise\<User\>;  

}  
```

  
 This decoupled system also allows teams to mix tech stacks, giving flexibility to optimize specific services.

### **3\. Event-driven architecture**

In event-driven systems, your services share data through message queues like Kafka or RabbitMQ. This keeps your system stable and running smoothly, even when you get lots of users at once.

**Why it works:**

-   Enables independent service operation during high traffic
-   Perfect for handling concurrent requests in real-time systems
-   Reduces system-wide slowdowns during peak loads
-   Efficiently manages traffic spikes during high-demand periods

**Example in Java using Kafka:**

```shell-session
// Sending events with Kafka producer

ProducerRecord<String, String> record = new ProducerRecord<>("user-registration", userData);

kafkaProducer.send(record);
```

Event-driven patterns work well with serverless systems, too. They help process things at the same tim,e which makes your system more flexible.

### **4\. Data caching pattern**

Database bottlenecks often hold back scaling efforts. Caching resolves this by storing frequently accessed data in memory, reducing query latency during heavy usage.

**Why it works:**

-   Offloads read-heavy operations to services like Redis or Memcached.
-   Batches similar requests, avoiding redundant network/database traffic.

**Example: Using DataLoader for GraphQL caching**

```shell-session
// Batch and cache GraphQL requests

const userLoader = new DataLoader(keys => batchLoadUsers(keys));

const user = await userLoader.load(userId);
```

Good caching helps your system stay stable when lots of people use it at once, taking some pressure off your database and making everything respond faster.

### **5\. Cloud-native patterns**

Cloud platforms such as AWS, Azure, and Google Cloud let you scale up and down automatically, which makes managing distributed systems a lot easier. Having this kind of flexibility means you don't have to spend as much time worrying about how to handle growth in your system.

**Infrastructure as code and portability** 

Scaling in 2026 needs to be about standardized environments rather than vendor-specific serverless functions. By defining your services and resource ratios through a unified configuration, you ensure your design patterns remain portable across cloud providers. This eliminates operational overhead and allows your team to focus on architectural integrity rather than cloud-specific setup.

**Why this works well**

-   The system scales itself based on demand, which keeps things running smoothly and costs under control.
-   Standardized environments make deployment easier so teams can spend more time building new features.
-   Upsun handles the underlying cloud orchestration: managing environment setup and security certificates while ensuring your system can grow as needed.

**Real example: AWS Lambda in action**

-   You write your function code
-   Then you deploy it and AWS handles everything else - it runs your code whenever something triggers it, like a new web request

Upsun takes care of all those annoying cloud setup tasks for you - handling environment setup and SSL certificates in the background while making sure your system can still grow when needed.

### **Getting started**

1.  First, take a look at what's slowing your system down - like if your database can't keep up with requests, or if your codebase is getting too messy, or if you've got everything stuffed into one big monolith that's getting harder to work with
2.  Take it step by step: Pick one feature to turn into a microservice or add some caching to speed up something that gets read a lot.
3.  Try cloud tools or serverless options for the simpler parts of your system - they handle the scaling for you.

Taking things step by step helps you build something that grows naturally without ending up with a system that's breaking down or slow to a crawl right when you need it to work the most.

### **Seeing patterns work together**

Let's look at a real example of how different patterns can work together to solve tricky problems. We'll see how mixing the Proxy pattern with Resource Cache makes data access work better:

```shell-session
// Resource Cache pattern
public class DataCache {
private Map<String, Object> cache = new HashMap<>();
public Object get(String ``key) {
return cache.getOrDefault(key, null);
}
public void put(String key, Object value) {
cache.put(key, value);
}
}
// Proxy pattern combined with cache
public class DatabaseProxy implements DatabaseInterface {
private final Database realDatabase;
private final DataCache cache;
public DatabaseProxy() {
this.realDatabase = new Database();
this.cache = new DataCache();
}
public Data fetchRecord(String id) {
// First check cache
Data cachedResult = (Data) cache.get(id);
if (cachedResult != null) {
return cachedResult;
}
// If not in cache, get from database
Data result = realDatabase.fetchRecord(id);
cache.put(id, result);
return result;
}
}

```

  
The Proxy pattern controls database access and keeps an eye on things, while the Resource Cache keeps frequently used data ready to go in memory. When they work together, you get both security and speed.

### **Continuous integration and deployment**

When your code base grows, handling changes while keeping things smooth is difficult. Things are running fast, and stability takes work.

CI/CD pipelines automate testing and deployment, which means you can push code changes through your system without constant manual work at each step. Your deployment process gets streamlined and takes less effort when rolling out updates.

Popular CI/CD tools like GitHub Actions, Jenkins, CircleCI, and GitLab CI, when combined with Docker, help ensure your builds stay consistent across environments.

For example, your pipeline could run all your tests, build containers, and roll updates out to Kubernetes without anyone having to do it by hand.

However, standard pipelines often encounter issues when testing complex scaling patterns against empty or mock databases. To properly validate distributed systems, the pipeline must account for data consistency. Testing against production-parallel datasets ensures that scaling logic and service integrations hold up under real-world conditions before updates reach production. 

So when you pair monitoring together with automated deployments, you end up with a system that can grow and adapt as you need.  
 

## **What modern design patterns help us achieve**

### **Improved scalability**

Modern design patterns help you target specific parts of your system that need more power - like separating the login service when tons of users try to get in at once. You'll target resources where they're needed, and your system will run better during high traffic periods.

When there's a spike in login traffic, you can scale up just that service while keeping everything else the same. This focused scaling strategy helps you use exactly what you need, and nothing more.

### **Increased maintainability**

Modern design patterns make your growing codebase less of a pain by creating clear, organized structures - which means you can understand what's happening when you need to fix something or add new features.

### **Resilience and fault tolerance**

When you build modern systems, making them resilient against failure needs to be a core part of your design. A good system architecture helps prevent small issues from taking down your entire application - which is super important when you're running services that depend on each other.

Breaking your system into smaller parts means that when something does break (and it will), the problem stays contained. And your users? They probably won't even notice there was an issue. This approach to building systems helps maintain service even when things aren't perfect, which is exactly what builds trust with the people using your product.

## **Making it work in practice with Upsun**

These patterns work even better with the right infrastructure backing them up. That's where Upsun comes in to make things simpler:

-   Quick cloning for dev environments
    -   Test each service quickly - no waiting
    -   Copy real data fast to test how things work
    -   Try new ways to build without breaking live sites
-   Workflow features that make distributed systems easier
    -   Preview environments show up automatically when you make changes
    -   Service routing and discovery just work
    -   SSL certs and security handled for you
-   Resource management made simple
    -   Scale each service based on what it needs
    -   Containers size themselves based on how they're used
    -   Only pay for what you use

Instead of spending time on infrastructure setup, your team can focus on implementing the patterns that matter most for your application's scalability. Upsun handles the complex parts of cloud infrastructure, letting you move faster on architectural improvements.

## **Scale with confidence**

Looking to scale? Here are some metrics that can help guide your decisions - think of them as signposts pointing you toward the right scaling approach for your system.

-   Consider microservices when:
-   If your requests are regularly taking more than half a second, it’s probably time to rethink your setup.
-   Individual service components handle >1000 requests per minute
-   Teams need autonomous deployment capabilities
-   Feature development becomes blocked by monolith complexity
-   It’s probably time to add caching if your database CPU is running hot. Say, above 70% most of the time.
-   If you’re reading far more than you’re writing. Think 80% reads or higher, and caching will take a lot of pressure off your database.
-   Query response times surpass 100ms
-   Identical data is repeatedly requested within short time windows
-   Adopt event-driven architecture when:
-   System processes >10,000 events per second
-   Traffic spikes exceed 3x baseline load
-   Async operations comprise >40% of processing time
-   Services need to maintain functionality during downstream outages

You'll get the most utility from these patterns at scale, and Upsun has the infrastructure covered so you can focus on building.

Fix your biggest bottleneck first. Use metrics to guide each scaling decision. This keeps your system performing well without unnecessary complexity.

### [Can your business survive with only 99.95% uptime | Upsun](https://upsun.com/blog/can-your-business-survive-with-only-99-95-percent-uptime/)

# Can your business survive with only 99.95% uptime?

IT leaders are often told that 99.95% availability is “good enough.” On paper, it sounds solid. In practice, those few minutes of downtime stack up into missed revenue, SLA penalties, and lost trust. For teams with broad portfolios and limited headcount, the risk profile of 99.95% looks worse every quarter.

## What 99.95% uptime really means

An SLA of 99.95% permits roughly 21 minutes 55 seconds of downtime each month.¹ Over a year, that grows to about 4 hours and 23 minutes.¹ By contrast, 99.99% trims the monthly allowance to about 4 minutes and 23 seconds, and the annual exposure to about 52 minutes.²

Those extra hours are not just an availability number. Google’s SRE guidance treats availability as a business decision, tied to customer impact and error budgets, not a vanity metric.³ The question is not “Can engineering tolerate 0.05& ?” It is “Can the business tolerate it during peak events, releases, and external incidents?”³

## The cost side of 99.95%

Independent studies continue to quantify the financial hit. In Uptime Institute’s 2024 analysis, 54% of organizations said their most recent significant outage cost more than 100,000 dollars, and 16% reported more than 1 million dollars.⁴ ITIC’s 2024 survey similarly found that the hourly cost of downtime exceeds 300,000 dollars for over 90% of midsize and large enterprises.⁵

Even if your incidents are shorter than an hour, compound effects matter. Recovery work steals focus from roadmap delivery. Support volume climbs. Stakeholder confidence erodes. For IT middle management tasked with modernization and predictable outcomes, “good enough” availability creates unpredictable weekends and unpredictable costs.

## Why teams settle for 99.95%

-   Legacy release processes that make safer deploys feel slower than risky ones.
-   Sparse staging environments that do not mirror production closely enough.
-   Tool sprawl across CI, hosting, and observability that hides the real SLO picture.
-   A belief that higher availability will increase infrastructure cost.

These are solvable platform problems, not permanent constraints.

## A pragmatic path to 99.99%

You do not need to overspend to raise your availability target. You need a platform approach that standardizes delivery, catches regressions early, and removes change risk.

### **1) Make every branch production-grade**

If the first time your code meets production data is production, you invite incidents. Upsun spins up production-perfect clones per Git branch that include code, configuration, and services, so regressions show up before they reach customers. Learn how Upsun environments work.

### **2) Clone data quickly and safely**

Previews are only useful if they use realistic data. Upsun’s instant data cloning supports sanitization patterns, so teams can test real scenarios without exposing sensitive information. This drives safer rollouts and fewer on-call pages. Explore Upsun product benefits.

### **3) Orchestrate multi-service apps reliably**

Complex topologies are a reliability risk when each team scripts them differently. Upsun orchestrates applications, services, routing, and deployments as a consistent, policy-aware workflow that developers do not have to reinvent. Build and deploy overview.

### **4) Close the loop with observability and APM**

Raising your SLO without visibility is guesswork. Consolidate logs, metrics, and traces so that error budgets are clear and rollbacks are fast. Teams report that integrated observability reduces MTTD and MTTR, shrinking the area under the downtime curve.⁴

## Calculating the impact: SLA and error budgets

An SLO of 99.99% yields a monthly error budget of about 4 minutes and 23 seconds.² Treat that budget as a planning tool. You spend it on controlled maintenance windows and minor blips. You do not spend it on risky night releases.

If you target only 99.95% , your monthly error budget is nearly 22 minutes.¹ That seems generous until you add a short provider incident, a noisy rollback, and a bad feature flag. The budget is gone before the quarter’s key launch.³

## Why IT leaders choose Upsun for higher availability

-   **Predictable delivery across teams.** Git-driven YAML config, consistent pipelines, and branch-level production clones reduce change risk. See what Upsun is.
-   **Faster diagnosis.** Integrated observability and profiling shorten feedback loops, enabling incidents to be contained quickly.
-   **Economics that beat build-your-own.** Buy over build to cut run costs and redeploy scarce engineers to modernization work.
-   **Uptime commitment.** Upsun backs its platform with a 99.99% SLA, so you are not accepting 99.95% risk by default.

For a deeper product overview, visit the Upsun homepage or learn how to get started.

## What to do next

1.  Reconfirm your critical journeys and set SLOs that reflect customer and regulatory risk.³
2.  Quantify downtime cost using your real revenue profile and support overhead.⁴ ⁵
3.  Pilot a platform workflow where every branch is production-grade, data is safely cloned, and deploys are boring. See the Upsun product page.

### **SLA and error budgets for IT leaders**

Raising availability is not about chasing perfection. It is about lowering the incident probability and blast radius at a cost that the business accepts. A platform that standardizes delivery, shortens feedback loops, and gives developers realistic environments is the most reliable way to trade 99.95% anxiety for 99.99% confidence.

**Sources**

1.  Uptime calculator: **99.95** percent availability and downtime windows.
2.  Uptime calculator: **99.99** percent availability and downtime windows.
3.  Google SRE, Availability table, and concepts. Google SRE workbook
4.  Annual Outage Analysis 2024, executive summary. Uptime Institute PDF

2024 Hourly Cost of Downtime Survey. ITIC report summary

### [AI cost optimization for scaling teams | Upsun](https://upsun.com/blog/ai-infrastructure-cost-optimization/)

# AI infrastructure cost optimization for scaling teams

The 2026 AI landscape has shifted from "Can we build it?" to "How much will it cost to run it?" 

For CTOs and engineering leaders, the challenge is no longer just model performance: it is the underlying infrastructure sprawl that silently erodes margins.

When AI workloads scale, they often inherit the inefficiencies of legacy cloud models: over-provisioned instances, fragmented data pipelines, and a lack of unified context. 

To optimize costs, leadership must move beyond reactive cost-cutting and toward **Architectural FinOps**.

### **The hidden cost of "operational glue"**

Most AI infrastructure is currently built as a patchwork. 

You might have a vector database on one provider, model inference on another, and application logic on a third. This "fragmentation tax" shows up in 3 measurable ways:

1.  **Data egress fees**: Moving massive datasets between siloed providers just to give your agents necessary context.
2.  **Idle compute**: Keeping high-powered GPU or CPU instances "warm" for intermittent agentic tasks that only run a few times an hour.
3.  **Operational glue**: The senior engineering hours required to keep these disconnected primitives in sync, manually updating documentation and API schemas across tools.

In high-growth teams, this operational glue is a silent killer of margins. 

When an AI agent has to pull data from a legacy database, send it to a vector store on a different cloud, and then run inference on a third, you aren't just paying for the compute. 

**You are paying for the** **latency that slows down agentic loops** **and the engineering time required to secure those cross-cloud tunnels.**

### **Optimization lever 1: Reducing the "AI rework tax" with MCP**

In AI engineering, the most expensive work is the work you have to do twice. 

When an AI coding assistant suggests code or infrastructure changes based on outdated information, the resulting hallucination leads to failed deployments and hours of human remediation.

Upsun resolves this by treating platform state as live data through the **Model Context Protocol (MCP)**. By using the Upsun MCP server, your AI tools (like Cursor, Claude, or Windsurf) ground their suggestions in your actual, live environment configuration.

Instead of an agent guessing which version of Python or which database schema you are running, it queries the platform directly. 

This shift from "probabilistic guesses" to "deterministic actions" significantly reduces the rework tax: the time spent by humans fixing low-quality AI outputs that didn't have the right context to begin with.

### **Optimization lever 2: Surgical resource-based scaling**

Traditional cloud providers force you to choose from a menu of "T-shirt-sized" instances.

If your Retrieval-Augmented Generation (RAG) pipeline needs 10GB of RAM but only minimal processing power, you are often forced to pay for a high-vCPU instance just to get the memory.

Upsun’s **resource transparency** allows for surgical scaling. You define exactly the resources your service needs in your .upsun/config.yaml and it provisions it accordingly.

-   **Denser workloads**: Upsun’s high-density container orchestration is designed to be **12x more CPU-efficient** than standard cloud instances, meaning scaling teams can run denser workloads on a significantly smaller footprint.
-   **The "Greener" Margin**: For high-growth teams, ESG goals are increasingly tied to procurement and funding. By selecting low-carbon regions, teams meet these mandates and receive a **3% Greener Region Discount**, directly improving the unit economics of every inference.

  
**For more info:** _**See how granular provision-based billing works**__**.**_

### **Optimization lever 3: Automated environments and regression testing**

Scaling teams struggle with environment parity. If code from an AI agent works on a developer's laptop but fails in staging because the vector database version is slightly different, that is a sunk cost you have to pay for on multiple levels.

Upsun’s **production-perfect clones** allow you to give an AI agent an isolated "Production Sandbox" in 60 seconds to test a new RAG retrieval strategy without touching live customer data. 

This isn't just about code; it's about the **cloned state**.

By automating the creation of these environments, you enable **Automated Regression Testing for AI**. 

Instead of human QA spending hours "vibe checking" AI responses, you can evaluate agentic outputs in a real, functional environment. When the experiment is over, the branch is deleted, and the associated resources are instantly reclaimed, eliminating "staging waste."

### **The verdict: Scaling on outcomes, not primitives**

Optimizing AI costs isn't about finding a cheaper GPU; it is about reducing the cost per outcome.

In 2026, a CTO’s job isn't to build a better Kubernetes cluster; it’s to build a better product delivery machine that can keep up with your innovation. 

If your senior architects are still configuring IAM policies for S3 buckets, they aren't working on your competitive advantage.

By unifying your code, data, and infrastructure context, you contain the complexity of the cloud. 

This move from managing plumbing to delivering logic is what allows engineering leaders to hit their innovation targets without the unpredictable "cloud bill shock" that traditionally follows AI pilot projects.

**Next steps:**

-   **Give your AI assistant context**   
    See how to connect Upsun docs to your IDE via MCP
-   **Scale without surprise bills**   
    View predictable pricing

### [Bulletproof your Symfony app for Black Friday | Upsun](https://upsun.com/blog/bulletproofing-your-symfony-application-for-black-friday/)

# Bulletproofing your Symfony application for Black Friday

_This blog is based on Thomás Di Luccio's talk "Bulletproofing for Black Friday" from the Symfony 2024 conference. Thomás is a Developer Relations Engineer at Upsun. We utilized AI tools for transcription and to enhance the structure and clarity of the content._

Picture this: You're a small ticketing startup that just landed a major deal with a large venue. After months of building features and preparing for launch, the big day arrives—season ticket sales go live. This venue could generate up to half of its yearly revenue in a single day. The stakes couldn't be higher.

At 10 AM, ticket sales begin. Online customers, on-site visitors, and mobile app users all access the same API simultaneously. For 45 minutes, everything seems fine. Then, gradually, the application starts slowing down. An hour in, everything crashes completely.

This was precisely what happened to Thomás and his team years ago. It was a crushing failure that affected not only that major client but also all their customers. The mood in the office was devastating, and nobody knew what had gone wrong or how to rectify the situation.

However, this failure marked the beginning of a journey into application performance and scaling, one that you won't have to repeat.

## The core problem: building features vs. building for scale

The fundamental issue wasn't with Symfony or any particular technology. The problem was simple: the team was so focused on shipping features that they completely overlooked preparing for high-traffic scenarios.

"We were so focused on building the product, shipping features, assembling features, that we were missing something essential, getting ready for the big day," Thomás explains.

This is a common trap in e-commerce and any business with peak traffic periods. Teams build excellent functionality, but often overlook the fact that success means more users, and more users can overwhelm unprepared systems.

## Four essential strategies for bulletproof applications

### **1\. Stress test your application relentlessly**

The first lesson is obvious but often overlooked: stress-test your applications before the critical day arrives. But this isn't just about running a few load tests; it's about systematically breaking your application.

**Break your application intentionally.**

Don't just test your application, break it. Be creative. Find new ways to push it to failure. As Thomás puts it, "Don't let this be in the hands of your users because they are mad people and they will break it in ways you won't be in control of."

**Invest in load testing tools.**

Choose tools that work for your team and stick with them. Popular options include:

-   **Locust** (Python-based, highly flexible)
-   **Gatling** (Java-based, enterprise-focused)
-   Various SaaS solutions for those preferring managed services

The key is finding the right balance between time investment and money spent to create a setup that anyone on your team can use reliably.

**Create real user journeys.**

Generic load testing isn't enough. You need to simulate actual user behavior:

-   Study your analytics to understand real user patterns.
-   Map out complete user journeys from homepage to checkout.
-   Use your APIs to fetch real data (product IDs, categories, search keywords).
-   Create modular test functions that can be combined like Lego blocks.

**Don't forget edge cases.**

In the ticketing company's case, their nemesis was groups of elderly theater enthusiasts who would send one person to buy dozens of tickets for the entire group. These large cart scenarios created massive computational loads that weren't accounted for in normal testing.

Always test extreme scenarios:

-   Large shopping carts with 50+ items.
-   Complex user configurations.
-   Heavy computational processes.

**Make it one-click simple.**

Anyone on your team should be able to run comprehensive load tests with a single command or button click. This removes barriers to regular testing and ensures that tests are actually run.

**Find your breaking points.**

Load testing reveals two critical numbers:

-   The point where your application starts slowing down
-   The point where it crashes completely

Understanding these thresholds is crucial because there's often a direct correlation between concurrent users and revenue. Knowing your breaking point means knowing the maximum revenue your current infrastructure can generate.

### **2\. Always work on production copies**

Never stress test in production. This seems obvious, but the challenge is creating truly accurate copies of your production environment.

**The Upsun approach**

Upsun, where Thomás works, provides Git-based Platform-as-a-Service that makes this seamless. You describe your infrastructure needs in YAML files committed to your repository:

-   Symfony applications with PHP 8.3 or 8.4
-   Frontend applications in Node.js
-   Data science pipelines
-   Go workers
-   Any combination of services your application needs

Every commit creates a new version, and every branch creates a complete copy of the parent environment, regardless of its complexity.

**DIY Solutions**

If Upsun isn't an option, invest in creating similar capabilities:

-   One-command environment cloning.
-   Automated infrastructure provisioning.
-   Identical configurations across environments.

For e-commerce applications, this capability is essential.

### **3\. Integrate observability into everything**

Having load testing and staging environments isn't enough if you can't understand what's happening inside your application during stress tests.

#### **What is observability?**

Observability is "the ability to witness the behavior of an application, detect bottlenecks, and improve performance." Think of it as bionic glasses for your application—a way to see through the black boxes and make educated decisions.

**Key observability features**

Modern observability tools like Blackfire provide several essential capabilities:

-   **Monitoring**: Track both CLI and HTTP traffic across your entire application stack.
-   **Continuous profiling**: Lightweight data collection with minimal overhead (0.05-0.1% performance impact) that works across multiple languages: PHP, Python, Node.js, Go, Ruby, Rust, and Java.
-   **Time frame comparison**: Compare quiet periods with load testing or actual Black Friday traffic to assess performance. This visual comparison shows which parts of your application consume proportionally more resources under load, helping identify bottlenecks.
-   **Deterministic profiling**: Deep, precise profiling for specific requests that shows exactly how your code executes, including loops, function calls, and resource consumption across all dimensions.
-   **Performance testing**: Automated performance tests that can prevent performance regressions from being merged into production.
-   **Infrastructure monitoring**: Track HTTP traffic and resource consumption for all services and containers to ensure proper scaling.
-   **Making educated decisions**
-   The goal is to enhance user experience, quickly identify areas for improvement, and ensure your application scales effectively. Whether you use Blackfire or alternatives, invest in tools that provide similar insights.

### **4\. Scale intelligently and granularly**

The final piece is understanding how to scale effectively. This means answering a complex question: "What part of your application needs what resources to achieve what results?"

**Start with your objectives**

Define your scaling scenarios:

-   Quiet periods (baseline traffic).
-   Peak periods (Black Friday, product launches).
-   Intermediate scenarios.

Run tests for each scenario until you understand the exact requirements.

**Identify precise requirements**

Use your testing and observability tools to determine:

-   Resource requirements per container
-   Whether you need load balancing (the answer isn't always yes)
-   Optimal instance counts for different traffic levels

Make cost-based and performance-based decisions using real data, not assumptions.

**Don't forget workers**

Scale your background workers alongside your web applications. Ensure they have sufficient resources in properly configured containers.

**Fine-grained resource allocation**

Upsun allows granular resource allocation; you can add more memory to one container while reducing CPU in another where it's wasted. You can also scale the number of instances with automatic load balancing.

**Avoid always-scaled solutions**

Many applications run at maximum scale year-round because their hosting providers make it difficult to scale up and down. This wastes money and has an unnecessary carbon footprint. Find solutions that allow dynamic scaling based on actual demand.

## The bulletproof application framework

When you combine these four strategies, you create a bulletproof framework:

1.  **Stress Testing**: Break your application systematically in controlled environments
2.  **Production Cloning**: Test on perfect copies of your production setup
3.  **360° Observability**: Understand what's happening inside your application during stress
4.  **Fine-Grained Scaling**: Scale precisely based on real data and requirements

## The real-world impact

Remember the original failure? The bottleneck turned out to be large shopping carts that the team hadn't anticipated. Groups of theater enthusiasts were purchasing 50-100 tickets in a single order, creating massive computational loads for seat allocation, pricing calculations, and ticket generation.

But the technical issue was just a symptom. The real problem was the team's isolation from actual users. They were building features based on assumptions rather than understanding how venues actually sell tickets.

"We were totally isolated in the engineering department, just shipping features from a backlog. We weren't with the people in the venue seeing how they actually work, how they actually sell things," Thomás reflects.

The goal is transformation: moving from a state of panic during high-traffic events to one of confident relaxation. When you have proper stress testing, production cloning, observability, and scaling in place, you can approach Black Friday knowing you're entirely in control.

Instead of rushing around trying to fix things, you can actually enjoy a drink while monitoring systems that you know will handle whatever traffic comes their way.

## A short Q&A from the room

**Q: How much monitoring is enough?**  
A: Keep continuous profiling on. For request monitoring, a 10% sampling rate is a good starting point for many applications. Extremely high-traffic apps can achieve lower traffic while maintaining statistical soundness. Early wins from using these tools often offset their overhead.

**Q: What caused that original outage?**  
A: Huge carts plus heavy seat allocation and ticketing logic, combined with choices made while focusing on shipping features, not on how real users would act on launch day. Even printers were fed oversized images. Tests were missing. The fix began with observing real workflows and tightening the system.

**Q: How do I avoid false confidence in perf tests?**  
A: Write performance tests alongside unit and integration tests. Start with the most critical user journeys—test causes, not just outcomes. For example, assert “fewer than N SQL queries” instead of only “under 10 ms,” so you do not pass due to warm caches while hiding actual costs.

**Q: What about third-party services during stress tests?**  
A: Point preview environments at sandbox accounts via environment variables. Use production credentials only in production. That way, you can test safely without burning through real quotas.

## The bottom line

Don't wait for your own disaster story. Start stress testing now, invest in proper tooling, and build systems that can handle success. Your future self and your users will thank you when the next Black Friday arrives and everything just works.

The difference between a successful high-traffic event and a catastrophic failure often comes down to preparation. Make that preparation a priority, not an afterthought.

### [Delivering Product Impact: My First 90 Days at Upsun](https://upsun.com/blog/shipping-impact-first-90-days/)

# Delivering a feature during my first 90 days at Upsun

Joining a new company as a Product Manager is always a challenge. You need to deep dive into the new system, understand customer profiles and needs, get a hold of a business strategy. However, the best way to truly learn the ropes is by owning a meaningful deliverable from day one. This is the story of how I shipped a new feature during my first 90 days at Upsun.

I joined Upsun early November as part of the Platform Core team. I've got a background in building PaaS for a different industry and I just love working on highly technical products. Being a natural learn-as-I-do person I was very excited to get my hands dirty and do some meaningful work.

Lucky me, I was available to take over a small feature several weeks after joining the company. The feature was focused on providing a possibility to limit the application of the variable to specific applications. It was already in progress with the API's development done and console design in progress.

From my perspective it was great to take over something that was already in progress and not to do the whole product discovery/delivery from scratch. Why so? When you join a new company as a product manager you need to learn a lot of things. Having a feature in progress to lead gives you a focus, which is especially precious on such a broad and complex product as Upsun.

What was also very helpful and encouraging - the help and support from my manager and my colleagues across different departments. Building a product involves multiple people across various departments: product, design, engineering, marketing, data, and many more. All my questions were answered, every time I got stuck someone was here to help me out. What happened is that I was given time and context to figure everything out, which is extremely precious for a new joiner.

I was not necessarily expecting to deliver the first functionality in my first 90 days, especially considering the Christmas period being part of these 90 days, but I did. It was possible due to a good on-boarding process and a great company culture. Product management is a team sport and I had an amazing team to make this first feature see the day. 

**If you want to learn more about this small feature,** **check out our docs****. Otherwise stay tuned for more posts about Upsun and our ways of working.**

### [PaaS: a better alternative to Kubernetes | Upsun](https://upsun.com/blog/kubernetes-alternative/)

# PaaS: a better alternative to Kubernetes

Today’s organizations face major challenges in effectively deploying and managing their online services, applications, and websites. In recent years, with interest in infrastructure technologies such as Kubernetes and Docker surging, container orchestration solutions have emerged as a core technology to help overcome challenges and move to a more modern approach. While many organizations have adopted some level of containerization within development, adoption for production remains relatively low, with organizations citing a lack of expertise and increasing security challenges as barriers.

Today, many organizations are shifting to cloud hosting platforms for application development and deployment, including container orchestration, as an alternative to Kubernetes. This provides the complete infrastructure needed for production, including security, infrastructure, load balancing, and high availability–all fully supported by the cloud hosting platform, also called Platform-as-a-Service (PaaS).

As cloud hosting platforms vary significantly, we will explain the benefits and technologies of containers, container orchestration, and Platform-as-a-Service. This includes what each technology does and doesn’t provide. We will cover some of the functionality necessary for organizations to leverage containers in production.

## **The benefits of containerization for developers**

Containers are built around core Linux kernel (LXC Containers and cgroups) and OS features that allow complete native isolation of an application’s view of the operating environment, including process trees, networking, user IDs, and mounted file systems. In other words, the Linux kernel itself provides a way of securely virtualizing an application without the need to spin up a virtual machine.

As a result, containers offer developers a solution to those in-application issues. If an application is deployed within a container, its view of the world is always the same. The segregation/sandboxing means another application can’t overwrite the memory being used, and an application runs the same regardless of the underlying hardware and infrastructure used for the cloud. Containers can be useful for individual developers, and they can manage/script on a small scale by numerous mechanisms. Also, proprietary container technologies, such as Docker, have become popular to help associate applications with containers and services.

## **Using Kubernetes to orchestrate containers**

Kubernetes (often referred to as K8s) is one of the most popular frameworks for container orchestration.

Kubernetes can be used to build a platform that then allows containers to be operated, deployed, moved, and scaled to maintain the desired state of the application and end service. The application itself runs on a distributed system of cloud and physical servers, using orchestration to ensure the resources are available and used optimally for the whole system, balancing and adjusting according to the needs of the applications.

Theoretically, this means that with the right triggers and monitoring a web application can respond to changing demands on it. If demand surges, for example, additional copies of a container can be spun up in seconds in geographies nearer to the demand. This, however, relies on building the infrastructure and tools within Kubernetes or leveraging and integrating the right third-party tools and functionality.

## **How to build a platform with Kubernetes**

To leverage container orchestration in production, you first need to build a platform, typically with functionality to ensure the platform provides:

-   High availability
-   Security updates
-   Environment cloning for developers to test their changes
-   Backups
-   Automated generation of staging clusters
-   Web application firewalls
-   Storage allocation and purchasing
-   Content delivery network
-   Monitoring and feedback

**Kubernetes itself is not a platform;** it’s a framework within which you can build one. The types of products and services that are added to Kubernetes can give you an idea of what’s needed:

-   storage/host management (AWS, Ceph, Terraform)
-   container templating/service registration (Docker, Rancher, Helm, JFrog)
-   logging/metrics (Grafana, fluentd)
-   code building and publishing (Jenkins, GitHub)
-   load balancing (Netscaler).

To build a platform around Kubernetes, you will need not only to evaluate, license, and support numerous tools and technologies, but also maintain, license, and support those components and their interactions.

Beyond maintaining and patching an infrastructure around Kubernetes, a production deployment needs significant development, tooling, and processes to integrate technologies that manage containers and their contents. While containers make it easier for developers to build applications faster, much of the software can contain vulnerabilities when developers end up relying on outdated components that haven’t been updated/patched or are unsupported. Later, we will cover how these challenges can be overcome by leveraging declarative architecture features within a cloud hosting platform or Platform-as-a-Service (PaaS).

## **Simplifying Kubernetes complexity with PaaS**

If your teams spend too much time evaluating, discussing, and implementing Kubernetes architecture components (such as Pods, Labels, Replica Sets, and Config Maps) or debating whether and how to combine Rancher with Helm and RabbitMQ, then a Platform-as-a-Service (PaaS) could suit your organization.

A PaaS provider takes on the overhead of building and supporting the development platform and all the components. Developers and architects are then free to focus on developing and improving their websites and applications.

## **Upsun helps scale and secure all your websites**

Upsun supports development stacks that include PHP, Drupal, Strapi, WordPress, Python, Laravel, Node.js, Magento, and many more. We power website portfolios that range from single applications to thousands of websites for organizations across different industries.

**MarketNation**

Upsun helped MarketNation migrate its +Shop distributed marketplace platform from an unreliable system to a fully managed PaaS solution serving hundreds of partner domains with improved performance and 99.99% uptime reliability.

**The University of Missouri**

Working with Upsun, the University of Missouri consolidated hundreds of websites and 13 different content management systems.

Regardless of the technology stack our customers use, we focus on measurable business value through practical features. We enable organizations deploying websites to:

-   Patch all their sites centrally
-   Secure their data with fully managed database services
-   Ensure governance over technology and processes
-   Provide high availability SLAs (up to 99.99%)
-   Rely on 24x7 global support

Focusing on the specific use cases and productivity features that a platform needs to provide, developers can often help an organization expose the security and reliability issues of in-house Kubernetes management.

Guides to demystifying Kubernetes or containers offer insight into the fundamental soundness of those technologies. But designing, documenting, and maintaining a working system is a very different matter. Managed Kubernetes services offer a wide range of individual components, but it’s up to the individual organization to figure out how to achieve high availability backups and how to integrate load-balancing or security gateways.

## **Upsun: The benefits of an integrated PaaS solution**

Key points:

-   Upsun leverages standard native containers and provides orchestration.
-   A vast amount of functionality is provided beyond container orchestration.
-   Key tools and applications are integrated into the platform, with the licensing and patching responsibilities undertaken by the platform.
-   Upsun provides a choice of infrastructure, sourced and priced at bulk (e.g., AWS, Azure).  
     

### **Next steps**

Does a bespoke Kubernetes solution meet your requirements? Upsun has experts available who can help walk you through your unique situation and provide a cost analysis of switching to Upsun. Talk with an Expert

### [How reinvention shapes careers: From ballet to employee experience](https://upsun.com/blog/employee-experience-journey/)

# Beyond the horizon: How Mia Garzón turned adversity into purpose

Welcome to _Beyond the horizon_, a monthly series celebrating the people who shape Upsun’s culture, innovation, and heart. As we open this new chapter, it feels fitting to begin with someone whose work touches every corner of our company.

Mia, our driving force behind employee experience, brings a unique blend of creativity, discipline, and deeply human insight to the work of shaping our culture.

Her story is one of reinvention and resilience, rooted in years of classical ballet training, strengthened through personal transformation, and guided by a lifelong commitment to connection and movement. Today, those experiences fuel her mission at Upsun: to create a workplace where people feel valued, supported, and inspired to do their best work.

Mia approaches culture-building with an artist’s eye and a strategist’s mind, crafting experiences that make Upsun not just a place to work, but a place to thrive. Whether she’s designing moments of joy, building community across continents, or simply reminding us of the power of being seen, her work helps define what it _feels_ like to belong here.

Her journey to Upsun is a powerful reminder that our horizons are shaped not just by our skills, but by our courage, determination, and the belief that something meaningful is ahead. As we share her story, we also celebrate the culture she helps nurture: warm, intentional, and boldly human.

We’re honored to highlight Mia this month, whose impact is woven into the everyday experiences that make Upsun a truly special place to grow.

### **Tell us a bit about yourself. What do you do and most importantly, who are you outside of work?**

> At Upsun, I focus on navigating the evolving world of remote and distributed work by designing employee experiences, events, and initiatives that strengthen engagement, well-being, retention, and our employer brand. I'm passionate about creating innovative, sustainable, and people-centric solutions that make work feel meaningful and connected.
> 
> Outside of work, my background is quite different; I trained as a classical ballet dancer. From age 10 to 17, I spent every weekday in regular school followed by four hours of dance lessons at the Dance Conservatory (no holidays ever!). That discipline and love for movement have stayed with me, even as my knee injury took me into other worlds. My passions still revolve around movement and creativity; music, dance, theatre, and literature are my happy places.
> 
> At home, I share life with my wonderful daughter (my greatest source of joy and motivation) and my dog, my loyal best friend. I'm determined, efficient, and energetic, but I also fully believe in the power of doing nothing every now and then! 

### **If you could describe your journey in one sentence, what would it be?**

> How a 50-year-old divorcee with a young child got her dream job after two years of job hunting.

### **What's a challenge you've faced and how have you grown from it?** 

> Being unemployed after a collective dismissal was really tough. The market was difficult, with very few openings in my field. In many selection processes, I reached the final interview stage, people were impressed by my skills, but being a mom with no support often raised biased doubts about my performance and commitment. It felt like that was always the "decisive" factor for being turned down.
> 
> I was frustrated because my personal life has never been an obstacle to being a strong, reliable contributor, even while managing large teams. When I joined Upsun, things were different. My professional acumen and experience were valued from the very beginning; what I could bring to the company was all that mattered. No one judged my personal circumstances; in fact, they were seen as a strength, a sign of determination and multitasking ability 😉.
> 
> That made me feel safe, respected, and truly considered. It's a reminder of how important it is that we never let bias or prejudice shape how we recruit or treat people.

### **Is there someone at Upsun who played a key role in your journey or made your experience possible?** 

> Yes: Caroline Leroy. She immediately recognized that Employee Experience is essential in a company that strives to be more than "just a company." She trusted my skills and experience from the very first interview and was eager to embark on this journey together. I've told her this many times, but it's worth saying again: thank you, Caroline!

### **As we say at Upsun, 'Your greatest work is just on the horizon.' What's the next horizon you're excited to reach in your journey?** 

> ​​I've always loved making others feel happy, and that's ultimately what my job is about. My goal is to make everyone at Upsun so happy and fulfilled that they can't imagine working anywhere else and can't stop talking about how great their company is.
> 
> We've set sail on a new chapter with so many exciting projects, ideas, and people dedicated to improving employee happiness and engagement. My next horizon is simple but powerful: seeing more smiles and watching the company grow!

Thanks for joining us on this month’s journey. Beyond the horizon is all about the stories that shape who we are. We hope you’ll return next month as we continue celebrating the people who inspire our culture and move Upsun forward. 💙

### [When cron isn’t enough, use worker instances | Upsun](https://upsun.com/blog/cron-job-and-worker/)

# When your job is too tough for cron

Cron jobs are good. Cron jobs are nice. But sometimes, a Cron job just isn’t enough. Running a task now and again may be good for some jobs, but what if you have a really big task. A task that needs muscle from a long-running process.

For the big tasks a Cron job just isn’t going to cut it.

What you need is a dedicated worker instance; Worker application instances that Upsun now provides, of course.

## What's wrong with Cron?

Cron tasks are fine for what they're good for: Relatively cheap single tasks that run at a specific time or times. Upsun has supported custom cron jobs since the stone age. (That's about 3 years in Internet time.) They have a number of limitations, though:

-   Cron tasks on Upsun run on the same container as your application instance, which means they're competing for resources.
-   A Cron task succeeds or fails entirely, making it a poor fit for a task that can be worked on incrementally.
-   We limit cron jobs to running no more often than every 5 minutes, which means a task that needs to be done "now, but not in the web request" may happen as long as 5 minutes later.
-   A running cron task blocks a new code deploy
-   If a cron task is still running when it's next triggered they may step on each other's toes and confuse the application state unless you're very very careful about how it's written.

As a general rule of thumb Cron jobs should be used when something needs to happen at a specific time. For example if you have to transfer a CSV export, every day, after midnight.

## What’s a worker?

Workers are more general and flexible than Cron jobs. They generally work iteratively on fine-grained tasks, like a queue, and because they're a persistent process can work on task immediately once it's enqueued.

On Upsun a worker is a parallel instance of your application that doesn’t respond to web requests. Instead, it runs a different, persistent background process. It’s the exact same code, just running a process other than listening to incoming web requests.

This makes it incredibly easy to first implement your application in a traditional, synchronous manner, and with trivial changes make the heavy-lifting lazy and asynchronous. This is useful for bulk processing; for handling large queues; for long-running tasks; or anything else that needs to be done “as quickly as possible but don’t block the web request for it.".

(If what you need is a totally separate application, possibly written in a different language, check-out our multi-application support.)

It's also possible to mix-and-match. For example, a weekly mass-mailing could be triggered by a Cron task that runs once a week and enqueues a long list of emails to contact. A worker would then immediately begin churning through that queue and sending out emails one by one. (Sending email is far more time consuming than just enqueuing the tasks to be done.) That's far more robust, as well as potentially faster; you can even create multiple identical workers to work through the queue even faster.

Using Upsun workers can make your web application faster and more responsive while simultaneously reducing the latency of your background jobs and making the whole system more robust and easier to manage.

## Great, so how does it work?

Setting up a worker is quite simple. For the most basic case, just add something like the following to your `./.upsun/config.yaml` file:

```shell-session
applications:
  myapp:
  <snip>
    workers:
      queue:
        commands:
          start: |
            php worker.php
```

That will cause your application to be deployed twice, in 2 separate containers: One to handle web requests (exactly as it does now), and a second container named “`queue`" with the exact same code that will run `worker.php` instead of a web server. It doesn’t have to be a PHP script, of course. It can be any command your application container can run.

For example, a Drupal site can use the Drush Waiting Queue module to run its queue as a real queue, rather than piggy-backing on cron. A Ruby on Rails application can use sidekiq with a persistent Valkey instance to churn through a long queue of background tasks. Symfony or Laravel developers can do the same with the PHP port of Resqeue, while Python people can opt for Celery.

Workers can also be backed by a dedicated queue server that offers more fine-grained functionality such as the RabbitMQ message-queue. It's your app, so pick the approach that works best for you.

Workers are of course much more flexible than just the few lines shown above, but you can see the documentation for the full low-down on how you can customize a worker instance to your needs, and even spin up multiple workers for different tasks.

For the tough jobs, bring a real worker process to the task.

### [Cut PCI DSS audit burden with inherited compliance | Upsun](https://upsun.com/blog/substantially-reduce-your-pci-dss-control-burden-through-inherited-infrastructure/)

# Substantially reduce your PCI DSS control burden through inherited infrastructure

For most engineering leaders, a PCI DSS audit is a "feature freeze" in disguise. 

It is a period where your most expensive talent stops shipping product to spend weeks gathering screenshots, verifying firewall rules, and proving that staging environments match production.

This manual evidence gathering is a symptom of a "build-it-yourself" infrastructure trap. When you build on top of raw infrastructure, you are responsible for everything from operating system hardening to network isolation.

At Upsun, we advocate for a different model: **Inherited Compliance.** 

By moving to a secure-by-default cloud application platform, you offload the vast majority of physical and network control requirements, leaving your team to focus only on the security of their own code.

## Automated patch deployment and traceability

Upsun reduces the overhead of manual infrastructure maintenance through **automated patch deployment with documented validation and change traceability**. 

We deploy critical security updates across your infrastructure, ensuring you maintain a strong security posture without the manual operational burden typically required to stay compliant.

## The shared responsibility model for PCI DSS

Compliance is never "plug and play," but it can be partitioned. To move fast, you must understand the line between your responsibility and ours.

-   **What Upsun manages:**   
    We secure the "Cloud of the Platform." This includes strict project isolation and hardware lifecycle management. Every deployment and configuration change is automatically logged, giving you a complete audit trail built into every environment.
-   **What you manage:**   
    You secure the "Security in the Platform." This includes your application code, user access levels (RBAC), and how you handle sensitive cardholder data (CHD) within your logic. While our infrastructure is PCI-hardened, we strongly encourage using third-party processors for cardholder activity to further shrink your audit surface.

By deploying on PCI-certified Dedicated Clusters, you start your audit with the vast majority of infrastructure-level controls already verified and documented by the platform.  
  
_Note that while Upsun provides a globally standardized experience, PCI certification currently excludes the FR-1 and FR-3 regions. Always verify your region's compliance status before initializing a PCI-scoped workload._

## Eliminating compliance drift with .upsun/config.yaml

The primary reason companies fail audits is "drift." A developer opens a port for a quick test, or a staging server is configured differently than production.

Upsun solves this by treating your infrastructure as version-controlled code. 

Your entire environment stack, including your **PostgreSQL** or **Redis** instances, is defined in your `.upsun/config.yaml` file.

-   **Integrated Edge Security:**   
    You can define your perimeter directly in code, managing the Upsun WAF or Fastly WAF settings to protect against OWASP Top 10 threats.
-   **Identical environments:**   
    When you create a preview environment, it is a perfect byte-for-byte clone of your production infrastructure. You can verify your security controls in a sandbox that behaves exactly like the live site.
-   **Auditable history:**   
    Your auditors do not need to hunt through a web console. They can review the Git history of your `.upsun/config.yaml` to see exactly when and why a routing rule was changed.

## Multi-cloud portability without the security tax

Standardizing on Upsun doesn't just simplify compliance; it protects your optionality. 

One of the biggest risks for a CTO is "compliance lock-in," where moving from one cloud provider to another requires a total rewrite of your security policies.

Upsun provides a consistent management layer. 

Whether you initialize your project on AWS, GCP, or Azure, your deployment workflow and security configuration remain identical. You get the power of a multi-cloud strategy with the simplicity of a single, compliant interface.

### Next step: define your compliance boundary

Don't wait for your QSA to find a gap. Transitioning to a managed platform is a strategic way to streamline your compliance workflows and accelerate your release cycles.

1.  **Audit your scope:**   
    Visit the Upsun Trust Center to access our PCI DSS Level 1 Attestation of Compliance (AoC) and map our controls to your internal audit requirements.
2.  **Initialize your config:**   
    Use `upsun init` to see how easily your current stack can be codified into a secure configuration file.
3.  **Consult an Architect:**   
    If you are migrating a legacy stack to a PCI-certified cluster, contact our solutions engineering team for a technical mapping session to review your architecture.

### [AI-ready sovereignty playbook for gen-AI in the EU | Upsun](https://upsun.com/blog/eu-ai-sovereignty-playbook/)

# AI-ready sovereignty playbook 2026: how to run gen-AI workloads (ethically) in the EU

Sovereignty is a concept that can have shown nuances in the way it is currently used by states and industry to describe some services.

The term “strategic autonomy” has also been used, as to describe the need for governments to ensure that they have a hand on the full value chain (or at least know the gaps and accept the risks) and can apply their rules while it seats in its jurisdiction (autonomy derives from the greek _autos_ (self) _nomos_ (rule).

Companies could apply the same principles at their level, talking about “organizational autonomy” or more commonly, ensuring service continuity in case of a supplier default (i.e. resilience).

That said, developers have a great role to play as some technological choices can be “future proof” regarding upcoming regulations that might come. Part of the answer is leveraging open source to build your solution and using suppliers supporting portability and interoperability to minimize switching efforts. 

This applies for any kind of workload, AI included. As this field progresses very fast, there is a redoubled need to be vigilant on the services used to avoid vendor lock-in when building tech services on top of it. 

## AI sovereignty: how pieces are moving

> “A primary tenet of “sovereign AI” is a nation-state’s desire to control its development, modeling and use of AI systems and techniques, with less dependence on other countries’ innovation and talent and less reliance on global vendors.” – Gartner

In some cases, the ambition could be shared by several member states within the same economical space, such as what is currently happening in the European Union, with a renewed ambition described on November 18th by German and French officials during the European digital sovereignty summit in Berlin.

Governments are increasingly looking into it, as market is shifting towards intensive use of AI in a very near future: Gartner predicts that “by 2027, 50% of business decisions will have been augmented or automated by AI agents for decision intelligence” but such adoption would be done in a highly regulated manner as “by 2027, 35% of countries will be locked into region-specific AI platforms”.

Europe has been on the forefront of regulations regarding data protection, and is augmenting it as AI usage brings more intensity through training and leveraging user data. 

Main aspects to consider while implementing AI in products in Europe:

-   **Transparency:** documenting which data, model and how decisions are being made;
-   **Jurisdiction**: ensuring residency and control over data without it flowing outside EU boundaries.
-   **Risk management**: depending on target usage, the AI can be considered as high risk and would need extra measures (fines up to €20 million or 4% of global revenue).

Those pieces are still moving, as the EU Commission released recently the draft Digital Omnibus, which seeks to simplify the interaction between the different legislations that had been drafted in the last years. 

Even if some AI dispositions are being postponed, the spirit of the law will remain and software architecture decisions will still need to be made accordingly to avoid future irregularities.

## Building one step at a time in a moving environment

Working with multiple models to benchmark performance has become the norm, as it seats at a higher level of abstraction. 

However, working with multiple cloud service providers in different regions to ensure resilience is something that is still time consuming.

→ Allowing businesses to choose where to run workloads, with different underlying cloud providers, **creates new international development opportunities** without compromising on security – from a jurisdictional standpoint – or compliance – as some requirements can be tied to geographies. 

Using AI to augment the capabilities of in-house developers to create new applications exposes IT departments who need, more than ever, to handle existing applications that can also be exposed as legacy and can also face deprecation when using older technologies. Leveraging a cloud application platform with integrated observability tools can also support strategies such as lift and shift then optimize, or directly go into an application modernization process seeking to switch only the required components to run it as state of the art.

## Wrapping up – leveraging a modern platforms like Upsun let you:

-   Create region-specific environments with one configuration file (.upsun/config.yaml) using approved local providers like OVHcloud for the EU.
-   Test sovereignty compliance in isolated preview environments.
-   Generate compliance documentation automatically based on available audit trails and activity logs.
-   Switch between regions without rebuilding depending on the end client's needs.
-   Accelerate application modernization, as there is no sovereignty without control on an up to date application portfolio.

### [Stop losing sprints to cloud setup toil | Upsun](https://upsun.com/blog/why-cloud-primitives-quietly-drain-developer-time/)

# Why cloud primitives quietly drain developer time

Cloud platforms are built to make shipping software easier. Yet, before the first feature is written, many teams lose days, or entire sprints, assembling cloud primitives: CI pipelines, permissions, networking rules, runtime versions, environment wiring, the list goes on. This work is usually framed as “setup,” something to get out of the way before real development begins.

The problem is that it never actually goes away. What starts as a one-time effort quietly becomes a recurring tax on delivery speed, focus, and confidence.

## **The sprint before the sprint**

Before a single line of product code gets written, most teams burn an entire sprint setting up infrastructure. This "Sprint 0", sometimes explicit, sometimes informal, consumes roughly ten days of full-team time on average: Jenkins files, CI/CD pipelines, networking rules, environment provisioning, before any product work can start.

This time rarely shows up in delivery metrics. It's treated as necessary overhead, not something to question or optimize.

What makes it especially costly is that the effort isn't additive. It doesn't make future work meaningfully easier. Instead, it establishes a baseline of configuration that must now be understood, maintained, and adjusted as the application evolves.

From that point on, every sprint carries hidden infrastructure work with it:

-   **Fine-tuning configuration files** eats hours each sprint
-   **Requesting new environments** means multiple tickets and 1-2 weeks of waiting for them to be spun up
-   **Upgrading runtime versions** can stretch into months of planning and work
-   **Context switching** between code and infrastructure kills productivity

None of these ships features.

## **Infrastructure work is never “done”**

Cloud primitives create a specific kind of toil: work that feels temporary, but becomes permanent.

Build pipelines need tuning. Environment variables drift. A new dependency requires a runtime change. A staging environment behaves differently from production. A hotfix works in one place but not another.

None of these tasks is particularly complex in isolation. But they reappear frequently, often unexpectedly, and usually at the worst possible time: during a release, a demo, or an incident.

This is why infrastructure tasks disproportionately slow feature delivery. The cost isn’t just the time spent doing the work. It’s the interruption. Each task forces developers to context switch, reconstruct mental models, and re-establish confidence before they can return to product logic.

Over time, teams end up maintaining a parallel system of infrastructure knowledge that lives partly in configuration files and partly in people’s heads. That knowledge becomes fragile as teams grow, change, or rotate responsibilities.

## **The role mismatch problem**

Terraform and Kubernetes are powerful tools built for infrastructure engineers, people whose job is to think about state management, declarative resource graphs, and reconciliation loops all day. Application developers have different priorities and different mental models. Kubernetes is a framework, not a platform. Asking developers to build the platform themselves comes at a high cost

The hardest part is not syntax. It is reasoning about impact. To use these tools safely, developers must understand:

-   Cloud provider behavior.
-   Dependency graphs.
-   Failure recovery.
-   State management.
-   Permission boundaries.

Partial understanding is dangerous. Many outages come from “almost right” changes:

-   A role that works in staging but not production.
-   A scaling rule that looks fine until traffic spikes.
-   A config copied from another service without full context.

## **What application developers actually need**

The question is not whether infrastructure matters. It does. The question is who should be responsible for what:

-   **Developers should specify:** which runtime, which services, which environment variables.
-   **Developers shouldn't specify:** how those requirements get fulfilled at the cloud provider level.
-   **Infrastructure should be:** a dependency of the application, declared like any other dependency.

Application developers should not need to manually think about: how many instances to run or which IAM policy allows a simple service call, etc. These are platform concerns. Modern platforms should handle them automatically and transparently, with guardrails instead of choices. Guardrails reduce errors by removing decisions that do not add product value. 

The ideal workflow is almost boring. Write code. Push to Git. Get a working environment that matches production. Not debugging YAML indentation at 4 PM on a Friday.

## **When infrastructure becomes a constant tax**

The common thread across these issues isn’t tooling choice. It’s how environments are constructed.

When environments are assembled from low-level primitives, every change becomes a bespoke decision. Every new service, branch, or configuration tweak adds another variable developers need to think about, reason about, and remember.

Over time, infrastructure stops being a foundation and becomes a constant tax on delivery. Teams spend more time maintaining the conditions for development than actually developing.

The teams that move faster aren’t necessarily using fewer tools or simpler stacks. They’re working with environments that behave predictably, are created the same way every time, and don’t require developers to reason about infrastructure mechanics just to ship code.

When environments are standardized, much of this work doesn’t disappear through automation alone. It disappears because it stops being a decision developers need to make in the first place.

And that’s where real developer time is quietly won back.

## **How Upsun eliminates the infrastructure burden**

Upsun is built around a simple idea: infrastructure should follow your code, not the other way around. Instead of managing Terraform modules, Kubernetes manifests, and cloud provider consoles, you define everything in a single configuration file that lives in your Git repository.

### **Git-driven environments that remove drift and bottlenecks**

Upsun ties infrastructure directly to Git. Every branch becomes a complete, isolated environment: database, services, and configuration are created automatically when you push and removed when you merge or delete.

This simple model eliminates problems that plague traditional setups:

-   **No staging bottlenecks.** Your branch, your environment. No waiting for someone else to finish testing.
-   **No environment gaps.** Every environment mirrors production because it's built from the same Git-tracked configuration.
-   **No config drift.** There's no long-lived state to manage or forget about. Environments are ephemeral by design.

**Instant production clones with real data**

When you branch an environment, Upsun creates a byte-level clone of everything: databases, files, services, storage, and configuration in minutes. **Your preview environment isn't an approximation. It's production with a different URL.**

This changes how teams work:

-   Test against real data, not mocked services or seed databases.
-   Reproduce data-dependent bugs instantly.
-   Validate migrations against production-scale data before merging.
-   Automatically sanitize sensitive data for safe testing.

**Faster delivery loops with CLI and API workflows**

One of the biggest slowdowns in cloud workflows is waiting. Waiting for pipelines, environments, approvals, or simply to see results. CLI and API-driven workflows reduce this friction. Actions that should take seconds often take hours because they depend on manual steps or UI flows.

With Upsun, developers can:

-   Spin up environments per branch from the terminal
-   Deploy from existing CI systems using API tokens
-   Automate environment cleanup and resource management
-   Test production-like setups early in development

Fast feedback changes behavior. Developers ship smaller changes, test more often, and take fewer risks because recovery is simple.

**Managed services without the management**

In traditional cloud setups, adding a database means configuring IAM roles, setting up security groups, creating VPC endpoints, and managing connection credentials. Every service multiplies the complexity.

Upsun makes  services declarative. Add PostgreSQL, MariaDB, Redis, Elasticsearch, MongoDB, RabbitMQ, Kafka, or any supported service to your configuration file, and Upsun provisions it automatically. No IAM policies. No networking rules. No connection strings to copy and paste: credentials are injected as environment variables at runtime.

**Flexible scaling without the guesswork**

Traffic doesn't arrive on schedule. Manual scaling requires predicting patterns and adjusting resources ahead of time, often leading to over-provisioning during quiet periods or scrambling during spikes.

Upsun scaling handles this automatically:

-   **Horizontal autoscaling** adds or removes app instances based on CPU and memory thresholds
-   **Vertical scaling** lets you adjust CPU, RAM, and disk per environment
-   **Per-environment resources** mean production can scale differently from development

Define your thresholds, and Upsun handles the rest.

**Configuration stability**

Terraform and Kubernetes configs require constant upkeep. Version upgrades break syntax. Deprecations force rewrites. Teams spend days updating infrastructure code that already works. Upsun takes a different approach: configuration stability is a design principle, not an afterthought.

Configuration files written years ago still deploy today. Platform upgrades don't introduce breaking changes. The YAML you write now will work the same way next year and the year after.

**Migrating without rewriting everything**

Migration fear is normal. Teams picture months of refactoring, rewritten pipelines, and broken deployments. The reality is simpler than it looks.

With Upsun, your application code stays the same. Your language, framework, and dependencies don't change. Your CI tools keep working. What changes are where infrastructure is defined, a single configuration file replacing scattered Terraform modules, and cloud console settings.

### **What to do next**

If cloud primitives are already part of your daily workflow, the next step isn’t learning more tools. It’s noticing where time quietly leaks out of delivery: waiting on environments, re-tuning pipelines, second-guessing configuration, or avoiding changes that feel risky.

Teams that reduce this friction don’t eliminate infrastructure. They standardize how environments behave, so developers can focus on shipping code instead of managing conditions.

If you’re exploring how standardized, predictable environments fit into your workflow, start by looking at how your environments are created, reviewed, and reused today and where they force developers to make decisions they shouldn’t have to make anymore.

### [AWS S3 snapshot repo for Elasticsearch | Upsun](https://upsun.com/blog/elasticsearch-aws-s3-snapshot/)

# Using AWS S3 snapshot repository for Elasticsearch

Contextual Code specializes in enterprise-level projects for state government agencies. We routinely tackle difficult web content management implementations, migrations, integrations, customizations, and operations. We know what it takes to get a project off the ground and onto the web.

Upsun is our primary hosting platform; it’s incredibly flexible, and it provides a vast list of services that can be set up with minimal configuration.

There are several possible scenarios, such as creating additional backups or syncing data to local development environments, when you may need to extract data from these services. In many cases, it’s simple to extract this data when you’re using Upsun. For example, you can get MariaDB/MySQL via the Upsun CLI tool command.

But in some cases, it’s more complex to extract the data you need; more advanced tools are necessary. We covered one such case in our Backup Solr on Upsun blog post. Today we’ll cover another—how to use AWS Elasticsearch S3 snapshot repository for Elasticsearch on Upsun.

## Getting started

First, let's make sure we have an Elasticsearch service in the `.upsun/config.yaml` configuration file, under the `services` key:

```shell-session
services:
  elasticsearch:
    type: elasticsearch:7.2
```

Then let’s inject the service into the application via the `elasticsearch` relationship in `.upsun/config.yaml`:

```shell-session
relationships:
  elasticsearch: 
```

Also, in the  AWS Management Console, we need to:

-   Create a new AWS S3 bucket
-   Use AWS IAM to create a new user with read and write permissions for the newly created bucket

## Registering the Elasticsearch S3 snapshot repository

The Elasticsearch S3 plugin is extremely easy to enable on Upsun. We just need to add `repository-s3` in `configuration.plugins` for the `elasticsearch` service in `.upsun/services.yaml`:

```shell-session
elasticsearch:
  type: elasticsearch:7.2
  configuration:
    plugins:
      - repository-s3
```

After we deploy this change, we need to SSH to the application container and register a new snapshot repository by running the following command:

```shell-session
# SSH to the Upsun.com app container
upsun ssh

# Replace the value for these variables
AWS_BUCKET_NAME="<YOUR_AWS_BUCKET_NAME>"
AWS_ACCESS_KEY_ID="<YOUR_AWS_ACCESS_KEY_ID>"
AWS_SECRET_ACCESS_KEY="<YOUR_AWS_SECRET_ACCESS_KEY>"

# Extract Elasticsearch host and port from relationships
ES_HOST=$(echo "$PLATFORM_RELATIONSHIPS" | base64 --decode | jq -r '.elasticsearch[0].host')
ES_PORT=$(echo "$PLATFORM_RELATIONSHIPS" | base64 --decode | jq -r '.elasticsearch[0].port')

# Register the snapshot repository
curl -X PUT "http://${ES_HOST}:${ES_PORT}/_snapshot/aws-s3?pretty" -H 'Content-Type: application/json' -d'{
 "type": "s3",
 "settings": {
   "bucket": "'"${AWS_BUCKET_NAME}"'",
   "client": "default",
   "access_key": "'"${AWS_ACCESS_KEY_ID}"'",
   "secret_key": "'"${AWS_SECRET_ACCESS_KEY}"'"
 }
}'
```

Once that is done, all new Elasticsearch snapshots will be stored on the AWS S3 bucket.

## Creating the new Elasticsearch snapshots

We’ll use a simple bash script that will need to be executed in the app container `--make-elasticsearch-snapshot.sh` in the root for your project:

```shell-session
# Extract snapshot parameters
SNAPSHOT_ID=$(date +"%Y%m%d-%H%M%S")
SNAPSHOT_NAME=$(echo "${PLATFORM_PROJECT}-${PLATFORM_BRANCH}-${SNAPSHOT_ID}")
SNAPSHOT_DATE=$(date +"%Y-%m-%d %H:%M:%S")

# Extract Elasticsearch host and port from relationships
ES_HOST=$(echo "$PLATFORM_RELATIONSHIPS" | base64 --decode | jq -r '.elasticsearch[0].host')
ES_PORT=$(echo "$PLATFORM_RELATIONSHIPS" | base64 --decode | jq -r '.elasticsearch[0].port')

# Create a new snapshot
curl -X PUT "http://${ES_HOST}:${ES_PORT}/_snapshot/aws-s3/${SNAPSHOT_NAME}?wait_for_completion=true&pretty" -H 'Content-Type: application/json' -d'{
 "ignore_unavailable": true,
 "include_global_state": false,
 "metadata": {
   "taken_by": "Upsun.com cron",
   "taken_on": "'"${SNAPSHOT_DATE}"'",
   "taken_because": "Daily backup"
 }
}
```

Add this script as `elasticsearch_snapshot` to the cron jobs in your application in  `.upsun/config.yaml`:

```shell-session
crons:
  ....
  elasticsearch_snapshot:
    spec: '15 23 * * *'
      commands:
        start: bash make-elasticsearch-snapshot.sh 
```

  
And deploy it:

```shell-session
git add .upsun/config.yaml make-elasticsearch-snapshot.sh
git commit -m "Added Elasticsearch snapshot cron job"
git push
```

After this is deployed, we can run the script in the app container:

```shell-session
# SSH to the Upsun.com app container
upsun ssh

# Run the newly deployed script
bash make-elasticsearch-snapshot.sh
```

The new snapshot will be created and stored in our AWS S3 bucket.

## Using Elasticsearch snapshots

We can get a list of available snapshots by running the following commands:

```shell-session
# SSH to the Upsun.com app container
upsun ssh

# Extract Elasticsearch host and port from relationships
ES_HOST=$(echo "$PLATFORM_RELATIONSHIPS" | base64 --decode | jq -r '.elasticsearch[0].host')
ES_PORT=$(echo "$PLATFORM_RELATIONSHIPS" | base64 --decode | jq -r '.elasticsearch[0].port')

# Get the list of available snapshots
curl -X GET "http://${ES_HOST}:${ES_PORT}/_cat/snapshots/aws-s3?v"
```

Our next steps would be:

-   Register the same s3 snapshot repository for our local Elasticsearch
-   Choose the snapshot we want to restore on our local installation
-   Restore the snapshot on our local Elasticsearch:

```shell-session
curl -X POST "http://%LOCAL_ELASTICSEARCH%/_snapshot/aws-s3/%SNAPSHOT_NAME%/_restore"
```

Once these steps are done, we export the data from Upsun Elasticsearch to our local installation. And we can repeat these steps whenever we need.

## Now it’s your turn

I hope you found this post interesting and useful. Hopefully, it illustrates how flexible and extensible the Upsun framework is. Feedback and comments are appreciated. Happy snapshotting!

(Reprinted with permission.)

### [The best Node.js dev teams in France | Upsun](https://upsun.com/blog/the-best-node-js-dev-teams-in-france/)

# The best Node.js dev teams in France: Your 2025 guide

_Looking for a Node.js team in France? Here's your guide on finding the right technical partner._

The right team makes a huge difference in how fast you ship and what it costs to keep things running. The French tech scene has over 35 development partners to pick from - and finding one that really strengthens your tech capabilities takes some strategy.

Understanding what Node.js development means for your project is important. We'll get into what French teams do really well, and walk you through choosing a development partner that fits what you need.

-   Experience with Node.js projects that match your industry
-   Technical skills for building systems that grow with you
-   Knowledge of cloud platforms you rely on
-   Development teams where you need them

## **Why Node.js development in France stands out**

Here are three key ways Node.js teams in France can help your project:

**Enterprise-focused teams in your backyard**: Teams deeply understand complicated enterprise systems, which means faster builds, cleaner code, and direct communication throughout development.

**Systems that handle heavy loads**: Many French dev teams know fintech and e-commerce platforms inside and out. They're building systems that can process millions of transactions every day without breaking a sweat - from payment systems that keep running during Black Friday rushes to inventory systems that track thousands of products as they update.

**Strategic development hubs**: Many Node.js teams work from key tech hubs like Paris and Lyon - making it easy to meet in person and quickly adapt to new needs.

## **Top Node.js agencies and what they do best**

### **NIJI: making convergence a reality**

Across seven major French cities,1,500 talents with soft skills and expertise embedded in the difference of their personal, academic and professional achievements who jointly perform their respective jobs with passion in accordance with state-of-the-art codes and practices, while living in authentic synergy in the big Niji “family”, steadily built over time, in total confidence and trust with its stakeholders.

**Core strengths:**

-   On the strength of our innovation DNA, our multidisciplinary consultants study and gauge your strategic new opportunities
-   Our agency’s designers re-examine your brand’s DNA, build stories and bring your concepts to life on the web and on mobile screens, in particular through distinctive communication campaigns.
-   We assist you with the choice and technological development of your digital services (web-based, mobile, SI and IoT), taking Green IT concerns into account.
-   Our experts speed up the transformation of your IT systems, taking into account the constraints of your legacy systems, to deliver the benefits of cloud migration.
-   Our certified multidisciplinary team implements the solutions of this world-leading software publisher that adapts to your requirements for greater performance and flexibility on a daily basis.

Geographic reach: Development hubs in Rennes, Paris, Lille, Nantes, Lyon, Nice, and Bordeaux, with APAC expansion through Singapore, enabling 24/7 support and development

### **Les Tilleuls: API Platform innovation and open source**

As creators of the API Platform framework, Les-Tilleuls.coop has proven their expertise by processing over 50 million API requests daily while maintaining 99.9% uptime. Their open source contributions demonstrate both innovation and practical implementation experience.

**Technical expertise:**

-   Advanced API development supporting over 2,000 concurrent requests with sub-100ms response times.
-   Full-stack implementations driving applications with 100,000+ monthly active users.
-   Microservices (built with Node.js, PHP, or Go) handling more than 1TB of data daily.
-   Cloud infrastructure supporting auto-scaling from 10 to 1000 containers in minutes
-   DevOps automation cutting deployment times from hours to under 15 minutes.

Notable implementations include delivering a real-time inventory system for General Electric, capable of processing 500,000 SKUs; scaling AB InBev's logistics platform to handle 10,000 transactions per hour; and developing LVMH's distributed product catalog, serving over 200 brands. While Les-Tilleuls.coop is renowned for its expertise in API architecture, modern enterprises often require comprehensive system integration capabilities. This is where the company's extensive experience with complex enterprise solutions truly shines.

### **Vanksen: scalable web platforms**

Vanksen is a full-service digital agency specializing in web development, with a strong focus on Node.js, delivering scalable and enterprise-ready solutions that meet modern technical challenges.

**Node.js at the core of Vanksen’ solutions**

Node.js is central to Vanksen’s approach to modern web development:

-   Scalable backend architectures that support complex workflows and high API demands
-   Real-time applications tailored e-commerce, and other performance-driven industries
-   Headless CMS implementations that ensure flexibility, speed, and content scalability
-   API-first ecosystems for seamless system integrations and optimized performance

**Cloud-native performance and global reach**

As a trusted Upsun partner, Vanksen excels in deploying cloud-native solutions that deliver reliability and scalability.  
Thanks to the Datawords group, Vanksen extends its global presence to serve enterprises in North America and Asia, alongside its offices in France, Luxembourg, Belgium, and Switzerland. This unique combination allows Vanksen to provide local precision while scaling efficiently across international markets.

**A strategic digital partner**

Vanksen offers more than technical development:

-   Holistic strategy: aligning technical solutions with business goals
-   Performance optimization: delivering speed, scalability, and SEO impact
-   User-centric design: creating engaging digital experiences
-   Security and brand protection: ensuring resilience and user trust

With advanced Node.js expertise, comprehensive digital services, and the global reach of Datawords, Vanksen is a trusted partner for enterprises looking for scalable, future-ready solutions worldwide.

### **Aion Solutions: Enterprise-Grade Web Platforms Powered by Node.js Excellence**

Aion Solutions is a specialized web agency leveraging Node.js expertise to craft sophisticated digital platforms that empower enterprise organizations. We excel at solving complex technical challenges through innovative solutions, including:

-   Global multilingual platforms that seamlessly manage extensive product catalogs with tens of thousands of SKUs for international brands.
-   Advanced industry compliance portals serving construction and manufacturing sectors, featuring real-time updates across vast regulatory document libraries.
-   Enterprise integration systems that seamlessly bridge your digital platforms with industry-leading business solutions.

**Node.js: Architecting Tomorrow's Digital Infrastructure**

Our Node.js implementations deliver exceptional performance and scalability, perfectly adapted to sophisticated enterprise environments:

-   Seamless enterprise integration: Creating platforms that synchronize flawlessly with your existing business systems (ERP, CRM, PIM), ensuring robust and automated data orchestration.
-   Resilient microservices: Building flexible, scalable architectures that adapt to your most demanding business requirements.
-   High-performance real-time systems: Engineering responsive applications that maintain reliability under intensive usage.

**Technical Excellence at Scale**

We harness cutting-edge technologies to ensure your platform's longevity and performance:

-   Cloud-native deployments: Unlimited scalability through sophisticated Docker implementations.
-   Performance engineering: Advanced optimization utilizing Nginx, Redis, Varnish, and OpenSearch.
-   API-centric architecture: Creating cohesive digital ecosystems that streamline operations and enhance data flow.

**Your Partner in Digital Transformation**

From conception to deployment, **Aion Solutions** provides comprehensive guidance throughout your project journey, delivering custom platforms that integrate seamlessly with your enterprise infrastructure and support your strategic vision. Partner with **Aion Solutions** to transform complex technical requirements into digital achievements that drive global business growth.

## **Finding the right Node.js partner for your industry**

Picking a Node.js partner really comes down to what your industry needs. Healthcare companies need systems that handle patient data securely. Fintech needs systems that process transactions reliably. E-commerce needs systems that scale up when traffic spikes. France has development teams that specialize in pretty much all of these areas.

### **What each industry needs:**

### **What you'll want in a Node.js partner**

Node.js architecture that actually works

-   Pick microservices or monoliths based on what your system needs - not just what's trending
-   Real production experience scaling Node.js apps Database patterns built for serious enterprise workloads

Deployment that gets results

-   Clean environments - because messy ones just cause headaches
-   Deployment pipeline that runs itself
-   24/7 monitoring to catch problems before they become Problems

**3\. Each team's core strength**

-   **NIJI**: Healthcare security experts
-   **Les Tilleuls**: API Platform innovators
-   **Vanksen**: Scalability experts

When evaluating Node.js partners, there are several thins to consider. Look for companies that demonstrate their enterprise experience with real data and metrics. Pay attention to their team's knowledge sharing practices - poor internal communication often translates into project delays.

## **What Node.js teams should have**

Tests should run throughout development, not just at the end. Look for teams who test at every step of the way.

Keep in mind, your Node.js team needs to know how to build systems that grow. They should understand both microservices and monoliths well enough to pick what works for your needs - not just what's popular. Look for teams who've built Node.js apps at scale and know how to handle heavy database loads.

And let’s not forget, infrastructure plays a huge role in Node.js development. Modern platforms give teams what they need to scale with confidence - automated deployments to built-in monitoring and the ability to scale well. When your team has this foundation in place, they can focus on building cool new features instead of maintaining infrastructure. Plus your systems stay reliable and perform consistently.

## **Key considerations for Node.js development teams**

Let's look at how the right resources shape your project outcomes, and what that means for budgeting and planning. Projects typically range from €50,000 to €500,000+, with your investment shaped by three key factors:

-   **Technical complexity and scope** - because every project has its own DNA
-   **Integration needs** - how your new solution fits with existing systems
-   **Team structure and timeline** - the who and when that drive success

The real question isn't just cost - it's value. French Node.js leaders are delivering game-changing results:

-   Processing 50 million patient records while keeping healthcare data secure
-   Processing over 50,000 transactions every hour for major retailers, while dealing with the whole real-time data thing for more than 100,000 users at once.

From fast apps to custom dev work, let's find what fits your needs. 

**Here's What Each Team Does Best**

-   NIJI handles 50M+ patient records with healthcare-grade security
-   Les Tilleuls runs 50M daily API requests at 99.9% uptime
-   Vanksen supports 100,000+ concurrent users in real-time

**What Makes These Teams Stand Out:**

Each of these Node.js teams are really good at what they do. NIJI is super impressive with their healthcare, handling compliance across six major French cities which is pretty amazing to see. Les Tilleuls, they're the ones who created this best in class API Platform framework - it really shows how innovative they are. And then there's Vanksen, who are absolute beasts when it comes to processing data - we're talking about handling 2TB+ of data every single day, which is pretty insane if you think about it.

**Picking a Node.js development partner that fits**

Here are some key areas to evaluate:

### **What to check**

-   **Technical skills:** Make sure their Node.js experience matches what your project needs
-   **Room to grow:** Look for teams that have handled projects that got bigger and more complex
-   **Security:** Their security practices need to match what your industry requires

### **Next steps**

-   Write down what you need technically and how you'll measure success
-   Ask for detailed examples of work they've done in your field
-   Talk to your top 2-3 choices

Each team brings their own flavor to the table. NIJI knows healthcare security through and through. Les Tilleuls builds APIs that handle serious traffic without breaking a sweat. And Vanksen? They keep everything running smooth even when your user count suddenly spikes through the roof. Take a look at what matters most for your project and reach out to the team that fits best.

Want to turn your ideas into real-world code? The Node.js teams in France are ready to help build systems that can grow with you. Whether you need secure healthcare systems, APIs that power through millions of requests, or apps that stay responsive when traffic spikes - France has the technical talent to make it happen. Take that first step and build something meaningful.

### [What you do vs what you want to do | Upsun](https://upsun.com/blog/build-features-not-infrastructure/)

# What you do vs. what you want to do

If your week keeps evaporating into incidents, flaky staging, and hand-built scripts, you are not alone. Many developers spend far too much time searching for answers and wrestling with tools, rather than building features. In Stack Overflow’s 2024 survey, 61 percent said they spend more than 30 minutes each day just searching for solutions.¹ Deloitte notes that time spent on configuration, tool integration, and debugging directly crowds out feature work.² SRE leaders even set a hard cap on toil because they know operational busywork expands to fill the day.³

This practical guide was created to help you get closer to what you actually want to do:  **ship ideas, improve user experience, and eat dinner on time**.

## **The pattern: DIY by default, complexity by surprise**

It is easy to default to building your own infrastructure and development platform. It feels faster to spin up a cluster, wire a pipeline, and add a logging agent. Then reality shows up:

-   Environments drift and break at the worst time.
-   Masking production data safely becomes a whole project.
-   A “temporary” script turns into a maintenance burden.
-   Reviews stall because “works on my machine” does not prove anything. 

You do not need another dashboard. You need a calmer path to production.

## **A calmer path: Git-driven config and real previews**

Upsun uses a single configuration file in your Git repository to describe your apps, services, build hooks, deploy hooks, and routes, so your pipeline is versioned alongside your code. For this reason, each branch gets a live, production-grade preview environment with cloned services and code to ensure safe and realistic testing.

To learn more, read how to configure your project and explore environment management product guide.

### **Instant, data-complete previews**

Creating a new branch can spin up a complete clone of your infrastructure, including your application, services, caches, data, and storage, so you can test against the same shape of data and services as if it were production. When you need to protect sensitive data, Upsun also supports database sanitization workflows out of the box. See sanitization concepts and a PostgreSQL example.

```shell-session
# .upsun/config.yaml
applications:
  app:
    type: "python:3.11"
    relationships:
      database: db:postgresql
    hooks:
      deploy: |
        if [ "$PLATFORM_ENVIRONMENT_TYPE" != "production" ]; then
          ./scripts/sanitize_db.sh  # mask PII for previews
        fi
services:
  db:
    type: postgresql:15
```

### **Observability and APM built in**

Profiling and metrics are included, allowing you to identify and resolve performance bottlenecks before users complain about slow load times or broken features. Full access to Blackfire for PHP and Python projects is included, along with additional continuous profiling views for other runtimes. Explore Upsun observability and Blackfire details.⁴

## **DIY with managed hosting vs Upsun: a quick comparison**

If you are considering building your own platform with managed hosting against Upsun, here is a fast, developer-first view:

-   **Scalability.** DIY with managed hosting means you’re responsible for sizing servers and tuning autoscaling to meet demands. Upsun manages all your containers and services with fewer surprises while keeping app definitions in code. 
-   **Security and compliance.** DIY means patching, policy, and audit trails are your problem. Upsun centralizes guardrails and audit-ready logs so you can prove “security and compliance” without slowing delivery. And Upsun delivers all the middleware updates, so you don't have to! 
-   **DevOps overhead.** DIY often turns into a platform project where you spend more time maintaining the platform than creating actual products. Upsun lets a small team ship more with Git-driven automation and consistent previews.  All your time is spent on your product and not on your platform. 
-   **Cost predictability.** DIY with managed hosting costs sprawl across infrastructure, services, licenses, vendor invoices, and time. Upsun provides a predictable footprint you can tie to environments and projects. 

If you want to dig deeper, Upsun’s YAML overview is a quick tour of what you can standardize.

## **For Magento and enterprise eCommerce teams**

Running Adobe Commerce or Magento at scale magnifies these issues: realistic testing, safe data, and predictable operations. Adobe’s own managed services guidance outlines shared responsibilities across performance, security, and compliance, such as SOC 2 and PCI.⁵ Upsun’s preview environments help teams working on extensive catalogs and promotion engines validate changes on real data shapes before peak traffic. 

## **What changes when you switch from the status quo to Upsun**

-   **Speed.** Real previews cut review cycles and reduce “works on my machine” pings. 
-   **Quality.** Built-in APM and profiling catch regressions before release. 
-   **Consistency.** One YAML file defines build, deploy, and hooks across services. 

**Cost.** Fewer bespoke scripts and fewer escalations make spending more predictable.

## **A realistic developer workflow on Upsun**

1.  Create a feature branch. A production-perfect preview environment is created with cloned services. 
2.  Run safe data cloning with sanitization hooks. 
3.  Use observability to validate performance. 
4.  Share the preview URL for design, QA, and stakeholder signoff. 
5.  Merge to release. Rollbacks and backups are one click in the console or a CLI command. See environment operations and logs via CLI.

## **The outcome**

You trade firefighting for focus. You define infrastructure once, preview every change on the real shape of production, and keep performance visible. That is how you get back to what you want to do: building.

### **Try it**

-   **Ship features without heroics.**  
    Watch a custom demo
-   **Try production-perfect previews now**  
    Start a free trial

## **Sources**

1.  Stack Overflow Developer Survey 2024. “61% spend more than 30 minutes per day searching for answers.” 
2.  Deloitte Insights. “Time spent on configuration, tool integration, and debugging takes away from building new features.” 
3.  Google SRE Book. “Keep toil below 50 percent of the time.” 
4.  Upsun Docs. “Blackfire for PHP and Python is bundled.” 
5.  Adobe Experience League. “Adobe Managed Services responsibilities include SOC 2 and PCI.” 
6.  Upsun Developer Center. “Preview environments: a developer’s secret weapon.”
7.  Gartner. “By 2026, 80 percent of large engineering orgs will establish platform engineering teams.”

### [How linux namespaces create containers of lies | Upsun](https://upsun.com/blog/the-container-is-a-lie/)

# The container is a lie

_(This article was originally published in_ php\[architect\] _magazine, in two installments.)_

As a general rule, lying to people is a bad idea. People don't like dishonesty. It's insulting to lie to a person and tends to destroy relationships, both personal and professional.

But computer software isn't people (thank goodness). Virtually all software today is based on lies, very well-organized and effective lies. Lies make modern computer systems possible.

The latest generation of software deception is "containers." Containers are all the rage these days: They make hosting more flexible and reliable; they make development environments easier to set up; they're "like lightweight VMs"; and based on the marketing, they also taste great and are less filling. But... what are they?

Here's the dirty little secret: They don't exist. In Linux, there is no such thing as a "container." It's all a lie. The technology that underpins Upsun's hosting is simply a careful combination of lies, all the way down to the microchip. That's the whole point!

To get to the truth of containers, we need to start unwrapping those lies and see how a modern Linux-based operating system actually works. Before we can talk about containers, we have to first talk about the very first lie of modern computing: multitasking.

## **What is a process?**

At the most fundamental level, any modern computer is a rock (the CPU) that has been convinced to move electrons around in a specific way based on a long series of instructions. Those instructions are all very low-level operations, but a long string of such instructions forms a _program_. And the current instruction being executed is tracked in a special slot called the "program counter" (PC).

Very often, a program will need to wait if it’s trying to communicate with another part of the computer, like a network port or disk drive. In that time, it's helpful for the CPU to be able to work on some other instructions while waiting. That lets the computer pretend (lie!) that it's running two programs "at the same time."

The hardware of the CPU has a special relationship with one particular program, called an _operating system_. That special program is always the first to start, and among other things, is responsible for "context switching." At regular intervals, the CPU will "tick" and register what's known as a _timer interrupt_. That causes the CPU to stop what it's doing and load a specific set of instructions out of the operating system into its active memory, then continue. That specific set of instructions is known as the "timer interruptherehandler." There are other types of interrupts and handlers as well that aren't relevant to us at the moment. The timer interrupt handler then picks a different program to load into the CPU's memory and lets it continue. That whole process can happen thousands of times a second, giving the illusion (lie!) that the computer is running multiple programs at once.

The part of the operating system responsible for swapping in and out of different running programs is called the _scheduler_. And technically, each one of the running programs is called a _process_. In a system with multiple CPUs or multiple cores, the same basic routine happens, but the scheduler has to keep track of multiple active instruction lists, each with its own program counter.

As an aside, a multithreaded program is a single process that can be thought of as having more than one program counter pointing at different instructions in the same program/process. When the operating system context switches, it may activate one program counter or another within a given process.

## **What is virtual memory?**

Of course, the programs don't know that they're all time-sharing the same CPU. And they don't know that they're all sharing the same system memory. The program says to write to the memory at address 12345, but it doesn't really have address 12345. The operating system is there!

Instead, CPUs and operating systems conspire against processes and lie to them, letting them all think that they have a long list of contiguous memory addresses starting at 0. Every program thinks it has that, but it really has a series of small, mostly contiguous chunks of memory all over the physical memory space of the computer. The CPU translates the process-local memory address into the physical memory address and back again, with the program none the wiser. This concept is known as "virtual memory."

There are two key advantages to this memory lie-map: simplicity and security. From the program's point of view, having to keep track of which memory belongs to it and which memory belongs to some other program is way too complex and hard. The memory used by other programs could change at any moment, and no mortal programmer is going to be able to account for that manually. By abstracting that problem away, it frees up the programmer from trying to avoid inevitable memory management mistakes.

That mapping also provides a layer of security. Most of the time, one program reading another program's memory is a security hole, and being able to write into another program's memory certainly is. By not giving programs a way to even address each other's memory, it makes it much harder for one running program to corrupt another. (Harder, but not impossible. In languages with manual memory management, it's still possible to do so with sloppy coding, which is one of the main sources of security problems in those languages.)

## **Process management**

On a Unix-family operating system, processes are tracked in a hierarchy by what other process started them. Any process can ask the operating system to start another process or to "fork" the running process into two processes that can then proceed "in parallel." The operating system itself doesn't have a process per se, but can be thought of as process ID 0 (or PID 0). In Linux, PID 1 is a special process called _init_, which is responsible for managing all other processes below it. Various init programs have come and gone over the years, from the venerable `sysvinit` to `runit`, `upstart`, and `systemd`.

Conceptually, then, the memory space of a modern Linux system looks something like Figure 1.

  
Each process has its own contained memory space and cannot directly touch any other process's memory space. It can, however, ask the operating system to pass a message to another process for it, which allows processes to communicate with each other. There are various mechanisms for that, but the most common is pipe files; that is, a fake file (lie!) that the operating system exposes that one process can write to in a stream and another process can read from in a stream. That abstraction allows a program to remain ignorant of whether the process it's talking to is on the same computer or a different computer over the network.

What's important to note here is that every process can know about every other process. They all can ask the operating system for information about the computer they're running on, such as what file systems are available, what users are on the system and what permissions they have, what the host name of the computer is, what local or network devices are available, and so on. And the operating system will give the same answer to each process that asks.

## **Introducing Linux namespaces**

Everything we've said up until now applies more or less the same to any reasonably modern operating system, give or take a few implementation details. The rest of this article is very specific to Linux (meaning the Linux kernel specifically, not the full GNU/Linux platform), as from here on much varies widely between different systems.

Starting in the mid to late 2000s, the Linux kernel started getting new and fun ways to lie to the processes it's managing. The last bits and pieces didn't fully work until as late as 2014 or even 2015, but by now they're fairly robust. Also, Linux is somewhat unique in that it implemented these features piecemeal, which allows programs to leverage them individually if necessary.

Most of these features fall under the umbrella term "namespaces." Similar to namespaces in mainstream programming languages, Linux namespaces provide a way to segment groups of processes from each other. More specifically, Linux namespaces allow the operating system to lie to different sets of processes in different ways about different things. And because processes are in a hierarchy, lying to one process also means lying to all of its child processes in the same way automatically (unless those have been moved to a different namespace explicitly).

Overall, there are six types of namespaces that the Linux kernel supports.

### **The UTS namespace**

The simplest type of namespace is the one that controls the hostname of the computer. There are three system calls that a process can make to the operating system to get and set its name: `sethostname()`, `setdomainname()`, and `uname()`. ormally, this just sets a global string, but by placing one or more processes into a UTS namespace, those processes have their very own "local global string" to set and read.

In practice, your `/etc/hostname` file may say the computer's name is "homesystem," but by placing your MySQL process into a namespace, you can make the MySQL process think the hostname is "database," while the rest of the computer still thinks it's "homesystem." That's right, it's easy to lie to a program about its very identity!

(Fun fact: The name UTS comes from the name of the struct in the source code that `uname()` uses, `utsname`, which in turn is an acronym for "Unix Time-sharing System.")

### **The mount namespace**

The oldest namespace by far is the mount namespace, dating all the way back to 2002. The mount namespace lets the operating system present a different file system to a different set of processes.

The `chroot()` command, which has been with Linux since basically forever, allows a selected process (and its children) to view a specific subset of the file system as though it were the whole file system. These "chroot jails" were often used to try and segment a system so that certain processes were ignorant of what else was on the same computer. There is still one large file system tree, however. With a mount namespace, it's possible for there to be completely different file system trees that do not overlap at all running at the same time; each mount namespace sees, and can modify, only one of those trees.

It gets weirder, too! Not only does that mean that for two given processes, the root of the file system could be two completely different disk partitions, but it also means they could be two completely different disk partitions, but also then both mount a third partition in different places in the two trees. Something kinda like Figure 3.

  
Also, bear in mind that any block device or pseudo-block device can be mounted into a file system. It could be a partition on a hard drive, but it could just as easily be a network drive on another computer, or a local removable device like a DVD or USB stick, or a file system image file that's sitting on... another file system.

The potential for lies and deception here is mind-boggling.

### **IPC namespace**

This one is a little obscure; recall earlier that we said processes could talk to each other through the operating system in various ways. Collectively, that is known as Inter-Process Communication (IPC), and there are standard ways to do that. Most of them are really just message passing through queues, and in fact, there are standard APIs in POSIX (the official standard that makes up any low-level \*nix system) for them. IPC namespaces let the kernel separate those, too, and deny access to some of those IPC channels to certain processes, depending on their namespace.

### **Process namespace**

Now we get to the interesting one. We said before that the process with PID 1 is always init, and all other processes are children of init, or children of children of init, etc. Every process gets a unique numeric PID to keep track of it.

You can have a look at the processes running on your system with the `ps` command. It has many possible switches and toggles, but we'll discuss just a few here.

Run `ps -A` to get a list of all processes running on the system. It should be a fairly long output, but if you scroll to the top of the list, you will see a PID 1, with a CMD column that indicates what init program your system is using. For example, the beginning of the `ps` output for my Ubuntu system reads:

```shell-session
$ ps -A
 PID TTY          TIME CMD
   1 ?        00:00:14 systemd
   2 ?        00:00:00 kthreadd
   4 ?        00:00:00 kworker/0:0H
   6 ?        00:00:03 ksoftirqd/0
   7 ?        00:05:36 rcu_sched
   8 ?        00:00:00 rcu_bh
   9 ?        00:00:00 migration/0
  10 ?        00:00:00 lru-add-drain
  11 ?        00:00:00 watchdog/0
  12 ?        00:00:00 cpuhp/0
  13 ?        00:00:00 cpuhp/1
  14 ?        00:00:00 watchdog/1
  15 ?        00:00:00 migration/1
```

Although there are over 300 processes total. Running `ps xf` will show all processes for your user and show the hierarchy of what process is a child of another process. Similarly, `ps axf` will show all processes for all users on the system, including their hierarchy.

That's very useful information, but there's a potential issue here: You can see exactly what processes any other user on the system is running! Is that a security issue? On your laptop, probably not, but on any truly multi-user system, it could be. Any malicious user (or a program by a malicious user) can trivially see what's running and its ID, which makes it easier to attack if the attacker knows another vulnerability to use.

Enter PID namespaces. PID namespaces are essentially what the name implies: They're a separate namespace for process IDs. When you create a new PID namespace, you specify one process that will be PID 1 in that namespace. That could be another instance of your init program (systemd in the example above), or it could be any arbitrary process. That process may be known as PID 345 to the "global" namespace, but it's also known as PID 1 within its scoped namespace. If it then forks off another process, that process will also get two PIDs: 346 according to the parent namespace and 2 within its scoped namespace.

However, and here's the really important part, that process won't know about both PIDs. It's running in a namespace that has only 2 processes, and it will know itself as PID 2. That is the only PID it will know about, and if it asks the operating system for a list of all processes on the system, it will see only those 2 in its namespace (lie!). It cannot initiate communication with any process outside of its namespace. It doesn't even know they exist. A process from the parent namespace, however, can see and initiate communication with a process in the child namespace.

If that's hard to wrap your brain around, see Figure 4 for a visual version.

Of course, because so much of process management is managed through the /proc pseudo-file system, things can get weird if the process namespace isn't aligned with the mount namespace. Whether that's good-weird or bad-weird depends on how you set it up.

### **Network namespace**

A network namespace is similar to the mount namespace in that it allows for the creation of an entirely separate collection of resources. In this case, the resources are network devices rather than a file tree. Unlike the mount namespaces, however, they cannot share these resources; a network device can be in one and only one namespace at a time. Moreover, physical network devices (those that correspond to a physical Ethernet card or WiFi adapter) can only remain in the root namespace, and thus a new network namespace begins life with no devices at all, and thus no connection to anything. (Technically, it has a loopback device, but even that is disabled by default.)

However, Linux can create any number of virtual network devices (lies!), which can be placed in a network namespace. Virtual network devices can also be created in pairs that essentially pipe from one to the other, even across a namespace boundary.

That allows for this clever bit of deception:

-   Create a new network namespace, A.
-   Create a pair of virtual network devices peered together. We'll call these `veth0` and `veth1`.
-   Keep `veth0` in the root namespace, and move `veth1` in the new network namespace.
-   Assign `veth0` the IP address 10.0.0.1 and `veth1` address 10.0.0.2. These two network devices can now connect to each other, because they're peered together by the kernel.
-   Assign one or more processes to this new network namespace, say, an nginx process.

That nginx process now starts listening to port 80 on veth1, address 10.0.0.2. Back in the global namespace, we set up routing and firewall rules (e.g., NAT) to forward requests to port 8888 to 10.0.0.2:80. That will cause incoming requests on port 8888 to get forwarded through veth0 to veth1 on port 80, right to where nginx is listening for it.

See Figure 5 for the graphical version.

### **User namespace**

Finally, the namespace that puts the icing and cherry on top. All processes, in addition to their PID, have an associated user and group. Those user and group markers, in turn, have an impact on access control; a process cannot force-kill another user’s process, for instance, unless it's owned by root.

With user namespaces, any process can now create a new user namespace, inside of which that process is owned by any user desired, including root. That means just as a process can have an in-namespace PID and an out-of-namespace PID, a process can have an in-namespace user that is distinct from its out-of-namespace user. And it's in-namespace user can be root, which gives it root access to all other processes in the namespace, even if it's just an ordinary user process in the parent namespace. What's more, if a process is owned by root in the parent namespace, then it can define a mapping of _any_ users in the parent namespace to users in the child namespace.

If that paragraph made your brain flip over, you're not alone. Figure 6 may make it easier to follow.

The important takeaway here is that it's now possible for one process to have supreme root power over a select group of other processes, rather than all-or-nothing across the whole system. There are plenty of other conspiracies you can hatch to give processes both internal and external users, but selective-root is the really fun one.

## **Control Groups**

The other piece of the puzzle is not so much about deception but about tweaking the scheduler. As we said before, the kernel, via the scheduler, switches different processes in and out of the CPU from time to time to simulate multitasking. How does it decide which processes are allowed to spend more time or less time on their CPU timeshare? There are many automated ways of allocating time more or less fairly, but they all assume that no particular process is going to be especially greedy. After all, a program can trivially break itself into multiple processes and therefore get extra pieces of the CPU pie.

The same applies to memory usage. The computer has a fixed amount of physical memory, and when programs fill it up with code and data the operating system will begin swapping seemingly less-used portions of it out to a scratch space on disk (called the "swap device" or "swap file," depending on the implementation). But that still means one greedy or inefficient program can elbow out other processes simply by asking for lots of memory at once.

Control groups are the Linux answer to that problem. Control groups work by creating a parallel hierarchy of processes, independent of the creation hierarchy used by namespaces. Processes can then be associated with one and only one leaf in that hierarchy.

Any node in that hierarchy can have one or more "controllers" associated with it. There are a dozen or so controllers currently implemented, some of which just track resource usage, some of which limit it, and some of which do both. The two most important controllers for our purposes are CPU and memory, which can cap the total CPU usage or memory usage of a tree of processes.

So, for example, we can create a control group of processes, assign all of the nginx processes to it, and put a controller on it that limits its CPU usage to 25% and restricts them to two of the four CPU cores in the computer. Then we can make another control group, assign the MariaDB process to it, and restrict it to 100% of one of the remaining CPUs. Now, while it is still possible for a bad query to cause MariaDB to eat up all of its available CPU time, it won't impact the running nginx processes. They're segregated to different CPUs and limits on usage, so while MariaDB may slow to a crawl, nginx will keep running, as well as any other processes in the top-level control group. (See Figure 7.)

A process in a control group will still know that it's in a control group and that it's getting only a portion of the total system resources. Unless the process is owned by root, however, it won't be able to change that configuration.

## **Overlapping namespaces**

An important point to note is that in Linux, unlike most older Unixes, each of these namespaces and control groups are distinct. It's entirely possible for processes 2, 3, and 4 to share a mount namespace, while process 3 is also in a user namespace and process 4 is in a UTS namespace. And then you can place processes 2 and 4 in a very CPU-limited cgroup together, while process 3 gets as much CPU time as it wants.

Such a configuration, while possible, is also quite complex. While some thoroughly fascinating functionality could result, it could also result in a completely unusable mess. More typically, only a few namespace features are used to obtain very specific segmentation goals.

The most practical and applicable combination, though, is "all of the above!", as seen in Figure 8. Consider, we can now create a group of processes that:

-   Only know about each other, not any other processes on the system.
-   Have one that thinks it has root access, and the other processes think is root, but doesn't have root on the whole system.
-   Have their own file tree, from/on down, and no way to access any other file systems.
-   Have their hostname.
-   Have their IP address they think they're running on, with their own set of ports, even their own IP routing rules for network access.
-   Have no way of accessing processes outside of that group or even knowing that there are processes outside of that group.
-   Will, collectively, use no more than 25% of CPU time and no more than 256 MB of RAM.

As far as a process in that group is concerned, what's the difference between that and running on its complete computer? In practice, very little. It gives almost all of the isolation power of using virtual machines but with only a tiny fraction of the overhead; really, the only overhead is lookup tables for the kernel to keep track of what lies it's telling which process. The only limitation is that there's still only a single kernel instance running and controlling it all.

This "all of the above" combination of lies is so commonly desired that it even has a common name: Containers.

In the end, that's all a "container" is: It's a short-hand name for "use all the namespaces lie at the same time to trick processes into thinking they're running on their own computer when they're not." And that ends up being extremely powerful.

## **Container abstractions**

While the kernel offers all sorts of APIs to manipulate namespaces and processes at a fine-grained level, that is often not especially helpful when trying to build a system at a more coarse-grained level, such as a macro "container." As is common practice in programming, therefore, various other tools have sprung up to abstract those low-level APIs into easier-to-use higher-level APIs. There are many such systems written in a variety of different languages. Any language that is capable of issuing libc commands can work.

There are many such abstraction tools, all of which do more or less the same thing. A few you might have heard of are listed below.

-   LXC (for LinuX Containers, written in C): https://linuxcontainers.org/
-   Docker (written in Go): https://www.docker.com/
-   lmctfy (short for Let Me Contain That For You): https://github.com/google/lmctfy/
-   Rocket / CoreOS: https://github.com/coreos/rocket
-   Vagga (written in Rust): https://github.com/tailhook/vagga
-   Bocker (written in Bash): https://github.com/p8952/bocker

An even larger list can be found on https://dagger.io/, and at least Bocker is worth reviewing just to see how basic such a system can be.

Docker is by far the most popular such container management tool, although it is neither the first nor most recent. It just happened to be the new-and-cool option when the market decided it was "ready" for containers. Originally, it was built as an additional layer on top of LXC, although it has since replaced its LXC dependency with its library, called runC.

Although a bit lower-level than most end users and system administrators would like, LXC is one of the most powerful options. It also has bindings to further automate its capabilities using a variety of languages, including C, Python, Go, and Haskell.

Regardless of the tool, all are simply abstractions around saying "start a process, create a bunch of namespaces on that process, and mount this filesystem into it." That routine is generally called "starting" a container.

## **Orchestration**

Another layer of abstraction that is often used is "orchestration." Orchestration is another abstraction layer on top of the container software. In a general sense, it's simply code that coordinates copying file system images between multiple computers, calling the container software on each computer and telling it to start a container, and then instructing the container software how to configure that container (namely, what details to set up for the various namespaces and cgroups).

In practice, it's common to want to use multiple containers in tandem, communicating as if they were over a network when they're really just different processes on the same computer. Setting that up manually is mostly straightforward but very tedious. Orchestration systems automate the task of creating multiple containers and connecting them with a nicer syntax. Kubernetes is the big name in this space right now, but many other examples exist, including Upsun itself.

## **Read-only containers**

It's very common for container implementations to encourage or require the use of read-only file systems. There are a variety of reasons for that. For one, it's simply very efficient. Linux is quite capable of taking a snapshot of a file system and producing a single file representation of it, which can then live on another file system. (Think of "ISO" filesystem images for CDs and DVDs. Plenty of other similar formats are available.) When creating a container, therefore, it's super easy to place its processes into a mount namespace, and then mount that file system image file as root within the mount namespace. Now, any process in the container, by which we mean in that mount namespace, will see that file system as the entire universe.

What's useful, though, is to make multiple copies of that container. Two different containers (that is, mount namespaces) can use the same file system image as their root mount point. If it's writeable, though, that raises all sorts of questions about how to synchronize writes between them. What happens if a process in one container makes a change that is important to a process in the other container? The answer is "it's messy."

If, however, that filesystem is read-only, not only does it avoid any such synchronization issues, but it means the operating system needs only a single copy of it. Two, three, or 30 mount namespaces (containers) can mount the same 10 GB file system image on their root directory, yet the operating system needs only read data off it only once. And since it doesn't need to load the entire filesystem into memory, that means the memory overhead for starting 30 containers with that same 10 GB file system is... a few KB of bookkeeping data inside the OS to keep its lies straight.

Take that, virtual machines!

## **Container portability**

The marketing around containers often likes to make references to shipping containers, which revolutionized the cargo industry by creating standard-sized boxes that clumsier objects could be put into, which could then be neatly stacked on ships, trucks, and airplanes. The sales pitch often claims that a container is a standard format that can then run "anywhere," just like shipping containers.

That marketing is, unfortunately, not only wrong but entirely backwards. It's yet another lie.

Generally speaking, the file system snapshots, or "images," that we discussed before are configured to only work correctly when loaded by one specific container abstraction library. They will often include not just a file system, but metadata that the abstraction library uses to decide what namespaces and cgroups to configure. Should this container have a network namespace that allows outbound access? On which ports? What additional file systems should be mounted? All of that metadata is in a library-specific format. A Docker-built image will not work on Vagga or LXC, and vice versa.

So if they're not portable, what's the advantage?

The advantage is from the inside. Almost any meaningful program relies on hundreds of other programs and libraries. These are generally installed by the Linux distribution at known fixed versions... or at least mostly known and fixed versions. They're patched all the time as bugs and security holes are fixed (or introduced). When people talk about "making production match staging," the long combination of possible versions of various libraries is what they're talking about. Even a simple hello-world PHP script relies on Apache or Nginx, PHP-FPM, the PHP engine itself, PHP extensions, C libraries used by those extensions, and likely a dozen other things. While in an ideal world, the various different combinations of libraries would work fine, we all know reality is rarely ideal, and it can be maddeningly time-consuming to find bugs introduced when the combination is different.

What containers give you is the ability to bundle all of those libraries up together into a filesystem snapshot. Almost invariably, one program (process) will start another by asking the operating system, "Start a new process using this file on disk." If the "disk" it knows about is a mount inside a mount namespace, and that mount is a filesystem image file, well, now you can tightly control the exact version of every dependency you put into that filesystem image. The one notable exception is the kernel itself. Everything else can be shipped along with your program.

It's like static linking your entire computer! Which means, yes, you're back to compiling things, even if writing in a scripting language like PHP or Node.

What containers buy you is the ability to ship not your application, but your application and all of its dependencies, pinned at a precise version. When you then load that container on another computer, it will start a PID namespace, mount namespace, user namespace, etc., around the entire collection of dependencies you provide and (potentially) use cgroups to contain all of those processes to just a fragment of the resources on the actual hardware. That filesystem image can also be reasonably small, since you know what tools you're going to need and can include just those select few. The lie to your application is maintained; it doesn't know if it's running in a container or not, nor should it care.

That's also why languages that compile to a single executable like Go (or Rust, depending on your settings) are well-suited to container setups. They already bundle all of their dependencies into a single program, so the "filesystem full of dependencies" you need is trivially small: often it's just the program executable itself.

Because the overhead of each container is so small, running 50 copies of a container is no more expensive than running 50 copies of the same program without a container. With cgroups, it's possibly cheaper and certainly easier to keep them from bumping into each other. That's in contrast to VMs, where every instance adds not just a few running processes and some bookkeeping but completely duplicated copies of the Linux kernel, all user-space tools, and whatever program you are trying to run.

## **Containers at Upsun**

There are numerous possible ways to set up all of this newfound flexibility, many of which are applicable in only certain situations. As a practical example, let's look at how our container implementation here at Upsun manages containers for customers and how it differs from Docker, which is widely used for local development.

Upsun treats container images as a build artifact. That is, what's in your project's Git repository is not what is deployed to production. Rather, we check out what's in Git, then run your "build hook" from the upsun/config.yaml file in your repository. That could include downloading dependencies with Composer, npm, Go modules, etc., as well as compiling Sass or Less files, minimizing JS scripts, or any other build commands you wish. The result is just "a bunch of files on disk" on a build server.

That "bunch of files on disk" is then compressed into a squashfs file. Squashfs is a compressed, read-only file system that is itself a single file on disk, much like an ISO image. That "application image" is then uploaded, along with the metadata derived from your configuration files, to one of the many VMs we have running.

On the VM, then, we assemble a container. Upsun uses LXC, rather than Docker, as it offers more low-level flexibility, on top of which we have our own coordination and orchestration software. The first step is to create a new LXC container, which tells LXC to create a new init process (we use runit) with its mount, pid, UTS, network, and user namespaces.

In that mount namespace, we then mount a base image, as defined by the aforementioned metadata. The base image is a squashfs file containing a minimal Debian installation with a user-selected language runtime and version: PHP 8.4, Python 3.12, or Go 1.18, for instance. That's now the file system that any process in the container (that is, in all of those namespaces) will see. And because it's a standard, common image, dozens of containers can be running on the same VM with almost no overhead.

Next, the user-provided application image is mounted at a standard location, specifically `/app`. That contains all user code, which obviously will vary between different projects but is generally far smaller than the entire rest of the shared OS image. Finally, the configuration metadata also defines various writeable mount points; those are part of a writeable network file system exposed for each container and mounted into the container's file tree wherever the configuration says to mount them. The result is a file system that consists of one widely shared squashfs image, one application-specific squashfs image, and zero or more network file mounts.

With the file system all assembled, the next step is setting up processes. If an application runtime requires extra configuration, those configuration files are generated out onto a small, writable ramdisk (again, limited to that mount namespace). For example, on PHP, the `php.ini` file and PHP-FPM configuration will be generated into that directory. On a Ruby container, it would be different files. All containers also include Nginx, so the `nginx.conf` file is written there as well. The base image includes symbolic links to where those configuration files will be, allowing the runtime to find them. (See Figure 9.)

LXC allows processes from the parent namespace to call into a container and execute an arbitrary command within the container (within all of the corresponding namespaces), which is how all of the control logic is built. The final step is to tell the init process inside the container to start the few processes it needs: SSH, nginx, and PHP-FPM if on a PHP container. A `ps axf` run from within one of these containers shows only the few processes that are part of the PID namespace of the container:

```shell-session
$ ps axf
 PID TTY      STAT   TIME COMMAND
   1 ?        Ss     0:06 init [2]
  72 ?        Ss     0:06 runsvdir -P /etc/service log: .................................................................
  78 ?        Ss     0:00  \_ runsv ssh
 105 ?        S      0:00  |   \_ /usr/sbin/sshd -D
20516 ?        Ss     0:00  |       \_ sshd: web [priv]
20518 ?        S      0:00  |           \_ sshd: web@pts/0
20519 pts/0    Ss     0:00  |               \_ -bash
20605 pts/0    R+     0:00  |                   \_ ps axf
  79 ?        Ss     0:00  \_ runsv nginx
  99 ?        S      0:00  |   \_ nginx: master process /usr/sbin/nginx -g daemon off; error_log /var/log/error.log; -c /
 104 ?        S      0:00  |       \_ nginx: worker process
  80 ?        Ss     0:00  \_ runsv newrelic
  81 ?        Ss     0:00  \_ runsv app
  89 ?        Ss     0:22      \_ php-fpm: master process (/etc/php/7.3/fpm/php-fpm.conf)
```

That's it. The VM the container is running on will have thousands of processes running, but inside this PID namespace there's only ssh, nginx, and PHP-FPM for PHP 7.3, plus some small coordination processes that runit uses. The kernel will know those processes by both the pids listed above and some other system-wide PID, but from inside the container, there's no way for us to find out what those are or even know that there are other processes, for that matter.

Finally, the coordination software instructs the OS to place all of these processes into a cgroup to restrict their collective CPU and memory usage. The level of restriction is based on the project's plan size.

That takes care of the application itself. A modern web application is more than just stand-alone scripts, though. Depending on the application, it could include a MySQL or MariaDB database, MongoDB, a Redis database, Memcache, possibly a queuing server, and various other things. That's controlled by the `services.yaml` file in the repository. If the `services.yaml` files say "this project needs a MariaDB server, an Elasticsearch server, and a Redis cache server," then the coordination software will create three more containers, one for each of those services. The process is essentially the same as for the application container, except there is no application image to mount. There's just a base image for the service (MariaDB, Elasticsearch, and Redis) and a writeable mount for the service's data files. Otherwise, the process is identical.

Additionally, because each of those containers implies a new network namespace, none of them are able to talk to the outside world by default. Instead, virtual network interfaces are created that allow only whitelisted connections between the containers on specific ports, meaning the application container can talk to the virtual port 3306 on the MariaDB container, but no other port. And the MariaDB container has no way of talking to the Redis container or any container that doesn't connect to it first. And so on.

All told, the overhead of creating those four containers (meaning four UTS namespaces, four PID namespaces, four user namespaces, and four network namespaces) is minimal, maybe a second or two. Compared to the time of the processes themselves actually starting, copying the application image to the VM, and the coordination software's bookkeeping, it's a rounding error.

Because containers are so fast, being just a lookup table of lies, and because most of the filesystem is read-only, it becomes practical to handle new deployments the same way: Simply kill all of the processes involved and restart them. But we can be smarter about it, too. If, for instance, only the application code has changed, none of the backend services containers need to be completely terminated and restarted. Just the file mounts on the application container are updated to point to a new version of the application image. If a newer version of the base image is available (a new bug fix release of Node.js, for instance) or if the configuration has changed and is now asking for a new version (to upgrade from PHP 7.3 to 7.4), then the application container is stopped completely and restarted with the new base image. In either case, the service containers don't need to do anything until their configuration changes as well.

Another advantage of the lookup table of lies is that creating multiple copies of a container takes only minimal extra time. Creating a new testing copy of the entire code base, services, and all, is simply a matter of creating more namespaces for the kernel to lie about and mounting the same file system images again in the new mount namespace.

The way Upsun handles it is that every branch in Git corresponds to an "environment," that is, a set of containers for the application and related services. Any branch can produce an application image, which can then be mounted into a new container (namespace) with little additional resource usage.

The tricky part is the writeable filesystem for each container. That's handled by a volume-level copy-on-write process, conceptually very similar to PHP's copy-on-write way of handling variables in memory. That allows the data to be replicated to a new container (mount namespace) in essentially constant time, forking the data as it gets modified over time. That process is handled independently of Linux namespaces, though, so we won't delve into it here.

Also, bear in mind that the Linux kernel is really, really good at avoiding loading data into memory it doesn't need to. If there are 100 containers in 100 sets of namespaces, running 100 copies of nginx off of the same read-only file system image... Linux won't load 100 copies of the nginx binary into memory. It will load the parts of the binary it needs into memory once, and then when it lies to each process about its virtual memory space, it will also lie to it about having its own copy of the application code. That means 100 copies of nginx don't take 100 times as much memory; they take maybe 25% more memory for each instance's data. (The actual amount will vary widely depending on how much actual runtime data the application stores in variables.)

The net result is that a single beefy VM, running a single Linux kernel, can run dozens of user-defined application containers, dozens of MariaDB instances, a dozen Apache Solr instances, a smattering of RabbitMQ instances, and a Redis index or two, all at the same time; all of those applications will think, if they query the operating system, that they're the sole application running on their computer; and all of them will be able to access only a select, whitelisted set of other "systems" (containers), in whitelisted ways.

All because Linux got good at lying.

## **Contrast with Docker**

Docker, by contrast, is set up to run a single process in each container (set of namespaces). That single process could be something like PHP-FPM, Nginx, or MariaDB, or a short-lived process like a running Composer command. Docker does not use an init process, so while it's possible to manually force multiple processes into a single container, it's not really the intended use case, and those processes will not start up and shut down gracefully if there’s a problem.

Docker also eschews the multiple-nested-mounts file system configuration in favor of a layered approach. Another Linux kernel trick is the ability to have multiple file system images "mask" each other. Essentially, multiple file systems can be mounted at `/`, and files in later file systems will get used instead of those in earlier file systems. That allows the common base tools of, say, a functional Debian or Red Hat system to live on disk only once and then get "masked" by an installed MariaDB or installed PHP-FPM overlay when the container boots. See Figure 10 for the visual.

For Docker's main use case, running local applications in a container, that's perfectly fine. It's actually better suited to one-off tasks, such as wrapping a command line tool like Composer or NPM into a container, than Upsun's model. Upsun's design, in contrast, gives a more "VM-like" feel and allows multiple related processes (such as Nginx and PHP-FPM) to run together in the same container for simplicity, something Docker doesn't do. Neither model is inherently "better" or "worse," just tailored to different use cases.

The biggest difference is that Docker is inherently a single-container system; managing multiple containers in concert is left to separate tools such as Kubernetes, Docker Compose, Docker Swarm, and so on. In Upsun's case, the assumption is that containers will always be deployed as a group, even if a group of 1. (Recall Garfield's Law, "One is a special case of many.")

There are other container systems in the wild, too. Red Hat's FlatPak or Ubuntu's Snaps are both container-based systems optimized for shipping desktop applications packaged up in containers. We won't go into detail about how those work as this article is long enough already, but be aware that those also exist and serve their own use cases better than either Upsun's hosting platform or Docker would.

The great thing about containers, as Linux implements them, is that they can be used in a wide variety of different ways depending on the use case. As with most things in technology, they're not good or bad, just a better or worse fit for a given situation.

## **Conclusion**

While cool, and while they enable a host (no pun intended) of new functionality, containers are not magic. They're nothing like shipping containers at all, despite the marketing hype. Nor is Docker the first, last, or only container system on the market. There are a variety of container coordination applications around, all with their own pros and cons, just like any other software market. Ultimately, all are simply organized and systematic ways to lie to your programs in new and creative ways.

At Upsun, we've embraced these "beautiful lies" to create something powerful: a platform where developers can focus on building amazing applications while we handle the complex orchestration of namespaces, containers, and infrastructure. Whether you're running a simple CMS or a complex microservices architecture, our container implementation ensures your applications get exactly the resources and isolation they need without you having to become an expert in Linux kernel internals.

Welcome to the future. Please keep your lies straight.

Ready to see these lies work in your favor? Try Upsun's container magic with a free trial and experience the power of perfectly orchestrated deception.

### [The hidden cost of free cloud credits | Upsun](https://upsun.com/blog/free-cloud-credits-devops-nightmare/)

# Your free credits are leading to a 30-person nightmare

Before I worked in tech, I worked in logistics. I saw  a specific pattern repeat itself at office supply companies over and over, until I could see it coming before the customer did.

The pattern went like this. A small office supply company would sell paper and pens to local businesses. One day a customer asked, "can you deliver a box of paper?" The salesperson said yes, drove the box over in their car after work, and thought nothing of it. The customer told their friend. The friend asked for delivery too. Management, reasonably, added "delivery" as a service offering.

A year later the company owned a box truck and had hired a driver. Two years after that, a small fleet, a maintenance crew, a dispatcher, a safety officer, and a lawyer on retainer for the transportation regulations.

Four years in, they were spending more time and money on the delivery operation than on selling office supplies.

## The same pattern, in tech

I thought about that pattern a lot once I was on the tech side and started watching it play out with tech founders.

The version I see most often goes like this. A founder takes free credits from one of the big hyperscalers at the start. Their most technical co-founder sets everything up in an afternoon. The setup works. It keeps working. The company grows past the shape the setup assumed.

A few years later, that same founder has thirty people on staff. Those thirty people spend their time on devops, CI/CD, infrastructure, security reviews, and legal paperwork around cloud contracts. Shipping product happens in whatever attention is left over after all that.

None of that work is something AI is going to take off their plate. You can't prompt your way through a SOC 2 walkthrough or a cloud provider's master services agreement. Those thirty people are thirty people for a reason, and the reason is the platform decision made at four people, not the product.

## Why it's hard to see coming

The evaluations that pick the platform happen at the smallest moment in the company's life. Four people, one app, a shared Notion workspace. The team has the most specific possible picture of what they need and the least specific possible picture of what they'll need next year. That's not a failure of judgment. It's the shape of the moment.

Here's the part that's easy to miss. The platform decision you make at four people is making a bet about the shape of the company at forty. It's often being made by whoever was available on a Friday afternoon, based on who had free credits and which framework somebody had just posted a blog about. The bet is often fine. When it isn't, the cost of being wrong is a migration during the busiest year of the company's life.

The founders I watch hit this wall almost never describe it as a single migration. They describe it as another piece. A customer asks for something the platform can't do, so they buy a tool to cover it. An auditor asks for something, so they buy another tool. A CFO asks for consolidation, so they bolt on a reporting layer. Every ask gets a piece bolted onto the jenga tower they've been building since the free-credits afternoon. None of the pieces is wrong, exactly. The tower is the problem. At some point the tower is the thing the company is actually maintaining, and the product is whatever sits on top of it, holding on.

The office supply company, four years in, did not set out to run a trucking operation. They set out to sell pens.

## What a platform that graduates with you does differently

The question I try to help teams ask now, when they're early enough for the question to be cheap, is what the platform looks like when the company is five times bigger, not what it looks like today.

On Upsun, a few things that matter at scale are already there at size one. The configuration is YAML from day one, which means the application infrastructure is code, which means it scales the way code scales. Every language commonly used in modern product development runs through the same pipeline. The same .upsun/config.yaml that runs a four-person Next.js project also runs a forty-person Next.js plus Go plus Python plus Ruby project. When a customer asks for deployment in their AWS account, it's a region change. When the compliance team asks for SOC 2, ISO 27001, PCI DSS or HIPAA scope across the whole application, that boundary already exists.

The capability that matters is not any one of those. It's that the shape of the platform doesn't change when the shape of the company changes. The thing the founding team picks in a week at seed stage is the same thing the operations team is still using at Series E. The graduation is smooth because there's nothing to graduate from.

That's not a promise that growth is easy. Growth is never easy. What it is, is a promise that the platform isn't the thing you migrate during growth.

## What this feels like a few years in

The customers I know who've been on Upsun for a few years describe the platform as "the thing we don't talk about." Which is, I think, the highest praise a platform decision can earn. It ran in the background while the company doubled and tripled and signed a bigger customer and passed an audit. It didn't require a re-evaluation. It didn't hit a ceiling that required a replatform. It scaled with the company, and the company got to spend its attention on the product.

The office supply companies that survived, by the way, were the ones that partnered with a delivery company instead of building one. They stayed in the business they were in.

## A question for earlier-stage teams

If you're picking a platform at seed or Series A, the question to sit with is: what does this platform look like when we're five times bigger?

Five times bigger isn't dramatic. It's two to three years. Five times more customers, five times more code, probably more languages, probably more runtimes, probably a security review from somebody with a clipboard. The question isn't whether the platform you pick today supports five-times-bigger use cases. It's whether the platform has a story for getting there without a migration in the middle or slapping on ten additional integrated technologies.

If the story is "use the same configuration, add what you need," you're in a good spot. If the story is "migrate to our enterprise tier" or "integrate with a different set of tools," that's the seed of a future Thursday spent on something that is not the product.

## Get back to selling office supplies

The founders I know untangling their jenga towers now are going to be fine. Products good, customers loyal, nothing on fire. They're just spending a year paying a bill they didn't know they were running up, and cutting the size of the team that maintains the tower in half.

If I were picking a platform today for a project with any chance of becoming a real company, I'd be thinking about the shape of the platform two to three years out more than the shape of it this quarter. The quarterly shape is easy to evaluate. The future shape is the one that matters.

If you're already running the company you started, good. If you look up one day and realize you're running a devops operation that ships apps on the side, it's not too late to go back to “selling office supplies” and let somebody else run the trucks.

## Further reading

-   Upsun platform overview
-   Upsun multi-cloud and multi-region deployment

### [Magento performance optimization: prove to speed up your store](https://upsun.com/blog/magento-performance-optimization/)

# Magento performance optimization–Actionable tips and strategies

Is your ecommerce store traffic resulting in enough conversions? If not, your store might be facing performance issues. Amazon loses 1% of its $141 billion online sales for every 100ms of latency. BBC risks 10% of its website visitors for every additional second of load time.

As your business grows, the need to build new features, customize code, and integrate third-party systems grows. Overwhelmed by these increasing needs, brands often ignore the negative impact this may have on their store: Slow site loading speed.

Even a slight difference in site speed could heavily impact your bottom line. Addressing it should be your utmost priority. Slow site speed not only affects conversions. Instead, it results in a quick surge in traffic, too. Google says that a 0.5s site speed delay can cause a 20% traffic drop.

Platforms like Adobe Commerce (Magento), with advantages like sturdy infrastructure and several built-in features, pose challenges in the form of loading speed. Optimizing your store on an ongoing basis with your Magento development services partner is a mandate to drive sales. In this blog, you’ll learn why page loading time matters and the best Magento speed optimization techniques to achieve it.

## **Why does Magento speed optimization matter?**

Site speed has a direct impact on factors that determine your ecommerce ROI, such as user experience, conversions, bounce rate, and SEO.

Having discussed the factors that highlight how vital page speed can be for an ecommerce business, let’s dive into the best performance optimization techniques that work for Magento store owners.

### **Magento performance optimization best practices**

#### **1\. Emphasize First Meaningful Paint (FMP)**

First Meaningful Paint (FMP) or loading above-the-fold content means showcasing the most relevant part of the page first. By prioritizing above-the-fold to load first, you showcase content to users faster, which reduces the bounce rate.

You can achieve it by refraining JavaScript from loading upfront. When a web page starts rendering, the JS code also runs in parallel, increasing the load time. To restrict JS from loading simultaneously, you can defer the code parsing using third-party extensions (Ex - Defer JavaScript) and move unnecessary JS code to the bottom of the page. Less JS code to process results in faster page loading speed.

#### **2\. Code optimization**

You customize code for requirements like building new functionalities and improvising extensions and themes. Any outdated or unnecessary codes in customization could cause performance issues and slow down your store’s performance.

Sign up for dedicated Magento managed services to perform code audits, identify bottlenecks, and review and refactor the code to improve efficiency

#### **3\. Search optimization**

A responsive product search system that fetches relevant results for queries can enhance user experience. Stores that hold thousands of product catalogs and attributes might suffer indexing issues, resulting in delays in product discovery. 

To speed up search functionality, configure Magento’s search indexing best practices to optimize indexers meant for the price, product, category attribute, and so on.

_**Effect of indexers on your store’s performance:**_

Indexers could slow down your store by consuming server resources upon indexing products you keep adding to your portfolio. There are two modes available for Magento indexers - ‘Update on Save’ and ‘Update on Schedule’.

If you enable ‘Update on Save,’ indexers will run whenever you save a product, category, or attribute. The better option, especially if you are frequently expanding your product portfolio, is ‘Update on Schedule’. Using this indexer, you can schedule the time when the products and related information need to be indexed. It’s recommended that the cron job be set for indexing during low traffic periods.

**To know the current indexing mode your store is in, use the following command:**

-   `php bin/magento indexer:show-mode`
-   Or, you can go to System > Index Management in your admin panel
-   Change the mode to ‘Update on Schedule’ using the command: `PHP bin/magento indexer:set-mode schedule`

**You can also select all the indexers and turn the ‘Update on Schedule’ by:**

-   Choosing System > Index Management: ‘Actions’ dropdown list 

**To schedule the cron job for the ‘Update on Schedule’ indexer:** 

-   Store > Settings > Configuration > Advanced > System > Cron (Scheduled Tasks)

### **4\. Elasticsearch**

Elasticsearch is an open-source search engine that generates accurate and relevant search results faster. Based on Apache Lucene, a search library (open-source), the search and analytics engine auto-suggests keywords and completes search queries. 

Contextual search enables the search engine to look only for relevant results instead of searching for the entire database. Thus, by reducing the look-up, search results are generated faster.

For related search queries, the search engine generates products, images, prices, etc, narrowing down the search and ultimately speeding up the product discovery process for users. 

If your store is operating on Magento 2.4.x or later versions, Elasticsearch will be enabled by default. If you are using older versions, you can enable it by following these steps:

-   Go to - Stores > Settings > Configuration.
-   Go to - Catalog > Catalog > Catalog Search.
-   In the Search Engine dropdown, Click Elasticsearch.
-   Click ‘Save Config’ 

### **5\. Optimize Time-to-First-Byte (TTFB)**

Time-to-first-byte is the time taken by a server to send the first byte of information after receiving a request (user) from a web application. In other words, it is the latency between a browser request and a server’s response time to send the first byte.

Optimizing TTFB is important for dynamic pages like cart, checkout. Factors like unoptimized code, poor web server configuration, slow database, routing, etc, increase TTFB.

Google’s recommended TTFB is 800ms or 0.8 seconds or less. You can optimize TTFB by configuring caching and the web server, performing extension audits, and code refactoring.

### **6\. GZip Compression**

GZip compression is an excellent way to compress files rendered when a page loads. Turn on GZip compression for your store. By configuring GZip, you can compress files like CSS, JavaScript, fonts etc. This reduces the time taken by the server to download the  
files, resulting in better performance.

**Enabling GZip Compression**

### **7\. Minification of CSS, JS and HTML**

Magento provides a built-in feature to minify CSS and JavaScript. The optimization of CSS and JS enables faster page loading by reducing the number of requests sent to the server by more than 25 times. To enable the built-in feature:

Turn the store to production mode (Minification works only in production mode)

-   Go to - Stores > Configuration > Advanced > Developer and enable modification.
-   Choose the option ‘Yes’ under Minify JavaScript Files feature
-   Click – Save Config
-   Go to System > Cache Management and choose Flush Cache

Source - Magento

### **8\. Image optimization**

Images are an integral part of ecommerce, but optimizing them is a mandate to help your store perform better. You can use third-party Magento extensions to reduce file size without compromising quality.

Use image optimization techniques like Lazy Loading, which loads images after the entire page loads. You can also use AWS or a CDN to deliver your content faster.

Other image optimization tips include avoiding oversized images and using advanced image formats like Adopt WebP and JPEG 2000, which deliver files in smaller sizes with zero compromise on quality.

### **9\. Advanced JS bundling**

While JS Bundling reduces the number of HTTP requests sent to the server, it loads all the JS bundles when a page loads. Advanced JS bundling manages this shortcoming by restricting the need to load all the JS bundles when a page load request is sent to a server.

Every page in your store, be it PDP or PLP, needs only a specific set of JS bundles to load. Using Advanced JS bundling, you can define bundles based on the type of the page like checkout, CMS pages, product detail pages, category, etc.

Source - Magento

### **10\. Audit third-party extensions**

Auditing your third-party Magento extensions is an important exercise to find out if they are causing speed issues for your store.

To perform the audit, choose one third-party extension and turn it off. Clear cache and perform a speed test on pages like the home page, checkout, cart, product detail page, and category pages. Look for changes in the performance of your store. If you note a positive impact on speed, you’ve located the extension.

Perform this procedure for all the third-party extensions to see if they have any performance impact. Contact the appropriate vendor, report issues, and ask for a fix.

### **11\. Leverage flat catalogs**

If your Magento store is showcasing huge volumes of catalogs, enabling flat catalogs becomes a handy performance optimization practice.

Magento stores product data and attributes using an EAV (Entity Attribute Value) model. EAV is a data model that Magento uses to denote entities. The model allows you to add entities along with attributes that describe them. In this model, an entity holds data like products, categories, customers, and orders. Attributes are data related to an entity, like name, price, etc. 

The EAV model enables the platform to store data in an organized way and concisely hold all the relevant data.

Attributes of each entity are stored in different tables based on the value type. Requests are sent to multiple tables to fetch data when product information is required. This slows down query response time.

The ‘Flat Tables’ option in Magento merges multiple attributes of an entity into a single table (Flat Table). So, to render product information, only one table is queried, speeding up the response.

Upon indexation, Magento generates and updates flat tables. Enable it using the following steps:

-   Go to Stores > Configuration > Catalog > Catalog > Storefront
-   Under use flat catalog category, choose ‘Yes’
-   Under use flat catalog product, choose ‘Yes’
-   Click - Save config

Source - Magento

### **12\. Integrate CDN**

Using CDN (Content Delivery Network), you can reduce response time significantly. A CDN caches the dynamic elements of your store, like CSS, JavaScript, images, videos, and fonts, and renders them, thereby minimizing the load on the servers.

CDN ensures high availability by utilizing multiple delivery networks to render static content on your Magento store. To implement CDN for your Magento store:

-   Go to Store > Configuration > ‘General’
-   Choose the tab ‘Web’ under ‘General’
-   Choose base URLs
-   Under the field ‘Base URL for Static View Files’, provide the CDN location where static files are stored.
-   Under the field ‘Base URL for User Media Files’ provide the CDN location of the JavaScript files.
-   Click – Save config

Source - Magento

### **13\. Clear database logs**

Magento generates logs to keep track of actions performed (Ex - products viewed). Eventually, these logs accumulate in the database, slowing up the response. Database cleaning helps clear up logs, which improves site performance and latency.

-   Go to > Stores > Configuration
-   Click on the ‘Advanced’ option.
-   Upon expansion, choose the ‘System’ tab and open ‘MySQL Message Queue Cleanup’
-   Under the ‘MySQL Message Queue Cleanup’ field, set the time to trigger auto cleanup for logs.
-   Click ‘Save config’

Source - Magento

### **14\. Expiration headers and render-blocking**

Expiration Headers instruct Magento 2 on how long it should cache static contents of your store. By configuring expiration headers, you can eliminate the browser from querying the server to render the unchanged portions of a page. You can add expires headers on configuration files on servers like Apache or Nginx.

Render blocking prioritizes CSS over JavaScript when a page loads, rendering the visible content faster.

### **15\. Varnish cache**

Varnish Cache is the caching technique for Magento 2 that serves as a proxy for web servers. When a client (browser) sends a request to a server to load a web page, the server processes the necessary CSS, HTML, JavaScript, and images.

Varnish cache creates temporary storage for these elements. When subsequent requests are received, the Varnish case renders the cached assets to the client, thereby significantly reducing the queries on the server. This improves the response time and facilitates faster loading. 

### **16\. Redis cache**

Redis cache plays an integral role in Database caching and Session-store caching. For websites with more dynamic pages, Database caching helps reduce server loads.

Session-store captures data like profile information, recommendations, discounts, etc. from a user sign-in to sign-out.

Redis, being an in-memory caching system, can be used to cache both. Using its eviction mechanism, Redic cache enables you to remove data to free up space for new caching through 6 eviction scenarios. 

### **17\. Switch to production mode**

Make sure your Magento store is operating under ‘Production’ mode. Production mode is optimized to render the best performance. You can set your store to production mode using the following command: `bin/magento deploy:mode:set production` 

### **18\. Version upgrades**

Upgrade your Magento store to leverage all the improvements of its latest version. Magento regularly provides upgrades aimed at enhancing the overall technicalities of the system and addresses shortcomings in the previous versions with an emphasis on security and performance.

Keeping your Magento store up to date can help in leveraging performance improvements. You can get help from your Magento / Adobe Commerce development agency to upgrade your store.

### **19\. PWA**

Progressive web apps mimic a mobile app-like experience for customers. PWA is focused on improving the performance of web applications on mobile, which not only improves your customer experience and conversions but also earns SEO rankings. Rendering a mobile app-like experience, PWA eliminates the need to download your store’s mobile app or the cost of building a mobile app.

As a store operating on Magento, you can leverage PWA Studio, Magento’s SDK, to build progressive web apps.

## **Summary**

Speed matters. Period. The fact is your months-long development, and years-long marketing efforts will pay off only if your site is fast enough to deliver its content. In addition to giving a great first impression, a better site speed keeps customers coming back and can also be your differentiating factor among competitors.

Make Magento performance optimization your top priority. Follow the Magento site speed optimization techniques we’ve discussed above. Get help from an official Magento partner agency with hands-on experience in performance optimization.

As many of the strategies involve server optimization, choosing a partner with expertise in providing platform-specific server environments like Upsun can ensure optimal performance tailored to the unique needs of your Magento store.

### [Shopware PaaS performance guide for scalable stores | Upsun](https://upsun.com/blog/shopware-performance-guide/)

# The definitive guide to Shopware performance on Shopware PaaS

A recent performance study analyzing hundreds of real Shopware projects found a 10× difference in page load times between similar storefronts. Product search pages ranged from under 200ms to well over 2 seconds; same platform, same page types, vastly different results.

This massive gap is not about luck or the platform itself. Running a high-performing Shopware store requires intentional infrastructure decisions, careful configuration, and defined development practices. A single misconfigured plugin, an unbatched ERP sync, or debug logging left enabled in production can transform a fast storefront into an unusable one.

This guide shares practical lessons from months of load testing across seven infrastructure tiers. We tested scenarios handling 3,000 to 73,000 orders per day to identify what configurations deliver the best Shopware performance.

## Who this guide is for

If you're a developer, software architect, DevOps engineer, or product manager working with Shopware, this guide is written for you. We'll walk through the common performance challenges we've encountered across dozens of projects, what the testing data actually reveals, and how to optimize your Shopware deployment for real-world scalability.

## The performance problem

Two Shopware sites that appear identical can behave very differently under load. Here's what we experience repeatedly across Shopware projects:

-   **Plugins are often the weak link.** Third-party and custom extensions are often poorly optimized, difficult to debug, and challenging to support under load.
-   **Cache invalidation causes problems.** ERP imports or admin changes can trigger mass cache purges, creating backend spikes and latency bursts.
-   **Headless architectures expose caching limitations.** The Store API relies heavily on POST requests, which don't play well with HTTP caching tools like Fastly or Varnish.
-   **DevOps workflows are inconsistent.** Teams waste time reinventing deployment, monitoring, and staging processes instead of focusing on product development.

These issues aren't due to bad intentions—they stem from complexity. Shopware is modular and capable, but without discipline and the right tools, performance suffers.

## What makes Shopware PaaS different

Built on Upsun, Shopware PaaS provides enterprise-grade infrastructure with SLAs for scalability, high availability, and performance. It includes standardized developer workflows with Git-based environments, CI/CD, and rollback capabilities built in. You also get tools for diagnosis and performance tuning, including native support for Blackfire, as well as best-practice templates and architectural guidance.

## How Shopware really performs

A recent Shopware 6 performance benchmark by Tideways analyzed hundreds of real projects and found a **10× difference in Time-to-First-Byte (TTFB)** across similar page types. Product search pages ranged from under 200ms to well over 2 seconds, depending on the project.

This disparity reflects what we see in practice: the software isn't inherently slow, but it's highly sensitive to how it's used.

### Real example: Debug logging nearly broke a store

In late 2024, we received a support ticket about a Shopware storefront suffering severe slowness. Some pages took over 10 seconds to load, with extreme cases exceeding 3 minutes.

Using Blackfire's profiling capabilities, we quickly identified the root cause: the PayPal plugin was running with DEBUG-level logging enabled. Under heavy traffic, this overwhelmed the disk with write operations, causing I/O contention as processes queued to write their own logs. Once debug mode was disabled, response times recovered almost immediately.

This case illustrates a recurring theme: a small misconfiguration in a third-party extension can destabilize the entire stack.

### Common performance pitfalls

-   **ERP integrations that trigger cache invalidations:** Inventory and product updates, especially when unbatched, cause sweeping cache invalidations, resulting in backend load spikes and frontend latency.
-   **Excessive personalization:** Serving unique content, such as customer-specific pricing or postal code-based adjustments, reduces cache efficiency and increases infrastructure load.
-   **Lack of performance budget:** Teams deploy features or plugins without defining acceptable performance thresholds, leading to slow degradation over time.

## Cache first, then everything else

No matter how efficient your custom code is, nothing beats a fast cache. Whether at the edge (Fastly), on the application side (Symfony HTTP cache), or in the database/query layer (Redis, Doctrine metadata), caching is the primary strategy for sustainable performance.

Studies correlate every second of added load time with a drop in conversion rate. For Shopware stores competing in crowded retail markets, performance isn't just technical, it's commercial.

## Understanding infrastructure options

Shopware PaaS offers several infrastructure tiers:

### Grid plans (XL, 2XL, 4XL)

Shared-resource model where your project runs in isolated containers on VMs shared with other customers. Best suited for entry-level and small-to-medium projects, offering cost-effective pricing; however, performance predictability is limited under extreme load conditions.

### Dedicated grid hosts (DGH-16, DGH-32, DGH-64, DGH-128)

Container-based model, but on dedicated VMs. All resources are exclusive to your project, enabling burst capacity and consistent performance. All containers are co-located on the same host, eliminating inter-service network latency. DGH plans also provide significantly higher memory limits than standard Grid plans.

Best for mid-sized to high-traffic storefronts needing predictable CPU access.

### Dedicated plans (D-12, D-24, D-48, D-96, D-192)

Three fully dedicated VMs configured for high availability with MySQL in multimaster cluster configuration, Redis with multi-master setup, and redundant application containers. Fully dedicated compute, network, and storage with zero-downtime vertical scaling.

Best for production environments with high concurrency and uptime demands.

### Dedicated split clusters

Separates concerns explicitly: three core nodes handle backend services (DB, cache, queues) while three or more web nodes serve application traffic. Core nodes scale vertically; web nodes scale both vertically and horizontally for seamless dynamic auto-scaling.

Best for enterprise-grade setups with high frontend concurrency or traffic spikes.

## Best practices for high performance

### Infrastructure and runtime configuration

Don't leave memory allocation and CPU resources at defaults. Set memory usage expectations explicitly in `.upsun/config.yaml`, enabling the platform to optimize PHP-FPM concurrency settings accordingly.

Maintain CPU usage below 70% under load to preserve headroom during peak traffic events. Infrastructure tiers should be selected based on both average load and burst capacity, considering business seasonality.

### Caching strategy

HTTP caching, application-side caching (Symfony HTTP cache), and object caching (Redis) must work in concert. Where possible, content should be made cacheable by design—using GET rather than POST methods where appropriate, ensuring consistent cache headers, and avoiding patterns that lead to cache fragmentation.

Prewarm the Fastly cache of critical pages after deployments or content imports to ensure traffic isn't served cold.

Validate that the cache is functioning by inspecting HTTP response headers, particularly the X-Cache header. A HIT value indicates the response was served from cache; MISS suggests a cache bypass or expiration.

Manage cache invalidation responsibly. Unbatched product updates or poorly scheduled ERP synchronizations can result in widespread cache purges. Techniques such as soft purges and deferred purging intervals can help mitigate their impact.

### Advanced cache features

**ESI (Edge Side Includes)** (Shopware ≥ 6.6.10.0) lets developers split page rendering into independently cacheable fragments. This is ideal when only parts of a page need frequent updates.

**Soft purge** (Shopware ≥ 6.4.15.0) marks entries as stale but still serves them until refreshed. The first request triggers background regeneration, allowing users to receive functional content without backend spikes.

### Extension and Plugin Management

Performance regressions are most frequently traced to third-party or custom plugins. These may introduce costly hooks, register redundant services, or execute blocking logic during template rendering or checkout flows.

Performance-aware development must include plugin impact assessment—both at installation and during updates. Even unused plugins may consume resources. Routinely audit the full plugin stack and remove obsolete packages.

### Admin Configuration and Application Logic

Misconfiguration at the admin level can significantly impact performance. For example, configuring category pages to display too many products leads to inefficient query execution. Dynamic rule conditions and promotions must be designed with query complexity in mind.

Where possible, avoid relying on raw SQL-based search behavior. Shopware PaaS supports integration with scalable search engines, such as OpenSearch, which offload search logic from the database.

External API calls should never block storefront responses. APIs are inherently brittle—slowness or outages can cascade across your entire system. External communications should be handled asynchronously whenever possible.

Logging levels must be adjusted appropriately for production environments. Enabling verbose or debug-level logs in live storefronts can overwhelm disk I/O and cause delays in application responses.

### Performance as a discipline

Successful Shopware implementations have a defined **performance budget**: measurable targets for TTFB thresholds, acceptable CPU usage under peak load, memory constraints, and failure rate ceilings. These metrics should guide development and be validated continuously.

Performance expectations must also be reflected in the development lifecycle: Git-based CI/CD workflows, environment consistency (dev, staging, production), and continuous observability.

## Load testing methodology

We used Grafana K6 as the load testing framework, building on Shopware-specific K6 scenarios that include four key traffic patterns:

-   **browse\_only:** Simulates casual users or bots (homepage visits, search, category browsing, product views)
-   **browse\_and\_buy:** Emulates a full customer journey (browsing, account creation, cart operations, checkout)
-   **logged\_in\_fast\_buy:** Models repeat customers (quick login and direct checkout)
-   **api\_import:** Represents system integrations (product imports, stock updates, price changes)

We tuned tests to mirror production behavior by using a fixed dataset and codebase across all tests, maintaining a consistent cache state with Crawlee to prewarm Fastly's HTTP cache, and resetting the database before each run.

We adjusted virtual users (VUs) and pauses between actions to simulate natural usage rather than raw concurrency. Without these pauses, smaller plans are saturated almost instantly, producing stress test results rather than load test results.

### Target metrics

We calibrated each test to align with:

-   Conversion rate of ~3% (visitors to buyers)
-   API requests share between 5%–10% of total traffic
-   Response time target: p95 TTFB under 600ms
-   CPU usage ceiling: kept near but below 70%
-   Error rate: under 0.05% failed requests

Tests ran for 5 minutes per configuration, repeated across six plan types.

## Performance results

Here's what the testing revealed:

  
**Key Observations**

-   **Performance scales predictably with resources.** Even modest plans, like XL, were capable of processing over 3,000 orders/day under optimal conditions.
-   **p95 response time held steady.** p95 TTFB remained under or near the 600ms target across all plans. However, to maintain this objective, we had to cap API import VUs at a maximum of 5. Going over five increased TTFB and limited RPS, even on the biggest plans.
-   **API load is expensive.** API requests, especially those that create or update products, invalidate multiple cache layers and stress both the database and Fastly edge. Even at just 5–10% of total traffic, they account for a disproportionate share of resource usage.
-   **Low failure rates across all tiers.** All plans maintained failure rates below 0.05%, demonstrating Shopware PaaS's resilience under consistent load.

## Using Blackfire to identify bottlenecks

Shopware PaaS includes Blackfire by default, giving you powerful tools to profile, observe, and continuously optimize your storefronts.

### Why profiling matters

Profiling helps answer questions like:

-   Why does this category page cause the CPU to spike?
-   What's behind this sudden I/O contention?
-   Is my ERP update logic inefficient?
-   Why does this plugin kill performance in staging but not locally?

### How to profile a Shopware page

You can initiate a profile from the Blackfire browser extension, the Blackfire CLI in staging or development, or your CI pipeline for automated test-based profiling.

Each profile provides a flame graph of the full request lifecycle, including execution time per function or service, I/O and memory usage hotspots, and time spent in templates, Doctrine queries, Redis calls, and plugins.

### Shopware-specific insights

Blackfire offers Shopware-specific instrumentation that exposes performance metrics aligned with the platform's architecture, including precise timings for ProductListingRoute, template rendering performance, and plugin listener overhead.

### Common bottlenecks

-   **Plugins with inefficient hooks:** Profiling reveals plugins that hook into every request and perform expensive logic, such as redundant database lookups or external API calls.
-   **Overloaded product listings:** Pages that render too many products or lack pagination trigger massive SQL queries and costly rendering.
-   **Unbatched ERP updates:** Frequent product updates without batching or delay saturate I/O, invalidate caches, and block PHP workers.
-   **Verbose logging in production:** As seen in the PayPal debug case, this can overwhelm disk I/O and cause delays in responses.

### Real-world example: analytics extension

Three years ago, a Shopware PaaS pilot customer experienced significant performance degradation, which occasionally resulted in downtime lasting several minutes and occurred multiple times a month. Using Blackfire enabled the immediate detection of a Statistics module executing exceptionally large queries, which effectively locked the MySQL database for durations of up to 16 minutes.

Blackfire facilitated rapid identification of the root cause within minutes, converting prolonged speculative analyses into swift diagnoses.

## Lessons from the field

### Configuration must be intentional

Default or ill-considered configuration choices are one of the most common sources of performance degradation. Category pages set to display too many products, logging levels left at debug in production, or pagination settings left in the default state all contribute to poor performance.

Projects that perform well exhibit intentionality in their setup: pagination, logging verbosity, cache invalidation behavior, and plugin configurations are explicitly tuned.

### Plugin usage requires vigilance

Third-party and custom plugins frequently account for the majority of runtime overhead in poorly performing storefronts. A plugin may introduce hooks that trigger on every request, perform redundant database operations, or interfere with cacheability.

High-performing projects treat plugins as runtime components to be evaluated and, where necessary, replaced or disabled; not just installed.

### Caching is central but often undervalued.

Caching success depends on deliberate implementation: using GET methods over POST, proper cache headers, and URL structures that avoid unnecessary variation.

In many cases, performance issues stem not from an absence of caching, but from cache invalidation processes triggered by unbatched ERP updates or administrative changes. Projects that maintain performance under load manage invalidation carefully and employ soft purge strategies.

### Performance testing must be realistic

Effective testing requires representative traffic blends, realistic conversion rates, appropriate delays between actions, and accurate replication of backend behaviors. This includes your CDN; while including Fastly in load tests may seem controversial, it's essential since Fastly is a key component of the runtime environment.

Testing that omits API imports, bot traffic, or concurrent checkout processes may fail to reveal scalability bottlenecks until they manifest in production.

### Operational discipline drives resilience

Successful Shopware projects are characterized by operational discipline, including CI/CD pipelines, staging environments that mirror production, monitoring and alerting, and well-tested rollback procedures.

This extends to campaign preparation; peak traffic events are treated as technical milestones. High-performing teams rehearse traffic scenarios in advance, prewarm caches, monitor system metrics throughout, and ensure rollback readiness.

## Pre-launch readiness checklist

Before going live or launching a major campaign, confirm:

-   \[ \] Product and category listings are paginated and optimized for efficient SQL queries.
-   \[ \] Plugin and extension performance has been profiled; unnecessary plugins are disabled.
-   \[ \] Logging levels are correctly set for production (no debug logs unless needed temporarily)
-   \[ \] ERP and external synchronizations are batched and scheduled outside peak hours.
-   \[ \] API-driven cache invalidations are delayed, batched, or throttled (Shopware ≥ 6.7)
-   \[ \] Cache prewarming is in place for key landing pages and navigation flows.
-   \[ \] HTTP cache is working: X-Cache headers return HIT for expected routes.
-   \[ \] The volume of cache invalidations per day remains within expected bounds.
-   \[ \] Infrastructure capacity has been sized for a realistic peak load (CPU usage stays below ~70%)
-   \[ \] Load tests have been run using realistic traffic mixes and session behaviors.
-   \[ \] CI/CD pipelines are tested and produce deterministic builds.
-   \[ \] Monitoring and alerting are enabled for application, system, and business-critical metrics.
-   \[ \] Deployment logs are reviewed for uncaught exceptions or failed hooks.
-   \[ \] 3rd-party integrations are monitored for availability and latency.
-   \[ \] Security headers and HTTPS enforcement are tested.
-   \[ \] SEO-critical pages are crawlable and performant under PageSpeed Insights.

## Conclusion

The results of our testing and field experience demonstrate that Shopware can perform exceptionally well, but only when supported by deliberate infrastructure decisions, thoughtful architectural patterns, and disciplined operational practices.

**The most consistent lesson:** Shopware performance is a shared, continuous responsibility. It's shaped not only by infrastructure size or application code, but by how thoughtfully a project is configured, extended, observed, and operated.

Real-world deployments prove this. A misconfigured payment plugin logging at the debug level in one project generated excessive disk I/O, severely slowing the site. Another experienced regular freezes due to an analytics module issuing long-running SQL queries that locked the database. One customer generated over 500 million cache invalidations per day through unbatched ERP updates, resulting in the cache remaining perpetually cold.

In contrast, projects that achieved stable, fast response times shared certain habits: they employed tools like Blackfire to locate bottlenecks, used deferred or soft purging to manage cache invalidation intelligently, and maintained close alignment between ERP updates and cache regeneration strategies. They didn't wait for performance to degrade; they designed for it.

### What you can do next

-   Review your caching strategy
-   Audit your plugin stack
-   Validate configuration
-   Replicate traffic
-   Standardize deployment
-   Use environment variables for configuration
-   Protect your infrastructure (ask about Fastly Next-Generation WAF)
-   Centralize your logs and audit them

Performance excellence isn't reserved for large teams or enterprise budgets; it's the result of consistently applying engineering discipline.

## Recommended tools and resources

-   Blackfire documentation: https://docs.blackfire.io
-   Shopware PaaS Blackfire integration: https://developer.shopware.com/docs/products/paas/blackfire.html
-   Grafana K6 (Open Source): https://k6.io
-   Shopware K6 scenario repository: https://github.com/shopware/k6-shopware
-   Crawlee (for cache prewarming): https://crawlee.dev
-   PHP-FPM runtime tuning (Upsun): https://fixed.docs.upsun.com/languages/php/fpm.html

### [Build AI-augmented apps with enterprise security | Upsun](https://upsun.com/blog/build-ai-augmented-applications-with-enterprise-grade-security/)

# Discover how to build AI-augmented applications with enterprise-grade security

IT leaders want AI that moves the needle without blowing up risk, cost, or changing control. Your teams need a path to productize AI features on top of existing apps, connect safely to external models, and satisfy audit requirements without slowing delivery. Those are the core buying criteria we hear from IT middle management: buy over build, predictable outcomes, and a strong compliance posture.

Upsun is a cloud application platform that pairs Git-driven configuration with production-grade preview environments and integrated guardrails, allowing you to deliver AI features quickly while maintaining control. It supports AI-augmented applications and agent workflows, providing AI tools with structured, real-time context through RAG capabilities.

## What you can build on Upsun today

-   **AI-augmented applications** with your choice of external model APIs. Upsun supports integration with any LLM service that provides an HTTP API, including OpenAI, Mistral, Claude, Gemini, or DeepSeek.¹
-   **RAG architecture** to ground model output in your domain data, improving accuracy and reducing hallucinations.² ³ Upsun supports a wide range of vector databases to embed and store your content.
-   **MCP-powered development** where Copilot, Claude, and other assistants query MCP servers you host on Upsun to pull live configuration or data, then propose changes aligned to your platform standards.⁴ ⁵ ⁶

**Important note on compute:** Upsun does not provide GPUs by default. You leverage your application and data on Upsun while connecting to external model endpoints or GPU-augmented servers for training or inference via standard HTTP APIs. See How to deploy AI.

## Enterprise-grade security without the slowdown

Security is table stakes. The average global cost of a data breach was USD 4.88 million in 2024, and IBM’s 2025 report shows a decline to USD 4.44 million for organizations accelerating detection and containment with AI.⁷ ⁸ That is still expensive, so guardrails matter.

Here is how Upsun helps:

-   **Git-driven YAML config.** Your infrastructure, services, and routes live in a single, reviewable `config.yaml`, versioned alongside code. See 'Configure your project and YAML structure' in the documentation. ¹⁰ ¹¹
-   **Automatic preview environments per Git branch.** Each branch gets a live, production-grade environment that can inherit data and services from the parent, so changes are validated against realistic conditions before merging. ¹² ¹³
-   **Instant data cloning with sanitization.** Clone data down for tests while removing PII using built-in sanitization workflows for MariaDB and PostgreSQL. ¹⁴ ¹⁵
-   **Access controls and MFA.** Enforce multifactor authentication across your org and manage least-privilege access per project through the CLI and Console. ¹⁶ ¹⁷
-   **Observability and APM.** Integrated profiling and application metrics enable you to measure performance at every stage of the lifecycle. ¹⁸ ¹⁹
-   **Compliance-ready posture.** Refer to the Security and Compliance documentation and Trust Center references for certifications, including SOC 2, PCI DSS Level 1, and ISO 27001.²⁰ ²¹

These guardrails align with recognized frameworks. NIST’s AI Risk Management Framework emphasizes governance, measurement, and operational controls across the AI lifecycle, while the EU AI Act begins phased obligations between 2025 and 2026.²² ²³

## Reference architecture: secure RAG and MCP on Upsun

This example shows a minimal setup that connects an API service to an external model endpoint, provisions a managed Postgres database for your embeddings store, and runs an optional MCP server that developer tools can query.

```shell-session
.upsun/config.yaml

applications:

  api:

    type: "python:3.11"

    relationships:

      db: "postgresql:postgres"

    variables:

      env:

        MODEL_BASE_URL: "https://api.openai.com"

        OPENAI_API_KEY: "@@OPENAI_API_KEY"   # stored as a secret variable

    web:

      commands:

        start: "uvicorn app:app --host 0.0.0.0 --port $PORT"

 

  mcp:

    type: "nodejs:18"

    web:

      commands:

        start: "node server.js"              # your MCP server for code assistants

 

services:

  postgresql:

    type: "postgresql:15"

 

routes:

  "https://{default}/":

    type: upstream

    upstream: "api:http"
```

-   Learn how to configure projects and routes. ¹⁰ ²⁴
-   Host AI agents and MCP servers on Upsun. ²⁵ ²⁶
-   Connect to any external LLM over HTTP. ²⁷

**Data handling best practices**

-   Use preview environments tied to feature branches and clone data selectively for test realism. ¹² ¹³
-   Apply sanitization jobs so no reviewer or agent sees raw PII. ¹⁴ ¹⁵
-   Enforce MFA at the organization level and use least-privilege roles for automation tokens. ¹⁶ ¹⁷
-   Instrument your services to capture metrics, traces, and profiles to detect regressions early. ¹⁸ ¹⁹

## Why this approach converts pilots into production

-   **Speed and quality.** Git-native config and per-branch previews shorten feedback loops and reduce the “works on my machine” risk. ¹² ¹³
-   **Consistency at scale.** One YAML and a predictable platform means you codify best practices once for every team.¹¹
-   **Reduced toil.** Managed services, automated cloning, and integrated observability cut manual glue work. ¹⁸ ¹⁹
-   **Predictable cost and compliance.** Upsun centralizes controls and supports enterprise certifications, helping you meet obligations while keeping focus on feature delivery. ²⁰ ²¹

## Proof points you can take to the board

-   Generative AI adoption is real: 65 percent of organizations were already using gen AI regularly in early 2024.²
-   RAG improves robustness by grounding outputs in current, relevant data and is the dominant pattern for enterprise AI apps.³
-   The EU AI Act is now in effect, with its obligations phasing in from 2025.²³
-   Breach costs remain material even as detection improves, reinforcing the need for strong guardrails when connecting to external AI services.⁷ ⁸

## Where to go next

-   Explore **Security and compliance** in the docs. ²⁰
-   Review **Preview environments** and **data cloning** tutorials. ²⁸
-   Try **RAG** **on Upsun** with a guided example. ²⁹ 

**AI-augmented applications** and **enterprise security** are not at odds. Upsun gives your teams the building blocks to connect to external models safely, validate changes against production-like data, and ship with confidence.

## Sources

1.  How to deploy AI (Upsun Docs)
2.  The state of AI in early 2024 (McKinsey)
3.  Retrieval-Augmented Generation for AI-Generated Content: A Survey (arXiv, 2024)
4.  MCP specification (Modelcontextprotocol)
5.  Use MCP servers in VS Code (Microsoft)
6.  Host MCP servers on Upsun (Upsun Docs)
7.  IBM newsroom: 2024 average breach cost USD 4.88M
8.  IBM Think: 2025 breach cost declined to USD 4.44M
9.  Security and compliance (Upsun Docs)
10.  Configure your project (Upsun Docs)
11.  YAML structure (Upsun Docs)
12.  Environments tied to Git branches (Upsun Docs)
13.  Clone data from parent on create (Upsun Docs)
14.  Sanitize databases overview (Upsun Docs)
15.  Sanitize Postgres and MariaDB examples (Upsun Docs)
16.  Enforce MFA announcement (Upsun Blog) 
17.  Multifactor Authentication (Upsun Docs) 
18.  Increase observability (Upsun Docs) 
19.  Blackfire for PHP and Python (Upsun Docs) 
20.  Security and compliance statement with Trust Center link (Upsun Docs) 
21.  Automate compliance claims (Upsun)
22.  NIST AI Risk Management Framework (overview) 
23.  EU Parliament brief: AI Act implementation timeline (2025) 
24.  Define routes (Upsun Docs)
25.  Host AI agents on Upsun (Upsun Docs) 
26.  Host MCP servers on Upsun (Upsun Docs) 
27.  Upsun AI overview: integrate any LLM over HTTP (Upsun Docs) 
28.  Preview environments deep dive (Upsun Developer Center) 
29.  Experiment with Chainlit and RAG on Upsun (Upsun Developer Center)

### [6 Best Railway Alternatives in 2026 Compared | Upsun](https://upsun.com/blog/railway-alternatives/)

# Best Railway alternatives in 2026

Railway is one of the easiest ways to ship an app. You connect a Git repository, push your code, and a few minutes later, you have a running service with a managed database next to it. For side projects and early-stage products, that speed is hard to beat.

But teams outgrow Railway. As an app moves toward serious production use, three limits tend to show up: Railway runs on a small number of regions, its lower tiers are built for a single developer, and usage-based costs can be hard to predict as traffic grows. Reliability also matters more once real users depend on you, and Railway reported networking issues in early 2026 that affected workload availability.

## **Key takeaways**

-   This guide compares Platform-as-a-Service (PaaS) and developer platforms that teams move to when they outgrow Railway, as of 2026.
-   Upsun is the strongest fit for teams running production-grade applications that need multi-cloud deployment, environment parity with live production data, and compliance certifications applied across all environments.
-   Render is the strongest alternative for teams that want predictable, plan-based pricing. Northflank is the strongest for Kubernetes-native teams that need BYOC without an enterprise contract.    
     

## **Why teams look for a Railway alternative**

These are the most common reasons teams move off Railway in 2026.

-   **No multi-cloud or BYOC below Enterprise.** Railway runs your app on Railway-managed infrastructure. Deploying into your own AWS, GCP, or Azure account requires an Enterprise contract. Regulated and data-sovereignty-sensitive teams need this earlier.
-   **Preview environments and environment parity.** Whether the platform creates an isolated environment for every branch, and whether that environment can include real production data, configuration, and code. Cloning live data is what eliminates staging drift.
-   **Pricing model.** Resource-based (CPU, RAM, storage), plan-based (fixed instance prices), or usage-based (pay-as-you-go). Each has different forecastability tradeoffs.
-   **Limited observability.** Logs and deploy history are basic. Teams running production workloads want metrics, profiling, and clear deploy visibility out of the box.
-   **No Kubernetes, Helm, or Terraform support.** Railway builds with Nixpacks and Docker. Teams with existing Kubernetes manifests or infrastructure-as-code cannot reuse them.
-   **Workarounds for background jobs.** Railway has no first-class background workers. The accepted pattern is to run a second service manually inside the project.

## **Quick look: Railway alternatives in 2026**

## **The best Railway alternatives in 2026**

#### **1\. Upsun: for multi-cloud teams and production-grade environments**

Upsun is a multi-cloud application platform that runs apps across AWS, Azure, IBM Cloud, Google Cloud, and OVHcloud from a single Git-driven workflow, and every branch produces a preview environment that clones the production environment, including live data, in under one minute. Pricing is resource-based, so teams pay for the CPU, RAM, and storage they provision, with commitment options for predictable spend.

**Key capabilities:**

-   Multi-cloud deployment across AWS, GCP, Azure, OVHcloud, and IBM Cloud.
-   Git-push deployment with automatic preview environments per branch.
-   Managed services catalog: PostgreSQL, MySQL, Redis, Elasticsearch, OpenSearch, RabbitMQ, and Kafka.
-   10 supported runtimes, including PHP, Python, Node.js, Java, Go, Ruby, and .NET.
-   Compliance with ISO 27001, SOC 2, PCI DSS, TX-RAMP, PCI DSS Level 1 HIPAA, and GDPR.    
     

**Choose Upsun if** you are outgrowing a single cloud host, need preview environments with real production data, or work in a regulated industry that requires compliance across every environment.

#### **2\. Render:  for predictable, plan-based full-stack hosting**

Render is the closest "it just works" successor to Heroku. It deploys from Git with no configuration files for common stacks, and it supports web services, static sites, background workers, cron jobs, and managed Postgres and Redis as first-class service types. Preview environments are built in.

The main contrast with Railway is the billing model. Render is plan-based, so you pick an instance size and pay a fixed, forecastable monthly price. Paid web services start at $7 per month, Standard at $25, and per-seat fees were removed in 2026. The free tier is generous for static sites, but free web services spin down after 15 minutes of idle time, and free Postgres is deleted after 30 days. There is no BYOC, multi-cloud, Kubernetes, or GPU.

**Key capabilities:**

-   Git-based deployment with built-in preview environments
-   First-class background workers and cron jobs
-   Managed Postgres and Redis
-   Free tier covering static site hosting

**Choose Render if** you want a simple, budget-friendly platform for full-stack apps with native background workers and managed databases, and you do not need to run in your own cloud.

#### **3\. Fly.io:  for globally distributed, low-latency apps**

Fly.io runs full-stack apps close to your users across many regions, and it assigns static IPv4 and IPv6 addresses by default. Billing is usage-based with no credit-based shutdown, so apps stay live as long as you pay for what they use. It supports persistent volumes and scheduled jobs.

Fly is CLI-first. That gives you precise control over deployment and scaling, but it has a steeper learning curve than Railway's dashboard-driven flow. Secret management is basic, and more advanced workflows can require manual setup.

**Key capabilities:**

-   Multi-region deployment across Fly-managed regions
-   Static IPv4 and IPv6 addresses by default
-   Persistent volumes and scheduled jobs
-   CLI-driven configuration

**Choose Fly.io if** low latency, multi-region deployment, or global reach is your priority, and you are comfortable managing builds and configuration from the command line.

#### **4\. Heroku:  for legacy apps and a mature add-on ecosystem**

Heroku is the platform that defined the modern PaaS category. It still works well, with buildpacks, a large add-on marketplace, CLI-driven workflows, and worker dynos for background jobs. It is a dependable home for established, Postgres-backed applications.

The tradeoffs are cost and momentum. Heroku no longer offers a free tier, pricing runs higher than newer platforms, and the developer experience has aged. Most new projects start on Railway, Render, or similar platforms instead. There is no BYOC or multi-cloud.

**Key capabilities:**

-   Buildpack-based deployment with no configuration for common stacks
-   Worker dynos as first-class background processes
-   Heroku Postgres and a broad third-party add-on marketplace
-   Review apps for pull-request preview environments

**Choose Heroku if** you maintain a legacy app that already relies on its add-on ecosystem, or you value a mature, well-documented platform over the lowest price.

#### **5\. DigitalOcean App Platform: for predictable pricing in the DO ecosystem**

DigitalOcean App Platform offers simple Git-based deploys and flat, predictable pricing, with free static site hosting. It is the natural choice for teams already using DigitalOcean droplets, databases, or networking, because everything sits in one account and one bill.

The limits are the scope. It has fewer regions and less sophisticated autoscaling than Railway or Fly.io, and it does not support BYOC. Background worker support is present but more limited than on Render or Heroku.

**Key capabilities:**

-   Git-based deployment with managed builds
-   Flat-rate pricing model with a free static site tier
-   Integration with DigitalOcean Managed Databases and networking
-   Background worker support

**Choose DigitalOcean App Platform if** you are already using DigitalOcean infrastructure and want a managed application layer on top.

#### **6\. Northflank: for Kubernetes-native teams that want BYOC**

Northflank is built for teams that have outgrown shared PaaS and want production-grade control. It supports BYOC across AWS, GCP, and Azure, Kubernetes and Helm workflows, custom Docker builds, persistent storage, first-class background workers, and detailed observability. It does not pause apps when credits run out, and it publishes a 99.99% historical uptime figure, backed by an SLA for enterprise customers.

The tradeoff is complexity. Northflank exposes more infrastructure surface than Railway, which is the point for platform teams, but more than a solo developer needs.

**Key capabilities:**

-   BYOC into AWS, GCP, or Azure accounts.
-   Kubernetes and Helm workflow support.
-   Custom Docker builds and persistent storage.
-   First-class background workers and detailed observability.

**Choose Northflank if** you need Kubernetes-native deployment, BYOC without an enterprise contract, and production controls like DORA metrics and persistent storage.

## **How to choose the right Railway alternative**

Use these criteria to match a platform to your needs.

1.  **Pricing model.** PaaS platforms bill in three patterns: usage-based (pay for what you consume, metered per second or per resource), plan-based (a fixed instance size at a fixed monthly price), and resource-based (you provision CPU, RAM, and storage, and pay for the allocation). Usage-based has the lowest floor for small apps, but is the hardest to forecast at scale. Plan-based is the simplest to budget. Resource-based gives more control over the cost-to-performance curve as workloads grow.
2.  **Where your app runs.** Platforms fall into three groups. Hosted platforms run your application on the provider's own infrastructure. Multi-cloud platforms manage the runtime but let you choose the underlying cloud, such as AWS, GCP, Azure, OVHcloud, or IBM Cloud. Bring-your-own-cloud (BYOC) platforms install into a cloud account you own. The latter two matter for data residency, regulatory scope, and avoiding lock-in.
3.  **Preview environments.** Confirm whether the platform creates an isolated environment for each branch or pull request, and whether that environment can include real configuration and data. Cloning production data is what eliminates environment drift.
4.  **Databases and background work.** Check for managed databases, caches, search engines, message queues, and background workers are offered as first-class managed services rather than manual workarounds.
5.  **Observability.** Look for logs, metrics, profiling, and deploy history included by default, not bolted on.
6.  **Compliance.** For regulated industries, verify certifications such as ISO 27001, SOC 2, PCI, and HIPAA, and confirm they apply across all environments, not just production.
7.  **Exit path.** Open standards, container exports, or BYOC make it easier to leave without re-architecting.

## **Frequently Asked Questions (FAQs)**

**What is the best Railway alternative in 2026?** 

There is no single best alternative, because teams leave Railway for different reasons. Upsun is the strongest choice for multi-cloud teams and regulated industries that need production-data preview environments and built-in compliance. Render is the strongest choice for full-stack apps that want predictable, plan-based pricing.

**Can I migrate from Railway to Upsun?**

Yes. Upsun runs containerized applications across 10 supported runtimes, including PHP, Python, Node.js, Java, Go, Ruby, and .NET, and applications are described in a single YAML configuration file. Most Railway applications can be ported by writing the equivalent Upsun configuration and connecting the Git repository. The exact effort depends on the number of services and the managed services in use.

**Which Railway alternatives support multi-cloud or bring-your-own-cloud (BYOC)?** 

Upsun supports multi-cloud deployment across AWS, GCP, Azure, OVHcloud, and IBM Cloud as a managed multi-cloud PaaS. Northflank supports BYOC into your own AWS, GCP, or Azure account. Render, Fly.io, Heroku, and DigitalOcean App Platform run on their own managed infrastructure and do not offer multi-cloud or BYOC.

**Which Railway alternative is best for preview environments?**

 Upsun creates a production-parity clone for every branch that includes live data, configuration, and code, which removes environment drift. Render, Heroku, and Northflank offer preview or review environments, but they do not clone production data automatically in the same way.

**Which Railway alternative has the most predictable pricing?**

 Render and DigitalOcean App Platform use plan-based pricing, where you pick an instance size and pay a fixed monthly rate, which is the easiest to forecast

**Which Railway alternative is best for regulated industries?**

 Upsun is built for regulated teams, with ISO/IEC 27001, SOC 2 Type 2, PCI DSS Level 1, HIPAA, and TX-RAMP applied across all environments, plus the option to run in your own cloud for data residency.

### [PHP LTS security fixes now available | Upsun](https://upsun.com/blog/php-lts-security-fixes/)

# PHP LTS security fixes have arrived

That’s right - thanks to a Freexian subscription, end-of-life versions of PHP are getting extended support!

## **The lifespan of a PHP version**

A PHP version is officially supported for a total of 3 years, with two distinct periods within those 3 years, which are:

-   2 years of active support
-   1 year of security fixes

After that last year of security fixes, the version is considered to be “end of life” and will no longer receive any bug fixes or security fixes.

With this in mind, we always encourage our Upsun users to use a supported version of PHP to ensure the best performance and security. And the good news is that with our platform, it’s simple to upgrade to the latest version of PHP in just a few steps: branch, update, deploy, test, and merge. Check out this blog where we explain how to do it.

## **What if I can’t upgrade to the latest PHP versions?**

We get it. Being able to upgrade to the latest version of PHP every time a new release is made available isn’t always easy or possible. Projects often involve challenges such as:

-   Custom code that needs to be upgraded to the latest version.
-   Unsupported plugins that may have been discontinued in the latest versions.
-   A long life cycle with huge QA steps.

That’s why, even with all the tooling and good intentions, many “end of life” versions of PHP are still used widely on production applications. So, what’s the alternative?

## **Enhancing application security with long-term PHP support**

Every year, when a PHP version reaches its ‘end of life’ and we receive a lot of enquiries from our customers and partners regarding their application security. Many of them do not want to migrate to a new version of PHP for similar reasons to those mentioned above, but want to know if their applications would still be secure. So we started looking for a solution to provide long-term support for PHP.

The good news is that we found a solution and implemented it. End-of-life PHP will continue to receive security fixes for our users. However, even with our PHP legacy and all of our skilled engineers, we are not PHP maintainers. That’s why we got in touch with Freexian.

Freexian is a service company specializing in Free Software and, in particular, Debian, who offer long-term support for Debian and PHP. Describing their security support as:

Upstream security and stability fixes, as applied to PHP stable releases, are backported to the Freexian LTS-supported PHP releases. This is essentially the same support that upstream PHP provides for their upstream-supported releases, but continued long after upstream PHP stopped supporting them.

We review and triage security issues regularly and apply patches according to impact and compatibility with the older PHP releases. This is done on a best-effort basis. Where an issue is not fixable, mitigations may be recommended.

Many security updates come with regression tests to ensure that they are fixed. These are usually backported with the patch, ensuring their correctness and avoiding future regression.

This is the same level of security support as is provided for PHP packages within regular Debian stable releases, by the same team.

## **How do I get this PHP LTS?**

PHP versions are now covered with LTS support without extra charge. Your projects will get the last version when the image is updated, which happens when a project is redeployed or when the SSL certificate is renewed.

To make sure that your projects use an LTS version, you can force a redeploy by using the following CLI command:

```shell-session
Upsun redeploy
```

Alternatively, in Console, you can:

-   Select the project and the environment
-   Click on the ‘More’ menu and select ‘Redeploy’

### **Which PHP versions are supported?**

At the time of writing this blog post, versions retroactively affected by this extended support are PHP 8.3 and 8.4.

The team is actively working on providing the same support on 7.2, 7.4, and 8.0 versions.

### **Stay ahead with PHP upgrades!**

We do our best to extend the support for PHP versions, but at the end of the day, older versions will disappear at some point, as it’s possible that someone discovers a security issue that just can’t be fixed and forces us to retire a version.

That’s why upgrading your PHP version, even from one minor version to another minor version, is always a good move and our top tip when it comes to optimizing your performance and security.

### [Your preview environment is lying to you | Upsun](https://upsun.com/blog/your-preview-environment-is-lying-to-you/)

# Your preview environment is lying to you

A customer asked me once, in the middle of a demo, "what is lorem ipsum?"

That is the moment. The preview URL loaded. Every page rendered. The merge was clean, the build was green, the tests passed. And a customer I was trying to sell to was reading placeholder copy out loud on a shared screen.

I've thought about that moment a lot. Not for the embarrassment, though I earned it. For what it told me about what a preview environment actually is, which is not what most of us think it is.

## The preview problem that isn't about code

Most conversations about preview environments stop at "does the build work." Every frontend-forward platform in the last five years has solved that cleanly. Push a branch, get a URL, share the URL, merge or don't. The code path is fine.

The data path is the lie.

In the platforms most of us use, the application gets branched on every push but the database does not. The preview URL points at staging data, or dev seed data, or a fixture someone's coworker wrote during their first week and nobody has touched since. The UI layer behaves correctly, rendering whatever happens to be in the table. The reviewer, looking at a preview, has no way to know whether the feature works against production-shaped data, because the preview has never seen production-shaped data.

The result is a class of bug that survives review and dies in front of a customer. The "what is lorem ipsum" moment is one of the nicer versions. The worse ones involve queries that were fine against a hundred rows and fall over against a million, UI states that only exist once a user has three years of history, and integrations whose credentials are valid in staging and wrong in production.

## Why the mismatch is structural, not accidental

A preview environment with fixture data is a model home. The couches look great. The light switches all work. Nobody has ever lived there, which means you can't tell whether the plumbing holds up once a family moves in.

The part nobody tells you: this isn't a bug the industry is ignoring. It's a problem teams have chosen to solve around rather than through.

You can wire up a managed database that supports branching per preview. You can write a fixture generator. You can copy anonymized production snapshots into staging weekly. Plenty of teams do, and most of them work, most of the time.

Each one is a configuration that lives outside the application. Each one is a second system, with its own expiry, its own access grant, its own cost model, and its own way to drift out of sync. Each one is time your team is focusing on infrastructure instead of features. 

The frontend-first platforms that popularized Git-push previews built that workflow around the code. The rest of the preview, the services and the data, lives in whatever integration the team wired up, usually through a marketplace or a GitHub Action someone bolted on last quarter.

A reviewer, sitting in a pull request, has to ask a question that shouldn't be their job: is the database on this preview the actual shape, or is it whatever the fixture gave me?

## What a preview environment could mean instead

I run a handful of side projects. Small enough that any platform decision is a judgment call about what my future self will thank me for. The one place I never cut is preview parity. Every time I have, my future self has become the customer staring at lorem ipsum on my own demo, which is a humbling way to review your own pull requests.

On Upsun, every Git branch gets a byte-for-byte clone of production. Application, services, data. It takes about a minute. The databases running in your preview are the databases running in production, with the same rows, the same indices, the same foreign keys, the same everything. If you don't want reviewers looking at customer data, you define a sanitization hook in your `.upsun/config.yaml` that strips PII on deploy, and reviewers get realistic-shaped but non-sensitive data.

This isn't a marketplace integration you configure per project. It's how environments work.

The term for this is byte-for-byte environment cloning. Not the catchiest phrase. What it actually does is let a reviewer answer "does this work?" without guessing.

## What changes in the day-to-day

I talk to customers every week and I ship code on side projects with the same workflow. Two different jobs, same pattern from different angles.

From the customer side, the preview stops being the place where bugs hide until the demo. Reviewers catch the query that won't scale. Product managers click through the feature and notice the empty-state language is wrong because they see real empty states. Sales engineers run the demo against the clone and nothing says lorem ipsum.

From the shipping side, the merge button starts to mean what it says. When I approve a pull request against a clone of production, I'm approving behavior against the actual data shape my users will hit. The class of "passed review, broke in prod" bugs gets smaller. Not zero. Smaller, and in a category you can reason about.

That's a small change in the workflow and a large change in the trust you have in your own pipeline.

## A question, and a confession

Pull up your last three production incidents. How many of them were visible in the preview environment where the change was reviewed? If the answer is none, and you're sure, your preview environment is doing its job. If the answer is "I don't know," the data path is probably the reason.

The customer who asked me what lorem ipsum was is still a customer. They were kind about it, the way people usually are when you've just caught yourself out in front of them. What they were actually asking, I think, is "why am I looking at something that isn't real?" That's the right question to ask any preview environment. Yours should be able to answer it without you squinting.

## Further reading

-   Upsun environments and cloning
-   Production clone in 45 seconds with full data and services

### [How cloud application platforms reduce tech debt for IT leaders](https://upsun.com/blog/cutting-tech-debt-cloud-platform/)

# Cutting tech debt at the source: how cloud application platforms put IT back on offense

For most Central IT leaders, tech debt isn't a surprise. It's the silent tax on every roadmap, every quarterly plan, every conversation about why things take so long. 

Modern cloud application platforms (true PaaS environments) give IT leaders a path to unwind years of accumulated complexity while simultaneously accelerating innovation. You no longer have to tolerate the tax.

### **What actually creates tech debt**

Tech debt rarely comes from one big bad decision. It builds up through operational reality mixed with well-intentioned shortcuts that seemed reasonable at the time. 

Legacy architectures weren't built to scale the way you need them to now. Systems designed for a different era end up patched and extended far beyond their intended lifespan, creating a foundation that gets more fragile with each new requirement.

You inherit siloed tools and one-off environments that made sense in isolation. Custom pipelines proliferate here, bespoke hosting arrangements there, and before long, you're running a zoo of disparate systems with no single source of truth. 

Under-resourced modernization efforts turn this into a compounding problem. When backlogs grow faster than headcount, those "temporary fixes" become permanent architecture. 

Slow release cycles make shipping updates feel risky and painful, which means people naturally defer work. That deferred work piles up and makes the next change even riskier. Teams respond by adopting their own tooling to move faster, and IT ends up holding the operational bag for systems they didn't choose and can't easily control.

### **Why tech debt stalls innovation and growth**

Central IT is supposed to be an enabler, but tech debt flips that script entirely. Instead of strategic execution, you're stuck keeping the lights on. 

Every new initiative becomes slower and costlier because you're building on brittle foundations, where you spend as much time avoiding breaking things as delivering actual value. Innovation gets gated by questions about whether your legacy stack can even handle what the business wants to do. The business is ready to move, but the platform isn't.

This creates a vicious cycle in which your capacity gets tied up in maintenance rather than growth. You find yourself resourcing operational firefighting rather than transformation work. 

Security posture suffers in the process because outdated infrastructure is more complex to patch, monitor, and govern at scale. The erosion happens across multiple dimensions at once: organizational agility drops, risk increases, and time-to-value stretches longer for every initiative you undertake.

### **How tech debt impacts the business**

This is where the CFO starts asking hard questions. Increased operating costs arise across multiple hosting providers, inconsistent tooling, and manual work that inflate your cost base in ways that are hard to justify. 

Slower execution across revenue-generating initiatives means everything takes longer to deliver, whether that's digital customer experiences or internal systems that support sales and operations.

The talent strategy problem runs deeper than most people realize. You become increasingly dependent on specialized skills for legacy systems, which handcuffs your hiring and retention efforts to yesterday's technology rather than tomorrow's capabilities. 

Reduced competitiveness follows naturally from this dynamic. Competitors operating on modern platforms can spin up new products faster and iterate more aggressively, while you're still figuring out how to deploy changes to systems built a decade ago safely. Tech debt stops being just an IT issue and becomes a fundamental business growth constraint.

### **How tech debt impacts the IT leader personally**

This part often goes under-acknowledged, but it matters. Your priorities get constantly hijacked. You're always reprioritizing around unexpected outages, aging systems, and unplanned work that wasn't on anyone's roadmap last quarter. 

Strategic credibility takes a hit when timelines slip because the underlying infrastructure is too fragile to support what you committed to delivering. IT takes the blame, even when the root cause is years of accumulated technical compromise.

Talent retention becomes harder because high performers don't want to spend their careers babysitting old systems. The pressure mounts from every direction at once. The business wants speed, security wants stability, finance wants cost control, and tech debt makes balancing these competing demands harder. 

Modernizing isn't really about architecture when you get down to it. It's about giving IT leaders the room to lead instead of constantly reacting to the constraints of systems that should have been retired years ago.

### **How a cloud application platform reduces tech debt**

A true cloud application platform (PaaS) addresses the root causes of tech debt rather than just treating symptoms. The difference comes down to how these platforms handle the application lifecycle and infrastructure management.

When you standardize and centralize the application lifecycle, you get consistent workflows for build, deploy, scale, and operate across your environment. Snowflake environments and bespoke deployments become exceptions rather than the norm. Operations become more predictable, governance gets cleaner, and variance drops across your entire estate.

Infrastructure maintenance is one of those areas where abstraction actually helps. A PaaS handles the grind of patching, scaling, OS upgrades, networking complexity, and compliance controls, so your teams can focus on applications rather than plumbing. 

The shift in how people spend their time is noticeable. More cycles go toward delivery, fewer toward keeping infrastructure running.

The incremental modernization path matters more than people often realize. PaaS platforms support polyglot environments and hybrid migration approaches, which means you can move applications at a pace that makes sense for your organization rather than being forced into a risky big-bang rewrite. 

You get to modernize without the disruption or massive one-time investment that traditionally comes with platform changes.

Security and governance benefit from unification. Standard policies, centralized auditing, automated compliance, role-based access, and built-in guardrails create a more consistent security posture without requiring more manual effort from your security team. The visibility alone changes how you think about risk.

Faster iteration becomes safer when deployment complexity drops and environments are properly isolated. Teams can move quickly without creating chaos. Consolidation, automation, and standardization work together to reduce operational costs over time, allowing budgets to shift from maintenance toward innovation.

## **The strategic takeaway**

A Cloud Application Platform isn't just another tool in the stack. It's more of an architectural reset that gives Central IT leaders leverage they haven't had in years. 

The shift is noticeable across multiple dimensions. You spend less time firefighting and more time building. Delivery timelines compress. Security posture strengthens. Operational overhead drops. 

Teams tend to be happier when they're working on meaningful problems instead of wrestling with infrastructure. Your relationship with the business improves when you can actually deliver on commitments without constant delays and exceptions.

Tech debt doesn't disappear on its own, and you can't simply work harder to eliminate it. The environment that creates tech debt has to change. A modern cloud application platform changes that environment.

### [How Shopware performs under load and how to improve it | Upsun](https://upsun.com/blog/shopware-performance-load-testing-guide/)

# What we learned from load testing Shopware at scale

_We ran real-world load tests across seven different infrastructure plans—from Grid to Dedicated Split—using realistic conversion rates, bot traffic blends, and ERP-driven API imports. The findings were clear: performance scales predictably with resources, but only if your code, cache, and configuration keep up. This blog post walks through key results, why API load is disproportionately expensive, and what metrics matter most._

How well does Shopware actually perform under load? This question comes up a lot, especially when teams are evaluating new infrastructure or preparing for traffic surges. So we decided to test it ourselves.

We ran structured, production-style load tests across seven different Shopware PaaS infrastructure plans, from entry-level Grid configurations to high-capacity Dedicated Split clusters. The goal was not to break the system, but to simulate real e-commerce usage under pressure: browsing, buying, and backend automation, all with realistic conversion rates and caching behaviour. Here’s what we found.

## **Real traffic is more complex than you think**

Many performance tests rely on synthetic scenarios, that is, single endpoints hammered at fixed rates. That’s not how real storefronts behave. Our test plan included:

-   Anonymous browsing (homepage, categories, search)
-   New customer journeys (browse, register, checkout)
-   Repeat customer purchases (login and fast-buy)
-   API-driven product imports (ERP simulation)

We also introduced realistic **conversion rates (~3%)**, **bot-to-user ratios**, and **caching behaviour**. Caches were prewarmed using automated crawlers to mirror real-world deployments.

## **Key findings from the load tests**

#### **1. Shopware scales predictably with resources**

As infrastructure plans increased in CPU and memory, Shopware handled more concurrent traffic while keeping response times low. Even modest plans performed well under tuned conditions. For example, a Dedicated Grid Host (DGH32) handled over 7,000 orders per day with sub-second p95 TTFB.

#### **2. The API is a hidden cost driver**

API traffic (such as product updates or ERP syncs) generated a disproportionate share of backend load. Even though it represented only 5–10% of total traffic, API requests were responsible for cache invalidations and spikes in CPU usage.

#### **3. Caching strategy makes or breaks performance**

Plans with prewarmed Fastly caches maintained consistent response times. Those tested without proper cache priming showed significant latency. Cache fragmentation and poorly structured endpoints led to MISS responses, which immediately degraded throughput.

#### **4. Infrastructure isn’t the bottleneck**

In almost every scenario where performance dropped, the issue traced back to code, configuration, or cache invalidation—not the underlying platform. For example, one plugin left in debug mode introduced disk I/O contention that slowed pages to a crawl.

## **A note on methodology**

We used Grafana K6 to simulate traffic and tracked metrics like:

-   p95 TTFB (Time to First Byte)
-   Peak requests per second (RPS)
-   CPU saturation
-   Error rate
-   Orders/hour and orders/day

Each test ran for 5 minutes with isolated, clean environments. Conversion logic and traffic shaping were applied to mirror real storefront behaviour as closely as possible.

Get the performance guide with the results of the rigorous load testing campaign on Shopware PaaS, a managed e-commerce platform built on Upsun and tailored specifically to run Shopware at scale.

### [Developer guide to building apps without infrastructure burden | Upsun](https://upsun.com/blog/developer-guide-to-building-apps-without-infrastructure-burden/)

# Developer guide to building apps without carrying the infrastructure burden

Most application developers spend a significant amount of time on tasks that have nothing to do with building features. Sprint 0 disappears into Jenkins files and Terraform configs. New environments require tickets to multiple teams and a one-to-two week wait. Runtime upgrades stretch into months-long projects.

This is the infrastructure tax, and it compounds. Every hour spent debugging IAM permissions or waiting for environment provisioning is an hour not spent on the product. The tools designed for infrastructure specialists (Terraform, Kubernetes, raw cloud configs) have become default expectations for application developers who never signed up for that work.

There's a cleaner split between what developers should own and what should be automated. Getting that split right changes how teams plan, build, and ship.

## **What "not carrying the infrastructure burden" actually means**

Let us be clear about what we are not suggesting: abandoning all infrastructure knowledge or pretending deployment does not matter. The goal is to separate _what_ you need from how it gets provisioned.

Infrastructure should be a dependency of your application, just like any other dependency in your codebase. You declare what you need (a PostgreSQL database, a Redis cache, a Node.js runtime), and the platform handles the rest. Beyond the contract between your application code and a dependency, you should not need to worry about how that dependency runs.

In practice, this means no more writing Terraform modules to provision managed databases. No more debugging Kubernetes YAML when your pod will not schedule. No more context-switching between your IDE and cloud provider consoles to figure out why IAM permissions are blocking your deployment.

You write code. You push to Git. Your application runs.

## **Infrastructure abstraction: what developers should keep control of**

Not everything should be abstracted away. Some infrastructure decisions directly affect how your application behaves, and those belong with the development team.

-   **Application architecture decisions** remain yours. Can your application run properly in a multi-node setup? Does it handle horizontal scaling gracefully? These questions require understanding your code, not your cloud provider.
-   **Service selection** stays with you. You know whether your workload needs PostgreSQL or MySQL, whether Redis makes sense for your caching strategy, and whether Elasticsearch fits your search requirements. The platform should make these services available instantly, but the choice is yours.
-   **Performance requirements** are your domain. How much CPU and memory does your application need? What response times do your users expect? You understand these constraints better than any infrastructure team.
-   **Business logic and data flow** obviously stay with you. How your application processes requests, stores data, and handles errors is core development work.

## **What should be abstracted away**

Everything else. Specifically, anything that requires specialist infrastructure knowledge but does not change how your application code works.

-   **Environment provisioning** should not consume your Sprint 0. When a platform handles this automatically, you go from committing code to having a running environment in minutes instead of days or weeks. Every Git branch can generate a complete environment with the same configuration, services, routing, and optional production data.
-   **Networking and routing** configuration should be invisible. TLS certificates, load balancing, DNS management, and service discovery can all be handled by the platform. You should not need to understand VPCs or security groups to deploy a web application.
-   **Runtime and service updates** should not be months-long projects. As a developer, you should not care about sub-point versions of your runtime or service. You should not have to deal with updating them because that is not your focus. Your focus should be on building new value or maintaining your application.
-   **Infrastructure security** is where guardrails should replace decision-making entirely. Read-only production file systems, automated TLS certificates, strict environment isolation: these should be built in, not configured.

## **How reduced infrastructure overhead change development speed**

When you remove infrastructure from your critical path, development speeds up.

-   **Faster feedback** loops become the norm. When creating a test environment takes seconds instead of filing tickets, you test more frequently. You catch problems earlier. You ship with more confidence.
-   **Feature branches become real environments**. Every branch you push can become a fully independent environment, complete with your application code, a copy of your database, and all supporting services. Its automatically generated URL can be sent to stakeholders or CI systems. It really is "what would my site look like if I merged this to production?" every time.
-   **Sprint planning changes**. Without Sprint 0 infrastructure work, you start building features on day one. Without environment provisioning delays, you stop padding estimates with "infrastructure time." You plan based on development complexity, not operational overhead.
-   **On-call becomes less stressful**. When infrastructure is predictable and rollbacks are reliable, sleep improves. Seriously.

## **Common fears about giving up low-level control**

Teams often hesitate to adopt standardized environments because they worry about losing flexibility. Let us address the most common concerns.

-   _"What if I need a custom configuration?"_ Standardized does not mean rigid. A well-designed platform exposes configuration where it matters (resource allocation, service selection, environment variables, etc.) while hiding complexity where it does not (networking, IAM, scaling mechanics).
-   _"What about vendor lock-in?"_ Your application code does not change. Your database schemas stay the same. Your APIs remain identical. The portability that matters, your actual application, stays portable.
-   _"How do I debug production issues?"_ Better than you do now, likely. When every environment is identical (same configuration, same services, same data structure), debugging "works on my machine" problems disappear. Full-production clones in minutes let you test in real conditions without touching live systems.
-   _"What about compliance and security requirements?"_ Built-in compliance (SOC 2, ISO 27001, PCI-DSS) often exceeds what teams achieve with DIY setups. When security is baked into the platform, you inherit it automatically.

## **What enables confidence when infrastructure is automated**

Confidence comes from predictability. When you understand exactly what will happen each time you deploy, fear decreases.

-   **Git becomes the single source of truth.** Your infrastructure configuration lives alongside your code in a simple YAML file. Infrastructure changes go through pull requests with the same review process as code changes. Every deployment is deterministic based on Git commits. Rolling back means reverting commits.
-   **Configuration stability over time.** One challenge with Terraform is version upgrades and syntax changes between versions. Upgrading Terraform is often significant work. With standardized platforms, a configuration file from years ago still works today.
-   **Environment parity is guaranteed.** The same configuration deploys to development, staging, and production. Environment-specific differences are handled through variables, not different configurations. Drift between environments simply does not happen.

## **Getting started**

The path forward does not require rewriting your application or abandoning everything you know. Start with a non-critical project. Create a simple configuration file. Push to Git. Watch your application deploy.

When you see how fast that feedback loop can be, when you experience creating a complete environment from a branch in seconds, the infrastructure burden starts feeling like a problem that belongs in the past.

You became a developer to build things. It is time to get back to that.

## **Learn more**

-   **What is Upsun?**   
    Understand the core concepts behind Git-driven infrastructure and how Upsun abstracts away operational complexity.
-   **Git-Driven Infrastructure: Why Configuration as Code Beats Click-and-Deploy**.  
    A deeper look at why YAML-driven deployments outperform manual provisioning for maintainable, scalable applications.
-   **Set up your local development environment**.  
    Connect your local workflow to Upsun using DDEV or SSH tunnels to iterate faster without pushing every change.
-   **Command line interface (CLI)**  
    Manage projects, environments, and deployments directly from your terminal with the Upsun CLI.
-   **Manage Upsun environments**.  
    Learn how to create, branch, sync, and merge environments tied to your Git workflow.

### [Focus on coding, not infrastructure | Upsun](https://upsun.com/blog/focus-on-coding-not-infrastructure/)

# Be able to focus on what matters to you

If you feel like your week gets swallowed by meetings, config churn, and “quick fixes,” you are not imagining it. Multiple independent studies show significant time losses from firefighting and inefficiencies, rather than creative work. Cisco reports **developers spend more than 57% of their time being dragged into ‘war rooms’ to solve application performance issues**, rather than investing their time developing new, cutting-edge software applications as part of their organization’s innovation strategy¹ ². 

The result: less time building features, more time switching context between fixing your workflows, infrastructure, pipelines, settings, and occasionally some actual development.

But there is an alternate path: a workflow where environments appear automatically for each branch, data clones safely, and instrumentation is built in so you can focus on code, not fixing the plumbing. This is the day-to-day experience Upsun aims to make normal for every developer.

## **Developer productivity without the infrastructure management drag**

What keeps you from staying in flow is rarely the tasks assigned to you. It is the meta-work around the work: provisioning, wiring services, fighting flaky staging, and proving a fix will behave in production. A cloud application platform can remove these chores by turning Git into the control plane and standardizing the environment shape across branches. This aligns with DORA position that standardization and platform capabilities correlate with better delivery and team well-being⁵ ⁶.

On Upsun, all of your infrastructure is declared once as a single config.yaml file in your Git repo. Push your code, and the platform builds, deploys, and routes everything for you. Every Git branch can be its own live environment, with all the services and data cloned from its parent. That means realistic previews for reviewers, and zero “works on my machine” debates because they can see it in a live environment that is a byte-for-byte copy of production.

-   Use a single config file to define applications, services, relationships, routes, build hooks, deploy hooks, and workers (all versioned alongside code). See What is Upsun.
-   Connect GitHub, GitLab, or Bitbucket so pull requests spin up production-grade preview environments automatically.

## **A cloud application platform for application modernization**

Modernizing an app is easier when your platform standardizes, deploys, and surfaces performance data in one place. Upsun integrates profiling and monitoring so you can see regressions early, not during an incident. You can also use built-in continuous profiling to compare builds over time. If you need to centralize events and monitoring, you can also forward all the platform logs to New Relic, Splunk, or Sumo Logic.

-   Forward logs to third-party observability tools.
-   Use continuous profiling to spot hot paths over time.

Explore Blackfire for full-stack observability with Upsun.

## **Platform engineering that developers actually like**

“Platform engineering” should not mean weeks of pipeline creation and maintenance. Upsun provides guardrails so teams can codify best practices once and reuse them across repositories, with multi-service orchestration and predictable environments. Your AI coding assistants can even gain structured context through our CLI or MCP, helping them generate changes that match your runtime and services.

-   Learn how MCP fits modern app workflows.
-   Connect an MCP server to a remote database for safe, contextual AI assistance.

## **What this looks like in practice**

Here is a minimal, Git-driven `.upsun/config.yaml` that defines a web app, a worker, and a database. Commit and push; the platform handles build, deploy, routing, and relationships.

```shell-session
applications:
  web:
    type: "php:8.2"
    build:
      flavor: composer
    relationships:
      database: "db:mysql"
    web:
      locations:
        "/":
          # The public directory of the app, relative to its root.
          root: "public"
          # The front-controller script to send non-static requests to.
          passthru: "/index.php"
    workers:
      queue:
        commands:
          start: "php bin/console messenger:consume async"
services:
  db:
    type: "mysql:10.6"
routes:
  "https://{default}/":
    type: upstream
    upstream: "web:http"
```

-   See the config structure in the docs.
-   Push to create or update environments.

## **Safe previews with instant data cloning and sanitization**

Realistic previews are only useful if your test data is safe. Upsun lets you clone live data into non-production environments and sanitize PII so reviewers can test with confidence. Start from the parent, clone, then sanitize using the examples for your stack.

-   Clone data as you create new environments.
-   Sanitize PostgreSQL or MariaDB data.

If you prefer a deeper dive, this preview primer shows how the building blocks fit together.

## **Why it matters for developer productivity**

-   You spend less time wiring infra and more time solving app problems.
-   Reviewers get production-grade previews per branch, so feedback cycles shrink.
-   Profiling and logs are on by default, so you catch issues before incidents.
-   Costs are more predictable, with visibility into usage and resources.

Independent research aligns with this direction. The DORA program links stable technical practices to strong delivery outcomes⁵ ⁶. At the same time, Atlassian’s 2025 DevEx report shows 68 percent of developers now save over 10 hours weekly with AI, yet organizational friction still erodes those gains² ⁷. That is why standardization and self-serve environments matter: they reduce the friction that steals your week.

## **Getting started in minutes**

1.  Connect your Git provider; Upsun will create environments for branches and pull requests.
2.  Add a `.upsun/config.yaml` with our `upsun init` cli command to declare apps and services.
3.  Enable log forwarding or profiling as needed.
4.  Clone data and sanitize it for safe previews.

Upsun is built to get applications into production and keep them there, so you can create without the constant drag of infrastructure management.

### **Who this helps**

-   Developers who want to stay in flow and ship.
-   Teams practicing platform engineering and application modernization at scale.
-   Any org looking for a cloud application platform that favors speed, simplicity, and reliability.

## **Sources**

1.  Developers spend more time firefighting than innovating, according to Cisco's newsroom.
2.  DORA 2024 report overview.
3.  Google Cloud on DORA’s four key metrics.
4.  State of Developer Experience 2025, report hub.

### [Git-driven environments: consistent builds without the drift | Upsun](https://upsun.com/blog/git-driven-environments-infrastructure-as-code/)

# Git-driven environments: why treating infra as code unlocks consistent builds every time

At some point in every developer's journey, they have experienced a “but it works perfectly in staging”. Then the code merges to production, and something breaks. Could be a missing environment variable or a service version mismatch, a configuration that drifted in the environment without anyone noticing. These reasons could go on and on. 

Then the post-deployment scramble begins. You dig through dashboards, compare settings, and try to reconstruct what actually runs in production versus what you tested. Hours later, you find the culprit: someone changed a setting in staging three weeks ago but never documented it.

This is the cost of managing infrastructure outside your codebase. And it compounds with every team member, every branch, and every deploy.

Git-driven environments solve this by putting your full infrastructure definition: apps, services, routes, and build logic into version-controlled code. Every branch becomes a deployable, production-aligned environment.

## **The real reason builds are inconsistent**

Environment drift happens when dev, staging, and production fall out of sync. It's rarely one big mistake. It's dozens of small ones:

-   Someone updates a database version in staging through a dashboard but forgets to do the same in dev.
-   A build command gets tweaked in production. The change never reaches the repo.
-   A new team member spins up a local environment using outdated setup docs.

Each change is invisible. There's no commit, no pull request, no audit trail. Over time, your environments diverge silently until something that worked everywhere else breaks in production.

The cost isn't theoretical. For many organizations, requesting new space for an application means submitting multiple tickets to multiple teams and waiting one to two weeks. Upgrading a runtime or service version can stretch into months. Before any product work even starts, teams commonly spend an entire sprint, ten days of full-team effort, just standing up infrastructure and CI pipelines. That's feature development time lost before a single line of product code ships

## **How Git-workflow changes everything**

Git-driven infrastructure treats your repository as the authoritative source for how your application runs. Every environment configuration lives in version control alongside your code. When you push a branch, the platform reads your configuration file and provisions everything needed to run that exact version of your application.

This approach delivers concrete benefits. 

First, environment parity becomes automatic. The same configuration file deploys to development, staging, and production. Environment-specific differences get handled through variables, not different configurations. 

Second, infrastructure changes go through code review. Modifying infrastructure means editing files and creating pull requests. Your team reviews infrastructure changes with the same rigor as application changes. 

Third, rollback becomes trivial. Deployments are deterministic processes based on Git commits. Rolling back infrastructure changes is as simple as reverting commits.

The configuration file also serves as documentation that stays current. When everything lives in code, there is no gap between what the documentation says and what actually runs.

### **Every git branch becomes a live environment**

With Git-driven workflows, creating a preview environment becomes a single action: push a branch. The platform automatically provisions an isolated environment that inherits data and services from its parent. Databases, network storage, queues, and routing configurations all replicate automatically.

This changes how teams work. Developers can test risky migrations against cloned production data without touching the live environment. Content editors can verify changes in preview URLs while developers refine API logic. QA can run end-to-end tests in environments that mirror production exactly.

When the experiment finishes, deleting the branch automatically tears down the environment. No cleanup tickets. No orphaned resources. No forgotten infrastructure accumulating cost.

Obscure, data-dependent bugs reproduce instantly when your preview environment carries real data and assets. Environment drift disappears from the conversation because every branch clones from its parent by default. Parity is not an afterthought; it is the starting point.

## **Scaling without the complexity tax**

Manually managed Terraform and Kubernetes stacks introduce hidden coupling and fragility that teams often underestimate. Version upgrades require learning new syntax. Configuration files from years ago may no longer work with current tooling. The complexity compounds as team size grows and more people touch the infrastructure.

Git-driven platforms reduce the number of decisions developers need to make. Infrastructure configurations that would otherwise require separate Terraform files, Kubernetes manifests, and CI/CD pipeline definitions are collapsed into a single declarative file. The platform validates syntax on push and shows errors in build logs before misconfiguration reaches reviewers.

When managing environments at scale, knowing that every environment built from the same branch is identical eliminates entire categories of debugging sessions. Configuration drift between environments becomes impossible. Once functionality is verified in one environment, it functions identically across all environments running that configuration.

## **How Upsun implements Git-driven environments**

Upsun treats your Git repository as the single source of truth for both application code and infrastructure. A unified `.upsun/config.yaml` file defines your runtime, services, routes, and environment variables. That configuration travels with your code, which eliminates the disconnect between what works locally and what runs in production.

Each push spins up an isolated container stack. You can branch that stack, data included, into a new preview environment in under a minute. The CLI and API enable teams to automate integration with existing CI/CD workflows without retooling everything.

Source integrations with GitHub, GitLab, and Bitbucket mean environments can be created automatically for pull requests and branches. When a merge request opens, an environment spins up with the target branch as its parent and a copy of its parent's data. Merge the request, and the preview environment tears down automatically.

Read-only infrastructure guarantees reproducibility. Files cannot be modified at runtime, so when you merge code from staging to production, you deploy the identical filesystem image. There is no configuration drift, no manual modifications, and no discrepancies between what passed testing and what runs live.

## **Moving forward**

Infrastructure should be a dependency of your application, just like any other dependency. Beyond the contract between application code and a service, developers should not need to worry about how that service gets provisioned or configured.

Git-driven environments make this practical. Every branch becomes a deployable environment. Every configuration change goes through review. Every deployment is reproducible from the version control system.

The result is faster feedback loops, fewer post-deployment surprises, and more time spent building features instead of debugging environment inconsistencies.

Ready to eliminate configuration drift? Start a free Upsun trial and experience Git-driven deployment.

### [Unified cloud management for multi-cloud apps | Upsun](https://upsun.com/blog/unified-cloud-management-platform/)

# Why cloud fragmentation is slowing teams down and how unified platforms solve it

Engineering teams today manage infrastructure spread across multiple clouds and tools. Whether this happened through gradual accumulation or deliberate strategy, the result is the same: complexity that slows teams down. Managing each cloud separately with different tools and workflows is a bottleneck to delivery speed, operational efficiency, and platform reliability. CTOs and platform engineering leaders tell the same story: too many tools, too many environments, not enough standardization, and too much DevOps toil. 

Unified cloud application platforms like Upsun resolve this by providing consistent workflows across multiple cloud providers, production-perfect environments, Git-driven deployments, built-in compliance and security guardrails, and observability and automation out of the box.

## **The evolution: from single cloud to complex ecosystems**

Cloud infrastructure has evolved from simple server hosting to complex, multi-cloud ecosystems that require sophisticated management approaches. Early cloud management typically involved creating a few virtual machines on a single provider, managing them individually through web consoles, and moving on. Today's reality is far more complex.

Most teams now run a mix of applications, services, and data stores across multiple regions and providers. A typical production environment might include:

-   Compute resources across multiple regions for redundancy.
-   Managed databases requiring backup strategies and failover configurations.
-   Container orchestration platforms running hundreds of microservices.
-   Content delivery networks, load balancers, and API gateways.
-   Monitoring, logging, and security tools generate massive data streams.
-   Development, staging, and production environments that must remain in sync.

This complexity creates real challenges.  For developers, this complexity steals time from shipping, and for IT leaders, it drives risk, inconsistency, and spiraling costs. 

## **Why engineering teams struggle with cloud fragmentation**

Most organizations don't choose fragmentation; they accumulate it. A team adopts AWS for core workloads, another builds analytics on GCP, a legacy system remains on Azure, and suddenly half the delivery cycle becomes about synchronizing tools rather than shipping software.

From our conversations with CTOs and platform engineering teams, several themes appear consistently:

#### **1\. Delivery slows because environments aren't consistent**

Each stack has its own provisioning workflow, configuration conventions, monitoring stack, and deployment model. Minor differences compound until "works on my machine" becomes "works on no one's environment."

Without consistent automation, developers spend hours navigating fragmented tools and docs instead of writing code. A recent survey found that developers spend an average of 30% of their time on infrastructure-related tasks that could be automated or simplified. That's roughly 12 hours per week that could be redirected toward feature development.

#### **2\. The DevOps burden becomes unmanageable**

Platform teams spend enormous time maintaining Terraform modules, CI/CD pipelines, custom scripts, drift corrections, and access policies. This directly competes with roadmap delivery.

Infrastructure sprawl becomes unmanageable as teams accumulate servers, databases, and services across multiple providers without unified visibility. Resources get orphaned, servers run indefinitely without central control, making it nearly impossible to understand what's running or what it costs.

#### **3\. Costs become unpredictable** 

Overprovisioning, idle environments, oversized instances, and orphaned resources across providers make cloud spend difficult to control or forecast. Organizations commonly waste 20-30% of their cloud spend on unused or underutilized resources.

#### **4\. Security and compliance gaps grow in the seams**

More providers equal more policies, more misconfiguration risk, and more places for something to go unnoticed. Each additional tool in the stack introduces another potential vulnerability.

Manual configuration creates inconsistency where every environment becomes slightly different. When infrastructure management is fragmented, it's easy to miss misconfigured security groups, exposed databases, or outdated access permissions.

#### **5\. Onboarding slows dramatically**

New developers face a maze of scripts, environments, and undocumented tribal knowledge. This knowledge gap becomes even more critical as teams scale. Onboarding new team members can take weeks instead of days when they need to learn multiple platforms, understand undocumented processes, and locate various resources.

**In summary,** fragmentation increases complexity exponentially, whereas platform engineering capacity grows linearly.

## **What engineering teams actually need** 

A consistent, unified way to deploy, manage, and scale applications regardless of cloud provider.

Modern teams need:

-   Standardized workflows across apps, teams, and clouds.
-   Automation that removes manual provisioning.
-   Preview environments that mirror production.
-   Guardrails that don't slow down developers.
-   Security and compliance are handled at the platform layer.
-   Freedom to deploy on the cloud regions required for cost, data sovereignty, or performance needs.

This is where unified cloud application platforms come in.

## **What is a unified cloud management platform?**

A unified cloud management platform addresses infrastructure fragmentation by providing a single, consistent layer of control across your entire infrastructure. Instead of managing components separately through different tools, everything is managed through unified workflows.

Think of it as the difference between managing finances with a dozen spreadsheets versus using a comprehensive financial dashboard that consolidates everything in one place.

True unified management provides several key capabilities:

-   **Single-pane visibility** across all your infrastructure resources, regardless of where they're hosted.
-   **Consistent automation** that works the same way whether you're provisioning resources on AWS, Google Cloud, or your own data center.
-   **Centralized access control** that lets you manage who can do what across your entire infrastructure stack, with audit logs that track every change.
-   **Unified monitoring and alerting** that correlates metrics across your entire stack.
-   **Cost management** that provides visibility into spending across providers, teams, and projects.

## **Key capabilities of unified platforms**

A unified cloud application platform consolidates deployment, environment management, scaling, observability, and governance into one consistent model. Below are the capabilities engineering leaders say have the highest impact:

#### **What if every environment behaved exactly like production?**

One of the biggest barriers to reliable releases is environmental drift: staging is close to production but not identical; developer environments rely on mocks; and CI runs against synthetic data.

**Upsun approach: production-perfect preview environments**

Every Git branch can automatically generate a complete environment with the same configuration, services (databases, caches, queues), routing, and optional sanitized production data.

Git-driven deployments have been shown to significantly reduce provisioning and sync times in infrastructure management. This eliminates drift and accelerates testing, QA, stakeholder signoff, and debugging.

**Result:** Teams ship faster, with fewer surprises, and with higher confidence.

#### **What if your infrastructure were defined and deployed through Git?**

CTOs want standardization without turning every developer into an infrastructure expert.

**Upsun Git-driven workflows:**

-   Infrastructure lives alongside code in a single config file
-   Developers deploy by pushing to Git—no scripts, no manual provisioning
-   Upsun automatically provisions, configures, and scales everything required

This removes 80%+ of the operational glue work that typically slows teams down. See how Git-driven infrastructure works.

#### **What if multi-cloud deployments were actually... simple?**

Organizations choose multi-cloud for sovereignty, resilience, cost optimization, and customer data location requirements. But maintaining multiple clouds yourself is rarely efficient.

**Upsun multi-cloud abstraction:**

Deploy the same application to AWS, Azure, GCP, IBM Cloud, and OVHcloud using the exact same workflows, configs, guardrails, and automation. No provider-specific pipelines, no duplicated platform engineering effort, no retraining teams for each cloud.

This eliminates vendor lock-in and lets organizations choose the best cloud for cost, performance, compliance, or regional needs. Upsun multi-cloud platform supports deployment across multiple cloud providers with portable YAML configuration that works across all providers, enabling disaster recovery and strategic provider transitions without rebuilding infrastructure from scratch.

#### **What if compliance stopped slowing down releases?**

As companies scale into finance, healthcare, or government, compliance often becomes a bottleneck.

**Upsun's built-in compliance:**

-   SOC 2 Type II
-   PCI DSS Level 1
-   GDPR-ready
-   ISO27001 certified
-   HIPAA-compliant hosting
-   Encryption everywhere
-   Role-based access control
-   Audit logs across environments

Security is built-in, not a separate operational chore. Upsun provides read-only containers that prevent unauthorized modifications, automated backups with point-in-time recovery, and environment isolation to prevent security issues from spreading. Read more on Upsun security and compliance.

#### **What if your platform was built for modern AI workflows?**

AI development introduces new requirements: frequent iterations, safe testing with real data, structured-environment metadata, a deterministic infrastructure, and compatibility with MCP servers.

**Upsun AI-ready architecture provides:**

-   Structured metadata for agent workflows
-   MCP server integration
-   Instant environment cloning for RAG and agent pipelines
-   Predictable routing and APIs that work smoothly with AI coding assistants

AI agents and human developers get the same reliable environment model, a major accelerator for internal AI adoption.

#### **What if observability was unified without having to stitch tools together?**

Unified platforms must give teams visibility into performance, exceptions, resource usage, slow endpoints, and scaling behavior.

**Upsun integrates:**

-   Blackfire for continuous profiling
-   Metrics for every environment
-   Server analytics
-   Alerts and insights baked into the platform

No integration drift, no custom dashboards, no fragmented views. Upsun includes automated performance testing where teams can set performance goals, run automated tests with every deployment, and block releases that don't meet performance standards.

## **How unified platforms improve engineering costs**

When engineering leaders evaluate build vs. buy, they tend to focus on direct infrastructure cost. But the _real_ savings come from removing operational drag.

Here's what CTOs report after adopting a unified platform model:

**1\. Faster roadmap delivery**

Teams spend more time writing code, less time managing infrastructure.

**2\. Fewer outages and regressions**

Production-perfect environments + consistent workflows = fewer late-stage surprises.

**3\. Lower DevOps toil**

Platform teams stop reinventing infrastructure for each app and instead focus on value creation.

**4\. Predictable, auditable compliance**

No more ad-hoc scripts, policy drift, or uncertainty during audits.

**5\. Better hiring and onboarding**

Standardized workflows reduce the cognitive load for new engineers.

## **Choosing the right management approach**

There's no one-size-fits-all solution for infrastructure management. The right approach depends on your organization's size, technical sophistication, and specific requirements.

**For small teams:** Platforms that provide integrated management capabilities with minimal configuration overhead offer the most value. The priority is simplicity and avoiding over-engineering.

**Mid-size organizations:** Typically benefit from unified management platforms that eliminate DevOps overhead and provide consistent workflows. At this scale, the productivity gains from automated environment management and deployment pipelines quickly justify the investment.

**Enterprise organizations:** Need comprehensive platforms that support policy-as-code, compliance automation, and granular access controls. Multiple teams need to share infrastructure safely, and the stakes of outages or security breaches are higher.

Regardless of size, certain principles apply universally:

-   Start with visibility before attempting automation.
-   Automate incrementally, focusing on high-impact tasks.
-   Establish clear ownership for different infrastructure aspects.
-   Invest in documentation that captures decisions and procedures.
-   Build feedback loops that help teams learn from incidents.  
     

### **Why Upsun? A unified cloud platform built to eliminate complexity**

Upsun is designed around a simple idea: **Engineering teams should spend their time building applications, not infrastructures.**

We deliver this through:

-   Git-driven deployments
-   Production-perfect preview environments
-   Multi-cloud portability
-   Built-in security and compliance
-   AI-friendly environment modeling
-   Standardization across environments and teams
-   99.99% uptime options
-   Sustainability insights and greener-region discounts

The platform supports multiple programming languages and frameworks, including Python, PHP, Node.js, Go, Java, .NET, Ruby, and Rust. This flexibility allows teams to use the technologies that work best for their applications without infrastructure constraints. This combination is rare and increasingly necessary as teams scale globally and adopt AI-driven development.

## **The path forward**

With each passing quarter, costs rise, complexity compounds, and delivery slows. Organizations that adopt unified platforms now rather than after a costly incident gain a lasting advantage in speed, reliability, and efficiency.

As new technologies and development practices continue to evolve, infrastructure complexity will only increase. But with the right foundation, unified visibility, consistent automation, and transparent processes, teams can turn this complexity into a competitive advantage.

The question isn't whether to invest in better infrastructure management, but when to invest. Teams that act proactively, before complexity becomes overwhelming, position themselves to move faster, spend smarter, and build more reliable systems.

### **Learn more**

Upsun simplifies cloud infrastructure management for teams building modern applications. Whether you're running SaaS platforms, eCommerce sites, or microservices, Upsun automates the operational complexity so your team can focus on shipping features.

**Explore how Upsun works:**

-   Environment cloning and preview environments
-   Multi-cloud deployment with portable configuration
-   Git-driven infrastructure workflows

Start your free trial and deploy your first application in minutes, or talk to our team about your infrastructure requirements.

### [Upsun vs Coolify 2026: Managed PaaS vs Self-Hosted | Upsun](https://upsun.com/blog/upsun-vs-coolify-2026/)

# Upsun vs Coolify in 2026: when self-hosted PaaS stops being worth it

Upsun and Coolify both deliver the Git driven deployment experience that defined the Platform as a Service category, but they sit at opposite ends of the infrastructure ownership spectrum. Upsun is a managed multi-cloud PaaS that runs application infrastructure across AWS, Google Cloud, Azure, OVHcloud, and IBM Cloud. Coolify is an open-source, self-hostable PaaS that runs on any server you provision yourself, from a $5 VPS to enterprise hardware.

Developers compare them because both promise a similar outcome: a smooth deployment workflow, managed databases, automatic SSL, and an escape from raw cloud infrastructure. The difference is who carries the operational weight. With Coolify, you do. With Upsun, the platform does.

## **Key takeaways**

-   Coolify is a self-hosted, open-source PaaS you run on your own infrastructure. Upsun is a managed multi-cloud PaaS that runs application infrastructure for you across AWS, GCP, Azure, OVHcloud, and IBM Cloud.
-   Choose Coolify if you want low monthly costs, full control over your servers, and you have the Linux sysadmin capacity to maintain them.
-   Choose Upsun if you need production-grade environments, compliance certifications, automatic scaling, and you do not want to operate infrastructure.
-   Coolify wins on raw cost. Upsun wins on operational overhead, reliability guarantees, and regulated-industry readiness.

## **What do Upsun and Coolify have in common?**

Both platforms share more than a casual comparison might suggest. Each offers Git-based deployment, supports a broad range of languages (Node.js, PHP, Python, Ruby, Go), and manages SSL certificates automatically.  They both let you provision databases such as PostgreSQL, MySQL, and Redis through the platform rather than configuring them manually. Both support preview environments tied to Git branches, although the implementations differ, and both abstract Docker container management to varying degrees.

If your only criterion is "Git push to deploy a containerized app," either platform will do the job. The question is what you are willing to manage to get there.

## **Key differences at a glance**

## **Detailed comparison**

### **How do Upsun and Coolify handle hosting and infrastructure?**

The clearest difference between Upsun and Coolify is who owns the servers. Upsun runs your application on infrastructure managed across five major cloud providers. You choose where to deploy, and the platform handles provisioning, networking, OS-level updates, and security patching. The same YAML configuration deploys identically across AWS, GCP, Azure, OVHcloud, or IBM Cloud.

Coolify runs on servers you provision yourself. You buy a VPS from Hetzner, DigitalOcean, AWS, or use a Raspberry Pi, and you install Coolify on it. The dashboard provides a deployment interface, but the underlying server, kernel, security updates, firewall, and backups are still yours to manage. Coolify Cloud, at $5 per month, manages the Coolify control plane only. You still bring and operate the application servers.

For teams comfortable with Linux operations, Coolify's model means total control. For teams without that bandwidth, Upsun's model removes an entire category of work.

### **How do their deployment workflows compare?**

Both platforms deploy from a Git push, but the configuration models differ.

Upsun uses a single YAML file, .upsun/config.yaml, that lives in your repository and defines services, routes, environment variables, and infrastructure for every branch. The configuration travels with the code, which makes environments reproducible and reviewable through pull requests.

Coolify configures applications through a web dashboard. You connect a repository, choose a build pack or Dockerfile, set environment variables, and deploy. Configuration changes happen in the UI rather than in version-controlled files, although Coolify does support importing Docker Compose files for multi-container setups.

Teams that want configuration-as-code will prefer Upsun's approach. Teams that prefer a visual interface and faster initial setup will prefer Coolify's.

### **Which platform scales better?**

This is where Coolify's limitations are most visible. Upsun supports automatic horizontal and vertical scaling. Application containers scale based on traffic and resource utilization, and database read replicas can scale independently. Production environments can be cloned in under a minute, with live data, for testing or feature work.

Coolify does not offer autoscaling. Scaling is manual. To scale horizontally, you add servers to your Coolify instance and distribute applications across them. Docker Swarm support exists but is marked experimental in Coolify's own documentation, and there is no Kubernetes integration. 

For teams running steady, predictable workloads on a few servers, this is fine. For teams handling traffic spikes, flash sales, or multi-region deployments, the manual model becomes a bottleneck.

### **What managed services and observability does each platform offer?**

Both platforms offer managed databases and services, but the scope and ownership differ. Upsun provides a managed services catalog including PostgreSQL, MySQL, MariaDB, Redis, Elasticsearch, OpenSearch, RabbitMQ, and Kafka. Services are provisioned through the YAML config and inherit the platform's backup, scaling, and security policies. Observability is built in: infrastructure metrics, logs, and continuous profiling come as part of the platform.

Coolify offers 280+ one-click deployable services, a significantly broader catalog. The trade-off is that you operate them. Backups, updates, and security patches for each service are your responsibility. Observability is not included. To match a production-ready observability stack, teams typically assemble their own stack using a tool such as Sentry, an analytics tool, and an uptime monitor, which adds a meaningful additional monthly cost in third-party tooling.

Coolify wins on catalog size and flexibility. Upsun wins on operational simplicity and integrated observability.

### **How does pricing compare between Upsun and Coolify?**

On sticker price, Coolify is dramatically cheaper. On the total cost of ownership, the math gets closer.

Coolify itself is free under the Apache 2.0 license. A production-capable VPS from Hetzner or DigitalOcean costs $5 to $25 per month. Coolify Cloud, which manages the control plane, costs $5 per month for two servers, with additional servers at $3 each.

Upsun uses a Flex pricing model that bills at the resource level for CPU, RAM, and storage. Costs scale linearly with actual usage. For a small production project, Upsun is meaningfully more expensive than a self-hosted Coolify instance. For a team needing observability, compliance, automated backups, multi-region failover, and 24/7 uptime, the total cost gap narrows considerably once you factor in the engineering hours and tooling required to match those capabilities on Coolify.

The honest framing: Coolify is cheaper if your time is free. Upsun is cheaper if your time is not.

### **Which platform is better for compliance and security?**

This is where the comparison ends decisively in one direction. Upsun holds ISO 27001, SOC 2, PCI DSS, HIPAA, and GDPR certifications. These are platform-level guarantees that customers inherit when deploying. Security patches, vulnerability management, and infrastructure-level compliance controls are managed by the platform.

Coolify holds no such certifications. Self-hosted Coolify makes you responsible for your own compliance posture, including OS patching, vulnerability management, audit logging, and access controls. For regulated industries such as healthcare, financial services, or government, Coolify is not a viable production platform without significant additional engineering work.

## **When should you choose Coolify?**

Coolify is the right choice when ownership, cost, and flexibility matter more than operational abstraction. Pick Coolify if:

-   You are a solo developer or indie team running side projects or small commercial applications, and a $5 to $25 monthly VPS bill is your operational ceiling.
-   You want full control over your servers and refuse to depend on a managed provider.
-   You have Linux sysadmin skills on the team and treat infrastructure as part of your craft rather than overhead.
-   Your application catalog benefits from Coolify's 280+ one-click services, especially self-hosted analytics, AI tools, and developer utilities.

Coolify is genuinely excellent at what it does. For the right team, it is a better fit than any managed PaaS.

## **When should you choose Upsun?**

Upsun is the right choice when the self-hosted model stops being worth the operational cost. Pick Upsun if:

-   Your application carries compliance obligations, including HIPAA, PCI DSS, or SOC 2, and you cannot take ownership of platform-level compliance.
-   You need automatic scaling for unpredictable traffic, such as e-commerce flash sales or product launches.
-   You operate multi-cloud or need data residency across AWS, GCP, Azure, OVHcloud, or IBM Cloud.
-   Your team should be writing application code, not patching Linux kernels or managing TLS rotations.
-   You need production-perfect preview environments with live data for QA, feature work, or AI agent testing.

The line between "self-hosted is great" and "self-hosted is expensive in engineering hours" usually crosses somewhere between a hobby project and a serious production workload. That crossover is when Upsun starts being the cheaper option, even when its monthly invoice is larger.

## **How do you migrate from Coolify to Upsun?**

Migrating from Coolify to Upsun involves three main steps: configuration translation, service mapping, and data migration.

Configuration moves from Coolify's dashboard-managed setup to a single .upsun/config.yaml file in your repository. You define applications, services, routes, and environment variables in YAML rather than through a web interface. This shift to infrastructure-as-code is the largest conceptual change.

Services such as PostgreSQL, MySQL, and Redis are supported by both platforms, so data can be migrated using standard database dump and restore workflows. Application-level connection logic typically needs minor updates to reference Upsun's environment variables and service relationships.

A production migration typically takes 6 to 9 weeks, with the longest phases being infrastructure documentation, MVP testing, and data validation rather than the configuration work itself. For self-hosted setups with custom server-level scripts, cron jobs, or Docker Compose overrides, expect additional time to translate those into Upsun's equivalent constructs.

## **Frequently Asked Questions(FAQs)**

**Is Coolify free?**

Yes. The self-hosted version of Coolify is free forever under the Apache 2.0 license, with no feature gates and no per-seat fees. You only pay for the VPS or server you run it on, which typically costs $5 to $25 per month. Coolify Cloud, an optional managed control plane, costs $5 per month for two servers.

**Can Coolify scale to enterprise workloads?**

Not without significant additional engineering. Coolify does not offer native autoscaling or Kubernetes integration, and its Docker Swarm support is experimental. Multi-server setups are possible but managed manually. For enterprise workloads with autoscaling, multi-region deployment, and high availability requirements, a managed PaaS like Upsun is a better fit.

**Does Coolify support SOC 2 or HIPAA compliance?**

No. Coolify does not hold SOC 2, HIPAA, PCI DSS, or ISO 27001 certifications. When you self-host Coolify, you inherit responsibility for compliance, including OS patching, audit logging, access controls, and vulnerability management. Teams in regulated industries typically need a managed platform with platform-level certifications, such as Upsun.

**Does Upsun support multi-cloud deployment?**

Yes. Upsun deploys across AWS, Google Cloud Platform, Microsoft Azure, OVHcloud, and IBM Cloud through identical workflows defined in a single .upsun/config.yaml file. Teams can meet data residency, compliance, and latency requirements without rewriting deployment pipelines for each provider. Coolify, by contrast, runs on any server with SSH access but does not abstract multi-cloud deployment; you manage cloud provider relationships and infrastructure yourself.

**How long does migration from Coolify to Upsun take?**

A production migration typically takes 6 to 9 weeks, with the longest phases being infrastructure documentation, MVP testing, and data validation. The technical translation work itself, moving from Coolify's dashboard to Upsun`.upsun/config.yaml` and mapping services, can complete in days for simple setups. The remaining time goes to validating that everything works in production.

**Is Coolify cheaper than Upsun?**

On the monthly invoice, yes. A self-hosted Coolify instance on a $10 VPS is significantly cheaper than an equivalent Upsun project. On total cost of ownership, the comparison narrows once you factor in engineering hours for maintenance, third-party observability tools, backup management, and compliance work. For hobby projects, Coolify is almost always cheaper. For production workloads with operational and compliance requirements, Upsun is often cheaper in total cost.

### [How a misconfigured plugin slowed down a Shopware store | Upsun](https://upsun.com/blog/shopware-slowdown-debug-logging-issue/)

# Navigating Shopware logs and slow pages in a real world scenario

_A Shopware store goes from smooth to sluggish—pages take 10 seconds to load, even longer in some cases. What happened? In this post, we tell the true story of how one overlooked plugin setting nearly collapsed a storefront, and how it was resolved using native tools. If you’re shipping code in Shopware without clear performance observability, this is your wake-up call._

Everything was working, until it wasn’t. A Shopware store that had been running smoothly for weeks began to show signs of severe slowdown. Pages that once loaded in under a second were now taking 10, 15, sometimes even 180 seconds to render. The business owner assumed it was a traffic spike or a temporary hosting issue. It wasn’t.

When our team investigated, we discovered the cause: a single plugin was quietly dragging the entire storefront down.

## **The culprit: a misconfigured plugin**

The PayPal plugin had been left with **debug logging enabled** in production. What seemed like an innocuous setting was generating thousands of log entries per hour, saturating disk I/O and delaying responses across the board.

The plugin itself wasn’t broken, but its configuration created a bottleneck that rippled through the system.

Once debug logging was disabled and log files rotated, response times returned to normal. The store recovered. But for several days, customers experienced delays, and sales were lost.

## **This isn’t an edge case**

We’ve seen many similar scenarios:

-   A plugin update introduces an unbounded loop on checkout.
-   A category page is configured to list thousands of products without pagination.
-   ERP syncs trigger constant cache invalidations during peak traffic.
-   Admin users leave verbose logging enabled across multiple services.

Each of these starts small and gradually builds pressure until something breaks.

## **Prevention is a process**

Crisis recovery is valuable, but **early detection and prevention** are better. Here's how we recommend thinking about Shopware performance:

1.  **Observe system behaviour continuously**: look for trends in latency, CPU usage, and cache misses.
2.  **Profile changes regularly**, even when no issues are visible.
3.  **Review all plugin configurations** before going live or after any update.
4.  **Prewarm your caches** to avoid cold start scenarios.
5.  **Simulate traffic before campaigns**, not during them.

## **Our full white paper covers these scenarios and more**

In our newly released white paper, we document:

-   Real load testing across seven infrastructure tiers.
-   Cache invalidation patterns and mitigation strategies.
-   Profiling tools and analysis techniques.
-   Lessons learned from customer deployments.
-   Best practices for Shopware performance, from dev to production.

### [Décision IT : Construire ou Acheter ? | Upsun](https://upsun.com/blog/build-vs-buy-platform-guide/)

# Build or buy, that is the question

_For IT leaders who need to move fast without breaking governance._

If you’re running IT for a bank, a SaaS company, or a Higher education institution, you’re carrying a brutal balancing act on your shoulders. 

On one side, your developers are pushing for autonomy, velocity, and the freedom to ship. On the other hand, you’re on the hook for governance, compliance, security, cost controls, and now that AI has entered the chat, innovation at scale.

Let’s just call it like it is: that’s a lot.

## **The reality: you’re supporting everyone, everywhere.**

Your job is to ensure developers have the resources and tooling they need to serve customers, fast, reliably, and safely. That means:

-   Making it easy for teams to build and deploy.
-   Keeping environments standardized.
-   Protecting data, ensuring compliance, and enforcing governance.
-   Doing all of it with finite people, time, and budget.  
     

But instead of leading the organization forward, you're spending more time chasing infrastructure:

-   Cloud workloads are scattered across services
-   On-prem systems, you still can’t retire
-   Point solutions for edge cases and legacy apps
-   Three different dashboards, four vendors, and too many SLAs.

It’s all “just the plumbing,” but the plumbing keeps clogging. And every new initiative adds another layer of complexity.

**And then your boss asks: “So… what are we doing with AI?”**  
  
You’re already underwater, and now leadership wants a full AI strategy, yesterday.  
  
You want to experiment. You want to innovate. But with infrastructure fires burning everywhere, it feels like you’re constantly reacting rather than steering. The backlog grows, innovation slows, and your team gets stretched even thinner.

You can’t keep going like this.  But what’s the alternative?

## **The big decision: build or buy?**

Do you invest in building out your own internal platform to standardize environments?

Or do you lean on a PaaS, what Gartner now calls a Cloud Application Platform, to offload the heavy lifting? Like everything in tech leadership, the answer isn’t black and white. Here’s a clear-eyed breakdown.

#### **Option 1: build your own internal platform**

##### **Pros**

 **Full control**

 You choose the stack, the tooling, and how everything integrates.

 **Deep alignment with internal processes**

 When you build it, it naturally mirrors your security model, compliance structure, and workflows.

 **Can be a strategic differentiator**

 A well-run internal platform can become a competitive advantage. If you have the capacity to maintain it.

##### **Cons**

**✘ It’s a massive investment**

 You’re not just building once, you’re maintaining forever. You’ll need a platform team with ongoing resourcing.

**✘ Technical debt piles up fast**

 Every custom integration becomes another thing that only one person on the team understands.

**✘ Innovation slows**

 Your most senior engineers spend their days managing infrastructure—not enabling developers or delivering business value.

**✘ Hard to scale consistently**

 More teams + more services = more entropy. Standardization becomes a moving target.  
 

#### **Option 2: Use a PaaS / Cloud Application Platform**

##### **Pros**

 **Instant operational efficiency**

 Provisioning, scaling, backups, observability, security, and updates are offloaded.

 **Standardization out of the box**

 Every environment follows the same patterns, which protect compliance and accelerate onboarding.

 **Developers ship faster**

 They focus on code, not configuration or infra babysitting.

 **You get time back for innovation.**

 Your team can finally tackle AI, modernization, and customer-facing initiatives.

##### **Cons**

✘ Requires a mindset shift

 Some organizations struggle with handing off infrastructure responsibilities to a vendor.

✘ Less control at the lowest layer

 If you need kernel-level tweaks, this model isn’t the right fit.

✘ Vendor dependency

You need a partner you can trust for stability, SLAs, and long-term alignment.

## **So… build or buy?**

Here’s the straight truth:

If infrastructure management is not your competitive differentiator, you shouldn’t be sinking most of your time and budget into it.

Your real differentiator is delivering value to your customers through software, experiences, and innovation. For most organizations operating in hybrid environments, facing compliance pressures and resource constraints, a Cloud Application Platform can reduce operational burden enough to change the team's trajectory materially.

And that’s exactly where Upsun comes in.

## **Where Upsun fits in**

Upsun is a Cloud Application Platform purpose-built for organizations that need speed and control. 

We give IT teams a standardized, automated, governance-first platform so developers can build and deploy across cloud and on-prem environments, without creating chaos.

With Upsun, you get:

-   A consistent, production-grade platform across all apps and environments.
-   Automated governance and compliance are baked into every workflow.
-   Developer self-service without compromising security.
-   AI-ready foundations, so exploring new capabilities doesn’t become another infrastructure project.
-   A massive reduction in operational overhead so your team can finally focus on innovation.  
     

The choice isn’t really “build or buy.” It’s whether you want your team investing in platform maintenance… or in delivering value that moves the business. 

If you're ready to shift from keeping the lights on to driving strategic outcomes, Upsun is built for exactly that.

### [DORA compliance: helping financial services with Upsun](https://upsun.com/blog/dora-compliance-for-financial-services/)

# DORA Compliance: how Upsun supports our financial services customers

The Digital Operational Resilience Act (DORA) is set to reshape how financial institutions in the EU manage and contract with their technology providers. Since January 17, 2025, DORA requires financial entities to meet stricter rules for managing digital risks, especially when it comes to the third-party ICT (Information and Communication Technology) service providers they rely on.

While Upsun is not directly subject to DORA—we are a cloud application platform provider, not a regulated financial entity—some of our customers are, and for them, the new regulation creates real contractual and operational obligations.

We are ready to help!

**Why DORA matters to you and how we support it**

DORA was introduced to strengthen the financial services industry’s ability to withstand IT-related disruptions. It applies not just to outsourcing, but to all ICT services. This includes cloud platforms like Upsun, where our infrastructure and deployment automation plays a key role in the digital delivery chain for banks, insurance firms, investment funds, and other financial entities.

One of DORA’s central requirements is that contracts with third-party ICT service providers must contain specific clauses to help financial entities manage digital risk, maintain oversight, and cooperate with regulators. These provisions vary depending on whether the ICT services are deemed to support “critical or important functions.”

To assist our customers in meeting these new expectations, our legal team has prepared a DORA Contractual Addendum. This addendum aligns with requirements under Articles 28 and 30 of DORA and reflects the key areas DORA covers, including service levels, data handling, subcontracting, termination rights, and incident response.

This DORA Contractual Addendum is available upon request and is designed to easily integrate with our standard agreements, helping customers close any regulatory gaps quickly and without unnecessary complexity.

**Do Upsun services support a “critical or important function”?**

One of the distinctions DORA introduces is between standard third-party ICT services and those that support “critical or important functions.” These are functions where a disruption could severely impact a financial entity’s ability to operate or remain compliant with applicable laws.

At Upsun, our default is that our services will not necessarily fall into this category. That said, we understand that each customer’s setup is unique. If you believe our platform supports critical or important functions within your organization, we’re happy to have that conversation. We will work with you to ensure the DORA Addendum reflects the heightened standards required for such services.

**What you need to do**

For our part, Upsun is committed to being a proactive and responsible partner. If you’re an existing customer and need DORA-compliant terms, your account manager or legal contact can provide you with our DORA Contractual Addendum.

Together, we’ll ensure your digital operations remain resilient, compliant, and ready for the future.

For questions or to request the DORA Contractual Addendum, kindly contact us via Support, or by contacting our sales team.

### [EVOLVE 2025: Upsun Partner Summit Recap in Paris and NYC](https://upsun.com/blog/evolve-2025-partner-summit/)

# EVOLVE 2025 Partner Summit: two cities, one playbook for growth

_**From year two in Paris to our first North American stage in New York, EVOLVE 2025 turned partner insight into action with a clearer Upsun story you can sell.**_

EVOLVE returned to Paris for year two and crossed the Atlantic for our first North American edition in New York. Same heartbeat in both rooms. Practical sessions, clear product direction, and a community of partners who build outcomes that customers trust. If you could not be there, this is the story of what happened and why it matters now.

## **Why we evolved**

We relaunched as Upsun to give you a simpler platform you can explain in one meeting and scale for years. The mission did not change. What changed is the canvas. You keep the strength you know for CMS and commerce. You gain room for complex applications and AI-assisted work without adding operational drag.

The product conversation landed cleanly. One platform with two commercial models. Fixed gives predictability for steady workloads and stable budgets. Flex provides precise, container-level control with automated, transparent billing, allowing you to protect your margin as your customer base grows. Paired with guaranteed resources on Upsun Cloud, you can move the conversation from components to outcomes and remove friction in procurement.

## **What partners heard in the keynotes**

Both cities heard the same talks, which brought everyone onto the same page. The roadmap is organised around six value pillars that buyers already recognise. Speed and simplicity for the teams that ship. Scale and standardisation for platform leaders. Security and sustainability for risk owners and procurement. We also showed what is arriving at the organisation layer. Analytics across FinOps, GreenOps, DevOps, and DevSecOps. Edge protection patterns that fit modern risk. Bring your own cloud paths for sovereignty and choice.

None of this lives only in slides. Console, CLI, and API performance continues to improve, so delivery teams feel the gains day to day.

## **Agency wisdom that travels**

Paris flash talks set the pace with lessons you can apply on Monday morning. Use AI where it reduces toil rather than creates noise. Apply eco-design and accessibility checklists to existing sites, not just greenfield projects. Choose decoupled patterns that stay manageable. Treat digital sovereignty as a design choice when regulation or risk requires it. New York echoed those same themes through customer stories and community perspectives. Different skyline, same playbook. Build fast, remove friction, keep optionality.

## **Sponsors who powered the work**

Thank you to Ibexa, Shopware, Pimcore, IBM, and BNPP. Your sessions helped partners move from ideas to implementation, whether that meant composing a sovereign DXP, de-risking commerce delivery, or packaging new service lines on top of Upsun.

## **Celebrating excellence**

EVOLVE is about momentum, but it is also about the people who create it. We closed each city by recognising partners who turned strategy into customer value. The awards celebrate consistent delivery, healthier margins, and the kind of collaboration that raises the bar for everyone. If you are scanning this recap to see who set the pace in 2025, start here.

## **Paris award winners**

-   Innovation Excellence: NIJI
-   Excellence in Expertise: Klee
-   Top Rising Star: Gain
-   Fastest Growing Partner: ANVIL
-   Most Engaged Partner: 6Tématiq
-   Ibexa Cloud Partner of the Year: OMMAX
-   Shopware PaaS Partner of the Year: Basecom
-   Symfony Cloud Partner of the Year: Sensio Labs
-   Pimcore PaaS Partner of the Year: Basecom
-   Adobe Commerce Cloud Partner of the Year: Dn’d
-   Beacon of Excellence: Vanksen
-   Upsun Pioneer Award: Epick One

## **New York award winners**

-   Innovation Excellence: Digital Convergence
-   Excellence in Expertise: Proven, Bemeir
-   Top Rising Star: Monarch Digital
-   Fastest Growing Partner: Symetris
-   Most Engaged Partner: Madden Media
-   Top Magento Partner: Smart Solutions
-   Shopware PaaS Partner of the Year: Above the Fray
-   Beacon of Excellence: Interactive Strategies, Unleashed Technologies
-   Top Collaborator: Rollin Studios, Vardot
-   Upsun Pioneer Award: Charles River Web

## **What this means for your next customer meeting**

If you already build on Upsun, bring both models to your account reviews and map each workload to the right fit. Fixed when predictability wins. Flex when dynamism pays. Use the six pillars to align with stakeholder goals without drifting into jargon. Package services with OEM partners and treat console extensions as a route to new value, not just a demo.

If you are evaluating Upsun, the takeaway is simple. You can launch faster with fewer moving parts. You can scale with confidence. You can keep control where it matters to your team and to your customers.

## **Watch the replay**

Or take a peek behind the scenes into Paris and New York to relive the magic.

## **The road ahead**

Year two in Paris showed momentum. The first North American summit showed scale. Across both cities, the message was consistent. When partners win, everyone wins. Now we build.

Learn more about our Agency Partner Program or find your strategic implementation expert for your next project.

### [On-prem vs managed hosting vs Upsun for Drupal | Upsun](https://upsun.com/blog/enterprise-drupal-hosting-choice/)

# Enterprise Drupal: why hosting choice impacts your success

Deploying a large-scale Drupal application involves numerous decisions, and one of the most significant is where to host it. Should you keep everything **on-premises**, use a **managed hosting** provider, or opt for a modern PaaS like Upsun? Each approach has trade-offs. In this article, we’ll dive into the real-world technical pitfalls of on-premises and managed hosting, and then explore how Upsun addresses those challenges in an enterprise Drupal context. The goal is to share insights from a senior full-stack developer perspective – pragmatic and a bit fun, without the sales pitch.

## **On-premises Drupal: control at a cost**

Running Drupal on-premises (in your own data center or servers) gives you maximum control, but **with great power comes great responsibility**. In an on-prem model, your team manages _everything_ from the hardware up to the Drupal app. That means racking servers, configuring networks, applying OS patches, updating PHP/SQL, and more​. This full-stack control can offer flexibility, but it **requires significant resources and expertise** to do safely at scale.

Some common pitfalls of on-prem Drupal hosting include:

-   **Heavy maintenance overhead:** You need skilled admins on call 24/7. Power, replacement parts – all on your dime. A **smaller IT team can’t match the economies of scale** that cloud providers or PaaS offer. Every hour spent fixing a server or tuning MySQL is an hour not spent building features for your users.
-   **Scaling pains:** If your Drupal site suddenly gets a traffic spike (say a viral campaign or Black Friday sale), on-prem scaling is tough. You might add servers, but that could mean procurement delays or scrambling to reallocate VMs. It’s hard to **“scale up” on demand** when “adding capacity” involves physically installing new hardware or complex virtualization. Many on-prem setups end up over-provisioned (wasting money) or under-prepared (risking downtime).
-   **Hardware failures:** In on-prem environments, there’s no abstracted hardware; if a server’s RAID controller dies at 2am, guess who’s replacing it? Without built-in redundancy, a single hardware failure can mean extended downtime. Enterprise teams often mitigate this with expensive clusters and failover systems – again, more cost and complexity. As an anecdote, I’ve seen a Drupal intranet go offline because a network switch failed and no one was around to reboot it. These things happen, and on-prem, you handle all consequences.

Real-world example: The University of Surrey initially hosted its Drupal sites on-premises, but as the platform grew, it became _“too challenging to manage”_. Daily content changes were slowed by an overnight deployment process, and the IT team didn’t have the capacity to maintain Drupal, plus other systems. It became clear that \*\*“on-premises hosting just didn’t make sense anymore”\*\*​ (source: University of Surrey optimizes developer operations by shifting to Upsun). Many enterprises reach this tipping point where the costs (in time and agility) outweigh the benefits of total control.

## **Managed hosting: convenience with trade-offs**

To ease the on-prem burden, organizations often turn to **managed hosting**. In this model, you’re using an external provider (or cloud infrastructure) that handles **some** layers of the stack, at the very least the hardware and basic infrastructure. For example, a managed Drupal host might provision servers, handle network and OS updates, and provide a panel or toolkit for deployments. This is a big step up in convenience: your team can focus more on the Drupal app itself, not the underlying metal. As one industry analysis put it, PaaS/managed cloud solutions _“offer economies of scale that smaller IT teams cannot attain on their own”_, eliminating the need to buy and maintain physical hardware​.

Managed hosting for Drupal comes in flavors – from general cloud VMs (IaaS with your setup) to Drupal-specific platforms run by companies like Acquia or Pantheon. These certainly **reduce maintenance overhead**: no more replacing disk drives or manually installing Linux patches. Security updates for the OS and runtime are often handled or at least streamlined by the provider. And scaling the hardware is easier than on-prem – you might click a button to get a bigger VM or add a load balancer, rather than ordering a new server.

However, managed hosting is not a silver bullet. Here are some limitations and pitfalls that enterprises often encounter:

-   **Limited environment flexibility:** Many managed Drupal hosts provide a fixed number of environments (e.g., dev, stage, prod). This can become a bottleneck for teams with multiple developers or projects. For instance, on one popular managed platform, an 8-person dev team was stuck sharing _one_ development environment – it became “unsustainable” as they grew​. Developers had to wait for others to finish testing, slowing down collaboration. Creating additional test environments often isn’t trivial or may incur extra cost. In contrast, on-prem, one could spin up endless VMs (if hardware allows), and as we’ll see, Upsun takes environment flexibility to another level.
-   **Customization constraints:** Managed platforms are tuned for common use cases, which means they might **restrict certain technologies or configurations**. Perhaps you need a specific version of Solr or a custom Nginx module – your host may not support it. Bounteous notes that highly specific requirements might force a team off a PaaS onto DIY hosting. In practice, most Drupal sites don’t need anything exotic, but if yours does, be aware of the managed host’s limits. Some hosted Drupal services also disallow certain PHP extensions or require the use of their tooling, which might require workarounds for unique needs.
-   **Integrating DevOps workflows:** Managed hosting sometimes presents a _“black box”_ that doesn’t play nicely with your existing DevOps tools. For example, you might have a CI/CD pipeline that needs to run tests and then deploy to the host. If the host’s API or integration options are limited, you’ll be bending your processes to fit their model. It’s not as open as running your infrastructure, where you have full scriptability. This can be frustrating for teams practicing modern GitOps or automated testing. (Having to SCP files or click a dashboard button as part of deployment feels archaic when you’re used to automation.)
-   **Scaling still has friction:** Yes, managed hosts can scale better than an on-prem server in a closet, but you may still hit limits. You might need to upgrade to a higher plan for more traffic, or there might be _manual steps_ to scale out. Some providers require you to contact support to add more application servers or to enable CDN/WAF features. It’s not exactly auto-scaling on demand in many cases. You get convenience, but often at the cost of handing over some control and agility.

To illustrate, consider the University of Surrey’s journey: they moved from on-prem to a managed Drupal host (Acquia) as an interim step. This solved their hardware and patching worries, but introduced new constraints. With a team of 3 developers, things were fine, but at 8 developers, coordinating work with a single shared dev site caused \_“significant delays”\_​ (source: University of Surrey optimizes developer operations by shifting to Upsun). Developers were waiting for their turn to test features. Clearly, they needed a more flexible solution. In their words, the tool’s constraints started to outweigh its benefits as the team grew. This is a common story – managed hosting is a relief at first, but as complexity increases, you may feel the walls closing in.

## **Enter Upsun: a modern PaaS for Drupal**

Upsun is a **Platform-as-a-Service** built to eliminate many of the headaches we just discussed. It’s essentially a cloud hosting solution with **DevOps best practices baked in**. For senior developers working with Drupal, Upsun often feels like a breath of fresh air. It removes the burden of infrastructure so they can focus on what they do best: coding. But unlike generic hosts, it’s tailored for applications like Drupal, with features that can make an enterprise developer giddy (yes, I said giddy about hosting – bear with me!).

How does Upsun address the pitfalls of on-prem and typical managed hosting?

-   **Automated infrastructure and updates:** On Upsun, you _define your environment in code_ (through YAML config files), and everything is provisioned for you on the fly. You specify the PHP version, services like MySQL or Redis, cron tasks, etc., in simple config files that live alongside your code. No more logging into servers to install extensions – it’s all declarative. When it comes to maintenance, Upsun takes care of the underlying system updates. For example, the PHP runtime and other services get security patches applied automatically by the platform. Their policy is “update early, update often,” ensuring your app stack is up-to-date with the latest security fixes. Crucially, these updates happen in a controlled way – new container images are applied on deployment, and the platform even auto-redeploys periodically (e.g., to rotate TLS certificates) so you’re never running a stale, vulnerable image​. Compare that to on-prem, where your team might postpone OS patching for weeks due to fear of breaking things. On Upsun, staying secure is the default state, not a burden on your admins.
-   **GitOps workflow and CI/CD out of the box:** Upsun is built around Git. You push code to a branch, and the platform _builds and deploys it automatically_ according to your config. It’s a very **GitOps-centric model** – infrastructure as code, and deployments triggered by version control. This means your **DevOps workflow is essentially integrated**. Every git push goes through build hooks (you can run Composer, Drush, tests, etc.) and if successful, deploys to a running environment. Need to integrate with GitHub or GitLab? It supports that too, so you can trigger platform deployments from pull requests, for example. One developer described Upsun as making “managing DevOps as easy as managing code,” which rings true. As a team, you spend less time fiddling with Jenkins or writing deployment scripts because the platform _is_ your CI/CD pipeline. This was a huge win for the University of Missouri’s web team: before, they had to write scripts to spin up test servers and sync databases; with Upsun, the workflow was built-in and **“it just makes our lives easier.”** (source: University of Missouri manages web operations at scale).
-   **On-demand environments for every feature:** This is arguably Upsun’s killer feature for teams: the ability to create **exact clones of production** (code _and_ data) for any new feature or branch. In practice, whenever you start a new feature (say on a git branch), you can spin up a full environment that is an **isolated copy of production database, files, and all**​. No more deploying to a shared dev site and hoping it “works on my machine but also on staging.” Each developer or each feature gets a truly production-like environment. The benefits here are enormous: QA can happen with real data, performance can be gauged accurately, and you catch integration issues early. The folks at the University of Surrey said that having these live preview (UAT) environments for every feature was a _“huge game-changer”_ and fit seamlessly into their workflow​ (source: University of Surrey optimizes developer operations by shifting to Upsun). In the past, manually setting up a UAT site for a feature was so painful it _“would drive us insane”_, recalls their lead developer – now it’s hands-off and automatic. This kind of workflow agility is hard to achieve on typical managed hosts (where you might get one staging site, but not one per branch). It accelerates approval and testing cycles tremendously​.
-   **Easy scaling and performance tuning:** Need more power? With Upsun you can adjust the resources (RAM, CPU, disk) for each service via configuration, or scale out by increasing the number of application instances. Because the platform is built on a container/grid architecture, it’s designed to **scale horizontally and vertically on demand**. You can even spin up a larger instance _temporarily_ on a branch to test how your site performs with double the resources, before deciding to scale up production. One team reported that with Upsun they could bring up a fully synced new site environment in **literally two minutes**, and keep stack components updated much faster than before​ (source: University of Missouri manages web operations at scale). The results? They saw a 300% performance boost for some sites after migrating to Upsun, thanks to modern infrastructure and tuning​. While your mileage may vary, the platform makes it easier to achieve optimal performance (e.g., built-in Redis caching, optimized PHP container, managed CDN integration, etc.).
-   **Integrated services and add-ons:** Enterprise Drupal sites often need more than just PHP and a database. You might use Solr/Elasticsearch for search, Redis for caching, or even a microservice alongside Drupal. On traditional hosting, adding these means provisioning additional servers or using cloud services that you must integrate and secure yourself. Upsun simplifies this: you can add **15+ managed services, each with two lines of YAML**​. Want a Redis cache or an Elasticsearch cluster? Just declare it in your config, and Upsun will provision it as part of the environment, wired into your app’s network. No separate billing or external setup – it’s part of your project. **Eliminate the yak-shaving** of setting up support services. This also ensures consistency between environments (your dev and prod both have the same services defined). As an example, a team I worked with needed to add a Solr search for their Drupal e-commerce site. On their old host, this meant spinning up a separate Solr server and writing custom deploy scripts. On Upsun, we added a few lines to services.yaml and had Solr running in every environment, from dev to prod, in minutes. That’s the kind of flexibility that wins hearts in operations.

**Security and compliance out of the box:** Enterprise IT managers worry about compliance, and rightly so. Upsun shines here by maintaining a robust security posture on behalf of customers. The platform is compliant with a range of standards (GDPR, ISO, SOC, etc.) and provides features like encryption at rest, automated backups, and role-based access control. From a practical standpoint, it _enforces security best practices by default_: every environment is isolated in its container, limiting attack scope. You can’t accidentally leave a database open to the internet, for instance – the platform’s network model is built to prevent common misconfigurations. Moreover, when security updates for underlying components are released, Upsun handles those quickly (often faster than a typical internal team could)​. This all gives enterprise teams peace of mind. One large university noted that Upsun _“satisfied our security team”_ by providing the controls to protect data while still letting devs work efficiently​ (source: University of Missouri manages web operations at scale). That balance of agility and governance is hard to strike, but crucial for enterprise adoption.

Importantly, Upsun achieves all this without feeling like a restrictive, proprietary box. As developers, we appreciate that it uses **standard tools** (Git, YAML, Composer, etc.) and doesn’t lock us into proprietary development practices. If you know Drupal, you don’t have to learn a new site-building UI or weird dev workflows – you just git push and the site builds. In fact, many in the Drupal community have found that among the major hosting options, Upsun _offers the best developer experience_. It’s designed by folks who understand the pains of web development.

Before we sound too idealist: yes, you still have to do your part: writing solid Drupal code, keeping your modules updated (Upsun won’t magically rewrite your outdated custom module!). But it dramatically reduces the infrastructure and deployment friction. As one team put it after migrating hundreds of sites: \_“We no longer worry about spinning up environments…we’ve automated processes that lower our maintenance cost per site across our entire fleet.”\_​ (source: University of Missouri manages web operations at scale) They went from spending 600 hours on manual updates to just a few minutes of automated updates per site. That freed them to focus on improving the sites rather than babysitting them. And ultimately, that’s the real win.

## **Conclusion**

Choosing the right hosting model for an enterprise Drupal application is a critical decision. On-premises hosting might appeal for its control and perhaps satisfy unique legacy requirements, but it comes at the cost of significant ongoing maintenance, slower scaling, and higher risk if your team can’t keep up with updates and hardware issues. Managed hosting takes away much of that operational burden, making life easier initially, yet you may encounter trade-offs in flexibility, environment availability, and adapting the platform to your workflows as your needs grow.

Upsun emerges as a compelling solution by combining the **convenience of managed hosting** with the **power of automation and modern DevOps**. It tackles the common pitfalls (scalability, patching, environment management, integration) in a way that resonates with developers and satisfies enterprise requirements. The technology is built to enable best practices – from Git-driven deployments to ephemeral environments, which translates to faster development cycles and more reliable deployments. And as the real-world examples show, it’s not just theory: organizations have gained agility, saved countless hours, and improved their Drupal site resilience by adopting this approach​ (source: University of Missouri manages web operations at scale).

In the end, the goal is to spend more time building a great Drupal experience for your users and less time fighting servers or waiting on slow processes. Whether you’re an IT manager or a technical lead, it’s worth evaluating how much value each hosting model delivers to your project. On-prem might give you bragging rights for running your own gear, but when uptime, security, and speed are on the line, a platform like Upsun can be a game-changer. After all, in the enterprise world, **time is money, reputation is critical,** and nobody ever complained that their deployment process was _too_ fast or _too_ easy.

### [Why environment parity is a security requirement | Upsun](https://upsun.com/blog/environment-parity-security-requirement/)

# Why environment parity is a security requirement, not just a dev convenience

_Key takeaway: Security is often treated as a production-only configuration, leaving preview and staging environments as fragmented "shadow" infrastructure. Moving security into the application's code via version-controlled configuration ensures that compliance and protection are inherited by every branch, not just opted into at the finish line._

## I. The trade-off between frontend speed and governance

_Key takeaway: The speed gained by "dashboard-first" configuration often creates a fragmented security posture that is difficult to audit at scale._

Frontend platforms have mastered the "push to deploy" workflow. This developer experience is genuinely strong, removing the friction between an idea and a URL. However, this strength often creates a structural trade-off: governance becomes a per-feature configuration.

When security controls like deployment protection, secret sensitivity, or authentication are configured via a dashboard toggle, they exist outside the version-controlled history of the application. 

For a single project, this is manageable. For a Platform Engineer managing fifty projects, it creates a governance tax where they must manually verify that every preview branch and experimental sandbox has the correct boxes checked.

## II. Why "shadow" environments are the primary risk

_Key takeaway: Security is only as strong as your least-protected environment, which is typically a "temporary" preview branch._

In modern development, we spin up dozens of environments a week. If those environments require manual setup to become compliant, they often stay naked for the sake of velocity. This creates a gap where:

-   **Secrets (API keys, database credentials)** are added to preview environments without being marked as sensitive.
-   **Preview URLs** are left public because setting up bypass tokens for automation is an extra step.
-   **Database clones** used in testing contain raw PII because sanitization isn't integrated into the platform's cloning mechanism.

On Upsun, we remove this trade-off. Because the entire stack (runtimes, services, and routes) is defined in `.upsun/config.yaml`, the security posture is versioned with the code. 

When you branch, you don't just branch the code; you branch the governance.

## III. Inherited compliance vs. configured compliance

_Key takeaway: Moving the compliance boundary to the platform level ensures that audit scope matches the architecture diagram._

The goal for any senior technical leader is to ensure that security review happens once, at the platform level.

Vercel provides strong security primitives, but they are often stage-dependent. A team's experimental branch may not automatically share the same compliance posture as their production cluster unless specifically configured to do so.

Upsun’s SOC 2 Type 2 and ISO 27001 boundary applies to every environment the platform creates. Whether a developer is sandboxing a new service or pushing to production, the databases, queues, and workers sit inside the same governance boundary.

-   **Auditability:** Your Upsun unified configuration file provides a clear, linkable record of how infrastructure was configured at any point in time.
-   **Parity:** Every environment is a byte-for-byte clone, meaning the security controls you tested in preview are the exact ones running in production.

### Frequently asked questions (FAQ)

**Is Upsun saying dashboard-driven platforms are insecure?** 

No. Platforms like Vercel have robust security programs and certifications. The distinction is the management model. Dashboard-driven platforms require you to opt-in and align security settings per project. Upsun uses a GitOps model where security is inherited via code.

**How does Upsun handle secrets differently?** 

Upsun manages secrets via the CLI and API, which are then injected into the environment. Because we use a declarative model, it ensures they are protected by the same platform-level SOC 2 controls across every branch.

**Does environment cloning include data security?** 

Yes. In addition, when Upsun clones an environment, it can trigger automatic PII sanitization via deploy hooks. This ensures that while you get production-parity data for testing, you aren't widening your compliance exposure by moving sensitive data into a development environment.

### [Best Fly.io Alternatives in 2026 | Upsun](https://upsun.com/blog/fly-io-alternative/)

# The best Fly.io alternatives in 2026

Fly.io is an edge deployment platform that runs application containers as micro-virtual machines (micro-VMs) across 18 global regions. It targets developers who need multi-region deployments and low-latency performance without managing raw cloud infrastructure. 

As teams scale, however, Fly.io's infrastructure-centric model and unpredictable cost structure push many developers to look for alternatives that offer more predictability, richer managed services, and stronger team collaboration tooling.

This guide covers the best Fly.io alternatives in 2026. Each platform is evaluated against the criteria that matter most to development teams: deployment model, environment management, multi-cloud support, pricing transparency, managed services, and compliance readiness. 

## **Key takeaways**

-   This guide covers Platform-as-a-Service (PaaS) and developer platforms that teams adopt when they outgrow Fly.io, as of 2026.
-   Upsun is the strongest fit for development teams that need multi-cloud deployment, production-parity preview environments with live data, and compliance certifications applied across all environments.
-   Other alternatives suit specific needs: simple Git-to-deploy workflows (Render), fast prototyping (Railway), DigitalOcean-native stacks (App Platform), serverless containers on GCP (Cloud Run), and the mature Heroku add-on ecosystem.
-   Every platform is evaluated against six consistent criteria: deployment model, multi-cloud or BYOC support, environment parity, managed services, pricing, and compliance.     
     

## **Why developers look for Fly.io alternatives**

Fly.io is a capable platform for globally distributed applications, but it has documented limitations that prompt developers to evaluate other options.

-   **Unpredictable pricing at scale.** Fly.io uses a usage-based billing model with no fixed monthly caps. Compute, bandwidth, storage, and multi-region replicas are billed separately, making cost forecasting difficult for teams running production workloads across multiple regions.
-   **CLI-first workflow with a minimal dashboard.** Fly.io is designed around its command-line interface. Teams that prefer a visual interface for deployment management, environment monitoring, or team access control will find the platform's dashboard limited compared to alternatives.
-   **Steep learning curve for non-Docker teams.** Fly.io requires Docker-based workflows. Teams not already fluent in containerization face a significant onboarding cost before they can run production deployments.
-   **Limited managed services and an add-on ecosystem.** Compared to more established PaaS platforms, Fly.io offers fewer plug-and-play services for queues, object storage, background workers, and third-party integrations. Teams often need to manually wire in external services.

## **What to look for in a Fly.io alternative**

Before evaluating specific platforms, it helps to define the criteria that distinguish a strong Fly.io alternative from a lateral move.

-   **Deployment model and developer experience.** A strong alternative supports Git-based deployments and automates build, test, and deploy pipelines without requiring teams to manage container configuration manually. 
-   **Environment parity and preview environments.** Production parity across development, staging, and production environments is a key indicator of platform maturity. Platforms that offer isolated, cloneable environments per branch eliminate the staging drift problem and accelerate QA cycles.
-   **Multi-cloud and regional flexibility.** Vendor lock-in to a single cloud provider increases long-term risk. Platforms that support deployment across AWS, Google Cloud, Azure, and alternative providers give teams the portability to meet compliance, latency, and cost requirements across different markets.
-   **Managed services catalog.** The databases, caches, search engines, and message queues are offered as first-class managed services rather than DIY add-ons. A complete catalog reduces operational overhead and third-party integration costs.
-   **Pricing transparency.** Predictable pricing, whether fixed, resource-based, or usage-based, is essential for budgeting. Platforms with clear resource-level pricing and no hidden egress or bandwidth charges are significantly easier to adopt at scale.
-   **Compliance and security posture.** Certifications such as ISO 27001, SOC 2, PCI DSS, HIPAA, and GDPR, and whether they apply across all environments, not only production.

## **The best Fly.io alternatives in 2026**

#### **1\. Upsun**

Upsun is a managed multi-cloud application platform that defines application code and infrastructure in a single YAML file. It runs across AWS, GCP, Azure, OVHcloud, and IBM Cloud with identical Git-push workflows, and clones full environments, including live data, per branch."

It runs across AWS, GCP, Azure, OVHcloud, and IBM Cloud with the same workflow regardless of provider. Upsun supports various languages, a solid managed services catalog, and resource-based pricing that charges for what you actually provision, not what a tier says you might need.

**Key capabilities:**

-   Multi-cloud deployment across AWS, GCP, Azure, OVHcloud, and IBM Cloud.
-   Git-push deployment with automatic preview environments per branch.
-   Managed services catalog: PostgreSQL, MySQL, Redis, Elasticsearch, OpenSearch, RabbitMQ, and Kafka.
-   10 supported runtimes, including PHP, Python, Node.js, Java, Go, Ruby, and .NET.
-   Compliance with ISO 27001, SOC 2, PCI DSS, TX-RAMP, PCI DSS Level 1 HIPAA, and GDPR.

**Best for:** Development and enterprises that need multi-cloud deployment, production-parity preview environments, comprehensive compliance coverage, and predictable resource-based pricing.

**Pros:**

-   Full environment cloning, including live data,  in under one minute.
-   Multi-cloud support across AWS, GCP, Azure, OVHcloud, and IBM Cloud with identical YAML-based workflows.
-   Comprehensive compliance certifications: ISO 27001, SOC 2, PCI DSS, HIPAA, GDPR.

**Cons:**

-   Resource-based billing requires more upfront planning.
-   Not optimized for solo developers or side projects.

#### **2\. Render**

A managed PaaS that prioritizes deployment simplicity for web services, static sites, cron jobs, and background workers.

Render offers Git-based deployment with automatic SSL, a built-in CDN for static sites, and a visual dashboard. It supports web services, static sites, cron jobs, and background workers as first-class service types, with managed Postgres and Redis available alongside. Render runs on its own infrastructure with no multi-cloud or BYOC option.

**Key capabilities:**

-   Git-based deployment with built-in preview environments.
-   First-class background workers and cron jobs.
-   Managed Postgres and Redis.
-   Free tier covering static sites and hobby services.

**Best for:** Small teams and indie developers who need fast, simple deployments without infrastructure configuration.

**Pros:**

-   Simple Git-to-deploy workflow with minimal configuration.
-   Generous free tier for static sites and hobby services.
-   Clean, visual dashboard suitable for non-DevOps users.

**Cons:**

-   No multi-cloud support; locked to AWS infrastructure.
-   Limited environment management; no production-parity cloning.

#### **3\. Railway**

Railway is a developer-focused cloud platform built for rapid application deployment with a visual project dashboard and flexible runtime support.

Railway targets developers who want the fastest path from code to a running service. Builds use Nixpacks or Docker, the visual dashboard handles services, databases, and environment variables, and pricing is usage-based with a credit on the Hobby plan. Railway is widely used for prototyping and early-stage projects.

**Key capabilities:**

-   Git-based deployment with no configuration for common stacks.
-   Visual dashboard for services, databases, and environment variables.
-   Managed Postgres, MySQL, Redis, and MongoDB.
-   Usage-based pricing with a low entry cost.

**Best for:** Individual developers and early-stage teams that prioritize speed of deployment and ease of use over infrastructure control.

**Pros:**

-   Minimal configuration to deploy most stacks
-   Clean visual interface for service and variable management
-   Low cost of entry for hobby projects

**Cons:**

-   Usage-based pricing can scale unpredictably for production workloads.
-   Limited enterprise features, compliance certifications, and private networking options.

####   
**4\. DigitalOcean App Platform**

DigitalOcean App Platform is a managed PaaS layer built on top of DigitalOcean's cloud infrastructure for teams already in the DigitalOcean ecosystem.

DigitalOcean App Platform supports Git-based deployments from GitHub and GitLab, with automatic HTTPS, horizontal scaling, and managed databases. It integrates with DigitalOcean Spaces for object storage and DigitalOcean Managed Databases. Workloads run only on DigitalOcean regions.

**Key capabilities:**

-   Git-based deployment from GitHub and GitLab.
-   Automatic HTTPS and horizontal scaling.
-   Integration with DigitalOcean Managed Databases and Spaces.
-   Support for both containerized and source-based deployments.

**Best for:** Teams already using DigitalOcean infrastructure who want a managed deployment layer without switching providers.

**Pros:**

-   Predictable pricing with clear resource tiers.
-   Tight integration with the broader DigitalOcean product suite.
-   Single-vendor billing and operations.

**Cons:**

-   Single-cloud platform; no deployment flexibility across AWS, GCP, or Azure.
-   Limited advanced environment management compared to enterprise PaaS options.

#### **5\. Google Cloud Run**

A fully managed serverless container platform that runs stateless containers on demand without server provisioning.

Cloud Run runs containerized workloads with scale-to-zero behavior and fast horizontal scaling, billing per request-processing time. It integrates natively with Cloud SQL, Pub/Sub, Artifact Registry, and Secret Manager. Cloud Run is cost-effective for workloads with variable traffic, but configuration requires Docker and Google Cloud expertise.

**Key capabilities:**

-   Serverless container execution with scale-to-zero.
-   Native integration with the Google Cloud services ecosystem.
-   Pay-per-request-processing-time billing.
-   Any containerized runtime, no language restrictions.

**Best for:** Engineering teams already on Google Cloud with strong Docker and GCP expertise that need fine-grained control over serverless containers.

**Pros:**

-   Scales to zero when idle; cost-effective for variable or low-traffic workloads
-   Native integration with the full Google Cloud services ecosystem
-   Supports any containerized runtime without language restrictions

**Cons:**

-   Requires Docker and Google Cloud expertise to configure
-   No Git-native deployment abstraction; teams operate their own CI/CD pipeline.

#### **6\. Heroku**

Heroku is one of the original Platform as a Service providers, offering a simple deployment model for web applications with a large add-on marketplace.

Heroku supports Git-based deployment with buildpacks, a large third-party add-on marketplace, and worker dynos for background jobs. It supports Ruby, Node.js, Python, Java, PHP, and Go, and its managed Postgres, Redis, and Kafka add-ons are widely used. Heroku runs on AWS infrastructure.

**Key capabilities:**

-   Buildpack-based deployment with no configuration for common stacks.
-   Worker dynos as first-class background processes.
-   Heroku Postgres, Redis, and Kafka, plus a broad third-party add-on marketplace.
-   Review apps for pull-request preview environments.

**Best for:** Teams with existing Heroku applications that are not yet ready to migrate, or developers who need a familiar Heroku-style workflow as a short-term solution.

**Pros:**

-   Mature ecosystem with hundreds of third-party add-ons.
-   Simple Git-to-deploy model with broad language support.

**Cons:**

-   No multi-cloud support; limited to AWS infrastructure.
-   No free tier, with pricing higher than newer alternatives.
-    Pricing is high relative to alternatives with equivalent capabilities.

## **Quick look: Fly.io alternatives compared** 

## **Choosing the right alternative**

The core question when moving away from Fly.io is how much infrastructure responsibility you want to carry. Fly.io hands you the controls and expects you to use them. The platforms in this list take varying amounts of that responsibility back.

For teams that need multi-cloud deployment, production-accurate environments, and compliance coverage without building custom infrastructure, Upsun is the most complete option in this comparison. The certifications are built in, the environments are cloned in under a minute, and the workflow is consistent regardless of which cloud you deploy to.

Render and Railway are the right starting points if your needs are simpler, a single service, an early-stage product, or a small team that wants to move fast without configuration overhead. Google Cloud Run suits teams already deep in the GCP ecosystem with the engineering capacity to manage it. 

Multi-cloud deployment and per-environment compliance in the same platform is a rare combination in this category. If those are on your requirements list, Upsun is the only platform in this comparison that covers both without requiring you to wire them together yourself.

## **Frequently Asked Questions (FAQs)**

**What is the best Fly.io alternative in 2026?**

There is no single best alternative, because teams leave Fly.io for different reasons. Upsun is the strongest choice for development teams that need multi-cloud deployment, production-parity preview environments, and compliance applied across every environment. Render and Railway are stronger choices for teams that prioritize simplicity over multi-cloud or compliance.

**Can I migrate from Fly.io to Upsun?**

Yes. Upsun supports containerized applications across 10 runtimes, including Node.js, Python, Go, Ruby, Java, PHP, and .NET, and applications are described in a single YAML configuration file. Most Fly.io applications can be ported by writing the equivalent Upsun configuration and connecting the Git repository. The exact effort depends on the number of services and managed services in use.

**Which Fly.io alternative supports multi-cloud deployment?**

Upsun supports multi-cloud deployment across AWS, GCP, Azure, OVHcloud, and IBM Cloud as a managed multi-cloud PaaS, with identical workflows across providers. Render, Railway, DigitalOcean App Platform, Google Cloud Run, and Heroku each run on a single underlying cloud, so multi-cloud or BYOC is not part of their model.

**Which Fly.io alternative is best for preview environments with production data?**

Upsun clones the production environment, including live data, configuration, and code, on every branch in under one minute. Render and Heroku offer preview or review environments, but they do not automatically clone production data. For regulated workloads, Upsun's compliance certifications apply to preview environments as well.

**Which Fly.io alternative is best for regulated industries?**

Upsun is built for regulated teams, with compliance covering ISO 27001, SOC 2, PCI DSS, HIPAA, and GDPR applied across all environments. Google Cloud Run inherits GCP-level certifications, but teams using it are responsible for the application-layer compliance scope themselves. Other alternatives in this list are not positioned specifically for regulated industries.

### [Upsun configs vs. DIY Terraform or Kubernetes | Upsun](https://upsun.com/blog/upsun-configurations-versus-diy-terraform-or-kubernetes/)

# Comparative deep dive: Upsun configurations versus DIY Terraform or Kubernetes

For the modern platform engineer, the choice isn't whether to use "Infrastructure as Code" (IaC). That battle is won. The real choice is the level of abstraction at which that code operates.

In a DIY world (typically built on a combination of Terraform for provisioning, Helm charts for packaging, and Kubernetes YAML for orchestration) you are coding the "how" of the infrastructure. You are managing primitives. In the Upsun world, you are coding the "what" of the application.

To be clear: well-run Terraform and Kubernetes platforms exist. 

They rely on strong conventions, internal modules, golden paths, and a dedicated platform team to keep things sane. 

This comparison assumes a competent DIY setup, not a chaotic one. 

**The question is not whether your team** _**can**_ **build it, but whether they** _**should**_ **be the ones operating and maintaining it at the primitive layer.**

## The cognitive load of the primitive layer

In a DIY setup, a developer or platform engineer is responsible for the entire lifecycle of the infrastructure primitives. 

Even with a library of well-maintained Terraform modules, your team must still author and maintain the "glue" that connects them. 

To get a standard web application with a database live on a hyperscaler, a typical DIY configuration requires:

-   **VPC and networking:** Defining subnets, route tables, internet gateways, and NAT gateways.
-   **Security groups and IAM:** Writing granular ingress and egress rules and complex IAM policies to allow the application to talk to the database.
-   **State management:** Managing Terraform state files, locking mechanisms, and backend storage (S3 or DynamoDB).
-   **Orchestration boilerplate:** Defining Kubernetes Deployments, Services, IngressControllers, and Horizontal Pod Autoscalers (HPA).

**The Upsun alternative: the config-to-asset ratio**

On Upsun, these primitives are "absorbed" by the platform. Your primary artifact is a version-controlled configuration file (`.upsun/config.yaml`). 

Compared to the fragmented stack of Terraform, Helm, and Kubernetes manifests required to operate a production application, Upsun reduces the amount of configuration your team must author and maintain by an order of magnitude.

When you move the abstraction layer up, you drastically improve your "config-to-asset" ratio. You gain the same infrastructure outcomes with significantly less code. 

This reduces the cognitive tax on your senior engineers, allowing them to stop being "YAML mechanics" and return to being application architects.

## Environment parity: why "close enough" is a failure mode

The greatest risk in DIY infrastructure is "environmental drift." Even with the best intentions, a staging environment in a DIY Kubernetes cluster eventually drifts from production.

**The build it yourself reality:**

In a DIY stack, creating a full-fidelity production clone with real data typically requires custom scripting, database sanitization pipelines, and manual cleanup. Which is why most teams avoid doing it routinely. Consequently, staging becomes a simplified, lower-resource version of production, leading to the "it worked in staging" failure mode.

**The Upsun standard:**

Upsun enforces environment parity through **Standardized Environments**. 

Because the infrastructure is defined by the application requirements, every branch is a production-grade clone. 

When you create a new environment on Upsun, you aren't just copying code; you are cloning the entire stack, services, configuration, and data, instantly. 

This is a platform-native capability that is functionally impossible to replicate in DIY without significant custom engineering and long term maintenance.

## A comparison of operational intent

## Day 2 operations: the hidden maintenance trap

The true cost of DIY infrastructure is "Day 2" operations, the ongoing maintenance required to keep the lights on. In a DIY Kubernetes environment, your team is responsible for cluster upgrades, patching underlying container runtimes, and ensuring provider API compatibility.

In practice, this means your most senior engineers become on-call maintainers for infrastructure they didn’t want to own in the first place.

Upsun treats infrastructure as a **managed dependency**. 

You gain the outcomes people adopt Kubernetes and Terraform for scalability, reproducibility, and automation, without having to operate those systems directly. 

Upsun manages the cluster upgrades, the security patching of the underlying runtimes, and the orchestration of the build process. Your team only manages the application.

## Failure modes: where DIY breaks

In a DIY environment, there are "silent" failure modes that have nothing to do with your application code. 

If a Terraform state file becomes desynced or locked due to a failed network request, your entire deployment pipeline grinds to a halt. Recovery often requires manual state surgery; a high-risk operation that pulls your best engineers away from product work.

Upsun removes these failure modes from your daily operations. 

You aren't responsible for the Kubernetes API version or the state of the underlying network. By moving these responsibilities to the platform layer, you reduce the surface area for failure and eliminate the "infrastructure firefighting" that stalls roadmaps.

## The economic case for the senior engineer

For a Senior Platform Engineer, the ROI of Upsun is about reclaimed capacity. 

Industry data suggests that up to 80% of developer time is spent on managing the delivery pipeline rather than building features.

**By adopting a standardized configuration model, you are buying back 80% of your senior team's capacity.** 

That reclaimed time doesn't go to more meetings; it goes to architecture, reliability improvements, and product-facing work that actually advances an engineer's career. You transition from a "build and maintain" posture to a "deploy and innovate" posture.

## An upgrade in ownership

DIY infrastructure offers the illusion of total control, but it often results in total overhead. For teams that need to scale without expanding their DevOps headcount, the choice is clear.

Standardized environments allow you to codify your application intent once and let the platform handle the execution. 

For teams that want Kubernetes-level outcomes without Kubernetes-level ownership, standardized environments aren’t a compromise, they’re an upgrade.

### [Cloud cost management | Upsun](https://upsun.com/blog/cloud-cost-management/)

# Predictable cloud pricing: guide to cloud cost management

_Imagine paying for a "Large" cloud hosting plan when your application only needs "Medium" resources most of the time. Or being locked into a "Small" tier that can't handle your growth spurts._ 

The mismatch between your applications' resource needs and your cloud bill means you're either overpaying for unused resources or facing surprise bills when demand spikes. Why does this happen? Traditional fixed pricing models force businesses into predefined 'one-size-fits-all' tiers that rarely match actual usage patterns. 

As technology advances and workloads become more dynamic, rigid tier pricing is no longer cost-effective. It leaves companies paying for resources they don't need while limiting their ability to scale efficiently.

The solution lies in a predictable pricing model that strikes a balance between flexibility and cost certainty. This guide explores predictable cloud pricing, why it matters, and how you can leverage flexible resource scaling to optimize your infrastructure costs, with a focus on the underlying resources: CPU, RAM, storage, and environments.

## **Understanding cloud cost models**

### **Traditional fixed pricing**

Traditional models often inflate cloud hosting costs by forcing you into oversized plans. Think of it like paying for an all-you-can-eat buffet; you pay the same price whether you have one plate or ten. In the cloud context, this means paying for a specific server size or resource allocation 24/7, even when you could get by with less.

Here's how the traditional fixed pricing model works: 

1.  Flat-rate pricing – You pay a fixed monthly or yearly fee regardless of whether you use 20% or 100% of your resources.
2.  Tiered pricing – You pay based on predefined tiers. You choose from "Small," "Medium," or "Large" packages with fixed resource allocations.
3.  Reserved instances/commitments – You commit to a certain level of usage for a long period (usually 1–3 years) in exchange for lower rates. Great if your workloads are stable, but risky if demand changes.

Each of these models has its pros and cons, as it provides stability but can result in inefficiency. There are instances where traditional fixed pricing is a better fit and works well for businesses. 

**Example: A small cafe with a steady website**  
A bakery that operates a simple website showcasing its menu, location, and contact information. Traffic is steady every day and remains unchanged. In this case:

-   Paying a flat monthly fee makes sense because the resource allocation matches their consistent needs.
-   The business avoids surprises and knows precisely what its bill will be.
-   Budgeting is straightforward.

In such situations, the stability of traditional cloud pricing can outweigh the flexibility of transparent and predictable pricing.

### **Predictable cloud pricing**

Predictable cloud pricing shifts the paradigm from fixed packages to transparent provisioning. Rather than choosing between pre-configured "starter," "professional," or "enterprise" tiers, you select the exact compute power, memory, and storage your application requires, with full cost visibility before you commit.

The core of predictable pricing is **provision-based pricing**, which means you pay for the specific resources you provision during each time period. Rather than being charged a fixed monthly fee regardless of your needs, you're billed for the exact CPU, RAM, and storage you provision as your requirements change.

Think of it like utilities:

-   Your electricity bill: you pay for the electricity capacity you need, not a preset package that might be too big or too small for your home. 

Or a more perfect example, which I love:

In an arcade, you pay only for each game you play. Not a large amount upfront, but a little bit each time you use a game. Play one game, you spend one token, or play ten games and you spend ten tokens.

In the cloud, it's the same principle: instead of paying for predetermined packages with resources you might not need, you can dynamically scale your provisioned CPU, memory, and storage up and down, paying for exactly what you provision during each period.

## **Key resources**

**1\. Central Processing Unit (CPU)**  
Think of the CPU as the **brain** of the computer or server. The performance of your application depends on how fast and powerful the CPU is. CPU usage is often measured in **vCPUs (virtual CPUs)** or **CPU time**. Under provision-based pricing:

-   A small app that gets just a few requests per hour might use only a fraction of a CPU’s processing power.
-   A high-traffic e-commerce site might spike to dozens of CPUs during peak shopping seasons.

**2. Random Access Memory (RAM)**

RAM affects how many processes your app can run simultaneously and how fast it can respond. The more RAM you have, the more tasks your app can handle at once.

**Example**: An app may need more RAM during heavy data processing periods. With dynamic provisioning, you can scale up memory allocation when needed and scale back down afterward, paying for the exact provisioning during each period rather than being forced into preset memory configurations.

**3\. Storage**

Storage is where your files, databases, and media are kept. Pricing is typically based on the amount of storage you allocate, measured in gigabytes or terabytes. Different storage types have different costs based on performance requirements.

**4\. Environments**

Environments (dev, test, staging, production) are critical in app development. Environments are the playgrounds where your app lives; these include development, staging, and production. Each environment uses its own share of resources (CPU, RAM, storage).

**Example:** A development team testing a new feature can run a staging environment for a week, pay for that usage, and shut it down afterward.

## **How predictable pricing transforms cloud cost management**

Take a food delivery application. Traffic is quiet most of the day, but spikes dramatically during lunch hours. Under traditional pricing, you would have to pay for infrastructure to handle peak demand 24/7, resulting in higher costs during off-peak hours. With flexible resources, you can provision resources that handle your typical load and have the ability to quickly scale your resources when needed, rather than paying for peak capacity whether it is needed or not.

Businesses building and running custom applications significantly benefit from provision-based pricing. Traditional pricing models force companies to choose oversized packages, paying for infrastructure they may not fully utilize. With provision-based pricing:

-   **Agility in development**: Developers can spin up and tear down environments for testing or staging without fear of sunk costs. This accelerates innovation while keeping costs lean and efficient.
-   **Cost optimization**: Avoid paying for predetermined packages that include unused resources during low-demand periods. A custom app that only sees traffic on weekends incurs higher costs than one that considers traffic throughout the month.
-   **Scalable growth**: As a custom app gains users, costs scale predictably. No need to renegotiate contracts or jump into higher flat tiers prematurely.
-   **Precise resource allocation**: Teams can monitor exactly which parts of an app consume CPU, RAM, or storage, then optimize accordingly. This drives both performance and efficiency.

## **Cloud cost optimization with Upsun** 

The traditional fixed pricing creates rigid, one-size-fits-all pricing tiers that rarely align with actual resource needs. Upsun addresses this with Upsun Flex, a transparent and predictable pricing model, where you pay only for the exact resources you provision. 

**How Upsun flex works**

-   **Granular r****esource selection****:** Choose exactly the CPU, memory, and storage each part of your application needs and scale them independently.
-   **Transparent pricing**: Clear, per-resource pricing with no hidden costs or forced bundling.
-   **Environment-specific scaling**: Scale different resource levels for development, staging, and production environments independently.
-   **Autoscaling**: Automatically adjust your resource provisioning as demand changes.

**Example**: An AI document processor can start with minimal resource provisioning during idle periods and automatically scale up CPU allocation during batch processing jobs, then scale back down when processing completes, paying for the exact resources provisioned during each phase rather than maintaining peak capacity continuously.

Different parts of your application can scale independently. Your database might need more memory provisioning while your web servers need more CPU provisioning, you pay for exactly what each component requires as it scales.

### **Why this matters for modern applications**

Upsun provision-based pricing is well-suited for custom applications. Unlike fixed pricing, Upsun flex ensures:

-   **Precise scaling**

Upsun scales costs up and down automatically. For example, an AI document processor may require significant CPU resources during batch jobs but minimal resources between processing cycles. 

-   **Cost-efficient environments**

Development, testing, and staging environments incur costs only while they are active. Applications that require multiple environments only pay for these environments when they are in use, not 24/7.

-   **Independent scaling**

 Different parts of your application can scale independently of each other. Your database might need more memory, while your web servers need more CPU; you pay for exactly what each component uses.

-   **Transparent cost control**

Full visibility into exactly what resources you're paying for as they scale.

## **Conclusion**

Predictable cloud pricing represents a shift toward more efficient and responsive cloud resource management, aligning costs directly with your actual resource needs as they change across CPU, memory, storage, and environment scaling.

Upsun Flex provides a transparent and dynamic pricing option that aligns your cloud costs with your changing resource requirements. You can build with complete visibility into your resource provisioning and costs, without being forced into oversized packages or preset tiers that don't match your actual usage patterns.

_Explore_ _Upsun's pricing_ _and see how flexible allocation can optimize your infrastructure cost management._

### [Vercel vs. Upsun: Platform architecture | Upsun](https://upsun.com/blog/vercel-vs-upsun-platform-architecture-comparison/)

# Vercel vs. Upsun: comparing platform architecture after the April 2026 incident

_Key takeaway: The April 2026 Vercel incident is a useful prompt to revisit where the audit trail for infrastructure change lives, how the compliance scope for a full-stack application is composed, and how portable the deployment is across clouds. Upsun's structural answer is a Git-native, YAML-defined model that covers the whole application._

## I. The architecture of a compromise

_Key takeaway: The surface area of any hosted platform includes the vendor's own supply chain. How visible that surface is from the customer's side varies between platforms._

The April 2026 Vercel security incident originated in a third-party tool connected to an employee's Google Workspace and escalated into internal Vercel systems. Per Vercel's bulletin, customer impact was limited, and Vercel has engaged incident response experts and notified law enforcement. Any platform can face an incident, and Vercel's handling has been direct and professional.

What the incident illustrates is a property of the shared multi-tenant SaaS model, not a failure of Vercel in particular. Every shared platform, Upsun included, has a supply chain somewhere in its architecture. The question worth asking is where each platform draws its boundaries, and how much of the application's operational surface a customer can see and audit from their own side.

The structural difference on Upsun is not in how secrets are stored. Environment variables on both platforms work similarly: values set via CLI or console, with an opt-in `sensitive` flag that hides them from the UI. The difference sits one layer up, in how infrastructure itself is defined and reviewed.

On dashboard-driven platforms, the configuration for routes, rewrites, function settings, region selection, and integration wiring lives in the platform operator's admin surface. Audit logs for those changes live in the platform's logs, behind the platform's access model.

On Upsun, that configuration lives in a `.upsun/config.yaml` file in the customer's own Git repository. Every change to a service definition, a route, a firewall rule, or a resource profile is a commit, reviewed through the customer's pull-request process, visible in their git log. The audit trail for infrastructure change is the audit trail the engineering team already maintains for application code.

## II. Where the audit trail for infrastructure lives

_Key takeaway: The audit trail for infrastructure change should be visible from inside the customer's own systems, not only from inside the vendor's._

Teams pick Vercel because the developer experience around the frontend runtime and preview flow is good. For teams whose backend is a managed database and a handful of functions, that strength compounds. The trade-off shows up when the application grows past that shape, and the operational surface outside the frontend needs the same level of visibility and review as the code.

Upsun treats infrastructure definition as code, which changes what's auditable from the customer's side:

-   **Infrastructure in Git.** Routes, services, workers, crons, firewall rules, service relationships, and resource allocations are declared in `.upsun/config.yaml` in your repository. Every change is a commit, reviewed through your pull-request process, visible in your git log. The audit trail for infrastructure change is the same trail the engineering team already maintains for application code.
-   **Secrets outside the config file, with parity on the flag itself.** Environment variables on both Upsun and Vercel use an opt-in `sensitive` flag that hides values from UI and CLI output. The structural difference is not in the flag. It's that on Upsun, the infrastructure that consumes those secrets (which services exist, what relationships they have, what firewall posture they run under) is version-controlled, so changes to that infrastructure are auditable outside the vendor's logs.
-   **Explicit service relationships.** On Upsun, a service receives credentials and connection information for another service only through a `relationships`declaration in YAML. The connection graph between your services is declared in code, not implicit in the platform's defaults.
-   **Per-service outbound firewall rules.** The firewall property in `.upsun/config.yaml` restricts which external hosts each service can reach, declared alongside the service definition. Outbound network posture is reviewed in the same pull request as the code that uses it.

## III. Portability across clouds, defined in code

_Key takeaway: A single-provider deployment model makes a lot of decisions easy, and makes those decisions harder to revisit later. Portability across clouds is a structural property that reduces that cost._

When an incident, a procurement requirement, or a compliance scope change prompts the question "can we run this somewhere else," the answer is shaped by how tightly the application is bound to one vendor's runtime. If the deployment logic is specific to a single platform, moving is a rewrite. If the deployment logic is generic, moving is a configuration change.

Upsun's `.upsun/config.yaml` is the same file whether the project runs on AWS, Azure, Google Cloud, or OVH, across dozens of regions. You pick the hyperscaler when you create the project, and the configuration does not change when you change the hyperscaler. Upsun is also available on the AWS, Azure, Google, and IBM marketplaces, so teams with existing committed-use agreements on any of those clouds can apply them against their Upsun usage.

Your application runs in Upsun-operated environments on the hyperscaler you choose. The portability is in the configuration, not in where the infrastructure is physically operated. What that changes is the cost of revisiting the cloud decision: it's a project setting instead of a quarter-long engineering project.

For teams whose roadmap includes regulated customers, sovereign-region requirements, or enterprise procurement that asks about hyperscaler preferences, that flexibility is often the difference between a yes and a replatform.

## Frequently asked questions

**Is Upsun more secure than Vercel?**

Both platforms hold SOC 2 Type 2 certifications and are used in production by serious teams. The differences worth comparing are structural. Where the audit trail for infrastructure change lives: on Upsun, in the customer's own Git repository; on Vercel, in the platform's admin surface and logs. How the compliance scope for a full-stack application is composed: Upsun's certifications cover the whole platform including databases, queues, object storage, and workers, while Vercel's SOC 2 scope covers the Vercel layer and HIPAA BAAs are available on Pro and Enterprise plans, with marketplace partners carrying their own certifications for stateful services. What options are available: Upsun offers SOC 2 Type 2, ISO 27001, with PCI DSS and HIPAA options across the platform.

**Does Upsun support Next.js?**

Yes. Next.js is a first-class runtime on Upsun. You define the application and its backing services (databases, caches, search, queues) in `.upsun/config.yaml`. Environment variables are set via the Upsun CLI or Console and can be flagged as sensitive so their values are hidden from UI and CLI output, the same opt-in model Vercel offers. Every Git branch gets a byte-for-byte clone of production (code, data, and services), which is useful when validating the application before cutting over from another platform.

**How long does it take to migrate from Vercel?**

For most Next.js applications, migration is primarily a matter of writing a `.upsun/config.yaml` file that describes the application and its services, and moving environment variables and DNS. Because every branch on Upsun gets a byte-for-byte preview environment cloned from production (code, data, and services), you can run the full migrated application against production-shape data before cutting over. Upsun's application services team supports migrations on a hands-on basis when that's the right path.

### [Migration blueprint for moving without rewriting | Upsun](https://upsun.com/blog/migration-blueprint-for-moving-your-application-without-rewriting/)

# Migration blueprint for moving your application without rewriting

The decision to migrate a production application is rarely about the destination. It is about the friction of the journey. 

For most engineering leaders, the word "migration" is a synonym for "refactor." 

The industry has conditioned us to assume that moving to a modern cloud platform requires throwing away years of stable configuration, learning a new proprietary DSL, and rewriting core application logic to fit a specific container or serverless model.

This "migration tax" is the single biggest reason why technical debt accumulates. Teams stay on aging, insecure, or expensive infrastructure because the cost of moving feels higher than the cost of staying.

However, when you analyze why migrations fail to meet deadlines or budgets, it is rarely the application code that causes the blowout. It is the infrastructure primitives. 

A migration strategy (what we call a "migration blueprint") focuses on decoupling your application from those primitives. By using standardized environments, you can move the application as it is, while the platform absorbs the complexity of the underlying wiring.

## Who this blueprint is for

This migration blueprint is designed for organizations managing long-lived, complex application estates where stability is non-negotiable. 

This blueprint applies if you are migrating:

-   **Legacy or long-lived applications:** Systems that have years of institutional knowledge baked into the code and cannot afford a multi-month refactor.
-   **Multi-service applications:** Workloads that depend on tight integration between databases, caches, search engines, and background workers.
-   **Custom infrastructure:** Applications currently running on virtual machines, Elastic Beanstalk, legacy PaaS, or self-managed Kubernetes clusters that have become difficult to patch or scale.
-   **Risk-sensitive workloads:** Applications in regulated industries where a failed cutover or data corruption carries significant business consequences.

## The hidden cost of "primitive debt"

When you migrate to a raw cloud provider, you are forced to pay a "primitive debt" before the first line of code even runs. 

This debt is the primary source of cognitive overload for senior engineers. It includes manual provisioning of virtual machines, writing thousands of lines of Terraform to define VPCs and subnets, and manually configuring IAM roles for every service connection.

For a mid-market organization, this manual overhead often consumes the majority of senior engineering time, delaying delivery by quarters rather than weeks. 

The goal is to eliminate this work. You are evaluating a platform based on how much of this "boring" infrastructure it can automate away.

## Pillar 1: Declarative service mapping over manual wiring

The first step in a rewrite-free migration is moving from imperative infrastructure to declarative service mapping. 

In a traditional migration, you tell the provider _how_ to build a database: "Create a t3.medium instance, attach 50GB of storage, and open port 5432."

In this blueprint, your primary migration artifact is a single, version-controlled configuration file (.upsun/config.yaml). This file defines:

-   **The application runtime:** Your specific language and build steps.
-   **Backing services:** The databases (PostgreSQL, MariaDB, Redis) and search engines (OpenSearch, Solr) your app requires.
-   **Resource relationships:** How these components talk to each other without manual networking configuration or opening public access to the services.

Because Upsun uses standardized environments, the platform already knows how to provision and secure these services. 

You don't have to rewrite your application's connection logic; the platform provides a consistent relationship between your app and its services. 

This turns the migration into an act of deployment rather than an act of manual engineering.

## Pillar 2: Eliminating environment drift through standardization

A primary reason for code rewrites during migration is "environment mismatch." 

An application that runs on a developer's laptop might fail in a legacy staging environment because of a slight difference in a library version or a different filesystem permission model.

To avoid a rewrite, you need environment parity. 

Upsun’s standardized environments ensure that the build and runtime are identical across every stage of the lifecycle. This is particularly critical for stateful workloads and monoliths that expect a specific, predictable environment.

When you define your application dependencies in your configuration, the platform creates a containerized environment that remains consistent from the first branch to final production. 

You don't have to "fix" your code to work in the cloud; the platform provides the predictability the code expects. For senior architects, this consistency is the ultimate safety net against the "it worked on my machine" syndrome.

## Pillar 3: Validating with production-perfect clones

The most dangerous moment of any migration is the "cutover." Traditionally, this is preceded by testing in a staging environment that is a "close approximation" of production.

In this blueprint, "close enough" is not an option. 

Upsun allows you to create production-perfect clones for every branch. When you are testing your migration on a feature branch, you are testing against a perfect replica of your target production stack. This includes your service versions, your infrastructure configuration, and a sanitized clone of your production data.

This allows you to validate the migration of the actual application logic against real world conditions. 

This capability transforms migration from a "leap of faith" into a verified deployment process. If the migration works on the branch, you have the proof required to proceed with the production cutover.

## Portability without the lock-in

A common trap in modernization is getting "locked in" to a provider's proprietary services as part of the migration. 

While these services offer power, they often require you to rewrite significant portions of your application to fit their specific APIs.

Upsun’s approach is built on portability. 

While you choose your cloud provider (AWS, Azure, GCP, IBM, or OVHcloud) at project creation, the platform layer remains identical. 

This means you can move your application from one provider to another by re-provisioning the project on the new provider, without rewriting your application code or your infrastructure configuration.

This gives you strategic optionality. You can meet data sovereignty requirements or satisfy an executive mandate for cloud diversity without the traditional increase in operational overhead.

## The economic case: reallocating senior engineering time

From a leadership perspective, a "no-rewrite" migration is about resource allocation. 

In most migrations, infrastructure work consumes the majority of senior engineering time. Every hour a senior developer spends debugging a Terraform script or refactoring a legacy module for a new provider is an hour they aren't spending on your product roadmap.

By letting the platform manage the "grind" of infrastructure, you can execute a migration with a smaller team in a fraction of the time. This is the difference between a migration that costs the company months of innovation and one that serves as a springboard for faster delivery.

## Making migration repeatable

The goal of this blueprint isn't to never migrate again. It is to make migration a repeatable, low-risk operation instead of a once-a-decade crisis.

By adopting a model based on standardized environments, you remove the friction of the "everything refactor" and eliminate the cognitive load of managing cloud primitives. You give your team the guardrails they need to move, scale, and iterate with confidence.

Migration doesn't have to be a rewrite. It just needs a better platform.

### [Vercel vs. Upsun: A structural comparison | Upsun](https://upsun.com/blog/vercel-vs-upsun-full-stack-application-2026/)

# Beyond the frontend: choosing between Vercel and Upsun for full-stack applications in 2026

If you're building a modern web application in 2026, Vercel is almost certainly on your shortlist, and probably near the top of it. The developer experience Vercel pioneered for Next.js and the frontend ecosystem around it is a real achievement. Push a branch, get a preview URL, ship. It works, it's fast, and an entire generation of frontend teams have built their workflow around it.

This article is not here to argue with any of that.

It's here because the applications teams are building have grown past the part of the stack Vercel was designed around, and the questions a full-stack team has to answer about a platform are different from the questions a frontend team has to answer. Where data lives. What compliance covers. Which cloud the application runs in. How infrastructure is described and reviewed. Whether backend services get the same treatment as the frontend.

This is a structural comparison of the two platforms on the dimensions that tend to matter once an application is more than its frontend. The goal is to help you decide honestly, not to tell you the answer.

## Where the two platforms diverge strategically

Vercel's center of gravity is the frontend runtime and the developer experience wrapped around it. The platform's recent additions, Fluid Compute for efficient JavaScript and Python serverless, Vercel Sandbox for ephemeral compute in Firecracker microVMs, and the tight integration with Next.js, all reinforce that center. The platform's strength is making the frontend layer excellent, and extending outward from it through a marketplace of integrations for the parts that sit beside it.

Upsun starts from a different center. The platform is designed to run an entire application, frontend, backend services, databases, queues, workers, caches, cron jobs, and everything that wires them together, under one declarative configuration, inside one governance boundary, on a cloud of your choosing. The emphasis is on treating the whole application as a unit rather than layering the surrounding pieces around a frontend core.

Both are legitimate approaches. They optimize for different shapes of team and different shapes of application. Where they produce different outcomes is in the specific capabilities below.

## The full application, not just the frontend layer

Vercel's managed surface is the frontend runtime and the serverless functions that sit next to it. Databases, object storage, and other stateful services are available through Vercel's Marketplace integrations with partner providers such as Neon, Supabase, and Upstash. Those integrations are genuinely convenient for teams whose backend is a database and a handful of functions.

The trade-off is that the parts of your application integrated through the marketplace sit inside a different provider's environment, with a different operational model, a different support contract, and a different governance boundary. For a simple backend, that's fine. For a full-stack application with long-running workers, message queues, multiple language runtimes, or data services that need to be co-located with the compute, the seams between Vercel and the marketplace partners become part of the architecture.

Upsun runs the whole application on one platform. A single `.upsun/config.yaml` file in your Git repository describes the frontend app, the Node or Python or PHP or Go or Java backend services, the PostgreSQL or MySQL database, the Redis cache, the RabbitMQ queue, the workers that consume from it, the cron jobs, and the routing between all of them. They deploy together, run together, and are governed together. There is no marketplace seam because there is no marketplace layer.

This matters most for applications with multiple backend services, non-trivial data layers, or language runtimes beyond JavaScript and Python.

## Preview environments: code versus byte-for-byte

Vercel's Preview Deployments are a core part of what made the platform famous. Every pull request gets a URL. Reviewers click, see the change, and approve or push back. It's the single feature that most raised the baseline for what developer experience should feel like across the industry.

The trade-off is that a preview deployment in Vercel is a code-level preview. The code is deployed, but the backing services, databases, object stores, queues, are whatever the environment was configured to point at. Teams typically wire previews to a shared staging database or a per-environment branched database via a marketplace partner. The preview URL loads, but whether the data underneath the preview matches the shape of production is a separate question with a separate answer.

Upsun's environment cloning engine creates a byte-for-byte replica of production on every branch. Not just the code. The databases, the files in object storage, the services, the search indexes, the caches. A reviewer opening a preview URL on Upsun is looking at the application running against a complete, isolated copy of production's actual state. Sanitization hooks defined in YAML can strip PII on clone, so reviewers work with realistic-shaped data without touching sensitive records.

For teams where the hardest bugs live in the interaction between code and data, this is a different review process. Bugs that previously lived until staging now die in pull-request review.

## **Cloud choice as a first-class capability**

Vercel runs on Vercel's global infrastructure. That's part of what makes the platform feel like magic: you don't think about regions, instances, or cloud providers because Vercel is handling all of it. Vercel's regional configuration lets you pick where functions execute, and the edge network fronts the application globally.

The trade-off is that "which cloud" is not a question the platform answers. If a regulator requires processing in a specific jurisdiction's infrastructure, if a customer's procurement team refuses to approve vendors that use a particular hyperscaler, or if a CFO wants cloud spend to count against an existing committed-use agreement with AWS or Azure or Google or IBM, the answer on Vercel is the answer the platform gives you.

Upsun deploys the same application, described by the same .upsun/config.yaml, to AWS, Azure, Google Cloud, or OVH, across dozens of regions. The configuration does not change when the cloud changes. Moving a project from one hyperscaler to another is a project-level setting, not a replatform. And Upsun is available on the AWS, Azure, Google, and IBM marketplaces, so teams with committed spend on a given cloud can apply that commitment against their Upsun usage. For teams whose business development path includes regulated industries, sovereign-region requirements, or enterprise customers with specific cloud preferences, this flexibility is often the difference between a yes and a ninety-day engineering project.

## Compliance: uniform across the platform, not opt-in per feature

This is the difference that matters most for teams whose compliance requirements are not optional, and it's the one most often underweighted in evaluations.

Vercel is SOC 2 Type 2 certified, and Vercel offers HIPAA Business Associate Agreements on Pro and Enterprise plans. The HIPAA posture requires being on a qualifying plan and signing the BAA. For teams on the right plan that execute the BAA, the coverage works as documented.

The trade-off is that Vercel's compliance posture is composed per team and per plan tier. You opt into HIPAA by upgrading to Pro or Enterprise and executing the BAA. You inherit Vercel's SOC 2 scope for the parts of the application Vercel manages, and your marketplace partners (for databases, queues, object storage, and other stateful services) have their own certifications, scopes, and BAAs for the parts they manage. The resulting compliance diagram is a composition of several platforms' postures, joined at the seams you built.

Upsun's SOC 2 Type 2, ISO 27001, and PCI DSS and HIPAA options apply to every feature and every environment on the platform, and every managed service you run on it. The compliance boundary is the same in staging as it is in production, the same for the frontend as it is for the queue worker, the same for the PostgreSQL service as it is for the application container, and the same regardless of which underlying hyperscaler your project runs on. When your audit scope needs to include the whole application, the scope statement matches the architecture diagram because the certifications cover the whole platform in one piece.

For teams in healthcare, financial services, government, or any B2B context where compliance is part of the procurement conversation, a uniform posture is materially simpler to defend than a composed one.

## Configuration and developer experience

Vercel's configuration model is primarily the dashboard and CLI, augmented by a `vercel.json` file for per-project settings. Environment variables, integrations, regions, and team settings are managed through the Vercel UI, which is well-designed and fast to learn. The experience is optimized for the solo developer and small team that wants most decisions made for them.

The trade-off is that the platform configuration lives in the platform's own admin surface rather than in your repository. For security teams that want every infrastructure change in version control under the same review process as application code, the Vercel model requires an additional audit layer to reconstruct what changed and when.

Upsun's model is Git-native. The `.upsun/config.yaml` file in your repository is the entire infrastructure definition. Every database version, every firewall rule, every service, every route, every cron, every resource allocation, all of it is a commit in your main branch. Changes flow through pull requests. Audits look at git log. Rollbacks are a git revert. The same review process that governs the application code governs the infrastructure.

This isn't a value judgment on dashboards. Dashboards are faster for individuals. YAML in Git is more defensible for teams with review requirements.

## Comparison at a glance

## When Vercel is probably the right choice

A frontend-first team building a Next.js application with a small backend surface and no imminent regulatory requirements will likely ship faster on Vercel than on anything else. If your application is substantially a frontend, if your team is aligned on JavaScript, if your backend is a managed database and a few serverless functions, and if your compliance needs fit inside what Vercel and its marketplace partners collectively certify, the platform's strengths compound in your favor. This is the case it was built for and continues to serve well.

## When Upsun is probably the right choice

A team whose application has multiple backend services, long-running workers, data layers that need to live with the compute, language runtimes beyond JavaScript and Python, or compliance requirements that need to cover the whole application, will find the structural properties of Upsun closer to the shape of the problem. Customers in healthcare, financial services, government, agencies building for regulated clients, and product teams past the point where the application is a frontend with a database, tend to land here. The capabilities that matter most in those contexts, YAML-defined infrastructure in Git, byte-for-byte environment cloning, multi-cloud deployment without configuration changes, and uniform compliance across every feature and environment, are structural choices the platform was built around rather than features added on.

## Moving from Vercel to Upsun, if that's where you land

Teams that migrate typically do it one application at a time. The application code itself usually needs minor adjustments. Most of the work is in translating the Vercel-specific configuration (rewrites, redirects, environment variables, serverless function settings) into the equivalent YAML declarations in .upsun/config.yaml, and in bringing the backend services that were integrated through the Vercel Marketplace onto Upsun's native service definitions.

Upsun's application services team works directly with engineering teams through migrations when that's the path forward. The goal of those engagements is less about selling a migration and more about producing a clear-eyed picture of what the move actually involves, so the team can make the decision with real numbers rather than estimates.

## The honest summary

Vercel and Upsun are both good platforms. They're aimed at different problems, and the right answer depends on the problem you actually have.

If your application is essentially a frontend, Vercel is probably a good fit, and a full-stack platform's depth might be wasted on a team that doesn't need it.

If your application has a substantial backend, compliance requirements that span the whole stack, cloud flexibility in its future, or a team that wants infrastructure in Git alongside the application code, the full-stack properties of Upsun are what the job asks for.

The mistake isn't picking one over the other. The mistake is picking the platform that fits what the application is today and discovering, in month twelve, that the platform is the reason the application cannot become what the team wanted it to be.

Pick the platform that fits where the application is going.

## **Further reading**

-   Upsun platform overview
-   Upsun environments and byte-for-byte cloning
-   Upsun compliance guidance
-   Vercel platform documentation
-   Vercel Fluid Compute
-   Vercel Sandbox
-   Vercel Preview Deployments
-   Vercel Security and Compliance

### [Things developers shouldn’t think about | Upsun](https://upsun.com/blog/things-developers-shouldnt-need-to-think-about/)

# Things developers shouldn’t need to think about in 2026

Every few years, expectations quietly shift.

Tasks that once demanded constant attention fade into the background. What used to feel like responsible engineering starts to feel redundant, even strange. Teams don't celebrate these changes or formally announce them. They simply stop talking about them.

Version control did this. CI did this. Containerization did this for many deployment workflows.

Infrastructure is approaching one of these moments.

In 2026, many of the things developers still worry about today shouldn't require active thought anymore. Not because developers have become less capable, but because platforms have matured enough to absorb the complexity. The tools exist. The patterns are proven. Yet teams keep reinventing the wheel, sprint after sprint.

## **Infrastructure should behave like a dependency, not a second job**

From an application developer’s perspective, infrastructure should behave like any other dependency.

There is a contract. The application relies on certain guarantees like availability, performance characteristics, scaling behavior, and isolation between environments. As long as those guarantees hold, the developer shouldn’t need to think about how they’re implemented or maintained.

This is already how most developers think about libraries, frameworks, and managed services. They care about interfaces and behavior, not internal mechanics. Infrastructure is often treated differently, even though it’s just as foundational.

That difference comes at a cost.

When developers are expected to reason about infrastructure internals, they’re effectively asked to take on a second job. Not full-time, but constantly in the background: checking versions, validating assumptions, coordinating changes, and worrying about edge cases they don’t encounter often enough to build intuition.

The fact that developers still spend time thinking about these internals isn’t a sign of diligence. It’s a signal that the abstraction is leaky.

For more on this, see: The cognitive tax of Terraform and Kubernetes

## **Legacy work teams keep doing out of habit**

A lot of infrastructure-related work persists not because it’s valuable, but because it’s familiar. Teams still spend time:

-   Tracking minor runtime and service version changes.
-   Manually coordinating environment updates.
-   Reasoning about sub-point releases that rarely affect application logic.
-   Handling infrastructure security concerns far removed from product behavior.

None of this meaningfully differentiates your application from competitors. It doesn’t improve user experience or unlock new capabilities. It’s maintenance of conditions, not progress toward outcomes.

What makes this work especially sticky is that it _feels_ responsible. Teams worry that if they stop paying attention, something will break. In practice, this vigilance often compensates for missing guarantees at the platform level.

When infrastructure doesn’t behave predictably, human attention becomes the safety net. And once that pattern is established, it’s hard to let go.

## **What should be handled by the platform instead**

In 2026, many infrastructure concerns should no longer be active decisions for application developers.

Developers should be able to declare what they need: resources, services, constraints, without having to manage how those needs are fulfilled:

-   **Environment provisioning:** Push a branch, get an environment that matches production with real data. Merge or delete the branch, and the environment disappears. No tickets to file, no dashboards to click through, no two-week wait times.
-   **Runtime and service upgrades:** Updating PHP from 8.1 to 8.2 or patching a database shouldn't require months of coordination across teams. The platform handles routine version management. Developers only need to care when changes directly affect their application code.
-   **Infrastructure security:** TLS certificates, network isolation, IAM policies, firewall rules. These should be enforced defaults, not repeated decisions. When the secure path is the default path, fewer mistakes happen.
-   **Environment consistency:** Infrastructure defined in code and tied to Git means every environment is identical. Staging matches production. No configuration drift, no "it works on my machine" surprises.
-   **Initial setup:** Getting infrastructure working shouldn't consume an entire sprint. That time should go toward the product, not pipeline configuration.

Runtime updates, patching, and infrastructure-level security should be handled consistently and safely by the platform underneath. That doesn't mean developers give up control. It means control moves to the right level. 

The platform’s role isn’t to hide everything. It’s to absorb complexity where it doesn’t add value, and surface it only where it affects application behavior. 

**Where guardrails should replace decision-making**

One of the most effective ways to reduce cognitive load is to replace repeated decisions with defaults.

Guardrails work when they remove entire classes of choice: which versions are allowed, how environments are separated, what “safe” looks like, and what gets promoted where. When these decisions are made once and applied everywhere, teams stop re-litigating them in every project.

This doesn’t limit flexibility. It preserves it.

Deviations still exist, but they’re intentional rather than accidental. Exceptions are visible instead of implicit. Teams spend less time debating basic setup and more time focusing on what actually makes their application different.

The alternative is a constant background negotiation between speed and safety — one that developers are rarely equipped or incentivized to resolve on their own.

## **What a “boring” developer workflow looks like**

A boring workflow is a predictable one.

Developers write code, push changes, and see results in environments that behave the same way every time. Infrastructure doesn’t surprise them. Upgrades don’t derail sprints. Security concerns don’t appear as last-minute blockers right before release.

When something goes wrong, the system provides clear signals. When something changes, it does so in expected ways. Teams don’t need heroics to understand what happened or why.

This kind of workflow isn’t exciting — and that’s exactly the point. Boring workflows scale better than heroic ones. They survive team growth, turnover, and increasing system complexity without demanding more cognitive effort from every developer.

## **Why this shift matters now**

As teams build more applications, operate across more environments, and integrate more services, the cost of infrastructure cognition compounds.

The question isn’t whether developers _can_ keep managing this complexity. It’s whether that’s still the best use of their attention.

Teams that treat infrastructure as a dependency that is backed by standardized environments and clear guardrails, so they spend less time maintaining conditions and more time delivering value. Over time, that difference shows up in delivery speed, reliability, and developer satisfaction.

This shouldn’t feel aspirational. This should feel normal.

For more on this, see: How teams build apps without carrying the infrastructure burden

### [Zero config full-stack previews in seconds | Upsun](https://upsun.com/blog/full-stack-preview-in-seconds-with-zero-config/)

# Full-stack preview in seconds with zero config

Preview environments should feel automatic. If you open a branch, you should get a live URL with your app, services, and realistic data. No tickets. No YAML spelunking. No “who owns staging” pings.

Developers already spend too much time fighting fires and hunting answers. A 2024 Cisco survey reported that developers spend more than 57 percent of their time in war rooms solving performance issues instead of building features.¹ Independent summaries echoed the same finding.² These delays compound when your team waits for shared staging.

Upsun removes that friction with zero-config branch previews that mirror production and spin up in seconds, so you can ship with confidence. Today, we will discover how it works and learn how to put it into use.

## What “zero config” means on Upsun

On Upsun, every branch can become a fully independent environment with your code, a copy of your database, search index, and files, plus an auto-generated URL you can share with reviewers. Read the overview: Upsun integrates with GitHub to automatically create an environment when a branch or pull request is opened, rebuild it on push, and remove it on merge. For developers, this means absolute feature isolation without requiring abysitting of infrastructure.

Behind the scenes, Upsun uses a single YAML configuration file in your Git repository that our AI onboarding can pre-generate based on your repository, allowing you to be even more productive.

## Why do preview environments per branch matter

-   Shorter feedback loops. Pre-production environments tied to pull requests enable teams to review the actual application before merging, which accelerates approvals and reduces rework.³
-   Better delivery performance. Teams that minimize handoffs and accelerate feedback tend to improve DORA metrics, such as lead time for changes and change failure rate.⁴ ⁵
-   Fewer “works on my machine” bugs. Identical clones of services and configuration make defects reproducible early (see Upsun’s environment model).  
     

## Clone the production environment safely

Real data makes previews useful, but it must be protected. Upsun previews inherit data from the parent environment, so you get realistic behavior. Use built-in sanitization patterns and hooks to remove personal data when cloning or syncing environments automatically. External regulators and standards bodies recommend anonymisation and data minimization for non-production use, so sanitizing test data is not just a preference, it is good governance.⁶ ⁷

## The Upsun approach: zero config, full stack

-   **Git-driven config.** Keep infra next to code in `.upsun/config.yaml`. Upsun can generate a starting config for you, and you commit changes as code.
-   **Per-branch environments.** Open a branch, and Upsun can stand up an isolated environment with apps, services, routes, variables, storage, and infrastructure. When you push, it builds. When you merge, it cleans up.
-   **Instant data cloning with sanitization.** Clone databases, caches, and files from production, then apply sanitization to keep previews safe.
-   **Multi-service orchestration.** Describe multiple apps and services in one file and deploy them together so frontend, API, and background workers stay in sync.
-   **Observability and APM.** Each environment exposes metrics and activity so you can validate performance before merging.

## Example: minimal config to get going

Upsun can generate this automatically, but here is the gist so you see how little you need to manage:

```shell-session
.upsun/config.yaml
applications:
  app:
    type: "nodejs:20"
    build:
      commands:
        - npm ci
        - npm run build
    web:
      commands:
        start: "npm run start"
    relationships:
      - "db:postgresql"
services:
  db:
    type: "postgresql:15"
routes:
  "https://{default}/":
    type: upstream
    upstream: "web:http"
```

Commit this, open a branch, and Upsun will create a full-stack preview with the app and a Postgres clone. Configure details as code over time; you do not need to wire environments manually.

## Implementation checklist

1.  **Initialize the project:** Run the Upsun CLI command upsun init to generate a starter YAML based on your stack.
2.  **Connect GitHub or GitLab:** Enable the integration so every branch and pull request gets its own environment automatically.
3.  **Sanitize data:** Add a sanitization script or use guidance to mask PII during environment clones. External guidance from the ICO and EDPB reinforces best practices for anonymizing test data.⁶ ⁷
4.  **Share the URL.** Every preview has an automatic domain. You can also configure custom domains for previews when needed.
5.  **Measure what matters.** Use previews to shift validation left. Faster, smaller changes improve DORA outcomes over time.⁴ ⁵
6.  **Pause idle previews.** Save resources by pausing environments when a review stalls.

## How does this improve speed, quality, and predictability

-   **Speed.** Branch-level previews remove staging wait time and reduce back-and-forth on PRs.³ ⁴
-   **Quality.** Full-stack parity catches integration issues before merge and encourages realistic testing.
-   **Consistency.** One YAML file standardizes services, routes, and deploy behavior across teams.
-   **Reduced toil.** Platform automation means fewer manual environment chores.
-   **Predictable cost.** Ephemeral previews clean up automatically and can be paused when idle.

Upsun’s product pillars emphasize speed, simplicity, scalability, standardization, security, and sustainability. Keep the grind out of shipping and let developers focus on building.

## FAQs developers ask

**How is this different from a shared staging server?**  
Shared staging often diverges from production and becomes a bottleneck in resource allocation. Per-branch previews are isolated, short-lived, and mirror the production configuration, which accelerates reviews and reduces the risk of errors.³ ⁴

**Do previews work for complex stacks?**  
Yes. Upsun orchestrates multiple apps and backing services from a single config, so your front end, API, workers, and databases deploy together.

**What about data privacy?**  
Use automatic sanitization when cloning data into previews. Regulators provide guidance on effective anonymisation for non-production use.⁶ ⁷

### **Next steps**

-   Get started with Upsun
-   Configure GitHub integration
-   Learn the YAML structure
-   Sanitize preview data guide

Sources

1.  Cisco Newsroom: Developers spending more time firefighting issues
2.  Developer-Tech: Cisco survey summary
3.  Microsoft Azure docs: Pre-production environments for pull requests
4.  DORA 2024 Accelerate State of DevOps Report
5.  Octopus: Understanding DORA metrics
6.  UK ICO guidance on anonymisation
7.  European Data Protection Board guidance overview

### [Production clone in 45s with full data and services | Upsun](https://upsun.com/blog/production-clone-with-data-files-services-everything/)

# Production clone in 45 seconds with data, files, services, everything

Watch the time-lapse demo below before you read on. It takes less than a minute to see how you can spin up a production-clone environment in under a minute… with the database, files, and services all included.

And here’s why that changes everything for developers.

You know the feeling. A regression slips past staging, customers feel it first, and your afternoon (or late night) becomes a post-deployment war room. Developers report spending most of their time on reactive work, such as debugging and war rooms, rather than building new software.¹ No wonder releases feel harder than they should.

This walkthrough shows how Upsun’s “production clone” turns any Git branch into a production-perfect environment in under a minute, with data, files, and services cloned from the parent. You can reproduce issues, validate fixes, and prove performance before merge. No more post-deployment fire drills.

## **The problem: environment drift and brittle testing**

Staging rarely matches production. Different service versions, missing data, developers pushing different versions of the code, or out-of-date assets create environment drift that hides real bugs until go-live. AWS’s DevOps guidance recommends baselining environments and continuously managing drift.²

Preview environments help, but only when they are truly “like prod.” That means:

-   Same applications, build, routes, and infra settings
-   Same services are provisioned the same way.
-   Fresh data and files.
-   Observability that flags problems early, not in a war room

## **Upsun solution: production cloning on every branch**

With Upsun, every Git branch can become a live, production-grade environment with cloned services and code. You keep the familiar Git workflow you already use, now backed by instant, production-perfect previews that unblock reviews and debugging.

-   **Git-driven YAML config.** Define applications, services, and routes once in `.upsun/config.yaml`, commit to Git, and keep it versioned with your code (learn more in YAML structure).
-   **Automatic previews per branch.** Branching creates a child environment that inherits code, data, and assets from its parent. See the make changes guide.
-   **Instant data cloning you can sanitize.** Clone production data into the preview, then automatically sanitize it via deploy hooks, so reviewers never handle PII. See sanitize databases.
-   **Multi-service orchestration.** Provision managed databases, caches, search, and more from the same config file (see add services).
-   **Observability and APM built in.** Blackfire APM and profiling help you catch performance regressions before release (see Blackfire for PHP and Python; Upsun features).

## **How production cloning works in practice**

### **1) One push creates a prod-clone**

Use Git push on a new branch, and Upsun can activate a new environment, clone the parent services, and clone the parent’s data in one go.

This single push sets up a branch environment with production-identical filesystems and services, plus a cloned dataset from its parent. See manage environments.

Need to refresh data later? Keep your branch in sync with `upsun env:sync data`. 

### **2) Keep configuration simple and explicit**

All apps, services, routes, and hooks live in `.upsun/config.yaml`. Here is a minimal example with a Node.js app, MariaDB, Redis, and a deploy hook that runs sanitization in non-production environments:

```shell-session
# .upsun/config.yaml
applications:
  web:
    type: "nodejs:22"
    relationships:
      mariadb: "mariadb"
      cache: "redis"
    hooks:
      deploy: |
        if [ "$PLATFORM_ENVIRONMENT_TYPE" != "production" ]; then
          ./scripts/sanitize_db.sh
        fi
services:
  mariadb:
    type: "mariadb:11.8"
  redis:
    type: "redis:7.2"  # persistent or ephemeral supported
routes:
  https://{default}/:
    type: upstream
    upstream: "web:http"
```

-   Services are declared in the same file and wired to the app via **relationships** (see database service example).
-   The deploy hook uses the documented environment variable `PLATFORM_ENVIRONMENT_TYPE` to vary behavior by environment and runs sanitization only on previews (see change hooks by environment).
-   Route config ensures your preview URLs are production-consistent (see Define Routes).

### **3) CI/CD testing that matches prod**

Because branches are production-perfect, your CI pipeline can run against the same topology, versions, and data profile you will eventually deploy to production. That dramatically reduces flaky tests caused by environment drift. See build and deploy overview.

You can also add the Blackfire build feature to your pipeline to automatically detect performance issues and provide actionable recommendations for PHP and Python (Upsun features; Blackfire on Upsun).

### **4) Safer application debugging with real data**

Obscure, data-dependent bugs reproduce instantly when your preview carries real data and assets. Upsun’s sanitization guides demonstrate how you can safely remove PII in popular stack combinations, such as PostgreSQL and Django, Symfony and PostgreSQL, or MariaDB and Drupal (see "Sanitize PostgreSQL and Django," "Sanitize Symfony and PostgreSQL," and "Sanitize MariaDB and Drupal").

Would you prefer to work locally using production clone data? Tether your local environment to the remote services for quick iteration (tethered local development).

## **Why this improves developer productivity**

-   **Eliminate environment drift.** Every branch is cloned from its parent, so parity is the default rather than an afterthought.³ 
-   **Shrink feedback loops.** Reproduce, instrument, and fix in the same place you validated your solution.
-   **Cut rework and meetings.** Fewer surprises in production means fewer war rooms and more time building.¹ ²
-   **Stay consistent across teams.** Git-driven YAML and managed services standardize delivery while preserving flexibility (Upsun docs home).

## **Put it together in your workflow**

1.  Create a branch. The environment activates and clones data from the parent.
2.  Your sanitization code runs automatically on deployment in non-production environments.
3.  Your CI runs end-to-end and performance checks against the production clone.
4.  Reviewers test the real thing and sign off quickly.
5.  Merge with confidence, then monitor with Blackfire after release.

For a deeper dive into YAML patterns or multi-service setups, explore developer tutorials.

**Who is this for?** Developers who want to code more and spend less time firefighting. That is by design: Upsun provides each branch with a live, production-grade environment, allowing you to test, iterate, and review without the dread of “what if this breaks everything.”

### **Production cloning and environment drift**

Use production cloning to remove environment drift from the conversation. When the environments are identical by default and carry safe, fresh data, CI/CD testing and application debugging feel honest again.

## **Try it yourself**

Watching a prod-clone appear in 45 seconds is cool. Experiencing it with your own code is the real game-changer.

Spin up a free trial, connect your Git repository, and watch every branch come to life as a production-grade environment with data, files, and services included.

## **Sources**

¹ Cisco Newsroom. “Developers spending more time firefighting issues than delivering innovation.”  
² Stack Overflow Developer Survey 2024. “Daily time spent searching for answers/solutions.”  
³ AWS Well-Architected DevOps Guidance. “\[AG.DEP.2\] Continuously baseline environments to manage drift.”

### [Stop the works on my machine loop | Upsun](https://upsun.com/blog/what-makes-a-bug-reproducible/)

# Architecture deep dive: What makes a bug reproducible?

The most difficult bugs to solve aren't those with the most complex code, but those with the most complex state. 

For a bug to be "reproducible," it must be deterministic, meaning the same set of inputs always yields the same failure. In a modern cloud environment, those "inputs" include more than just your code; they include the specific version of your database, the latency of your service mesh, and the exact configuration of your underlying infrastructure.

True reproducibility requires moving from manual setups to a versioned, deterministic environment. You can **test this architecture via the Upsun free trial** to see how a platform-level approach to determinism makes production-grade bugs instantly inspectable on any branch.

### The three pillars of environment determinism

When your infrastructure is a "best guess" approximation of production rather than a production-identical clone, your debugging process is essentially guesswork. 

To move toward a truly reproducible architecture, IT teams must stop managing servers and start managing definitions based on three core pillars:

1.  **Service Parity:** Your development environment must use the exact same service versions and sidecars as production. A "similar" version of Redis is not enough to catch a race condition.
2.  **State Consistency:** Bugs often live in the "shape" of the data. Reproducibility requires a safe, automated way to clone the production data context into an isolated branch—including backing services like S3 buckets or ElastiCache states.
3.  **Deployment Behavior:** The build process itself must be immutable. If your deployment pipeline introduces unique variables that aren't present in your test environment, you have lost your source of truth.

Achieving this level of parity doesn't require a total overhaul of your existing stack. If you’re looking for a tactical path forward, you can read our developer guide for migrating to reproducible environments to see how to start standardizing your environment definitions without a complete rewrite.

### The immutability mandate

If your deployment process involves manual `apt-get` commands, "quick fixes" applied directly to a server, or a CI/CD pipeline that behaves differently for "dev" than it does for "prod," you have lost your source of truth. 

Reproducibility requires Immutable Build Artifacts: the application image created during the build phase must be the same one used in every environment.

Using Repeatable Pipelines (via Build Hooks) ensures that every time an environment is created, the setup steps, compiling assets, generating caches, occur in the exact same sequence. If the build fails in dev, it is going to fail in prod.

### Mirroring observability and failure modes

A bug is only reproducible if it is observable. If production has deep observability (logs, metrics, traces) but your dev environment is a "black box," you’ll never find the signal in the noise. Deterministic environments must provide:

-   **Log & metric parity:** Access to the same container and activity logs in your clone that you have in production.
-   **Predictable configuration:** Moving variables out of "tribal knowledge" and into version-controlled YAML. This allows you to "diff" the infrastructure of a failing branch against a working one to see exactly what changed.

### Ending the "investigation gap"

The time spent between an alert firing and a developer actually seeing the bug in a local environment is the Investigative Gap. 

In fragmented architectures, this gap is measured in hours or days. In a deterministic architecture, defined by Infrastructure-as-Code, this gap is reduced to the time it takes to run `git checkout`.

### **Next Steps:**

-   **Audit your drift:** Compare your local `docker-compose` versions against your production cloud console. Any difference is a potential Heisenbug.
-   **Automate your clones:** Implement a system where every pull request automatically receives a production-identical environment.
-   **Codify the context:** Use .upsun/config.yaml to ensure that your services, routes, and relationships are versioned alongside your code.

By making the environment part of the code, you ensure that "it works on my machine" finally means "it works in production”.

### [Modernize financial apps: secure and agile cloud](https://upsun.com/blog/faster-compliant-regulated-cloud-with-upsun-and-ibm/)

# Faster, compliant delivery on regulated cloud with Upsun and IBM Cloud for Financial Services

We are continually enhancing our offering to support enterprises looking to modernize without the pain of modernization. 

We partnered with IBM to bring our highly flexible cloud application platform to the IBM Cloud Marketplace to give financial service organizations a cloud option that meets both workload and organizational requirements. By achieving IBM Cloud for Financial Services validation and ISO 27001 certification, we enable enterprises to deploy and scale their applications with greater agility while maintaining the highest levels of regulatory compliance. 

Financial institutions face increasing pressure to innovate quickly without compromising on compliance, data security, or operational resilience. They need a solution they can trust and rely on to help alleviate these pressures with a simplified and automated platform so they can focus on innovation. 

By combining the power of IBM’s trusted cloud infrastructure and compliance tooling with Upsun’s developer-centric flexibility, we open a new path for financial enterprises to innovate, build, and deploy without risk. 

IBM Cloud is a public cloud with controls, reference architectures, and tooling aligned to financial-sector obligations. It helps institutions move regulated workloads to the cloud with a clear compliance story while improving resilience and security. With Upsun, you can simply choose an IBM Cloud region and deploy, with no additional configuration required.

> “Upsun, the cloud application platform, has been de-risked against Financial Services regulations and standards for continuous compliance and cyber resilience. This has been achieved on IBM's Cloud for Financial Services, leveraging IBM's Cloud Framework for Financial Services, IBM's OpenPages, and IBM's Security and Compliance Center.” **\-** **Christophe Sorré, France CTO for Financial Services & Consumer Industry, Distinguished Engineer, Executive IT Architect, IBM**

### **Why financial enterprises value IBM Cloud**

-   **Compliance by design.** IBM Cloud ships with a control framework and service catalog mapped to laws and standards the sector cares about, from privacy to cyber to payments. PCI DSS, for example, is an industry security standard governed by the PCI Security Standards Council, not a law, but it is widely required by card brands.
-   **DORA alignment.** In the EU, the Digital Operational Resilience Act (DORA) entered into application on 17 January 2025, making operational resilience a board-level obligation for banks and insurers. IBM’s focus on multi-zone regions, reference architectures, and continuous testing directly supports DORA’s emphasis on ICT risk, incident reporting, and third-party oversight.
-   **Sovereignty options.** In France, the SecNumCloud qualification defines strict criteria for “trusted” cloud, including governance and protection from extraterritorial access. While not universally mandatory for private firms today, it shapes enterprise choices and procurement.
-   **Data protection with strong cryptography.** IBM Hyper Protect Crypto Services provides key management on FIPS 140-2 Level 4 certified hardware, the highest evaluated level for HSM tamper resistance, underpinning “keep your own keys” models.

### **What financial institutions tell us about Upsun**

-   **Legacy system compatibility:** Connect your legacy systems to modern apps using secure APIs. Works with Python, Java, PHP, Node.js, .NET, and frameworks like Django, Express, Symfony, and Strapi. No rewrites required.
-   **Enterprise-grade security:** Security runs deep here with read-only systems, project isolation, and encryption, all work together. You get MFA, WAF, and 175+ Gbps DDoS protection right out of the box. Critical patches get deployed within 2 hours.
-   **Developer ecosystem:** The Git-based platform provides developers with tools they actually want to use, resulting in less shadow IT and faster development.
-   **Real-time monitoring:** Blackfire gives you real-time performance insights, pinpointing exactly where slowdowns may occur. Clone your production environment in seconds to debug issues; your live systems stay safe.
-   **Open Banking compliance:** API security and compliance controls handle PSD2/PSD3 requirements, including secure TPP access.

Together, these pillars make IBM Cloud for Financial Services and Upsun a top choice when you must prove resilience, limit risk, and still ship features fast.

IBM Cloud for Financial Services gives you a sector-specific control fabric and resilience blueprint. Upsun builds on that fabric to cut time-to-market, reduce operational toil, and make compliance evidence a by-product of everyday delivery.

Use your tools, keep your workflow; we handle security. Modernize with a Cloud Application Platform that offers continuous compliance and robust cyber resilience for customers operating in regulated industries, modernize with Upsun.

### [Evaluating platforms after the Vercel incident | Upsun](https://upsun.com/blog/vercel-alternatives-after-security-incident/)

# Vercel alternatives after the April 2026 security incident: what to evaluate

_Key takeaway: The April 2026 Vercel incident is a reasonable prompt to revisit four structural properties of your platform: where the audit trail for infrastructure lives, whether preview environments include the data layer, how compliance scope is composed across the whole application, and how portable the deployment is across clouds. These are the questions worth answering whether you stay on Vercel or move._

## 1\. Where does the audit trail for infrastructure change live?

Vercel configures infrastructure primarily through the dashboard: routes, rewrites, function settings, region selection, environment variables, and marketplace integrations. The record of who changed what and when is kept in Vercel's own logs, accessed through Vercel's admin surface.

On Upsun, infrastructure is defined in a `.upsun/config.yaml` file in the customer's own Git repository. Routes, service definitions, workers, cron jobs, firewall rules, service relationships, and resource allocations are declared in code. Every change is a commit, reviewed through the customer's pull-request process, visible in the customer's git log.

What that changes, in the context of a supply-chain incident: the audit trail for infrastructure change is visible from inside the customer's own systems, not only from inside the vendor's.

Environment variables work similarly on both platforms: values set via CLI or Console, with an opt-in `sensitive` flag that hides them from UI and CLI output. The difference is one layer up, in the infrastructure that consumes those secrets, not in the secrets themselves.

## 2\. Do preview environments include the data layer?

Vercel's Preview Deployments give every branch a URL and a build. For changes that live in the frontend, that's enough to ship confidently. Backing services (databases, queues, object stores) typically come from Vercel Marketplace partners such as Neon, Supabase, or Upstash, configured per project, pointing at shared staging data or per-branch data via the partner's branching features.

Upsun's environment cloning provisions a byte-for-byte replica of production on every Git branch: code, services, and data. Reviewers look at the application running against a complete, isolated copy of production's actual state, typically in around a minute. Sanitization hooks defined in YAML strip PII on clone, so reviewers work with realistic-shaped data without touching sensitive records.

What that changes, in the context of verifying an application during or after an incident: engineers can inspect the shape of production state in an isolated environment, run credential rotations or integration changes against that state, and verify the result before touching live.

## 3\. What is in scope for the platform's compliance certifications?

Vercel is SOC 2 Type 2 certified and offers HIPAA Business Associate Agreements on Pro and Enterprise plans. The scope covers the part of the stack Vercel operates.

For full-stack applications on Vercel, stateful services (databases, queues, object storage) are typically provided by marketplace partners. Those partners carry their own certifications, their own scope statements, and their own BAAs. A customer's compliance posture for the whole application is composed across Vercel's scope plus each marketplace partner's, joined at the seams the customer built.

Upsun's SOC 2 Type 2, ISO 27001, with PCI DSS and HIPAA options cover the entire platform: compute, databases, queues, object storage, workers, crons, and the pipelines that deploy them. The compliance scope statement and the application architecture diagram are the same document.

For teams in healthcare, financial services, government, or any B2B context where compliance is part of the procurement conversation, a single-platform scope is materially simpler to defend than a composed one.

## 4\. How portable is the deployment across clouds?

Vercel runs on Vercel-operated global infrastructure. Region selection within that infrastructure is available per function and deployment. Cloud selection is not a question the platform answers.

Upsun's `.upsun/config.yaml` is the same file whether the project runs on AWS, Azure, Google Cloud, or OVH, across dozens of regions. You pick the hyperscaler when you create the project, and the configuration does not change when you change the hyperscaler. Upsun is also available on the AWS, Azure, Google, and IBM marketplaces, so teams with committed-use agreements on any of those clouds can apply them against their Upsun usage.

Your application runs in Upsun-operated environments on the hyperscaler you choose. The portability is in the configuration, not in where the infrastructure is physically operated. What that changes is the cost of revisiting the cloud decision: it's a project setting instead of a quarter-long engineering project.

## Should you move off Vercel?

Not necessarily. No single incident decides whether a platform is right for an application. What's worth doing is asking the four questions above about your current platform and any alternative you're evaluating, and making sure the answers match what your business actually needs.

For a frontend-heavy application with a small backend surface and no regulated compliance scope, Vercel is a good fit, and a migration is probably not the right use of the quarter. For a full-stack application with data-heavy previews, multi-vendor compliance friction, or cloud-choice requirements, the answers on a full-stack platform like Upsun are structurally different in ways that tend to matter at procurement time.

## What moving looks like, if you do

For most Next.js applications, migration is primarily writing a .upsun/config.yaml that describes the frontend runtime, backend services, databases, and other components, plus moving environment variables and DNS. Because every Git branch on Upsun gets a byte-for-byte preview environment, engineers can run the migrated application against production-shape data before cutting over. Upsun's application services team supports migrations on a hands-on basis when that's the right path.

## Frequently asked questions

**Is Upsun more secure than Vercel?**

Both platforms hold SOC 2 Type 2 certifications and run production applications for serious teams. The differences worth comparing are structural. Where the infrastructure audit trail lives: on Upsun, in the customer's own Git repository; on Vercel, in the platform's admin surface and logs. How compliance scope is composed: Upsun's certifications cover the whole platform including databases, queues, and workers, while Vercel's cover the Vercel-managed layer with marketplace partners carrying certifications for stateful services. What options are available: SOC 2 Type 2, ISO 27001, with PCI DSS and HIPAA options on Upsun; SOC 2 Type 2 with HIPAA BAAs on Pro and Enterprise plans on Vercel.

**Does Upsun support Next.js?**

Yes. Next.js is a first-class runtime on Upsun. You define the application and any backing services it depends on in `.upsun/config.yaml`. Deployment is Git-driven, environment variables are managed through CLI or Console with an opt-in `sensitive` flag (the same model Vercel offers), and every branch gets a byte-for-byte preview environment.

**How are secrets handled?**

Environment variables on both Upsun and Vercel are set via CLI or the web console, not stored in version control. Upsun's YAML configuration file is explicitly called out in the documentation as a poor fit for secret values, because it's committed to Git. Variables can be flagged as `sensitive`, which hides their values from the UI and CLI output on both platforms. The structural difference between the two platforms is not in how secrets are stored but in the infrastructure that surrounds them: on Upsun, that infrastructure is declared in Git and reviewable alongside application code.

**How long does a migration take?**

For most applications, the work is primarily a configuration exercise: describing the existing stack in `.upsun/config.yaml`, moving environment variables, cutting DNS. Because preview environments on Upsun include the data layer, the migrated application can be validated against production-shape data before cutover. Upsun's application services team supports migrations hands-on when that's useful.

## **Further reading**

-   Upsun platform overview
-   Upsun compliance guidance
-   Upsun preview environments
-   Vercel April 2026 security incident bulletin
-   Vercel security and compliance
-   Vercel HIPAA BAAs for Pro teams
-   Vercel Preview Deployments

### [Why container security needs a managed platform | Upsun](https://upsun.com/blog/why-container-security-only-works-when-the-platform-owns-it/)

# Why container security only works when the platform owns it

Container security has finally gone mainstream.

When Docker announced hardened container images in late 2025, complete with minimal attack surfaces, non-root defaults, continuous CVE scanning, and automated updates, the response was enthusiastic. For teams managing their own infrastructure, this was a real step forward. Secure-by-default containers are no longer niche or expensive. They are expected.

But that moment also exposed a misunderstanding that still shows up in many organizations:

**Hardened images alone do not make a secure platform.**

At scale, container security is not a feature you adopt once. It is an ongoing operational responsibility that has to be owned, automated, tested, and governed somewhere. 

The question is not _whether_ containers are hardened, but _who_ carries the burden of keeping them that way over time.

## The illusion of “one hardened image”

The idea of a single, hardened base image is appealing. One image, carefully locked down, continuously patched, and reused everywhere. Simple. Auditable. Safe.

That model breaks down quickly in real production environments.

Most teams run more than one runtime. PHP, Python, Node.js, Java, databases, caches. Each runtime has multiple supported versions. Many rely on native extensions compiled against specific system libraries. Change the wrong dependency and applications break in subtle, expensive ways.

This is where security and stability collide.

If you upgrade a base image aggressively to chase the latest patches, you risk breaking workloads. If you delay upgrades to protect stability, you increase exposure. Managing that tradeoff is not something most application teams are equipped to do repeatedly and safely.

At scale, the problem is not hardening an image.

It is maintaining **hundreds of versioned images**, each with different compatibility constraints, while keeping all of them secure.

## What secure containers actually require at scale

Once you move beyond toy examples, container security becomes an exercise in systems engineering.

A secure platform has to handle, continuously:

-   Multiple runtimes and runtime versions
-   ABI compatibility for native extensions
-   OS-level package updates and security patches
-   Controlled rollout and regression testing
-   Emergency response paths for critical vulnerabilities
-   Predictable, auditable update behavior

This work is repetitive, unglamorous, and easy to underestimate. It cannot be handled manually, and it cannot be delegated piecemeal to application teams without introducing risk.

That is why mature platforms treat container security as **invisible infrastructure**. Something that runs continuously in the background, absorbs complexity, and fails safely.

## The platform approach: security without heroics

Upsun has taken this approach from the beginning.

Rather than maintaining a single “golden” container image, Upsun maintains hundreds of images across runtimes and versions. Each image is built, updated, and tracked independently to preserve compatibility while still receiving security updates.

This is not done through ad-hoc rebuilds or manual patching. The system is fully automated and declarative. Package versions are defined explicitly. Updates are detected programmatically. Images are rebuilt only when something actually changes.

Most of the time, nothing happens. And that is exactly the point.

Security at scale should be boring. It should rely on automation, not vigilance. When updates are needed, they should flow through a predictable pipeline that prioritizes correctness as much as speed.

## Why testing cadence matters more than patch speed

Security conversations often focus on how quickly patches are applied. Speed matters, but speed without control is dangerous.

Database engines, language runtimes, and system libraries are not interchangeable parts. A broken update can corrupt data or cause prolonged outages. That risk is unacceptable for a platform running production workloads.

For this reason, Upsun separates **building updates** from **deploying them**.

Images are continuously monitored and rebuilt as packages change. Deployment to production follows a measured cadence, with full testing before rollout. Updates first land in internal testing environments, then progress safely toward production.

There is one exception: critical vulnerabilities with active exploitation. In those cases, the platform can fast-track updates through an accelerated path. This capability exists precisely because the normal system is automated and well understood.

The result is a balance most teams struggle to achieve on their own:

-   Fast response when it truly matters
-   Stability and predictability the rest of the time

## What this changes for application teams

The practical impact of this model is simple, but profound.

Application teams do not need to:

-   Track OS-level CVEs
-   Rebuild base images
-   Coordinate patch rollouts
-   Worry about breaking native extensions
-   Decide when security updates are “safe enough”

Instead, responsibilities are clearly divided:

-   **The platform** owns system packages, base images, and security updates
-   **Teams** own application code and application-level dependencies

This division of labor is what turns infrastructure from a constant source of risk into a stable foundation.

It also reduces cognitive load. Engineers can focus on shipping features, not evaluating whether a new OpenSSL patch might destabilize their runtime.

## The one responsibility platforms cannot absorb forever

There is an important boundary that serious platforms are honest about.

No amount of automation can secure software that is no longer maintained upstream. When a runtime or operating system version reaches end of life, security updates stop. At that point, the only safe option is to upgrade.

Upsun enforces this boundary intentionally. Images tied to unsupported base systems eventually stop receiving updates. This is not a limitation of the platform; it is a reflection of reality.

Regular runtime upgrades are not about chasing novelty. They are about staying on supported foundations that can actually be secured. A platform can make upgrades safer and easier, but it cannot make abandoned software safe.

Clear boundaries build trust.

## What Docker’s announcement actually validates

Docker’s move to make hardened images free and open source is good for the industry. It acknowledges what experienced platform teams already know:

Container security cannot be bolted on. It requires automation, continuous maintenance, and disciplined rollout.

That is exactly the model Upsun has been running in production for years, not as a feature launch, but as a necessity. When you operate a platform that hosts thousands of applications across many runtimes, manual security work simply does not scale.

The work that matters most is not flashy. It is the repetitive, automated checking of packages, the careful rebuilding of images, the testing pipelines, and the controlled deployments. That is what keeps systems secure over time.

## Security as a property of the platform

The real takeaway is not about who did it first.

It is about where security belongs.

Hardened images are valuable. But without a platform that owns updates, testing, rollout, and lifecycle management, they shift responsibility onto teams that are already overloaded.

When security is handled at the platform layer, it stops being a recurring crisis and becomes part of the background. That is what allows teams to move faster without increasing risk.

That is what a platform is for.

### **Explore further**

-   **Explore Upsun’s security and compliance model**  
    Learn how Upsun handles security as part of the platform, not as an add-on.
-   **Read the technical deep dive on container hardening**  
    For a detailed look at how images are built, updated, and tested, see the original Dev Center article.

### [How tech empowers hard of hearing professionals](https://upsun.com/blog/tech-accessibility-hard-of-hearing/)

# Evolution of a hard-of-hearing person with technology

Hello, my name is Florian, I'm 37 years old, and currently occupy the position of Field CTO at Upsun. I've been with this company for 11 years. My primary job is to help our teams collaborate better in order to solve our customers’ problems. There's an irony in my role: I have had profound hearing loss since birth.

With hearing aids, I can participate in conversations under the right circumstances. Quiet rooms work well. High-quality audio sources work well. But restaurants, street conversations, and most standard TV broadcasts remain largely inaccessible. My hearing cuts off completely above 8kHz, which means high-frequency consonants like "f" and "s" are difficult to distinguish. I've never actually heard "th" pronounced correctly. Put me in a calm room within reasonable distance, and we can solve problems together. Add background noise or distance, and communication becomes challenging.

On the surface, profound hearing loss seems incompatible with a role centered on collaboration. But technological progress over the past 15 years has changed that equation. I want to share six advancements that have transformed accessibility for people like me, along with three requests for the tech community.

## **Hearing aids: incremental improvements**

The hearing aid industry moves slowly. It's a niche market dominated by a few large manufacturers, and their primary customer base skews older. Innovation isn't a priority. When I purchased my current pair in 2020, they lacked built-in Bluetooth—a feature that had been standard in consumer electronics for over a decade.

Despite this glacial pace, hearing aids have been foundational. They've allowed me to navigate most of my life without immediately signaling my disability. That invisible accommodation matters more than it should, but it does matter.

## **Subtitles transform entertainment**

In the 2010s, French television began adding subtitles as a standard feature. Streaming platforms accelerated this trend, with most offering subtitles by default. This was the first time I could actually enjoy movies and TV shows. Before subtitles became widespread, I was missing half of every story.

Today, subtitles are ubiquitous. TikTok videos, YouTube Shorts, and Instagram Reels routinely embed text directly into the content. What started as an accessibility feature has become mainstream, benefiting everyone from language learners to people watching videos in quiet spaces. The normalization of subtitles has been one of the most democratizing changes in media accessibility.

## **Text-based communication creates equality**

The rise of workplace chat platforms—HipChat, then Slack, then Discord, and all their successors—fundamentally changed professional communication. When text is the primary communication medium, everyone operates on equal footing. I'm not struggling to hear. No one is struggling with accents or speech impediments. Information flows uniformly.

Yes, text-based communication makes conveying emotion and nuance more difficult. But that tradeoff is worth it. When everyone has the same level of access to information, the quality of collaboration improves dramatically.

**This leads to my first request: invest in written communication skills.** Text transcends the limitations of hearing, accents, and speech patterns. It's the most accessible way to share information. When your team communicates effectively in writing, you're not only accommodating people with hearing loss—you're creating better documentation, clearer thinking, and more inclusive collaboration.

## **Bluetooth connectivity opens new doors**

Around 2015, I acquired a Bluetooth accessory for my hearing aids. This small device connected to my laptop, phone, or TV, then streamed audio directly into my ears. The improvement was remarkable. Movies became comprehensible. Video calls went from frustrating to functional.

The change in comprehension was dramatic. On video calls, I went from catching roughly 30% of conversations to understanding 50-80%. That increase might not sound life-changing on paper, but it meant the difference between being a passive observer and an active participant. Bluetooth connectivity was the first technology that made remote work genuinely viable for me.

## **Live captions revolutionize video calls**

At Upsun, we've used Google Suite since the beginning. I've worked remotely since I was hired in 2014. Video calls were always hit or miss. They improved in 2015 with the Bluetooth accessory, but they were still far from ideal. In early 2020, Google started rolling out live captions in Google Meet.

The impact was profound.

My understanding of conversations jumped to 90-100%. This fundamentally changed how I participated in meetings. This feature alone probably enabled me to collaborate much better with other people. Live captions then rolled out to other platforms: Microsoft Teams, Zoom, and others. Not all platforms support them though (like Slack's Huddles), so if you see me pulling you back to Google Meet, this is why.

**My second request: use and encourage platforms that support live captions.** Prefer ones where you don't have to ask the host to change the language settings (looking at you, Teams). The fewer barriers to usage, the more people you include. Having to ask the host to change the language every time raises unnecessary obstacles.

You'll notice that all these advancements helped me collaborate online, but none addressed in-person conversations.

## **Smart glasses: the final piece**

The sixth advancement is what inspired me to write this article: live captions in glasses. I've watched "smart glasses" for the past 2-3 years. Something always seemed promising, but there was always an issue. One product used the phone's microphone. Another didn't support prescription lenses. Yet another looked good but cost $5,000. Until this year: Captify released their Captify Pro glasses. They support prescription lenses, have a directional microphone, and are affordable (I realize affordability is subjective). They checked all the boxes.

A few weeks ago, we organized the Evolve conference—a place to meet our partners. As Field CTO, this was where I wanted to be. I was anxious because conferences are typically noisy environments. I've never had good experiences at conferences or summits unless I walked away from the noise. The big networking room where everyone gathers has usually been my nemesis.

For the first time, I had these new glasses, and they changed everything. I could be part of conversations in the middle of the networking room. I could understand most of what was said. It was a revelation. The evening party was equally amazing. Being able to have discussions with everyone without needing to escape the music changed everything. I had a blast. This latest advancement made a huge stride in closing this gap.

The glasses do have some shortcomings. They're new, so they still have minor issues here and there. The battery lasts 2-3 hours. Thankfully they recharge in only 30 minutes, but I can't wear them all day without worrying about power. They have some small UX issues, like no warning when the battery runs out. Overall though, the UX is clean and simple, and they accomplished their mission. That's why I wanted to give this product a shout-out.

**My third and final request: make conferences more accessible to hard-of-hearing and deaf people.** Most conferences give microphones to speakers. It's possible to route the sound through something that displays live captions (you could even connect the mic to a Google Meet call). This completely changes the experience. The talks become immediately accessible. The glasses help, but they work better with people close by, and they have limited battery life anyway.

## **The time is now**

Technology has come a long way. I can participate in meetings, enjoy movies, and have conversations at loud conferences. What was once impossible is now possible, and it keeps getting better.

Each advancement—from hearing aids to live captions to smart glasses—has opened new doors for me. But there's still work to do. By choosing accessible tools, writing clearly, and advocating for inclusive practices, you can help make collaboration possible for everyone.

The time to be hard-of-hearing/deaf has never been better. And with your help, it can get even better.

### [Hyperscaler: horizontal & cluster autoscaling | Upsun](https://upsun.com/blog/hyperscaler/)

# Scale smarter with a hyperscaler: horizontal and cluster autoscaling made easy

Traffic surges, whether from a product launch or Black Friday shopping, shouldn't crash your application or max out your storage and RAM capacity. This is where smart autoscaling comes in. It keeps applications fast and costs in check by **adding or removing application instances** as demand changes. Rather than guessing a fixed size, the platform watches live signals and adjusts resources automatically. 

Modern applications require more than just throwing additional servers at a problem. They need sophisticated scaling strategies that can distinguish between temporary spikes and sustained growth, scale individual components independently, and maintain performance across multiple cloud environments. The key lies in understanding two fundamental scaling approaches: horizontal scaling and cluster autoscaling.

## **Horizontal scaling vs cluster scaling**

Application scaling isn't a one-size-fits-all solution. Different workloads require different strategies, and the most effective scaling implementations combine multiple approaches to create resilient, cost-effective systems.

**Horizontal scaling** focuses on adding more instances of your application containers to distribute load. Rather than upgrading to a more powerful server, horizontal scaling creates additional identical application instances that share the incoming traffic. This approach works exceptionally well for stateless applications where any available instance can handle each request.

**Cluster scaling**, on the other hand, operates at the infrastructure layer, automatically adjusting the number of compute nodes available to your applications. When your application instances need more resources than your current cluster can provide, cluster autoscaling provisions additional nodes. Conversely, when demand decreases, it removes underutilized nodes to reduce costs.

You're probably wondering, what about vertical scaling then? **Vertical scaling** takes a different approach by increasing the power of existing servers, adding more CPU, RAM, or storage to the machines you already have. Instead of running more copies of your app, you allocate more resources to your current app instances to handle the increased load. This works well for applications that cannot be easily split into multiple instances, such as databases or applications with complex state management. However, vertical scaling has its limits; there's only so much CPU and RAM that can be added to a single server, and it doesn't provide the same fault tolerance as horizontal scaling, since you're still relying on individual machines.

_Let's dive a little into an example we can both relate to._ 

Think of a road trip. Normally, your family of 4 travels comfortably in one sedan. Today, you're organizing a reunion and need to transport 20 people to the beach. Vertical scaling is getting a bigger vehicle; trade your sedan for a large bus that can carry all 20 people in one trip. 

On the other hand, horizontal scaling involves keeping your sedan and getting four more identical cars. Now you have five sedans that can carry a total of 20 people (4 people per car). If one car has trouble, the other four can still make the trip, and people can redistribute between cars.

With cluster autoscaling, you recruit three more family members who can drive. Now each of your five cars has a driver, and all 20 people can travel efficiently.

Let's take a closer look at cluster autoscalers.

## **Cluster autoscaler fundamentals**

In traditional cloud environments, cluster autoscaling operates at the infrastructure layer, automatically adjusting the number of compute nodes in response to application demands. When your applications need more resources than your current nodes can provide, a cluster autoscaler provisions additional nodes. When demand decreases, it removes underutilized nodes to reduce costs.

The cluster autoscaler continuously monitors resource requests and scheduling needs across your infrastructure. Modern implementations utilize algorithms that take into account factors such as pending pod scheduling requests, node utilization patterns, and application resource requirements when making scaling decisions. This prevents both resource shortages and wasteful over-provisioning.

The integration between horizontal pod scaling and cluster autoscaling creates a complete scaling ecosystem in Kubernetes environments. When applications need more instances but existing nodes lack capacity, pods remain pending until the cluster autoscaler provisions additional nodes to accommodate them.

However, managing cluster autoscaling requires expertise in Kubernetes operations, cloud provider integrations, and careful configuration of scaling policies, node pools, and cost controls. This operational complexity is one reason why many teams prefer managed platforms that automatically handle infrastructure scaling.

## **The hyperscaler advantage in multicloud environments**

By “hyperscaler,” we mean the large cloud providers, such as AWS, Google Cloud, and Microsoft Azure, that run massive fleets of machines across multiple regions. Their value is simple: near-instant capacity and a global footprint when you need it. Their global network of data centers, advanced orchestration capabilities, and managed services create the perfect environment for implementing intelligent scaling strategies. However, with their services, you would still wire up node groups, autoscalers, and metrics. 

Upsun operates across AWS, Azure, and Google Cloud Platform, giving your applications access to hyperscaler infrastructure while abstracting away the complexity of managing multiple cloud environments. This multicloud approach provides several advantages for scaling operations.

First, it eliminates vendor lock-in concerns that often limit scaling decisions. Your applications can leverage the best features from each hyperscaler without compromising on architecture. AWS might offer the most mature autoscaling services, Google Cloud might provide the best Kubernetes integration, and Azure might deliver superior enterprise integration. With Upsun, you don't have to choose just one.

Second, multicloud deployment enables geographic distribution that improves both performance and resilience. Your European users can be served from Azure's European regions while your Asian traffic routes through Google Cloud's Asia-Pacific infrastructure. Serve users from the provider and region you choose. If you require multi-region high availability, run projects in multiple regions and place a CDN or DNS routing layer in front.

Third, cost optimization becomes more sophisticated in a multicloud environment. Different hyperscalers offer varying pricing models for compute, storage, and networking. Intelligent workload placement can significantly reduce operational expenses while maintaining performance requirements.

## **How autoscaling works on Upsun**

Upsun provides flexibility with both horizontal and vertical scaling, allowing you to choose the right approach for each situation. In the Console today, autoscaling is driven by average CPU. Memory-based autoscaling is on the roadmap. During traffic spikes, Console autoscaling automatically adds or removes application instances within the rules you set. When you need more power per instance, you can adjust CPU, RAM, and disk for each container, including databases and caches. 

**Horizontal scaling on Upsun**

Horizontal scaling on Upsun is handled through a built-in autoscaling feature. Upsun adds or removes application instances to match live demand. Rather than having to watch your app and manually add more instances when traffic picks up, Upsun tracks your app’s average CPU and adjusts instance count within rules you set. 

Here's how it works: Upsun watches the average CPU across all your app instances. If CPU stays at 80% or higher for 5 minutes straight, it automatically spins up another instance to help handle the load. When there’s a change and the CPU drops below 20%, it waits for 5 minutes and then removes extra instances. Default instance limits are typically 1–8 per environment, although the exact values vary by region.

You can set this up right from the Console by clicking "Configure resources" and then "Enable" under the autoscaling column. From there, you get to decide:

-   **Minimum instances** - How many copies of your app should always be running (usually starts at 1)
-   **Maximum instances** - The most instances you want, so costs don't get out of hand (typically 1-8 per environment, depending on your region)
-   **When to scale up/down** - You can adjust those CPU thresholds if 80% and 20% don't work for your app.
-   **How long to wait** - The evaluation period (1-60 minutes) before making changes, so temporary spikes don't trigger unnecessary scaling.
-   **Cooldown time** - How long to wait between scaling actions (default is 5 minutes) to prevent the system from constantly adding and removing instances.
-   **No scale-to-zero** - Autoscaling won’t reduce an app to 0 instances; set your minimum to define the baseline.

Once autoscaling is enabled, you cannot manually set the instance counts anymore. Upsun handles it all within the limits you set. However, you can adjust the amount of CPU, RAM, and disk each instance receives, but the number of instances becomes automatic.

_**Keep in mind that autoscaling currently works only for applications.**_

A quick example: If your shop typically runs two app instances, the autoscaler will add instances once the CPU usage exceeds 80% for 5 minutes and continue until demand settles or it reaches your configured maximum. Treat “8” as a standard default cap, not a guarantee, because caps vary by region. 

The beauty of this approach lies in its seamless operation. Since horizontal scaling involves adding or removing instances, Upsun deploys the change, which utilizes build minutes. Each scaling action consumes build minutes since new or removed instances are deployed with the scaling action. If your app scales frequently, this could increase build minute usage. Keep evaluation periods sensible to avoid frequent changes and control costs by avoiding overly aggressive scaling settings.

### **Vertical scaling on Upsun**

Sometimes, you don't need more instances; you just need to give your existing instances more power. With vertical scaling, you're basically giving your existing app a hardware upgrade: more CPU, extra RAM, or additional storage space, rather than spinning up additional instances. 

This approach works really well when you're dealing with databases or apps that don't work well being split across multiple instances. Consider this: running multiple database instances sounds great until you realize you now have to keep all that data in sync, which becomes complicated quickly. It's much simpler to allocate more RAM and CPU power to your single database instance.

Upsun offers four different container profiles that give you various combinations of CPU and RAM, depending on what your app needs:

-   **HIGH\_CPU** - More processing power for compute-heavy tasks
-   **BALANCED** - Even mix of CPU and RAM for typical web apps
-   **HIGH\_MEMORY** - Extra RAM for apps that need to keep lots of data in memory
-   **HIGHER\_MEMORY** - Even more RAM for memory-intensive workloads

You can adjust these resources through the Console or the CLI at any time. Saving vertical changes redeploy the environment (**short downtime**), and each instance receives the full CPU and RAM you select. This works great for services like databases, caches, or apps that can't easily split their work across multiple instances. Instead of trying to run multiple database instances (which can become complicated due to data consistency issues), you can simply allocate more RAM and CPU to your single database instance to handle the increased load.

You can mix and match, use vertical scaling for your database and horizontal scaling for your web app, all within the same project. Upsun handles resource allocation per environment, allowing you to allocate more power to your production database than to your development one, while keeping costs reasonable.

## **Final thoughts**

Upsun operates differently from traditional Kubernetes setups. While the cluster autoscalers apply to self-managed clusters, Upsun handles all infrastructure scaling automatically behind the scenes. As a user, you focus on horizontal and vertical scaling of your applications, while Upsun manages the underlying infrastructure capacity for you.

Getting autoscaling right isn't just about turning on a feature; you need to understand how your app actually behaves, select the right metrics to monitor, and continually adjust settings based on what actually happens in production. Platforms like Upsun make this much easier by handling the complex infrastructure stuff automatically, so you can focus on building great apps instead of wrestling with scaling configurations.

As your applications grow, your scaling approach should grow with them. Implementing smart autoscaling in place pays off in better performance, reduced costs, and the ability to quickly adapt when your business needs change or new opportunities arise.

The apps that will succeed are those that can scale smartly, adjusting to demand automatically while keeping both performance and costs in check. With the right platform and approach, your applications can handle whatever growth throws at them.

### [Heroku vs Upsun: the 2026 PaaS choice | Upsun](https://upsun.com/blog/heroku-vs-upsun/)

# Beyond the legacy PaaS: choosing between Heroku and Upsun in the 2026 cloud ecosystem

In the high-stakes world of enterprise IT, a platform is more than just a place to host code; it is a strategic partner in your delivery lifecycle. Recent shifts in the PaaS landscape (specifically Heroku’s strategic "End of Sale" for net-new Enterprise customers) marks a significant inflection point.

For the IT manager, it is vital to separate fact from fiction. **Heroku is not going away, but, given its announced feature freeze, it would seem to have no plans for improving enterprise customers' experience.** Existing customers can continue to renew, use the product, and receive the business-as-usual support they’ve relied on for years. However, for organizations looking toward the next five years of growth, a platform’s roadmap is its most important feature.

When a provider pivots away from enterprise expansion, it often results in a **stagnation of the roadmap**. For teams that have outgrown legacy constraints, Upsun represents the natural evolution, retaining the developer experience you love while introducing the governance and flexibility modern enterprises demand.

## **The strategic divergence: why roadmaps matter**

For a project manager or IT director, the risk isn't that a legacy platform will suddenly disappear; the risk is that it will fail to solve the _next_ set of challenges.

-   **Complex feature prioritization:** A platform that isn't pursuing new enterprise growth is unlikely to invest in the complex, high-security features that mid-market and enterprise users actually need.
-   **The "workaround" cost:** As your team’s requirements for AI integration, edge computing, or specific compliance standards grow, a stagnant platform forces your engineers to build manual workarounds. This saps velocity and increases operational "toil."
-   **Modern market sentiment:** The market is moving toward **Multi-Cloud** and **Resource Efficiency**. Sticking with a single-vendor, fixed-tier model can lead to unnecessary budget bloat and vendor lock-in.

## **Upsun: the "same, but better" evolution**

Upsun offers the familiar, Git-based workflow that defined the PaaS era, but it removes the "ceiling" that many enterprise teams eventually hit with PaaS plans and features.  Most PaaS products on the market are too narrow by focusing on a single stack, cloud or as set plan that limits your ability to scale. Upsun provides the enterprise-grade stability, hyperscaler integration, and developer velocity you count on, while adding a suite of capabilities that were previously out of reach.

### **1\. Production-perfect previews (The cloning engine)**

In legacy environments, "Review Apps" often only test code. This leads to the "works on my machine" syndrome when that code hits a production database or a specific search index configuration.

Upsun utilizes a sophisticated **environment cloning engine**. Every time a developer pushes to a new branch, Upsun can create an ephemeral environment that is a byte-for-byte replica of production that includes the data, the services (Redis, OpenSearch, etc.), and the networking.

For a manager, this means **significantly lower Change Failure Rates (CFR)**. You can verify performance and security on a perfect replica before a single line of code touches the live site.

### **2\. Granular resource control vs. "the Dyno Tax"**

Heroku’s fixed tiers (Standard, Performance) often lead to over-provisioning. If your app needs more RAM but no more CPU, you’re forced to pay for a higher tier regardless.

Upsun introduces **provision-based pricing**. You define the exact CPU and RAM requirements for every service.

-   **Predictable billing:** Pay only for the resources you provision.
-   **Vertical and horizontal scaling****:** Scale individual components (like a high-load worker) without scaling the entire stack.
-   **ROI optimization:** Mid-market teams often see a **20-30% reduction in waste** simply by right-sizing their resource footprint.

### **3\. Multicloud autonomy and compliance**

While legacy providers are often tied to a single infrastructure partner, Upsun gives you the power of choice. You can deploy to **AWS, Azure, Google Cloud, or IBM Cloud**—or even move between them using the same configuration files.

## **Enhanced security and configuration automation**

For the IT manager, governance is as important as deployment. Upsun enforces Infrastructure as Code (IaC). Because every database version and firewall rule is stored in your Git repository, your infrastructure becomes:

-   **Auditable:** See exactly who changed what and when.
-   **Reproducible:** Spin up a new environment or a disaster recovery instance in minutes.
-   **Secure:** Automated patches for managed services are handled by our team. We offer out-of-the-box compliance for the application layer, helping you meet standards like GDPR, SOC 2, PCI, HIPAA, and ISO, ensuring your cloud, architecture, and security teams can sleep better.

### **Better support for AI-enabled projects**

As you integrate AI into your development lifecycle, you need a platform that provides the flexible compute and high-performance data services required for LLM orchestration and vector databases. Upsun’s agnostic approach allows you to build and integrate _your_ AI solutions without being funneled into a specific vendor's ecosystem.

## **We are here to help: a seamless transition**

Moving to a new platform is a significant decision. We are committed to making it a "step up," not a disruption. Upsun is designed to delight your cloud architects and your developers simultaneously by giving them the autonomy they crave and the oversight you require.

**How we support your move:**

-   **Free strategic assessment:** We’ll evaluate your current Heroku stack and provide a blueprint for a more efficient, multi-cloud setup.
-   **Hands-on migration help:** Our application services team is available to help your team migrate your projects to Upsun.

### **Start your evolution today**

Don't wait for potential roadmap stagnation to affect your team's velocity. Let's discuss how a modern, multi-cloud PaaS can give your developers their time back and your budget more breathing room.

-   **Contact our Enterprise Team** for a free assessment.
-   **Explore the Documentation** to see our YAML configuration in action.

### [Hidden costs of running Kubernetes at scale | Upsun](https://upsun.com/blog/hidden-costs-of-running-kubernetes-at-scale/)

# The hidden cost of "just using Kubernetes"

Kubernetes has become the default foundation for a lot of modern application infrastructure. 

It’s powerful, flexible, and widely supported, which makes it an obvious starting point for many teams building a cloud-native application platform (a standardized way for teams to deploy, run, secure, and operate applications in production).

But there’s a distinction that often gets lost early in the decision process:

**Kubernetes is a framework. It is not a platform.**

Choosing Kubernetes doesn’t automatically mean you’re building a full platform. But the moment you want consistent deployments, security guardrails, shared services, observability, and sane developer workflows, you quickly move beyond “just Kubernetes” and into platform-building territory.

Kubernetes provides the core orchestration layer. Everything else, from CI/CD and environment management to security controls, service provisioning, and governance, has to be designed, integrated, and maintained on top of it.

## **What managed Kubernetes actually gives you**

Managed Kubernetes services such as EKS, AKS, or GKE undeniably reduce some of the operational burden. They typically handle the control plane, cluster lifecycle, and an increasing number of infrastructure concerns, making Kubernetes easier to adopt than it once was.

Even with these advances, Kubernetes remains a framework rather than a complete application platform. Teams still need to design and maintain the path from code to production, integrate CI/CD and Git workflows, secure applications, and operate application-level services such as databases, caches, and storage.

Kubernetes provides powerful primitives. Turning those primitives into a coherent, secure, and repeatable developer experience is a separate engineering effort that requires ongoing expertise and maintenance.

## **Where complexity quietly accumulates**

Early Kubernetes environments often feel manageable. A small cluster, a handful of services, and a few engineers who know their way around YAML can get surprisingly far.

The complexity shows up later.

As environments grow, teams must start making precise decisions about resource requests and limits, isolation boundaries, network policies, and access controls. Multi-tenancy introduces new challenges around fairness, security, and blast radius. Observability and alerting evolve from “nice to have” into critical infrastructure that has to be reliable under pressure.

None of this is unsolvable, but none of it is free. Each layer adds configuration, operational knowledge, and long-term maintenance overhead.

## **The real cost of Kubernetes is not the cloud bill**

Kubernetes is often described as “cheap” because the software itself is open source and managed clusters are relatively inexpensive to provision.

In practice, infrastructure costs are rarely the limiting factor. **The real cost shows up in engineering time and focus.**

Running Kubernetes well requires ongoing decisions about networking, storage, security, deployment workflows, and service integration. Even in leaner setups, teams still need to understand how these pieces fit together and how changes affect reliability and security over time. This work does not stop after the first deployment.

In practice, many teams spend months assembling and stabilizing the surrounding platform before developers can reliably ship production code.

For many organizations, this means allocating senior engineering time to operating the platform rather than building product. Over time, that opportunity cost often outweighs the apparent savings of a DIY approach. The real question is not whether Kubernetes can be made to work, but whether this is where a team’s engineering effort is best spent.

## **Scaling safely is harder than scaling quickly**

Kubernetes is designed to scale workloads. Scaling safely, predictably, and securely across diverse applications is a different challenge altogether.

As clusters grow, teams have to balance performance with isolation. Misconfigured resource limits can lead to noisy neighbors. Weak isolation can turn small failures into platform-wide incidents. Security becomes a multi-layered problem spanning infrastructure, the Kubernetes control plane, and the applications themselves.

These are not one-time design decisions. They are ongoing operational concerns that demand constant attention and adjustment.

## **Cost control erodes through operational drift**

Another common surprise is how difficult cost control becomes over time.

Clusters tend to grow incrementally. Nodes are added “just in case.” Storage accumulates. Network egress costs creep in. Tooling for monitoring, security, or policy enforcement often comes with its own licensing costs.

More importantly, misconfigurations and manual changes introduce waste and risk. Each error costs engineering time, causes downtime, or increases exposure. These costs rarely show up neatly on a cloud invoice, but they compound steadily.

## **Security and compliance shift responsibility upward**

Kubernetes is not secure by default. Even with a managed service, your team remains responsible for securing large portions of the stack.

That includes configuring access controls, enforcing network policies, managing secrets, and documenting controls for audits and certifications. Each additional tool or layer increases both the attack surface and the documentation burden.

For regulated environments, this overhead can become a serious blocker. A platform that embeds security, backups, and auditability by default removes much of that burden and makes compliance a property of the system rather than a recurring project.

## **Stateful workloads expose the limits of DIY platforms**

Kubernetes is a strong foundation for running applications, including those that depend on state. The challenge is not that Kubernetes cannot run stateful workloads, but that managing state reliably introduces a different class of complexity.

Databases, caches, and other stateful services require careful handling of data consistency, backups, recovery procedures, upgrades, and high availability. Kubernetes provides primitives to support this, and modern approaches such as Operators can help automate parts of the lifecycle. 

Even so, teams still need to understand what those abstractions do, where they fall short, and how to diagnose problems when something goes wrong.

Some organizations address this by pairing Kubernetes with managed database services from their cloud provider. That can remove part of the operational burden, but it also introduces new integration points, cost considerations, and operational boundaries that teams need to manage explicitly.

The core question for buyers is not whether stateful workloads can run on Kubernetes. It is whether they want to own the domain-specific expertise required to operate them safely over time. That includes tuning, backup validation, recovery testing, and consistency across environments.

A cloud application platform shifts this responsibility away from application teams. Stateful services are provisioned, managed, and integrated consistently across environments, often with the same workflows used for application code. This reduces fragility and typically costs less, in both time and effort, than assembling and maintaining an equivalent setup yourself.

## **Developer experience is not an accident**

Kubernetes is often described as a foundation for building developer platforms. That phrasing is accurate, and it also reveals where much of the hidden cost actually lives.

A good developer experience does not emerge automatically from Kubernetes primitives. It has to be designed. Opinionated workflows, clear guardrails, and integrated tooling do not appear by default. They are the result of deliberate product and platform design, followed by ongoing maintenance as teams, applications, and requirements evolve.

In practice, this means organizations end up building and maintaining an internal platform alongside their product. Engineers are needed not only to keep the system running, but also to define deployment flows, manage environment lifecycles, standardize how services are consumed, and ensure that day-to-day development remains predictable and safe. This is real engineering work, and it compounds over time.

A managed cloud application platform takes on that responsibility directly. The developer experience is provided out of the box, with established workflows and guardrails that reflect production realities. Developers can focus on application logic and delivery, while the platform absorbs the complexity of designing and maintaining the paths they use every day.

## **The real decision is about ownership**

None of this is an argument against Kubernetes. It is an exceptionally capable framework, and for some organizations, building on it directly is the right choice.

The real decision is about ownership.

Choosing Kubernetes means owning the platform: its security model, its workflows, its services, and its long-term evolution. Choosing a cloud application platform means delegating that responsibility to a system designed to absorb it.

The perceived higher cost of a platform like Upsun reflects work you no longer have to do and risk you no longer have to carry.

_For a deeper look at why many teams choose a PaaS over a DIY Kubernetes approach, see our_ _breakdown of PaaS vs Kubernetes__._

## **Choosing where responsibility lives**

The most important question isn’t whether Kubernetes is powerful enough. It almost always is.

The question is whether your organization wants to spend its time building and operating a platform, or whether it wants that platform to already exist.

When responsibility lives at the platform layer, teams move faster with fewer surprises. When it lives with application teams, flexibility comes with ongoing complexity and operational toil.

Understanding that tradeoff early is what separates sustainable platform strategies from expensive experiments.

### **Explore further**

-   Explore Upsun as a cloud application platform  
    Learn how Upsun handles environments, services, security, and developer workflows out of the box.
-   Read why PaaS can be a better alternative to Kubernetes  
    Dive deeper into the technical and operational differences in our comparison resources.

### [What’s New in Upsun Q3 2025 | Smarter, Faster, Greener Cloud Development](https://upsun.com/blog/whats-new-in-upsun-q325/)

# Upsun product showcase - What's new in Q3 2025?

## **Scaling smarter, running faster and building greener: what’s new this quarter on Upsun**

We are constantly advancing Upsun to deliver the tools you need. In the past quarter, we've been laser-focused on delivering powerful new features that give you more control, unlock better performance, and streamline your workflows. Our goal is to build tools that not only meet the technical demands of modern applications but also make the development process faster and more intuitive. Our latest AI-assisted features mark a major step forward in our commitment to AI-enhanced development. We’re not adding AI as a gimmick. Every AI capability must deliver measurable improvements in developer efficiency, reliability, or insight. Every feature we ship must prove one thing: **it helps developers do their best work.**  
  
From intelligent configuration to dedicated resources and sustainability insights, here’s a look at what’s new.

### **1\. AI-generated configuration files: build faster with an AI assistant**

Say goodbye to the usual manual scaffolding of your platform setup. With the new AI-Generated Configuration feature from Upsun, you can automatically create your project’s `.upsun/config.yaml` , based on your code repository. Opt-in to the AI mode when you run `upsun init`, and the tool will analyze your repository and send it to the Upsun API so the AI can propose a valid starter configuration. While the output is ready to deploy, you still retain full oversight — you review, adjust and fine-tune the YAML as needed. This approach streamlines onboarding for new projects, dramatically reduces setup time, and aligns your configuration with best-practice templates from day one. 

Privacy and security are at the forefront; there is minimal use of personal data: simply reading the user ID for authentication and audit log purposes (the user ID is not sent to AI). Any personal data stored by the customer in their project repository, or logged by the customer's application will be minimized.

### 2\. Upsun MCP Server

Unlock intelligent, AI-driven infrastructure management  simplifying operations, boosting productivity, and integrating seamlessly into developer workflows.

-   **Natural-language control**: Manage infrastructure with plain English commands, no CLI needed.
-   **Zero context switching**: Operate directly from your IDE or AI assistant.
-   **Secure operations**: Respects Upsun’s permissions and access model by default. Defaults to read-only operations unless explicitly configured to allow write operations.
-   **End-to-end management**: Create, monitor, and deploy environments seamlessly across projects  
     

**Beta Availability**  
The Upsun MCP Server is currently in **beta release**. By default, it operates in **read-only mode** to ensure safety during evaluation. Write operations (such as creating or modifying resources) can be **enabled manually via explicit configuration**.

To learn more, please read the dev-center article and the GitHub repository

### **3\. Guaranteed CPU resources: power when you need it most**

For your most critical applications, consistent performance is non-negotiable. We're excited to introduce **Guaranteed CPU Resources**, giving you access to dedicated, non-shared computing power for your most demanding workloads.

-   **Why it matters:** Guaranteed resources give your application its **own dedicated CPU and memory**, rather than sharing capacity with other workloads. This ensures **consistent, stable performance**, especially for workloads like databases, message brokers, or latency-sensitive services that can’t afford slowdowns from “noisy neighbors.” They’re ideal when you need predictable behavior, want to avoid performance surprises, or need to scale a single container beyond the normal shared limits. Once enabled, your app or service runs on a dedicated host just for that container, and the platform automatically provisions more hosts in the background if demand increases. This is entirely **self-service, automated,** and can be applied **per service or app**, giving you flexibility and reliability without operational overhead.

For more information, take a look at the documentation

### **4\. Automated horizontal scaling: effortless performance, optimized costs**

Say goodbye to manual resource management and late-night alerts. Our new **Autoscaling** feature allows you to automatically and precisely scale the resources for your app containers up or down based on real-time demand. This means no more over-provisioning for anticipated peaks or getting caught off guard by unexpected traffic.

Our goal with this is to make your application’s scaling Simple, Scalable and Sustainable

-   Simple - Set up resource thresholds and durations with minimum and maximum instances once and forget about any last-minute manual changes or custom scripts.
-   Scalable - Maintain optimal performance during periods of high demand and avoid slowdowns or downtime. Try automated scaling in development or staging environments to make sure your defined thresholds make sense before moving to production.
-   Sustainable - Reduce environmental impact and avoid unnecessary costs by automatically reducing resource allocation when demand is low.

For more information on how Autoscaling works, take a look at the documentation.

### **5\. Zero-downtime development: deploy without interruptions**

We're really excited to have Zero-downtime deployments in an early-access beta release. The goal is to allow you to keep your applications running smoothly while you release updates. With our new Zero-Downtime Development option, you can choose a deployment strategy that ensures your users never experience interruptions. **As this beta feature is still being actively worked on, please take a look at the** **technical documentation** for a deeper dive on how the feature works, current limitations and what use cases work best. We'd love to hear your thoughts and feedback, join our community or send us your feedback here

**The new ideal workflow:** Instead of waiting for a maintenance window or risking momentary outages during deploys, you can now roll out changes seamlessly with no downtime. For those rare cases where platform upgrades require downtime, in the future you'll be able to schedule dedicated maintenance windows on your own terms. The result: uninterrupted service for your users, greater flexibility for your team, and complete confidence every time you push to production.

### **6\. Manual deployment setting: deploy with confidence**

We understand that for mission-critical applications, you need an extra layer of control before pushing changes live. The new **Manual deployment setting** introduces a staging queue, giving your team the final say on exactly when your updates are deployed to production. Add and update variables with changes are staged automatically without triggering a full redeploy. This means you can update sensitive configuration values or environment settings on the fly, bundle them with code changes if needed, and push everything live only when you’re ready; saving time, reducing risk, and keeping your production environment stable.  
 

### **7\. Fastly CDN metrics, plugin and alerts.**

Managing your CDN shouldn’t require hopping between dashboards or juggling separate tooling. With the new **Fastly CDN plugin app**, you can configure, monitor, and purge your Fastly CDN directly inside the Upsun console, giving development teams a consistent and consolidated workflow within the tools they already use. This is ideal for teams that deploy frequently across multiple environments and need real-time CDN insight along with quick, precision cache purging. Whether you’re reviewing performance metrics, updating ACL rules, or triggering cache purges, everything is just one click away.

The plugin follows security best practices by storing all credentials locally in your browser and never sharing them with third parties. As an open-source project, our Fastly CDN plugin welcomes community contributions and feedback; view the source code on GitHub and suggest features, join the discussion on the Upsun discord. Or for a more in-depth view of the plugin, check out the dev-center article.  
 

### **8\. Carbon emissions dashboard: track your environmental impact**

Sustainability is a core value for us and for many of our customers. Our new **Carbon emissions dashboard** provides clear, actionable transparency into the environmental footprint of your services. You can now view and download your historical emissions data directly from the console, making it easier than ever to track, report, and work toward your company's sustainability goals. This tool empowers you to make informed decisions about your architecture and resource usage with environmental impact in mind.

### We want to hear from you!

We’re incredibly excited to see how you leverage these new tools to build, deploy, and scale your applications. Login to your console to try them out today. As always, we welcome your feedback (or checkout our Community as well!) as we continue to build a platform that works for you.

### [Why AI adoption outpaces governance and raises risk | Upsun](https://upsun.com/blog/ai-adoption-is-moving-faster-than-governance/)

# Why AI adoption outpacing governance poses real risks

AI pilots turn into production use fast, and spend follows. In December 2025, enterprise spending on OpenAI reached a new record, with business adoption climbing to 36.8%, signaling that AI is moving from experiments to everyday work.

Yet governance is lagging behind.

Most firms still lack clear controls, roles, accountability structures, and runbooks for safe use. McKinsey’s 2025 survey finds that while AI tools are common, most companies have not embedded governance deep enough to deliver enterprise-level outcomes. 

This mismatch creates real risk. Netskope reports that data policy violations tied to generative AI have doubled year over year, with many involving regulated data and the use of personal, unmanaged accounts.³

Your teams are shipping code and content with AI, while governance is still catching up. Why does the gap exist, why does it matter, and why must governance be designed alongside AI adoption, not after?

## Why AI adoption spreads faster than organizational governance

AI adoption is moving quickly for one simple reason. The tools are easy to access and mostly immediately useful.

Most modern AI tools are:

-   Cloud based
-   Low cost or free to start
-   Easy to integrate into existing workflows
-   Marketed directly to developers and businesses. 

An employee can start using an AI assistant in minutes. No procurement process. No architecture review. No formal approval. This leads to a pattern seen across many organizations what security teams now call shadow AI. The value is immediate, especially for repetitive or boilerplate tasks.

This leads to a pattern seen across many organizations:

-   Individual employees experiment with AI tools
-   Teams begin relying on them for daily work
-   Usage becomes embedded before leadership is aware

By the time governance conversations start, AI is already part of the daily workflow.

## Why AI governance moves slower than AI adoption

Governance requires coordination. AI governance in particular touches multiple teams:

-   Security teams
-   Legal and compliance
-   Data protection officers
-   Architecture and platform teams
-   Engineering leadership

Each group has different concerns, incentives, and risk tolerances. Aligning them takes time.

In contrast, adopting an AI tool can take minutes.

This imbalance creates a predictable outcome. Adoption happens first. Governance becomes a reaction, not a design input.

## The most common AI governance blind spots in enterprise teams

When AI tools are adopted without structure, several risks often go unnoticed.

### Shadow AI and data exposure

Employees frequently paste internal content into AI tools. This may include:

-   Proprietary source code.
-   Internal documentation.
-   Configuration files.
-   Customer or client data.

Even when this is done to improve productivity, it can expose sensitive information outside the organization.

Many AI providers collect user interactions, and in some cases, this data may be used to train models. This creates a real risk that proprietary IP or customer data leaves the organization without formal consent.

### Loss of intellectual property control

Source code is intellectual property. When developers share it with external AI tools, ownership and usage rights may become unclear.

Without governance, organizations may not know:

-   Which tools are approved
-   Where proprietary code is being shared
-   Whether that code is stored or reused

### Model drift and reliability risks

AI systems can change behaviour over time as models are updated. Outputs that were reliable last month may not behave the same way today.

Without governance, teams may:

-   Treat AI outputs as deterministic
-   Use them in critical paths without validation
-   Miss changes that affect accuracy or bias

Without clear guidance, teams may trust AI output more than they should. This creates operational risk that is difficult to detect after deployment.

### Compliance and regulatory exposure

Regulators are paying attention to AI usage. The EU AI Act entered into force in 2024, and similar frameworks introduce obligations around transparency, risk classification, and accountability³. If models touch personal data, GDPR duties also apply. 

However, many existing privacy and compliance processes do not yet account for how LLMs access customer data or how vendors handle training data.

## Governance does not mean blocking AI

One of the biggest misconceptions is that governance equals restriction.

Good governance enables faster adoption as it:

-   Defines which tools are safe to use
-   Clarifies what data can and cannot be shared
-   Provides safe environments for experimentation
-   Reduces uncertainty for teams

Teams move faster when rules are clear. The problem is not governance itself. The problem is introducing it too late.

## The role of platforms in enforcing AI governance

AI governance is also a platform challenge.

Without the right infrastructure capabilities, governance relies on trust and manual checks. That does not scale.

Stable platforms support governance by design through:

-   Isolated environments for testing and experimentation
-   Clear separation between production and non-production data
-   Auditable deployment workflows
-   Visibility into services and dependencies

Platforms that standardise how applications are built, deployed, and operated make it easier to enforce governance consistently without slowing teams down. This is especially true when platforms expose clear, predictable configuration and deployment models that both humans and automation can rely on.  It allows teams to experiment and innovate without bureaucracy slowing them down.

This is even more true when technological advances like the Model Context Protocol (MCP) have expanded what AI agents can do and access by enabling them to connect to databases, file systems, APIs, and internal tools with ease.

This further heightens the need for governance. The more capable AI agents become, the more urgent the need for clear boundaries, approved tooling, and auditable trails.

## Designing governance alongside AI adoption

The safest organizations are not waiting for perfect regulations or final frameworks.

They are:

-   Mapping where AI is already used
-   Defining lightweight usage policies
-   Providing approved tooling and environments
-   Building governance into developer workflows

This approach keeps teams moving while reducing risk.

Governance becomes part of how software is built, not an external checkpoint.

## The cost of ignoring the AI governance gap

The longer the governance gap persists, the harder it becomes to close. AI usage spreads quickly. Once embedded, it is difficult to unwind without disruption.

The risks compound:

-   Security incidents become harder to trace
-   Compliance gaps widen
-   Trust with customers and partners erodes
-   Teams lose confidence in AI outputs

None of these outcomes is inevitable. They are the result of delaying structure until after scale.

## Closing the governance gap intentionally

AI adoption is not slowing down. That is a given.

The real choice is whether organizations adopt AI deliberately or allow it to spread without structure.

The strongest teams design governance alongside adoption. They create safe paths for experimentation rather than trying to control behaviour after the fact.

## **Sources**

1.  Business Insider: Enterprise spending on OpenAI hit a record in December 2025  (https://www.businessinsider.com/openai-business-spending-ai-models-jumps-record-ramp-data-2026-1)
2.  McKinsey, The State of AI 2025 (https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai)
3.  ITPro summary of Netskope Threat Labs, 2025 report on generative AI data violations (https://www.itpro.com/technology/artificial-intelligence/generative-ai-data-violations-more-than-doubled-last-year)
4.  Journal of Medical Internet Research, 2024 study on hallucinated references (https://www.jmir.org/2024/1/e53164)
5.  European Parliament Research Service, AI Act implementation timeline, June 2025 (https://www.europarl.europa.eu/RegData/etudes/ATAG/2025/772906/EPRS\_ATA%282025%29772906\_EN.pdf)
6.  Goodwin Procter, EU AI Act implementation timeline explainer, Oct 2024 (https://www.goodwinlaw.com/en/insights/publications/2024/10/insights-technology-aiml-eu-ai-act-implementation-timeline)

### [The most common AI policy failures in organizations | Upsun](https://upsun.com/blog/most-common-ai-policy-failures-in-organizations/)

# The most common AI policy failures in organizations

AI adoption in mid-market organizations is moving fast. In many cases, it is moving faster than policy, controls, and oversight can keep up. For IT leaders, this creates a quiet but growing risk. AI tools are already embedded in daily work, yet few organizations have clear rules for how those tools should be used.

**Why AI policy failures are so common**

In most organizations, AI adoption does not happen through a formal process but rather through individual teams. Developers use AI tools to speed up development. Analysts use it to summarize data. Marketing teams use it to draft content. These tools feel harmless because they are easy to access and often free or low-cost.

The core issue is not malicious intent. The issue is unmanaged usage. Employees often paste internal content into AI tools without understanding where that data goes, how it may be stored, or how it may be reused.

When AI adoption is informal, policy usually comes later, if at all. By then, risky patterns are already embedded in workflows.

## Failure 1: No clear rules on what data can be shared with AI tools

One of the most common failures is the absence of clear data boundaries. Many organizations have general data protection policies, but those policies were written before the widespread use of large language models. They often do not explain whether employees can paste:

-   Source code
-   Customer records
-   Internal documents
-   Incident reports
-   Credentials or configuration details

Without explicit rules, employees make their own decisions. Well-publicized incidents show employees have pasted source code and confidential notes into public chatbots, creating potential exposure and loss of IP. 

Most commercial AI providers collect the inputs users provide. Some use those interactions to train future model versions. Your proprietary code, customer data, and strategic documents become part of a dataset you cannot access, audit, or delete.¹.

## Failure 2: Assuming AI tools are safe because they are popular

Another policy failure is equating popularity with safety. Tools like ChatGPT or similar assistants are widely used and well-known. This can create a false sense of security. IT teams may assume that if a tool is widely adopted, it must already be compliant with enterprise expectations.

In reality, most general-purpose AI tools are designed for broad consumer use, not regulated business environments. They are not automatically aligned with internal security policies, data residency requirements, or sector-specific compliance obligations.

Governance gaps often appear because AI tools are not formally reviewed, approved, or restricted in the same way as other software .

## Failure 3: Ignoring AI hallucinations as a business risk

AI systems generate confident-sounding text that is sometimes factually wrong. In technical terms, this is called hallucination. In business terms, it means errors can enter your documents, code, and customer communications without anyone noticing.

Without policy controls, there is often no requirement for validation or review. Hallucinated outputs often end up in business documents because teams trust AI responses too readily.

For IT leaders, this creates accountability risk. Decisions may be made based on content that appears authoritative but is not grounded in verified data.

## Failure 4: AI is excluded from existing compliance frameworks

If your organization handles customer data in Europe, you have GDPR obligations that AI tools quietly violate. The issue is straightforward: when AI systems access databases containing personal information, that access must be documented, disclosed, and justified under data protection law.

However, most corporate data privacy regulations were implemented before AI tools became common. They cover how customer data moves between internal systems and external partners. They specify how long data is retained and who can access it. But they rarely address the question of whether an AI system can process that data or what happens when that processing occurs on servers you do not control.

The result is a compliance blind spot. Your privacy policy explains how your customers' data is protected. But if an employee feeds that data into an external AI tool, you may be breaking promises you do not even know you made. 

## Failure 5: No approved list of AI tools

Another common gap is the lack of a validated tool list. In many organizations, employees choose AI tools independently. Some use browser-based tools. Others install extensions or integrate APIs directly into workflows. IT teams often discover this only after an incident or audit.

Without an approved list, IT leaders cannot:

-   Enforce consistent security controls.
-   Ensure data localization requirements.
-   Apply logging or monitoring.
-   Respond effectively to incidents.

## Failure 6: Treating AI as a productivity tool only

AI is often framed internally as a productivity booster. That framing can limit policy thinking. When AI is seen only as a way to save time, organizations may skip risk analysis. They may not ask:

-   What data is exposed?
-   Who owns the output?
-   How is the model trained?
-   What happens to our inputs?

This narrow view ignores long-term risks, including IP leakage, compliance exposure, and loss of control over sensitive knowledge.

Independent research shows that data exposure remains one of the most expensive and damaging forms of business risk, particularly for mid-sized organizations³.

## Failure 7: No accountability for AI usage

Finally, many AI policies fail because no one owns them.

There is often no clear answer to questions such as:

-   Who approves AI tools?
-   Who updates the AI policy?
-   Who audits AI usage?
-   Who responds to AI-related incidents?

Without ownership, policies stay theoretical. Usage spreads without oversight. When problems arise, responsibility is unclear.

## Why these failures matter now

These policy failures matter because AI adoption is accelerating, not slowing down. Mid-market organizations sit in a difficult position. They are large enough to face regulatory scrutiny, but often lack the resources of large enterprises.

Weak AI governance increases the likelihood of:

-   Data privacy breaches.
-   Regulatory non-compliance.
-   IP loss.
-   Operational errors.
-   Reputational damage.

For IT middle management, this risk is both personal and organizational. Governance gaps often surface during audits, incidents, or executive reviews, by which time it is already too late.

## Moving forward: visibility & control as the starting point

The goal is not to block AI usage. It is to bring it under control. The first step for any mid-market IT leader is understanding how AI tools are actually being used across the organization today. Which tools are employees accessing? What data flows through them? Where does that data end up?

Most organizations discover they have far less visibility than they assumed. The tools are often browser-based and bypass traditional IT controls. Usage is distributed across teams with no central tracking. The gap between official policy and actual practice is wide.

Closing that gap requires governance around validated tools, data localization, and clear guidelines for what information can and cannot be shared with AI systems. It requires updating compliance programs to address AI as a data-processing category. And it requires review processes that account for the specific risks AI-generated content introduces.

## How Upsun helps you close the gaps

Upsun helps connect AI policy to day-to-day operations by making controls visible, repeatable, and enforceable.

-   **Git-driven YAML configuration:** Infrastructure, services, and access rules are defined in version-controlled YAML, making changes auditable and easy to review as code.
-   **Automatic previews per branch**: Every change can run in an isolated preview environment, with support for cloning data and applying sanitization. This allows teams to test AI-related workflows safely before production.
-   **Multi-service orchestration**: Applications, APIs, and supporting services are deployed and managed together, reducing the risk of unmanaged scripts or disconnected AI components.
-   **Built-in observability and APM** : Integrated logging and performance monitoring make it easier to track behaviour, performance, and failures across environments from day one.
-   **Platform-level compliance and security controls:** Upsun operates under established security and compliance frameworks, which gives IT teams a controlled foundation for running AI-enabled workloads alongside regulated systems. This supports internal governance efforts by aligning infrastructure with recognised standards. See Upsun Trust center to learn more.

Together, these features help IT teams balance developer velocity with operational oversight. 

## **Sources**

1.  OpenAI, “Data usage and retention policies.”  
    https://openai.com/policies
2.  European Commission, “General Data Protection Regulation (GDPR)”  
    https://gdpr.eu
3.  IBM, “Cost of a Data Breach Report 2024”  
    https://www.ibm.com/reports/data-breach
4.  TechRadar coverage of Dataiku findings on shadow AI (https://www.techradar.com/pro/businesses-are-losing-control-of-ai-and-bosses-are-starting-to-despair)
5.  Cybernews recap of Samsung leak incidents (https://cybernews.com/security/chatgpt-samsung-leak-explained-lessons/)
6.  EDPB opinion on AI models and GDPR principles (https://www.edpb.europa.eu/news/news/2024/edpb-opinion-ai-models-gdpr-principles-support-responsible-ai\_en)
7.  EDPB “AI privacy risks and mitigations” support-pool guidance (https://www.edpb.europa.eu/our-work-tools/our-documents/support-pool-experts-projects/ai-privacy-risks-mitigations-large\_en)
8.  UK ICO guidance on AI and data protection (https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/)

### [How Upsun delivers 99.99% uptime for AI workloads | Upsun](https://upsun.com/blog/how-upsun-delivers-9999percent-uptime-for-ai/)

# Inside the architecture: How Upsun delivers 99.99% uptime for AI

For a CTO, "four nines" represents a commitment to keeping production revenue live with less than 0.01% of total downtime per year. 

As AI workloads move from pilot projects into core production services, the reliability requirements for infrastructure have shifted. AI agents, RAG pipelines, and automated LLM workflows depend on a consistent platform state. 

When the underlying infrastructure is fragmented or prone to configuration drift, these agentic loops fail, leading to expensive human intervention and broken user trust.

## From static clusters to dynamic scaling

Historically, high availability meant provisioning "Dedicated" clusters, which were isolated virtual servers that split the load, but meant you were typically over provisioned. 

Today, Upsun delivers redundancy through **horizontal scaling**.

Instead of a single, rigid environment, you can now deploy multiple instances of your application containers across isolated hosts. If one container or host fails, the Upsun router instantly detects the health change and shifts traffic to healthy instances. 

This self-healing mechanism ensures that your applications and AI agents keep running without manual intervention.

## Performance without compromise: Guaranteed resources

A common risk in shared cloud environments is the "noisy neighbor," a situation where another project’s traffic spike steals your CPU cycles. In the past, the only solution to guarantee performance was a Dedicated host.

Upsun now solves this through **Guaranteed Resource Profiles**. 

By selecting a "Guaranteed" profile for your application, you receive dedicated CPU and RAM allocations that are not shared with any other project. This provides the same performance consistency as a dedicated server but with the agility of a containerized platform. 

For compute-heavy tasks like LLM inference or vector database indexing, this ensures your response times remain flat even during peak global traffic.

## Operational reliability through container immutability

Design is only half of the reliability equation; the other half is operational control. 

A primary cause of production outages is "hot-fixing" or making manual changes directly on a production server that are never tracked in version control. These changes eventually cause the environment to diverge from the original configuration, creating a "snowflake" server that is impossible to debug or replicate.

Upsun enforces reliability through **Read-Only Containers**. Every deployment builds a new, immutable container image. Once deployed, the file system is read-only. This prevents unauthorized or accidental modifications to the running application code.

Because every restart or failover event uses the exact same cryptographically verified image, the system always returns to a "known good" state. 

This level of environmental parity ensures that if an AI agent works in a preview environment, it will behave identically in production.

## Automated health monitoring and edge shielding

High availability on Upsun includes an automated layer of health monitoring and recovery. 

The platform continuously tracks process health; if a container hangs or a health check fails, the platform triggers an **automatic restart** or reroutes traffic to other instances. This self-healing capability moves the burden of first-response from your on-call engineers to the platform itself.

Furthermore, availability must extend beyond the application logic to the network layer. AI agents are often compute-intensive, making them vulnerable to resource exhaustion during external traffic spikes or DDoS attacks.

Upsun integrates a **managed edge layer** that can provide:

-   **Automated WAF and DDoS protection**: Malicious traffic is absorbed at the edge before it ever reaches your application nodes.
-   **Regional edge proxies**: Intelligent routing ensures that legitimate requests are prioritized, preserving compute resources for intensive AI inference tasks.

**The outcome-anchored shortcut:** If you’re seeing intermittent ‘works on my machine’ behavior or deployment-related outages, here’s a quick set of signals that usually points to environment drift.

## Data integrity: automated protection and rapid recovery

Reliability is not just about staying online; it is about ensuring that your data remains safe and recoverable even in the face of error or operational mishaps. Upsun provides an integrated backup system that acts as a final safety net for your production environments.

-   **Automated daily snapshots:** Upsun automatically creates regular backups for every production environment. These snapshots capture the entire state of your application, including all persistent data from managed services like databases and all files stored on mounts.
-   **Customizable retention policies:** Depending on your business needs, you can choose between Basic, Advanced, or Premium backup schedules. This allows for retention periods ranging from a few days to an entire year of monthly archives, ensuring you meet both internal recovery goals and external compliance requirements.
-   **Near-zero downtime backups:** By default, manual backups involve a momentary pause of roughly 15 to 30 seconds to ensure a consistent data state. For mission-critical services that cannot afford any interruption, Upsun offers a "Live Backup" option that creates snapshots while the environment remains fully open to connections.
-   **Flexible restoration:** In the event of an incident, you can restore a backup to its original environment or to a completely new one. This is particularly useful for disaster recovery or for creating "safe" staging environments where you can test the restoration of production data before applying changes to the live site.

By centralizing these recovery mechanisms within the platform, Upsun removes the need for complex third-party backup tooling and ensures that your disaster recovery path is as automated as your deployment pipeline.

_**For more info:**_ _**Explore why Upsun is the multi-cloud PaaS technical leaders are choosing in 2026.**_

## The verdict: shifting from plumbing to product logic

The cost of an outage in 2026 isn't just lost transactions; it is a loss of data context for your AI systems. 

By utilizing a platform that manages container orchestration, security updates, and high-availability failover at the architectural level, engineering leaders can refocus their senior talent.

Instead of managing the plumbing of cloud providers, your architects can focus on the logic and performance of the applications that move the business forward

**Next steps for engineering leaders:**

-   **Map the approach**: If you want to see how these architectural pillars translate into a delivery workflow - **Explore the latest product showcase and orchestration updates**. 
-   **Build with confidence**: If you’re ready to validate this on a real service, the next step that actually answers "will this work for us?" is a PoC - **Start your free 15-day trial**.

### [Meet the ADA Title II mandate with WCAG 2.1 AA | Upsun](https://upsun.com/blog/ada-title-ii-mandate-higher-ed-wcag-2-1-aa/)

# Why your April 2026 ADA compliance strategy will fail without environment parity

For decades, digital accessibility in state-funded higher education has largely been a "reactive" game. 

If a student with a visual impairment reported an issue with a tuition portal, the university would scramble to provide an accommodation. 

As long as the institution could show "meaningful progress" toward compliance, it was generally shielded from significant legal repercussions.

**That era is officially ending.**

The U.S. Department of Justice’s new ADA Title II rule has set a firm deadline: **April 24, 2026**. 

By this date, state-funded universities and local government institutions must meet the **Web Content Accessibility Guidelines (WCAG) 2.1, Level AA** standard.

The most critical shift? "Meaningful progress" is no longer a legal defense. 

In this new landscape, accessibility isn't just a policy; it’s a technical requirement. 

To meet this challenge, universities must move away from manual, piecemeal fixes and toward an infrastructure that makes accessibility an automated, standardized part of the development lifecycle.

## **The end of the safety net**

Paul Gilzow, Technical Success Manager at Upsun and a 20+ year veteran of Mizzou’s technical landscape, warns that the legacy safety net is gone.

"In the past, as long as you were notified of an issue and showed you were working on it, that was usually enough," says Gilzow. "The difference now is that this is no longer an accepted defense. You are opening yourself up to further investigation and potentially lawsuits the moment the deadline hits."

The scope of responsibility has also expanded. **Universities are now fully liable for the accessibility of third-party vendors**. 

Whether it is a student portal, a Learning Management System (LMS), or a niche research blog, if the university provides the URL, the university is responsible for its compliance.

**Resource:** Explore how Upsun helps Higher Ed teams maintain 99.99% uptime and compliance across complex fleets.

## **Solving the "digital sprawl" and "toil" of decentralization**

Higher education presents a unique architectural challenge: extreme decentralization. 

A single university system can host hundreds of sites, ranging from high-traffic admissions portals to small, faculty-led research blogs.

"The big advantage Upsun brings is the ability to develop standards across that decentralized area," says Gilzow. 

By standardizing the infrastructure, tech stacks, and frameworks used across the entire institution, central IT departments can eliminate "toil": the manual work of configuring servers or managing disparate environments.

**Case Study:** How the University of Missouri centralized 1,600 unmanaged sites and reduced maintenance time by 75%.

This standardization allows IT teams to focus on the "tail" of the university's digital presence. 

Once the high-resource sites like Admissions are secured, teams can use the resources saved through automation to help smaller departments that lack the budget for dedicated accessibility experts.

## **Engineering accessibility with production-perfect clones**

**The most dangerous moment for accessibility isn't the initial launch; it is the "deployment gap."** 

This happens when new code is pushed to production and accidentally breaks a previously compliant page: a "regression" that often goes unnoticed until a user files a complaint.

Upsun mitigates this risk through automated preview environments defined in your .upsun/config.yaml:

-   **Exact byte-for-byte clones:** Developers can spin up an exact clone of the production environment for every single pull request. This includes the database, files, and configurations.
-   **Testing against real content:** Accessibility issues often hide in the interaction between code and content. These environments allow teams to test new code against real production content in total isolation.
-   **Catching regressions early:** As Gilzow notes, "It is not so much that it fixes accessibility, but it allows you to catch potential issues or regressions before they are exposed to the public."

**By integrating these clones into the Git workflow (GitHub, GitLab, or Bitbucket), accessibility becomes a visible, non-negotiable part of the review process rather than an afterthought.**

## **Building automated guardrails in your pipeline**

While automation is essential, it isn't a simple "pass/fail" check. Accessibility is a shared responsibility between IT (code) and content owners. 

"You can write code that checks if an image has alt-text," Gilzow explains. "But historically, it has been hard for code to verify if that alt-text is actually good and describes the image accurately."

Instead of a binary check, universities should use Upsun to build technical guardrails. By integrating tools like Axe-core, Lighthouse, or Pa11y directly into the CI/CD pipeline via .upsun/config.yaml, developers can:

1.  **Enforce code standards:** Ensure the underlying HTML structure supports assistive technologies like screen readers.
2.  **Test user journeys:** Use end-to-end testing in preview environments to ensure a student can navigate a payment flow or registration form via keyboard navigation.
3.  **Empower content creators:** Set up the system so that content owners use themes and modules that have been pre-verified for compliance, reducing the chance of human error.

## **Modernizing legacy debt without the "fear of breaking"**

Every university has "that site": a project built by a grad student years ago that is now vital to a department but too brittle to touch. 

Modernizing these sites for WCAG 2.1 AA is often delayed because teams are terrified of breaking production.

Upsun’s infrastructure-as-code model allows teams to clone these legacy environments into isolated sandboxes. 

This removes the fear of experimentation, enabling teams to modernize old document silos or replace inaccessible front-ends without risking a system-wide outage.

## **Future-proofing: from WCAG 2.1 to 3.0**

The 2026 deadline focuses on WCAG 2.1 AA, but the standards are evolving. WCAG 2.2 is already being adopted, and WCAG 3.0 is on the horizon.

"The good news is that 2.2 is backwards compatible with 2.1," says Gilzow. "If you meet 2.2, you already meet 2.1." 

By using Upsun's flexible, cloud-native architecture, institutions can update their tech stacks and accessibility standards incrementally. You don't need a total rip-and-replace every five years. 

The agility of the platform allows you to manage resources and introduce enhancements whenever your team is ready.

## **Redirecting resources to the mission**

Ultimately, meeting the ADA Title II mandate is a resource management problem. Universities have limited time and a massive amount of digital ground to cover before April 2026.

Upsun reduces the "cognitive load" on your developers. 

When the infrastructure works the same way regardless of the tech stack (Drupal, WordPress, or Node.js), and when preview environments are automated, developers can stop worrying about "how" to deploy and start focusing on "what" they are deploying.

**Is your institution ready for April 2026?** Standardize the infrastructure, automate the checks, and redirect those resources back to the mission: making education accessible for everyone.

**Schedule a demo with our experts to audit your fleet.**

### [Why real-time AI needs real-time governance | Upsun](https://upsun.com/blog/why-real-time-ai-systems-require-real-time-governance/)

# Why real-time AI systems require real-time governance

**Why real-time AI systems require real-time governance**

For many organizations, AI has become a routine part of how work gets done. With the adoption of tools that summarise documents, write code, query data, or assist customer support, which are used daily by engineers, analysts, and business teams. For IT leaders, the value is clear: productivity improves, delivery speeds up.

But governance has not kept pace.

Most enterprise controls were designed for systems that act after a request is reviewed, logged, or approved. Modern AI systems do not wait. They respond in milliseconds, often using live data and external models. Once an AI action happens, the data leaks, compliance violation,s and security breaches happen without anyone noticing until the damage materialises.

This is why real-time AI systems require real-time governance. Policy enforcement must happen before an AI action executes, not after. It means building guardrails into the infrastructure itself, not bolting them on as an afterthought.

## The governance gap created by real-time AI systems

Traditional governance was designed for a different era. Compliance teams would review systems before deployment, conduct periodic audits, and update policies annually. That model assumed decisions happened slowly enough for humans to intervene when needed.

Real-time AI systems completely break this model.

-   They respond in milliseconds.
-   They often combine internal data with external models.
-   They are used directly by employees, not only through controlled applications.

This creates a clear governance gap. By the time a policy violation is detected, sensitive data may already be exposed or copied elsewhere.

For IT middle management, this gap is not theoretical. It shows up in daily operations.

-   Employees paste internal documents into AI tools.
-   Code snippets containing secrets are shared with external models.
-   AI-generated outputs are trusted without validation.

Once this happens, controls applied after runtime are no longer effective.

## AI governance failures start before runtime

Most AI risk does not come from malicious intent. It comes from normal behaviour.

Engineers use AI to speed up repetitive work. Analysts use it to summarise reports. Support teams use it to draft responses. These actions often happen outside formal workflows.

One of the biggest risks is employees unintentionally leaking proprietary data by copying and pasting it into AI systems . At runtime, the AI has already received the data. Governance that relies on audits, reviews, or alerts after execution is too late.

This is why policy must be enforced before the AI system is allowed to act.

## GDPR and compliance risks increase with AI access

In regulated environments, AI introduces additional complexity.

Customer databases often contain personal or identifying data. If AI systems can query or process this data, organisations must ensure that customers are informed and that access is lawful.

Many existing data privacy processes do not account for AI or LLM access at all .

This creates several problems:

-   Customers are not informed that AI systems may process their data.
-   Data localisation rules may be violated.
-   Audit trails may not clearly show how data was used.

Once again, controls applied after runtime cannot undo these issues.

## Why policy enforcement must happen pre-runtime

The solution is not better audits. It is embedding governance into the runtime environment. Policy must be enforced the moment an AI system attempts to take an action, not discovered weeks later in a log review.

This concept, sometimes called policy-as-code, translates human-readable rules into machine-executable controls. 

Pre-runtime policy enforcement focuses on:

-   Which AI tools are approved.
-   What data those tools can access.
-   How requests are structured and constrained.
-   What outputs are permitted.

If a request violates policy, it should be blocked before execution, not logged for review later. Organizations implementing this approach catch compliance issues during development rather than production, where remediation costs are dramatically lower. They also see faster deployment cycles because governance becomes a predictable pipeline component rather than an unpredictable bottleneck.

## Predictable interfaces reduce AI governance risk

One reason governance struggles with AI is unpredictability. Many AI tools operate as black boxes. Inputs are flexible. Outputs vary. Integrations change frequently. You cannot govern what you cannot see or control.

From a governance perspective, this is difficult to manage.

This is where predictable and standardized protocols become essential. When AI agents access tools and data through defined interfaces, every interaction can be logged, permissioned, audited, and policies applied consistently.

This includes:

-   Clear input boundaries.
-   Explicit data sources.
-   Known execution paths.
-   Observable outcomes.

Organizations can define what data sources AI systems may access, what actions they may take, and what information they may expose. Those rules apply universally because every AI interaction flows through governed interfaces. 

## Real-time governance is an IT responsibility

A common concern is that governance will slow teams down. In practice, unclear governance creates more friction.

When policies are vague, teams make their own decisions. When incidents occur, controls are added hastily. This leads to inconsistent rules and growing operational toil.

Real-time governance works best when it is embedded into platforms and workflows that teams already use.

For IT middle management, the goal is not to block AI adoption. It is to make safe usage the default.

## Governance at the Platform Layer: Scalability Without Sacrificing Control

For modern leadership, the challenge isn't just adopting AI. It’s doing so without creating a fragmented ecosystem of "shadow AI" that bypasses traditional security protocols. Traditional governance models, built on manual reviews and annual audits, act as a bottleneck that slows down innovation. Real-time AI systems require a shift toward platforms that standardize how applications are built, deployed, and operated. By moving governance to the infrastructure layer, organizations can ensure that policy enforcement is an automated part of the development pipeline rather than a manual hurdle.

**Upsun** applies this principle by providing a platform that makes governance enforceable by design, rather than just theoretical. By utilizing **predictable configuration**, **isolated environments**, and a **clear separation** between code, data, and services, Upsun allows IT leaders to bake safety into the very foundation of their AI workflows.

### Out-of-the-Box Guardrails for Real-Time AI

When governance is embedded directly into the platform, the transition from "advisory" policies to "enforceable" controls happens automatically. This approach supports high-velocity development through:

-   **Pre-approved Integrations**: Ensure AI agents only connect to vetted, secure external models and tools, preventing the use of unmanaged black-box services.
-   **Controlled Data Access**: Define exactly what data sources AI systems can query, ensuring sensitive customer databases remain protected and compliant with GDPR or data localization rules.
-   **Clear Auditability**: Every interaction through governed interfaces is logged in real-time, providing a transparent trail of how data was used and what actions were taken.
-   **Reduced Risk of Accidental Exposure**: By isolating environments and standardizing protocols, the risk of an employee unintentionally leaking proprietary data into an external LLM is drastically minimized.

The key takeaway for leadership is that the **model matters more than the tool**. To scale AI safely, you need an infrastructure that treats **policy-as-code**. With Upsun, your teams move faster because they aren't waiting for manual reviews; they are operating within a framework where the guardrails are already built-in.

## Moving governance to where AI decisions are made

If you manage AI governance, the shift to pre-runtime policy has immediate implications. Start by auditing where your current AI tools connect and what data they can access. 

Next, evaluate whether your governance controls are advisory or enforceable. A policy document prohibiting certain AI uses is advisory. A technical control blocking those uses is enforceable. The difference determines whether your governance actually works.

Finally, consider how your AI infrastructure enables or prevents governance. Custom integrations built for specific tools create ungovernable systems. Standardized interfaces that all AI tools must use create governance opportunities. The architecture you choose now determines whether real-time policy enforcement is even possible.

The organizations getting this right treat governance as the foundation that makes AI adoption safe enough to scale. When policy is embedded in infrastructure, teams move faster because they do not wait for manual reviews. They take on more ambitious use cases because guardrails are built in. They build trust with stakeholders because governance is demonstrable, not just documented.

Real-time AI systems will only become more prevalent. The question is whether your governance keeps pace. The answer depends on treating policy as code rather than documentation. 

## **Sources**

1.  Stanford HAI, AI Index Report 2025
2.  IBM, Cost of a Data Breach Report 2025
3.  McKinsey & Company, The State of AI 2024
4.  IAPP, AI Governance Survey 2025
5.  Knostic, AI Governance Statistics 2025

### [Transforming a Symfony monolith to multi-apps | Upsun](https://upsun.com/blog/transforming-symfony-monolith-to-multi-apps/)

# Transforming Symfony monolith to multi-apps: a step-by-step guide

_This blog post is based on Florent Huck, Developer Advocate at Upsun, at SymfonyCon 2023. We utilized AI tools for transcription and to enhance the structure and clarity of the content._

The journey from a single monolithic application to a multi-application architecture doesn't have to be daunting. At a recent developer conference, Florent from Upsun's Developer Relations team shared a practical step-by-step guide on how to refactor a monolith into multiple applications using Upsun.

## Why move from one app to many

According to Upsun’s data, an overwhelming 90% of Symfony applications hosted on their platform are monoliths, with only 10% using two or more applications. This statistic reveals a significant opportunity for developers to modernize their architecture and decouple their applications for better scalability and maintainability.

The example project is the “Bigfoot” workshop site. It started as a Symfony 6.2 application on PHP 8.3 with PostgreSQL 15 and no admin interface. For the workshop, the team needed the same site in other languages and a simple way to manage content. That pushed the move from one app to a multi-app setup:

-   Keep Symfony as the core app and add API Platform to expose data.
-   Add an admin using the API Platform Admin components.
-   Add a Gatsby “white label” front end that reads from the API.
-   Add a Mercure server for real-time updates.

## What Upsun handles for you

Upsun sits between your code and a major cloud provider you choose. You do not manage servers. You push your code, set a simple YAML config, and Upsun handles hosting.  A new project gets the default architecture out of the box: CDN, automatic backups, caches, search, and a database. Even the demo app includes PostgreSQL without requiring any additional steps. Certificates are managed for you with automatic renewals, so you don't have to worry about TLS certificate management.

If you want a quick look at how Upsun works, start here on the Upsun website.

**Four commands to live**

The deployment process is straightforward. With just four commands using the Symfony CLI, you can have your application up and running:

1.  Create a demo project with the Upsun option
2.  Initialize an existing Symfony project (which auto-generates the necessary config files)
3.  Follow the standard Git workflow (add, commit)
4.  Create and push your project

From there, every Git branch gets its own live environment with a stable URL and a valid certificate. You test in an environment that behaves like a production environment. Thanks to Fabien Potencier's work integrating Upsun CLI tools into the Symfony CLI, everything can be managed through a single interface.

## Case study: The Bigfoot website

To demonstrate the refactoring process, Florent used a real example: the Bigfoot website, originally created for Blackfire workshops. This blog-like site about Bigfoot sightings was built as a monolith using:

-   Symfony 6.2 (updated to work with PHP 8.3)
-   PostgreSQL 15
-   Extensive fixtures
-   No administration interface

The goal was to transform this single application into multiple interconnected applications:

-   A Symfony application serving the main Bigfoot site
-   An API Platform admin component for content administration
-   A Gatsby frontend as a white-label solution
-   A Mercure server for real-time communication

## Step-by-step refactoring process

#### **1\. Create a new environment**

Never push directly to production. Start by creating a new branch using the Symfony CLI, which automatically creates both a local Git branch and a corresponding environment with the same data as your previous branch.

Upsun automatically generates SSL certificates and manages their renewal, eliminating the pain point that many developers face when managing certificates manually.

#### **2\. Adapt folder structure**

The transformation requires reorganizing your folder structure. Instead of having a single application with a `.upsun` configuration folder, you create:

-   A root `.upsun` folder containing the main configuration
-   Separate folders for each application containing their respective source code
-   Each application gets its own customized configuration

#### **3\. Add API Platform to Symfony**

Install the API Platform core bundle in the Symfony app. It exposes a REST API from your Doctrine entities. When an entity changes, the REST endpoints reflect that change. That is how the Gatsby front end and the admin will read and write content.

#### **4\. Manage configuration** 

Upsun uses a single YAML configuration file. This file contains three main sections:

**Routes configuration:** Each application gets its own routing block. You define URL patterns, such as using the default domain for the main app, /admin for the administration interface, `/site` for the Gatsby frontend, and subdomains for services like Mercure.

**Services configuration:** Adding services is straightforward. Under `services`, define the data stores each app needs:

-   `type: postgresql` with `version: 15` for the database.

 For example, to add Redis, you simply specify:

```shell-session
redis:

  type: redis

  version: 7
```

You can add small config flags here (such as max memory policy). Upsun transforms this simple block into the right managed service on the cloud you've chosen. You do not write provider-specific setup scripts.

**Application configuration:** For each application, you define:

-   **Runtime:** Specify major and minor versions (for example, PHP 8.3). Each deploy uses the latest maintenance release for that line.
-   **Source root:** The folder where that app’s code lives.
-   **Relationships:** Link the app to services (for example, the Symfony app to PostgreSQL).
-   **Mounts:** Writable paths such as var/ for cache and logs.
-   **Web:** Where the web root and front controller live (for example, `public/index.php`).
-   **Build and deploy steps:** Use Symfony Configurator’s `symfony build` and `symfony deploy` to clear cache, run migrations, and run any custom commands you need. Add cron jobs and workers if needed.

## Push, test, and promote

When your config and code changes are ready:

-   Push your branch: `symfony push` deploys your branch environment.
-   Upsun prints a small graph of apps and services, allowing you to confirm the relationships.
-   Routes are generated from your routing rules, such as:
    -   Default site at the root.
    -   Admin at `/admin`.
    -   Gatsby site at a path like `/site`.
    -   Mercure on a subdomain.

Test each route. When you are satisfied, run `symfony merge`. Upsun promotes the build-to-production.

## Resource allocation: what changes with Upsun

Upsun introduces a `resource:set` CLI command that allows per-container resource allocation. You can specify exactly how much CPU and RAM each container receives, making the platform more flexible and cost-effective.

This granular control means you can:

-   Downsize resources for development environments
-   Test different resource configurations on dedicated environments
-   Pay only for what you provision across all environments

### **Continuous integration**

Upsun supports integration with GitHub, GitLab, and Bitbucket. When you create a new branch and push it to your repository, Upsun automatically deploys your source code to a dedicated environment, enabling proper continuous integration.

However, developers must be mindful of resource usage since each environment contributes to the monthly bill. Unlike fixed-size preview environments, Upsun's flexible model means your feature branches can impact costs if not adequately managed.

## Best practices

### **Deploy often, deploy confidently**

Upsun's motto is "Deploy Friday" (and even "Deploy on Black Friday"). The philosophy is simple: if you can test your features in a production-like environment, you can confidently push all necessary source code to your Git branch.

This approach eliminates the common developer nightmare: "I don't understand why staging crashed; it works locally." With proper environment parity, missing files will cause failures in your development environment before reaching production.

### **Git workflow adaptation**

The multi-application architecture requires slight modifications to your Git workflow, but the core process remains familiar. The key is to deploy frequently and test thoroughly in environment branches before merging to production.

## Common pitfalls and solutions

During the development of the multi-application Bigfoot site, several challenges emerged:

1.  **Routing Issues:** When using URI elements to recognize applications, you must report the first URI element in both the route name and path configuration.
2.  **Environment Variables:** Local development typically uses localhost:8000, but production uses dynamic URLs. The `.environment` file solution offers the flexibility required for various deployment scenarios.
3.  **Resource Management:** Without careful planning, development environments can consume as many resources as production, significantly impacting costs.

## The future of multi-application architecture

This approach to refactoring opens up numerous possibilities for modern web development. By decoupling your monolith into specialized applications, you gain:

-   Better separation of concerns
-   Improved scalability options
-   Technology diversity (mixing Symfony, Gatsby, and other frameworks)
-   Enhanced development team workflow

The Bigfoot project successfully demonstrated how a traditional Symfony monolith can evolve into a modern, multi-application architecture while maintaining all functionality and adding new capabilities, such as real-time communication and advanced administration interfaces.

## Where this leaves you

You do not have to jump into a microservices maze. You can split a monolith into several apps where it makes sense, such as API, admin, frontend, and real-time. Upsun’s single YAML, managed services, auto HTTPS, and branch environments make that move safe and repeatable. When you are ready, merge and go live.

### [What is an MCP server and how to use it | Upsun](https://upsun.com/blog/mcp-server/)

# Managing cloud infrastructure with AI assistant and Upsun MCP server 

Artificial intelligence is changing the way we execute our everyday operations. AI assistants are incredibly intelligent; they can write code, explain complex concepts, and answer any question you throw at them. However, they can't execute actions on their own.

If you ask your AI assistant to _“create a backup of my database,”_ it may provide you with clear instructions, run the CLI commands directly or in some cases, even trigger actions through connected agent workflows. But for most developers today, these tasks still require switching to your terminal or platform tooling to review, validate, and run commands manually. This constant back-and-forth between your AI assistant and your actual tools wastes time and breaks your focus.

The Model Context Protocol (MCP) closes this gap between AI assistants and external systems. MCP provides a standardized way for AI to access tools and real-time data. The Upsun MCP server applies this to cloud infrastructure management, connecting your AI assistant directly to the Upsun API.

### **The problem MCP solves**

AI assistants have a fundamental limitation: they can describe how to do something, but they can't actually do it. They lack connections to the tools and systems you use daily.

Before MCP, every connection between an AI model and an external tool required custom code. Want Claude to read your Google Drive files? Someone builds that specific integration. Want ChatGPT to query your database? That's another custom integration. The number of integrations needed grows exponentially with each new AI model and tool you add. This fragmented approach created significant problems, such as:

-   **No standardization:** Each AI assistant had its own method for connecting to external systems, making integrations difficult to reuse or maintain across platforms. A tool built for Claude wouldn't work with ChatGPT or other AI assistants.
-   **Duplicate effort for developers**: Organizations building AI integrations have to write and maintain separate code for each AI platform they want to support. For example, if a tool is needed to manage cloud resources, it will be rebuilt for every AI assistant. Work done for one provider couldn’t be easily transferred to another.
-   **Limited access to real systems and data:** Without a standardized way to expose tools or data sources, AI assistants operate with incomplete context. They could generate helpful outputs, but lacked the secure access needed to interact with external systems.

MCP addresses this by standardizing how AI assistants interface with external systems.

## **What is an MCP server?**

Anthropic, the developers of MCP, described MCP as "the USB-C for AI", a single, universal standard for connecting AI assistants to external tools and data.

MCP is an open standard for connecting AI applications to external systems. If Large Language Models are the brain, MCP is the nervous system that connects the brain to the hands to be able to do things. MCP standardizes how AI systems connect to external tools and data sources. An MCP server is the component that exposes the real capabilities to AI assistants, including reading files, querying APIs, fetching logs, and, in some cases, infrastructure modifications. 

When your AI assistant needs to perform an action:

 1. The AI decides which tool to use.

2\. The MCP client sends a standardized request.

 3. The MCP server executes the action.

 4. The server returns the result.

 5. Your AI uses that result in its response.

This interaction model works identically across all MCP-compatible tools and assistants.  Instead of building a custom integration for every combination of AI and tool, you build once using MCP. Any AI assistant that speaks MCP can then connect to any tool that speaks MCP.

## **How MCP servers work**

To understand how MCP servers work, it's important to understand the components that work together. MCP servers work within a three-part system:

**1\. MCP host**

The application where your AI assistant runs. This is the interface you interact with when you type a question or request. This can Claude Desktop, or IDES such as, VS Code, Cursor, JetBrains IDEs, or any tool with an AI assistant. The host application contains the AI model and handles your requests.

**2\. MCP client**

The MCP client resides within the host and serves as a translator. It translates the AI model's requests into a format the MCP server understands and converts the server's responses back into a format the AI can use. Unlike the MCP host, you don't see the client in action because it operates behind the scenes to keep everything running smoothly.

**3\. MCP server**

The MCP server is an external service that provides context, data, or capabilities via an MCP interface, such as accessing databases, calling APIs, managing file systems, or, in our case, managing cloud infrastructure.

To connect to multiple services, a single host manages multiple MCP clients, each of which connects to a different MCP server. The AI assistant can then request actions across all connected services using natural language.

## **Why MCP matters for cloud infrastructure management**

With AI assistants becoming standard in development tools, MCP shifts them from passive helpers into active operators. MCP enables new workflows for infrastructure management:

-   **Multi-step automation:** Your AI assistant can check prerequisites, execute actions in sequence, verify results, and adjust its approach based on outcomes, adapting rather than following rigid scripts.
-   **Natural language becomes a valid interface for technical operations:** Describe what you want in plain language, and the AI translates that intent into proper actions through MCP. "Create a new environment from this branch" becomes a complete, executable instruction.
-   **Context switching disappears from your workflow:** Instead of jumping between your IDE, terminal, cloud console, and documentation, you work in one place. Your AI assistant becomes the bridge to all your tools. You stay focused, maintain flow, and work more efficiently.
-   **One integration works across multiple AI platforms:** MCP provides a universal, open standard for connecting AI systems with data sources, replacing fragmented integrations with a single protocol. Build an MCP server once, and it works with an MCP-compatible AI assistant. You're not locked into a single vendor's ecosystem.
-   **Access real-time data from your systems:** Rather than relying on outdated training data or requiring manual input, AI can query your databases, check your deployment status, or retrieve your project configuration directly. The information is current, accurate, and contextual.

## **Upsun MCP server**

The Upsun MCP server connects AI assistants to your Upsun cloud platform. You can manage your Upsun projects and environments through conversations with your AI assistant, right from your code editor, without switching to terminals, web consoles, or memorizing CLI commands.

### **Why use the Upsun MCP server**

The Upsun MCP server gives your AI assistant access to the Upsun API, the same secure API used by the CLI and Console. All operations follow the same authentication, authorization, and security validation as direct API calls, ensuring that your organization's permissions and access controls are adhered to.  While you can give the Upsun MCP the ability to make changes to your projects, the Upsun MCP defaults to read only to start. 

The Upsun MCP server provides three core capabilities:

-   **Natural language infrastructure management:** Describe what you need in plain language instead of memorizing CLI commands or navigating dashboards. "List all environments in this project and highlight which ones are active" becomes an executable instruction, not just a request for help.
-   **CI/CD integration**: Trigger deployments, monitor build progress, and check pipeline status directly from your IDE or documentation tools. Your AI assistant connects to your existing development workflows without requiring you to switch contexts.
-   **AI-assisted operations:** Using environment details, activities, logs, routing data, and configuration retrieved through MCP, your AI assistant can help diagnose issues, summarize system state, and guide you toward the next steps. As Upsun expands its MCP support for metrics and performance insights, this guidance will become even more powerful, offering adaptive recommendations rather than rigid, predefined scripts.

These capabilities enable specific operations such as:

-   Project and environment management: View project information and metadata, list projects in your organization, create and delete projects, retrieve environment details, and manage environment configurations.
-   Environment creation and management: Create new environments from branches, delete environments when they are no longer needed, retrieve detailed environment information, including status and deployments, list all environments within a project, and inspect environment variables and settings. Every operation maintains consistency with Upsun's Git-driven infrastructure model.
-   Operational visibility: Access detailed information about your infrastructure, including environment state, recent deployment activities, application logs, routing configuration, project domains, available backups, and active certificates. By pulling this live operational data directly from the MCP server, your AI assistant can understand your system's current health and behavior, identify issues, trace deployment history, and provide informed guidance during troubleshooting or operational planning.

**Note:** The Upsun MCP server focuses on infrastructure and deployment operations. Administrative functions such as user management, billing, and account settings are managed through the Upsun Console.

### **Security and operational safety**

Security is a fundamental aspect of the Upsun MCP server. Understanding how it protects your infrastructure helps you use it confidently. 

As mentioned earlier, the MCP operations follow the existing Upsun security model. When your AI assistant makes a request to the MCP server, it goes through the same authentication and authorization checks as if you used the CLI or made a direct API call. The MCP server doesn't bypass or weaken any existing security controls; it uses them. Authentication is handled via API tokens, which you generate in your Upsun account settings with the appropriate permissions for your projects.

**Read-only by default**

The Upsun MCP server operates in **read-only mode by default**, allowing you to safely explore and understand your infrastructure without risking unintended changes. In this mode, you can view organizations, projects, and environments, read configuration files like .upsun/config.yaml, but you cannot make changes until you explicitly enable write operations. This default behavior ensures that no deployments, environment changes, or configuration updates occur unless you intentionally allow them.

**Enabling write operations**

On the Upsun MCP server, write operations are disabled by default, but you can enable them by setting "enable-write":"true" in your MCP configuration. This setting should be enabled only after you understand its implications and are comfortable with your AI assistant making infrastructure changes on your behalf. Even with write mode enabled, all actions remain bound by your account’s permissions. The AI assistant cannot perform operations beyond what your API token is authorized to do.

**API Token management**

API tokens follow Upsun's standard security practices:

-   Generate tokens through your account settings with permissions scoped to specific projects.
-   Use separate tokens for different environments or teams to maintain fine-grained access control.
-    Rotate tokens regularly following your organization's security policies.
-   Store tokens securely. 

The MCP server respects the boundaries of your token's permissions. If your token doesn't have permission to modify production environments, the MCP server can't modify production environments, regardless of what your AI assistant requests.

## **Setting up the Upsun MCP server**

Getting started with the Upsun MCP server requires two steps: obtaining an API token and configuring your MCP client.

**Obtaining your Upsun API token**

Navigate to the Upsun Console and access your account settings. Generate a new API token with appropriate permissions for your projects. The token scope determines which operations the MCP server can perform on your behalf. For initial exploration, read-only permissions provide a safe starting point.

Remember to store your API token securely. This token provides access to your infrastructure, so treat it with the same care as any other credential.

**Configuring your MCP client**

The Upsun MCP server works with all major AI development environments. Configuration follows a consistent pattern across different clients, though the specific syntax varies by platform.

For example, on Cursor, paste the following configuration into your ~/.cursor/mcp.json file. You can also install it in a specific project by creating a .cursor/mcp.json file in your project folder. See Cursor MCP docs for more information.

```json
{
  "mcpServers": {
    "upsun": {
      "url": "https://mcp.upsun.com/mcp",
      "headers": {
        "upsun-api-token": "YOUR_API_TOKEN",
        "enable-write": "false"
      }
    }
  }
}
```

  
For Claude Code, run this command in your terminal. See Claude Code MCP docs for more information.

```Javascript
claude mcp add --transport http upsun https://mcp.upsun.com/mcp --header "upsun-api-token: YOUR_API_TOKEN" --header "enable-write: false"

```

For VS Code, add this to your VS Code MCP config file. See VS Code MCP docs for more information.  
 

```Javascript
"upsun": { 
  "type": "http",
  "url": "https://mcp.upsun.com/mcp",
  "headers": {
    "upsun-api-token": "YOUR_API_TOKEN",
    "enable-write": "false"

  }

}
```

The Upsun MCP server works with 20+ AI development environments. For complete setup instructions for all supported clients, see the Upsun MCP documentation**.**

**Test your connection**

After configuration, verify your connection by asking your AI assistant simple questions about your Upsun infrastructure. You can start with read-only operations, such as checking project status or listing environments. 

Being specific in your requests yields better results: instead of "check my stuff," try "show me the status of all environments in the production project." As you gain confidence, explore more complex operations and ask your AI assistant to explain what it plans to do before executing write operations.

> _**Note**: Results depend on the capabilities of your AI assistant. Different AI models interpret requests differently and may vary in their ability to handle complex infrastructure tasks. It is important to verify the AI's understanding before executing write operations and using clear instructions._

###   
**Extend your workflow**

The Upsun MCP server integrates with other AI features to create a unified development experience:

-   **AI-generated configuration:** Run 'upsun init' to analyze your repository and automatically generate an initial Upsun configuration file.
-   **Context7 integration:** Access Upsun documentation directly from your AI assistant for troubleshooting guides and configuration examples without leaving your IDE. See the Upsun and Context7 guide for setup instructions.
-   **PostgreSQL MCP:** Query your Upsun databases using natural language. See Using PostgreSQL MCP with Upsun Remote Database for details.

## **Start building with Upsun today**

The Model Context Protocol changes how you interact with tools and infrastructure. By standardizing the connection between AI assistants and external systems, MCP eliminates the fragmented landscape of custom integrations and enables truly connected workflows. The Upsun MCP server brings this vision to cloud infrastructure management. It can eliminate interruptions, reduce manual work, and let you focus on building rather than managing. This is not about replacing your expertise. It is about augmenting your capabilities and removing friction from your daily workflows.

As MCP adoption grows across the industry, expect more services to expose their capabilities through standardized servers. The ecosystem is moving toward a future where your AI assistant can seamlessly interact with every tool and platform you use, all through natural language.

-   Ready to see MCP in action? Check out the Introduction to the Upsun MCP Server Guide. 
-   Explore the MCP guide to start managing your infrastructure through natural language today.

For comprehensive information about the Model Context Protocol standard, visit the official MCP documentation maintained by Anthropic.

### [Scalable AI governance policy guidelines for IT teams | Upsun](https://upsun.com/blog/ai-governance-policy-guidelines/)

# AI governance policy guidelines that actually scale

AI is already embedded in day-to-day workflows. 

For many IT teams, the harder problem is not adopting AI tools, but controlling how they are used. Policies often exist as PDFs, slide decks, or internal wiki pages that look good during audits but are easy to ignore in daily work.

This blog introduces a practical guideline library for AI governance. The goal is simple: give IT leaders reusable policy guidelines that cover real risks and can scale across teams, tools, and environments without slowing delivery.

The focus is on four areas where governance most often breaks down: API access, deployments, data handling, and AI agent interaction. 

These areas reflect the main risks identified by enterprise practitioners, including data leakage, the use of unapproved tools, and unclear accountability for AI-driven actions.

## **Why traditional policy guidelines fail to scale**

Most AI governance guidelines are created with good intent. They define what is allowed and what is not. The problem is where those rules live and how they are enforced.

Common failure patterns include:

-   Policies written in natural language only, with no link to technical controls.
-   One-size-fits-all rules that do not reflect how teams actually build and deploy software.
-   Manual approval steps that slow teams down and are bypassed under pressure.
-   No clear ownership when AI systems behave in unexpected ways.

When governance lives outside the delivery workflow, it is invisible when decisions are made. Scalable governance needs guidelines that can be reused, reviewed, and enforced where work happens.

## **What a scalable AI policy guideline looks like**

A scalable AI governance policy guideline has a few defining traits:

-   It is specific enough to guide action.
-   It can be reviewed like code.
-   It maps to technical controls, not just intent.
-   It can evolve as tools and regulations change.

Instead of long prose, guidelines should define scope, allowed actions, required controls, and ownership. Think of them as building blocks that teams can combine, rather than a single master document.

## **API access policy guideline**

Every AI integration starts with an API connection. They are also a major source of risk when access is poorly defined.

**Guideline structure:**

-   **Approved services:** List which AI services (for example, OpenAI or Anthropic) are authorized.
-   **Secret management:** Define how API keys are stored and rotated.
-   **Usage monitoring:** Set rate limits and logging expectations.
-   **Upsun enforcement:** Use project variables to inject API keys into environments securely. This ensures keys are never stored in the codebase and are only available to authorized environments.

## **Deployment policy guideline for AI workloads**

AI systems behave differently across environments. A model that is safe in a test environment can create risk in production if controls change or data sources expand.

**Guideline structure:**

-   **Environment scope:** Define where AI workloads are allowed to run.
-   **Approval criteria:** Set the promotion rules for moving AI features to production.
-   **Rollback plan:** Define incident response expectations for autonomous systems.
-   **Upsun enforcement:** Use production perfect preview environments to test how AI agents behave under security constraints before the public sees them.

## **Data handling and privacy policy guideline**

Data handling is the most critical area for AI governance. SMEs consistently highlight data privacy as the top risk, especially under regulations such as GDPR.

**Guideline structure:**

-   **Access rights:** What data are AI systems allowed to read?
-   **Anonymization rules:** Is personal or sensitive data permitted in prompts?
-   **Residency requirements:** Where must the data be stored and processed?
-   **Upsun enforcement:** Use regional hosting to pin AI workloads to specific locations. This ensures data stays within the required jurisdiction while maintaining a unified management experience.

## **AI agent interaction policy guideline**

As teams move from simple prompts to AI agents that act autonomously, governance becomes more complex.

**Guideline structure:**

-   **Agent permissions:** Which systems can the agent read from or write to?
-   **Human oversight:** Define which sensitive actions require manual approval.
-   **Audit trail:** Set monitoring and execution logging expectations.
-   **Upsun enforcement:** Leverage activity logs and Git driven configuration to ensure every action taken by or for an agent is documented and reversible.

## **How a guideline library supports IT leadership goals**

For IT middle management, governance is about balancing speed, risk, and trust. A reusable AI governance guideline library supports this balance by:

-   Reducing policy creation effort across teams.
-   Making reviews faster and more consistent.
-   Enabling enforcement through technical controls.
-   Improving visibility into how AI is used.

Instead of debating rules for each new project, teams start from a shared baseline. This shifts conversations from whether AI is allowed to how it is used safely.

## **Moving from guidelines to practice**

guidelines alone are not enough. They must be embedded into workflows, reviewed regularly, and treated as living artifacts.

Platforms that support configuration in code, automated environment management, and built-in observability make this easier. They allow policies to move from documents into enforceable controls that scale with delivery. AI governance should not rely on trust alone. It should rely on clear, reusable policies that are easy to apply and hard to bypass.

### **Sources**

-   NIST AI Risk Management Framework overview. https://www.nist.gov/itl/ai-risk-management-framework 
-   EU AI Act, obligations of deployers and timeline.  
    https://artificialintelligenceact.eu/article/26/ 
-   ISO/IEC 42001:2023 page.  
    https://www.iso.org/standard/42001

### [Django deployments without downtime | Upsun](https://upsun.com/blog/django-deployments-without-downtime/)

# Django deployments without downtime: static files and migrations

_This blog post is based on_ _a product presentation by Antonis Kalipetis, Staff Engineer_ _at SymfonyCon 2023, about Upsun's experience with Nix. We utilized ChatGPT for transcription and to enhance the grammar and syntax._

Django deployments have evolved since the framework's early days. While Django migrations were introduced in version 1.6 to simplify our lives, modern deployment patterns, such as rolling updates and horizontal scaling, have introduced new complexities that developers need to understand and plan for. In a live workshop, Antonis walked through what actually breaks during deployments and how to prevent it.

## Understanding Django deployment architecture

Every Django application deployment consists of several key components working together. At the front, you have a proxy server - typically Nginx, Apache, or newer options like Caddy and Traefik. This proxy handles TLS termination, domain routing, and redirects. Behind it sits your application server, commonly Gunicorn or Uvicorn for asynchronous applications. Supporting these are a cache layer (such as Redis or Memcached) and a database (PostgreSQL, MySQL, or increasingly SQLite, for certain use cases).

This architecture works well for single-server deployments, but modern applications often run across multiple servers with rolling updates, creating scenarios where different versions of your application run simultaneously.

## The static assets challenge

When you develop Django applications locally, `manage.py runserver` handles static file serving automatically. In production, however, this approach becomes problematic. Python application servers are designed to handle one request at a time (with some exceptions for ASGI), making them unsuitable for serving static content, such as CSS, JavaScript, and images.

### **The problem multiplies with scale**

The real challenge arises when multiple application servers are running different versions of your code. Consider this scenario: you update your CSS with a new brand color and deploy using Django's `ManifestStaticFilesStorage`. This storage backend creates hashed filenames, such as `app.a1b2c3d4.css` to enable permanent caching.

During a rolling deployment, you might have:

-   Server A is running the old version with `app.old123.css`
-   Server B is running the new version with `app.new456.css`

If a user's request for the new CSS file gets routed to the old server, they'll receive a 404 error, breaking the page styling.

### **Solutions for static asset management**

**External storage**: Upload static files to services like Amazon S3 or similar cloud storage. This ensures all versions of your application can access the same static files.

**Proxy-level caching**: Configure your proxy server (Nginx, etc.) to cache static files for a reasonable duration. This creates a buffer during deployments where old files remain available while new ones propagate.

**Shared file systems**: Mount the static directory across all servers so both old and new application versions can serve files from the same location.

**WhiteNoise middleware**: This Python library serves static files directly from your Django application with efficient caching headers, though it does use application server resources.

## Schema migration complexities

Django migrations are powerful, but they require careful planning in multi-version environments. The presenter demonstrated this with a practical example using a Bigfoot sighting reporting application.

### **The compatibility problem**

Adding a new field to a model seems straightforward, but consider what happens when you add a required field with a default value:

```Python
# New field added

gdpr_accepted = models.BooleanField(default=False)
```

After running migrations, the new application version is aware of this field, but the old version is not. When the old version tries to save a record, it fails because the database expects the `gdpr_accepted` field, but the old code doesn't provide it.

### **Django 5's database defaults**

The presenter highlighted Django 5's new `db_default` parameter as a solution:

```Python
gdpr_accepted = models.BooleanField(db_default=False)
```

With `db_default`, the database itself handles the default value, not the Python code. This means old application versions can successfully save records even without knowledge of the new field.

### **Migration strategy best practices**

-   **Forward and Backward Compatibility**: Design migrations that work with both the current and previous versions of your application code.
-   **Multi-Step Deployments**: For complex schema changes, consider deploying in multiple stages:

1.  Add the new field as nullable
2.  Deploy code that handles both old and new schemas
3.  Populate existing records
4.  Make the field non-nullable if needed

-   **Data Migration Considerations**: When you need to update existing data, create separate data migrations that can run safely alongside the old application code.

## The rolling update challenge

Rolling updates create a temporary state where multiple versions of your application run simultaneously. This requires careful coordination between:

-   **Migration timing**: When to apply database changes
-   **Code deployment**: Ensuring compatibility between versions
-   **Static file distribution**: Managing asset versions across servers
-   **Rollback planning**: Having a clear strategy when things go wrong

### **Rollback reality check**

While Django makes rolling back migrations seem simple with `manage.py migrate app_name 0001`, production rollbacks are rarely that straightforward. The presenter emphasized from experience that rollbacks often encounter unexpected issues, making prevention through careful planning more valuable than relying on rollback capabilities.

## Practical deployment strategies

-   **Environment Parity**: Ensure your staging environment closely mirrors production, including multi-server setups when possible.
-   **Feature Flags**: Use feature flags to deploy code without immediately exposing new functionality, allowing you to separate code deployment from feature activation.
-   **Blue-Green Deployments**: Maintain two identical production environments and switch traffic between them, eliminating the multi-version complexity entirely.
-   **Canary Releases**: Gradually route traffic to new versions, allowing you to catch issues before they affect all users.

## Platform solutions

Modern Platform-as-a-Service providers like Upsun address many of these challenges through:

-   Automated static file handling with shared storage
-   Managed database migrations with timing controls
-   Built-in caching layers at the proxy level
-   Tools for coordinating multi-service deployments

However, understanding the underlying challenges remains crucial even when using managed platforms.

## Key takeaways

Django's built-in tools, such as migrations and static file management, are powerful, but they require thoughtful application in production environments. The complexity increases significantly when you move from single-server deployments to horizontally scaled, continuously deployed applications.

Success requires:

-   Planning migrations for compatibility across application versions
-   Implementing robust static file serving strategies
-   Understanding the timing and coordination of rolling deployments
-   Having realistic rollback procedures
-   Testing deployment processes in staging environments

As Django applications grow and deployment patterns become more sophisticated, developers must evolve their understanding beyond local development patterns. The framework provides the tools, but successful production deployments require careful orchestration of these tools within your specific infrastructure context.

While Django continues to make our development lives easier, production deployment remains an area where careful planning and understanding of the underlying systems pays dividends in application reliability and user experience.

### [Dark code: how AI erodes architectural intent | Upsun](https://upsun.com/blog/dark-code-architectural-intent/)

# The rise of dark code and the death of architectural intent

As Staff Engineers and Principal Architects, most of us have spent years thinking about long-term system health. We are considerate of the company’s business objectives and strategy, accumulation of technical debt, and operational risk. For us it is not about whether code works today, but whether the engineer who inherits it in three years will be able to understand what it was trying to do and why. That's what makes a codebase maintainable rather than just functional.

AI coding assistants are eroding that. A lot of the current discourse focuses on speed and enabling developers to do more with less time. But, as additional tools are introduced into the mix, what we are losing is an understanding of developer intent. While we are technically moving faster, we are generating a new category of technical debt, but it doesn't look like technical debt. It looks like clean, well-structured, passing code, but with no human reasoning behind it.

### **The anatomy of dark code**

_Key takeaway: Automated code generation masks the loss of developer intent. Clean repositories are accumulating legacy at double the historical speed._

The local AI development loop feels productive on the surface. A developer opens their editor, highlights a block of code, and prompts the model: "Refactor this authentication handler to support multi-tenant token exchanges." The model returns a 200-line diff. The developer skims it, runs a local test, commits with a message like "refactor auth for multi-tenant," and pushes to the branch.

On paper, the task is complete. In practice, the repository just inherited a liability.

Version control recorded the what: the raw diff of the newly generated lines. It captured nothing about the why. The prompt, the context the model was working from, the logic paths it evaluated and discarded, the structural assumptions baked into the output, all of it evaporated when the editor session closed.

Picture that same authentication handler, six months later, failing at 2am because of an edge-case token configuration nobody anticipated. A senior engineer runs git blame. They don't find a design decision. Instead they find an artifact, driven by an agent choice. There's no commit message that explains the reasoning, no PR comment that captures the tradeoffs, no way to reconstruct what the model was optimizing for when it chose that particular structure. The context is gone because it was never written down anywhere that outlasted the session that produced it.

We've always accumulated technical debt. But, now we're accumulating it faster, and in a form that's harder to pay back, because of the absence of context.

### **The collapse of Git authorship**

_Key takeaway: When an engineer reviews and merges a diff they can't trace, they become accountable for decisions they didn't make._

Git was built on a foundational assumption: the name on a commit represents the mind that planned the change. That relationship has quietly broken down.

Developers using local AI tools have shifted from authors to editors of machine-generated text. That shift has consequences that aren't evenly distributed. The developer who prompted the model moves on. The reviewer is the one left holding the diff.

A Staff Engineer reviewing a complex multi-file pull request is now being asked to sign off on architectural choices (e.g., a specific database lock pattern, a particular approach to nested async calls) without knowing whether those choices were intentional decisions or the model's best guess given a context window the reviewer has never seen. The model isn't available for questions. The developer who ran the prompt may not fully understand why the output looks the way it does either.

Two things follow from this. The first is a review quality problem: under backlog pressure, the honest answer to "do you understand why this code is structured this way" is increasingly no, but the merge happens anyway. The second is an accountability problem that most teams haven't fully reckoned with yet: the person who clicks merge is operationally responsible for the consequences of code they didn't design and can't fully trace.

### **What traceability actually requires**

_Key takeaway: The fix isn't_ _restricting AI use__. It's capturing the context that AI execution currently discards._

The temptation is to treat this as a tooling problem with a tooling fix: better commit message discipline, mandatory PR templates, AI code review layers. Those things help at the margins. They don't solve the underlying issue.

The underlying issue is that AI reasoning happens in a place that produces no durable record. A model running inside a developer's local editor processes context, makes decisions, and generates output, and then the context is gone. What gets committed to version control is the output. Everything that led to it is gone.

The teams starting to work through this seriously are rethinking where in the process AI operates, not just how it operates. When the context an agent works from, the decisions it makes, and the human review of those decisions are all captured as part of the same record as the code change itself, you have something you can actually audit. Six months later, when something breaks, the reasoning is still there.

That's a different kind of infrastructure requirement than most teams are used to thinking about. But it's the right framing for the problem. We don't have a code quality problem. We have a context preservation problem. And solving it means treating the reasoning behind a code change as part of the engineering artifact, not a byproduct that gets discarded when the session ends.

This is the problem we're building Upsun Dispatch™ to solve: capturing the full chain of context, reasoning, and human sign-off as part of the engineering record itself, not something recreated after the fact.

-   **New here?** **Read the introduction to Upsun Dispatch**
-   **Want to help build it? Apply to the** **founding design partner cohort**

* * *

### **Frequently asked questions (FAQ)**

**What exactly is dark code?**

This is code that compiles, passes review, and reaches production with no auditable record of why it was written the way it was. The architectural decisions are invisible to everyone except the model that made them, and that model may be long gone.

**Why isn't a good commit message enough to avoid dark code?**

A commit message captures what a human chose to summarize. It doesn't capture the prompts, the context, or the reasoning chain that led an AI to specific structural decisions. A developer writing "refactor auth for multi-tenant" is summarising their interpretation of the output, not documenting the process that produced it. Those are very different things.

**Doesn't traceability slow developers down?**

Only if you implement it badly. The goal isn't to make developers manually document every AI interaction. It's to capture that context automatically, at the point where AI is actually operating, without adding friction to the developer's workflow.

**How does dark code relate to compliance?**

Frameworks like ISO 27001 require you to prove why a change was made, who authorized it, and how it was verified. Code generated locally by an AI assistant, with no shared record of context or approval, is genuinely difficult to account for in an audit. That's a risk most teams haven't fully mapped yet.

### [When the cloud goes dark: continuity planning for IT leaders | Upsun](https://upsun.com/blog/when-the-cloud-goes-dark/)

# When the cloud goes dark: what every IT leader should have ready before the next outage

A large cloud outage is never just a technical issue. It's a revenue issue, a reputation issue, and an additional workload for already stretched teams. The major incident that disrupted a global hyperscaler in October 2025, taking down a wide range of internet services for hours, is a useful case study in how quickly failure cascades across identity, DNS, networking, and third-party APIs. It reminded everyone that even world-class platforms can have bad days, and that continuity plans must account for the full web of real dependencies, not just the primary provider.

Our goal here is to clarify what business continuity means in a cloud-first world, why portability matters, and how to prepare realistic recovery paths when a region experiences a major incident.

## **Why outages still happen today**

Complexity drives risk. The Uptime Institute’s analysis notes that while overall outage frequency and severity have trended down, modern architectures introduce new failure modes that operators must actively manage. Within those incidents, IT and networking causes are a meaningful share and can create cross-provider ripple effects that make headlines. You cannot eliminate outages in a distributed, API-driven world. You can reduce blast radius, shorten recovery, and maintain business operations by assuming components will fail and designing your application platform to adapt.

## **The domino effect of downtime**

The costs of unplanned downtime compound in ways that rarely appear on a single dashboard. Financially, the exposure is significant: Uptime Intelligence reports that 54 percent of respondents said their most recent significant outage cost more than $100,000, and about one in five reported costs above $1 million. 

Reputation damage accumulates more slowly but lasts longer. Customers may forgive an isolated incident, but repeated outages shape brand perception well after services are restored. Meanwhile, the incident itself consumes exactly the senior engineering attention that should be focused on delivery, and rushed remediations create follow-on risk. 

Overlapping with a security incident makes the picture worse still: IBM's 2025 data puts the average global cost of a data breach at $4.44 million, a figure that underscores how quickly a crisis condition can become a material financial event.

## **What your CEO and board want to hear when your cloud platform fails**

When an outage begins, leadership needs to hear four things: 

First, that you have a current, tested continuity plan: one that names owners, playbooks, and decision thresholds, and that covers failure of identity, DNS, CDN, data stores, and CI systems, not just a cloud provider. NIST SP 800-34 offers a dependable framework for plan structure, roles, and exercises. 

Second, that you can run the business in a degraded state, knowing which services can operate read-only, what features can be shed, and what SLAs you can meet. 

Third, that your platform emphasizes region choice and portability, not as a promise of seamless failover, but as an operational choice that supports disaster recovery and sovereignty. 

And fourth, that you measure resilience work like any other investment: tracking recovery performance against internal objectives, dependency count, and change failure rate, and reporting on incident causes and improvements in recovery time over time.

## **A resilience checklist for cloud-first teams**

### **1) Map and minimize critical dependencies**

Identify single points of failure across identity, DNS, certificate issuance, artifact registries, object storage, and message queues. Secondary DNS, alternative artifact mirrors, cross-region object replication, and a backup identity assertion path for break-glass access are sensible starting points. Document third-party APIs that are operationally critical and define fallbacks or feature flags for graceful degradation.

### **2) Classify services by criticality and failure mode**

For each service, document internal recovery objectives, including target time to restore and acceptable data loss, alongside acceptable downgrade modes and the locations where it can run. Prioritise customer-facing pathways that drive cash flow, and decouple analytics and back-office workloads from the hot path whenever possible.

### **3) Practice game days, not just DR tests**

Move beyond scripted restore tests. Inject real fault types such as DNS failures, expired certificates, stalled CI runners, and partial storage unavailability. Include executive stakeholders and practise status updates, customer communications, and vendor escalations in a single exercise.

### **4) Treat data as the contract**

Standardise backup and restore procedures with sanitisation to guarantee a clean, time-bounded dataset for testing and recovery. Keep data portability top of mind: if your datastore is managed, ensure you can restore it and run it elsewhere when needed.

### **5) Bake resilience into delivery**

Every change should be deployable with health checks, traffic shifting, and instant rollback. "Everything as code" is not a slogan: define networking and services declaratively so you can reconstruct environments on demand.

## **How cloud portability and region choice fits without overreach**

Cloud portability is a strategy for choice and operational resilience, not a promise of seamless failover. The aim is to reduce correlated risk and retain the option to restore service at another location when needed—treating it as an enabler for disaster recovery plans and region placement, rather than a guarantee of lower downtime by default. Gartner identifies digital sovereignty and strategic flexibility as key trends guiding cloud decisions, and portability is central to both.

Use a tiered approach:

-   **Tier 1 (critical pathways):** Engineer for fast detection and operator-led restoration. Maintain tested playbooks for DNS and identity changes, and ensure data and images can be restored elsewhere.
-   **Tier 2 (important but not cash-path):** Achieve cross-region resilience within your provider, and keep portability artifacts current so you can rebuild in a different location if required.
-   **Tier 3 (internal and analytics):** Optimize for cost and simplicity with scheduled backups and a longer recovery window based on internal objectives.

Keep complexity proportional to value. Focus on portability and documented procedures that your team can execute under pressure.

## **What “designing for failure” looks like on Upsun**

Upsun helps enterprises make restoration predictable and repeatable. It is not an automated cross-region failover system. Instead, it gives you the consistency and controls to execute your business continuity and disaster recovery plans.

-   **Git-driven, YAML-based configuration:** Define services and routing declaratively so you can rebuild environments from a clean Git checkout. See the Upsun platform overview and the documentation.
-   **Automatic preview environments per branch:** Spin up production-like test environments to rehearse restoration steps, validate feature flags, and exercise dependency changes without risk. Explore developer resources.
-   **Managed backup and restore with sanitization:** Create safe, representative datasets for game days and restore tests by cloning environments directly through the platform, no manual export steps required.
-   **Multi-service orchestration:** Run heterogeneous stacks with consistent rules so services come back as a unit during restoration.
-   **Observability and APM:** Centralize metrics, traces, and logs to speed detection and confirm recovery against internal objectives.
-   **Region choice:** Choose from supported cloud regions to meet data sovereignty and disaster recovery needs. Restoration is initiated and controlled by your team following your playbooks.

_**Note:** Upsun does not perform automated failover across regions or clouds; continuity is achieved through planned restoration procedures initiated by your operators._

## **A practical 30-day continuity plan**

Even if your destination is a broader cloud portability strategy, you can materially improve resilience in the next month.

**Week 1: Baseline and prioritise**

Build a current dependency map, noting identity provider, DNS, CDN, and critical third-party APIs. Define internal recovery objectives for the top five customer-facing services, including target time to restore and acceptable data loss. Pick one critical user journey and define a degraded mode.

**Week 2: Prove portability**

Build and document a clean restore path to a secondary region or data centre. Restore the primary database into the secondary target and validate it. Capture every step in code or scripts and commit to Git.

**Week 3: Exercise restoration**

Run a disaster recovery exercise that simulates a provider region outage. Practise DNS updates, emergency identity access, and read-only mode while you execute the restoration. Measure time to detect, decide, and restore, and identify where automation reduces manual steps.

**Week 4: Automate and communicate**

Automate the environment build from Git via a single YAML config, including networking and service definitions. Draft customer and internal communication templates for incidents. Brief the board: present today's baseline, the measured game day results, and the 90-day roadmap for portability and testing cadence.

If you use Upsun, most of these steps map directly to platform features: declarative config, branch-based previews, managed backup and restore with sanitisation, and multi-service orchestration. If you are building in-house, focus on achieving parity in the narrow areas that yield the most risk reduction.

## **Talking to stakeholders without assigning blame**

When an incident originates with a cloud provider, resist the urge to assign public blame. Emphasise that your platform supports region choice and portability, that you have tested restoration procedures and documented playbooks, and that your resilience investment assumes software and networks sometimes fail. 

You follow industry guidance, structuring plans, exercises, and metrics consistent with NIST recommendations. You use region choice and portability to keep your options open and to make restoration predictable; not as a substitute for careful planning.

## **What to measure next quarter**

The metrics that matter most are the ones that reveal whether your plans hold up under real conditions. 

**Track recovery performance** for Tier 1 services against your internal objectives for restore time and acceptable data loss. **Monitor change failure** **rate** **and mean time to restore**. Delivery quality and resilience tend to move together. Count dependencies on the hot path, since fewer is better and the trend matters as much as the number. 

**Run regular portability checkpoints** to confirm you can recreate the application in another region from a clean Git checkout and a single config file. Score each restoration drill on steps completed from Git, time to restore data, and on-call team workload. And finally, **track the cost of resilience**: spend on redundancy and game days against avoided incident hours and reduced business impact.

## **Cloud outage, business continuity, and cloud portability**

If your board is asking for an updated continuity position after a high-profile outage, anchor the conversation on three points:

1.  **Design for failure, not for perfection.** Set internal recovery objectives for each service, including target time to restore and acceptable data loss. Practise them with disaster recovery exercises.
2.  **Portability is preparation.** Keep the ability to rebuild in another location documented, scripted, and rehearsed.
3.  **Platforms can help.** Choose tools that standardize environments and reduce manual steps during restoration. Upsun's Git-driven config, previews, managed backup and restore with sanitisation, orchestration, and observability exist to make your plan executable in practice

The October 2025 outage is a reminder of something that has always been true: the internet is a system of systems, and no component is immune to disruption. The right response, then and now, is a sober, well-communicated plan that designs for failure, practises restoration, and uses the right platform abstractions to make resilience routine. 

That is how you protect revenue, reputation, and your team's focus when the cloud goes dark.

### [WordPress vanilla vs Composer vs Bedrock | Upsun](https://upsun.com/blog/wordpress-vanilla-vs-composer-vs-bedrock/)

# WordPress Vanilla vs Composer vs Bedrock - which wins?

> _This blog post is based on the Upsun live stream with Greg Qualls, Director of Product Marketing, and Paul Gilzow, Developer Advocate at Upsun._

WordPress powers over 40% of the web, but not all WordPress installations are created equal. Whether you're a solo developer, managing an agency, or overseeing hundreds of sites, the way you install and manage WordPress can make or break your workflow.

In a recent live stream discussion, we dived deep into three popular WordPress installation methods: Vanilla, Composer-based, and Bedrock. Each approach has its merits, but which one should you choose? Let's break down the showdown.

### Vanilla WordPress

The traditional install. Vanilla WordPress is what most people think of when they hear "WordPress installation." This approach has been in use since WordPress was introduced and remains the most common method today.

It follows a straightforward process: you download the ZIP file from wordpress.org, extract it to your server directory, and run through the famous five-minute installation. Next, install plugins and themes through the WordPress admin dashboard, and updates happen with a simple click from within WordPress itself. If you're working with version control, you typically commit all the WordPress core files to your repository and push them to your hosting environment.

**The good:**

-   Familiar territory: Most WordPress developers know this approach inside and out
-   Backward compatibility: Works with virtually any hosting setup
-   Simplicity: No additional tools or knowledge required
-   Wide support: Plenty of tutorials and community help available.

**The challenges:**

-   Version control nightmares: Committing WordPress core files to your repository creates bloated repos.
-   Update anxiety: Remember the white screen of death? Manual updates can break sites.
-   Developer collaboration: Hard to ensure everyone has the same plugin versions
-   Security concerns: Direct file access can be risky in production

As Paul Gilzow noted from his university days managing 200+ WordPress sites: "I fought Composer for six months because I was so used to vanilla, but I finally realized there just wasn't going to be a way to accomplish all the goals I needed with that traditional setup."

### Composer-based WordPress: the package manager revolution

Composer brings modern dependency management to WordPress, which fundamentally changes how we think about WordPress installations. Rather than treating WordPress as a single application with add-ons, Composer treats everything, including WordPress core itself, as a package.

The process begins by creating a `composer.json` file that defines WordPress core, plugins, and themes as dependencies, along with specific version numbers. Running `composer install` downloads all these dependencies into organized directories. Importantly, only your custom code and configuration files are committed to version control; the actual WordPress files are downloaded fresh each time. Updates are made by changing version numbers in your JSON file and running `composer update`, rather than clicking buttons in the WordPress admin.

**The good:**

-   Clean repositories: Only your custom code and configuration files get committed
-   Reproducible builds: Anyone can recreate your exact setup with one command
-   Easy rollbacks: Change a version number instead of reversing commits
-   Fleet management: Perfect for agencies or organizations with multiple sites
-   Zero-downtime updates: Code updates happen during deployment, not on live sites
-   Auditing capabilities: See exactly what versions you're running across all sites

**The challenges:**

-   Third-party dependency: Relies on community-maintained packages
-   Learning curve: Requires understanding package management concepts
-   Less official support: WordPress.org won't help with composer issues

### Bedrock: the modern architecture approach

Bedrock, created by Roots, takes composer-based WordPress and adds a full 12-factor app methodology.

Bedrock, created by Roots, takes composer-based WordPress and adds a full 12-factor app methodology. This approach doesn't just modernize how you install WordPress; it modernizes your entire perspective on WordPress applications.

Built on top of composer-based WordPress, but adds its own rules about how things should be organized. Think of it like a strict filing system; everything has its proper place. Instead of hardcoding settings, such as database passwords, directly into your files, Bedrock retrieves this information from the server environment. This means you can move your site between different servers without needing to change any code.

**The good**:

-   12-factor compliance: Follows modern cloud application best practices.
-   Security enhancements: Built-in bcrypt password hashing and other improvements.
-   Must-use plugin support: Automatically handles this WordPress quirk.
-   Official support: Actual documentation and community support from Roots.
-   Laravel-friendly: Great for developers coming from a Laravel background.

**The challenges:**

-   Third-party dependency: Like Composer, you're relying on Roots to maintain their packages.
-   Opinionated structure: Bedrock has specific ways of doing things; if those don't mesh with your needs, you'll likely encounter conflicts with the framework.
-   Additional complexity: More concepts to learn beyond just the composer.
-   Vendor lock-in: Dependent on Roots maintaining the project.
-   Regulatory concerns: As Paul noted from his university experience, some organizations have issues with proprietary solutions.
-   Overkill for simple sites: All the 12-factor benefits may be unnecessary for basic WordPress sites.

## **The verdict**

_It's not about winning, it's about fit for purpose._ After weighing the pros and cons, we agree: there's no universal winner. Like choosing between a hammer drill, an impact driver, and a regular screwdriver, the best tool depends on the specific job at hand.

**Choose Vanilla if:**

-   You're working solo on simple sites
-   Your hosting doesn't support modern deployment practices
-   You need maximum compatibility with existing workflows
-   You're just getting started with WordPress

**Choose Composer if:**

-   You're managing multiple WordPress sites
-   You work with other developers and need consistency
-   You want modern development practices without too much complexity
-   You're using cloud hosting platforms that support Git-based deployment

**Choose Bedrock if:**

-   You're building complex, scalable applications
-   Your team values modern development methodologies
-   You need the security and organizational benefits of 12-factor apps
-   You're willing to learn a more opinionated workflow

## Real-world recommendations

From Paul's experience managing hundreds of university websites: "Composer really does make management of a fleet of sites much, much easier. You can audit what plugins are running across all your sites, update them consistently, and avoid the 'it works on my computer' problems."

For most developers and agencies, composer-based WordPress hits the spot. It provides the modern tooling benefits without the complexity overhead of Bedrock, while still being approachable for developers familiar with vanilla WordPress.

## The future of WordPress development

As WordPress continues to evolve, adding GraphQL support, improving the block editor, and moving toward more headless capabilities, the development toolchain is becoming increasingly important.

As the web development world embraces package managers, containerization, and modern deployment practices, vanilla WordPress installations may become the exception rather than the rule. But for now, WordPress's strength lies in its flexibility to accommodate all these approaches.

## Getting started

Ready to modernize your WordPress workflow? Here are some next steps:

-   **Try composer-based WordPress** with a simple project to see how package management feels
-   **Explore Upsun or similar platforms** that provide templates for all three approaches
-   **Consider your team's needs** - are you managing one site or one hundred?
-   **Think about your hosting environment** - does it support modern deployment practices?

The WordPress showdown is not about declaring a single winner. It's about understanding your options and choosing the approach that makes your development life easier, more secure, and more scalable.

**Useful links**

-   https://upsun.com/blog/bedrock-wordpress-development
-   https://upsun.com/blog/modern-wordpress-development-workflow

### [From curiosity to confidence: building impact in tech sales](https://upsun.com/blog/confidence-and-growth-in-tech-sales/)

# Beyond the horizon: How saying yes to the unfamiliar shaped Amy Williams’ journey

Welcome to _Beyond the horizon_, a monthly series celebrating the people who shape Upsun's culture, innovation, and heart. In this month's edition, we're featuring someone who brings curiosity and momentum to Upsun's growth. Amy Williams, a Strategic Account Executive for Europe, sits within our sales organization, but her work is about far more than selling. She's a problem-solver and partner to teams across industries, helping organizations uncover real value, innovate faster, and build with security at the core. 

What makes Amy’s story especially compelling is how seamlessly her personal compass aligns with the way she shows up at work. A lifelong explorer who has spent months traveling through Southeast Asia and the Americas—hiking volcanoes, diving with sharks, and saying yes to the unfamiliar—Amy brings that same adventurous spirit into every customer conversation. She leans into complexity, thrives on new challenges, and approaches each relationship with a discovery mindset rather than a transactional one.

Amy also speaks candidly about navigating the gender imbalance in tech sales, transforming what could be a barrier into purpose. Her journey is a reminder that confidence is built through doing, belonging is created through representation, and progress happens when people share their stories openly. At Upsun, she's not only helping shape our next phase of growth, but she's also helping shape the kind of industry we want to be part of.

### **Tell us a bit about yourself. What do you do and most importantly, who are you outside of work?**

> Hi! I'm Amy Williams, a Strategic Account Executive for Europe here at Upsun. In my role, I get to partner with teams across a huge variety of industries and countries to welcome new users into the Upsun ecosystem. Although I sit within the sales organization, what we really do is help businesses uncover value. We’re not here to “sell” in the traditional sense — we solve problems, co-create solutions, and help organisations innovate faster with security at the heart of everything.
> 
> I genuinely love what I do. Every conversation is an opportunity to understand a new challenge, puzzle out an approach, and see first-hand how our platform can transform the way teams build and deliver. It’s the perfect role for someone who thrives on curiosity… which brings me to life outside of Upsun!
> 
> When I’m not helping companies modernize their development workflows, you’ll usually find me on a plane, in the ocean, or halfway up a mountain. Before joining Upsun, I spent seven months travelling through Southeast Asia and South and Central America. Along the way I hiked active volcanoes, dived with sharks, lived in the Amazon (where dinner involved catching your own piranhas!), and fully embraced saying “yes” to the unfamiliar.
> 
> That same sense of curiosity and adventure shapes how I show up at work — I love exploring new ideas and diving into complex challenges, whether they come from a customer conversation or a jungle river.
> 
> I'm also a huge foodie. Whenever I visit a new city, I research the best local, independent restaurants before I even pack my suitcase. During my travels, I took several cooking classes and fell in love with bringing those flavours home — there's nothing better than recreating a dish you learned in a tiny open-air kitchen and sharing it with friends and family over dinner.

  
Amy in Uyuni, the salt flats in Bolivia.

### **If you could describe your journey in one sentence, what would it be?**

> “Always exploring - new places, new challenges, new solutions.”

### **What's a challenge you've faced and how have you grown from it?** 

> One challenge that's been impossible to ignore is the gender imbalance in the tech industry, particularly from my experience in sales roles. Walking into rooms, virtual or otherwise, where I'm one of the only women isn't daunting, but it _is_ a clear reminder of the imbalance that still exists. Rather than seeing it as a barrier, I've come to view it as a motivating force.
> 
> Working in a male-heavy industry has pushed me to build confidence, trust my voice, and back my expertise. It's also made my achievements feel even more meaningful — not just on a personal level, but as proof that women belong and can thrive in these spaces.
> 
> More importantly, it's made me passionate about helping change the landscape. I want to see more women in tech sales, and I hope that by sharing my experiences openly — with friends, peers, or anyone considering this path — I can encourage others to step into roles they might have once thought weren't "for them." If my journey can make even one woman feel more confident entering the industry, that feels like progress.
> 
> For me, the challenge has ultimately become a purpose: to do well, to lift others up, and to help shape a more balanced and inclusive future for tech.

### **Is there someone at Upsun who played a key role in your journey or made your experience possible?** 

> If I had to highlight one person who has truly shaped my Upsun journey, it would be my manager, Chris. From the very beginning, he was the person who believed I was the right fit for his team — even before I officially joined. That early confidence meant a lot, and it’s something he has continued to show throughout my time here.
> 
> Chris is the definition of a champion for his people. He's always on hand to help, genuinely listens, and consistently goes above and beyond to make sure our voices are heard. At the same time, he's brilliant at managing expectations and keeping us focused, which creates a team environment that feels both supportive and high-performing.
> 
> One of my favourite things he’s introduced is the way we run our off-sites. Instead of being stuck in a meeting room for two days straight, we explore a new city together and incorporate “walking and talking” sessions. There’s something incredibly refreshing about discussing strategy, challenges, and new ideas while out in the open air, letting the world around us spark inspiration.
> 
> I genuinely feel lucky to have a manager who not only believes in me, but helps create an environment where that belief can turn into real progress and success.

### **As we say at Upsun, 'Your greatest work is just on the horizon.' What's the next horizon you're excited to reach in your journey?** 

> For me, that horizon is all about propelling us into 2026 with real momentum. I’m excited to play my part in accelerating our new business growth across Europe as we continue shifting into our identity as a leading cloud application platform.
> 
> Our solution is evolving, our story is evolving, and that evolution opens the door to entirely new conversations with customers. There’s something incredibly energizing about being part of that transformation — helping organizations modernize faster, adopt secure and scalable practices, and ultimately bring their ideas to life with fewer barriers.
> 
> Personally, this next chapter feels like a natural extension of everything that has shaped my journey so far: curiosity, problem-solving, and a belief in what we're building. I'm looking forward to taking on this new challenge alongside the amazing team around me, championing Upsun’s values in a way that inspires confidence and excitement.

As we wrap up this month’s journey, Amy’s story reminds us that growth often begins the moment we step into the unfamiliar. Her curiosity, resilience, and commitment to lifting others reflect the spirit that moves Upsun forward — a belief that exploration fuels innovation, and that every new path holds the potential to reshape what’s possible. We’re grateful to have Amy guiding customers, inspiring colleagues, and charting new frontiers across Europe. 

Join us next month as we continue to spotlight the people whose stories shape our culture and illuminate the horizons ahead. 💙

### [Prep your eCommerce platform for Black Friday traffic | Upsun](https://upsun.com/blog/preparing-your-ecommerce-platform-performance-for-black-friday/)

# Preparing your eCommerce platform performance for Black Friday

_This blog is based on an Upsun livestream discussion featuring Guillaume Moigneu, Field Engineer, and Thomas di Luccio, Product Manager at Upsun. The conversation was moderated by Greg Qualls. We utilized AI tools for transcription and to enhance the structure and clarity of the content._

When Black Friday approaches, the stakes are high for eCommerce businesses. While marketing teams dream of record-breaking sales, technical teams face a different reality: ensuring the infrastructure can handle unprecedented traffic without collapsing. In a recent conversation between developers Greg, Guillaume, and Thomas, the group shared hard-won lessons from managing high-traffic events.

## The scars of black Friday past

Guillaume's experience paints a vivid picture of what's at stake. Having worked for eCommerce agencies that manage 30-40 major European retailers, primarily in the fashion sector, he has seen both triumphs and disasters. "It's always a lot of pressure and trying to react as much as we can," he explained, recalling the stress of teams working around the clock during peak sales periods.

Thomas shared his own cautionary tale from the ticketing industry. When his company secured a deal with a significant new venue, the season announcement brought a flood of eager buyers. "Everybody was taking the frequent buyers buying tickets, a lot of tickets at the same time, big rush on the website, every app was eating the same API, and everything collapsed," he recalled. The lesson was clear: preparation isn't optional.

### Start preparing months ahead, not days

Both experts emphasized that successful Black Friday preparation begins months ahead, not weeks. Guillaume recommended a specific approach: "Every time you go for Black Friday, especially if that's a new application or something you haven't really battle tested before, you need to take a few months actually to slow down on the new development and new features."

This doesn't mean implementing a complete code freeze, but it does require shifting priorities. Development teams need time to establish comprehensive testing processes, implement application performance monitoring tools like Blackfire or New Relic, and profile their code to identify potential bottlenecks before they become critical failures.

### Create testing environments

One of Thomas's key recommendations centers on creating accurate testing conditions. "You need to be able to create the same conditions, so create a clone of your production application same setup, same version of everything, same level of resources," he explained.

This principle extends beyond just hardware specifications. Teams should test with production-scale databases rather than small development datasets. As Thomas noted, testing with a couple of hundred entries bears no resemblance to querying a production database with complex, real-world data. The differences in performance can be dramatic and revelatory.

### Load testing: tools and approaches

For load testing, the discussion highlighted tools like Locust, which can simulate thousands of concurrent users. However, Guillaume emphasized an important consideration: generating realistic traffic requires substantial resources. "Most of the big eCommerce websites want to handle like 10,000 transactions or users at the same time, so leveraging software and solutions like Locust Cloud could actually be helpful because you don't want to set up like dozens of AWS instances to send traffic to that site."

The challenge isn't just technical; it's about defining realistic testing scenarios. Users behave unpredictably: some browse catalogs for hours, others add hundreds of products to their cart only to use it as a wishlist. Working with analytics teams to understand actual user patterns is time-consuming but essential.

### The power of caching

When asked what single action developers should take if time is limited, Guillaume didn't hesitate: focus on caching. "Caching can be amazing, caching can remove a lot of bottlenecks in your application when it's done right," he said, referencing the famous computer science saying about the two hard things: "caching and naming."

Properly implemented caching serves two critical functions. First, it dramatically improves user experience through faster loading times. Guillaume cited the often-quoted Amazon statistic about losing significant revenue for every 100 milliseconds of additional loading time. Second, caching reduces the strain on backend resources and databases, preventing overload during traffic spikes.

### Invest in observability

Thomas's top recommendation was investing in observability tools. "Give yourself the ability to witness your application, your infrastructure behaving, and try to learn from this," he advised. However, investment isn't purely financial; it requires time to learn how to utilize these tools effectively and comprehend the data they provide.

The beauty of observability, according to Thomas, is its guidance: “It will tap you on the shoulder and say, "Look at this, look in this direction." Rather than guessing where problems might occur, observability tools reveal actual bottlenecks, slow requests, and resource-hungry processes, enabling targeted optimization.

### Testing the team, not just the technology

Greg raised an often-overlooked point: load testing isn't just about validating technology it also tests people and processes. Regular testing helps new team members understand emergency procedures before a crisis occurs, ensuring they are prepared. It also reveals how seemingly minor changes can have unexpected impacts across the system.

Guillaume emphasized the importance of backup processes: "You should have backup processes in place, the same way you should have backups for your data." Things inevitably go wrong staff may be unavailable, marketing may request last-minute changes, products may sell out, requiring updates. Having documented processes and clear communication channels becomes critical.

### Working with vendors and planning for scale

The conversation highlighted how modern cloud infrastructure has transformed the preparation for Black Friday. Gone are the days of driving to data centers at 4 AM to physically add servers. However, new challenges have emerged. During the COVID-19 pandemic, when eCommerce demand skyrocketed, some cloud providers struggled to provision new instances due to chip shortages.

Guillaume now works for a cloud application platform and has seen clients scale to 1,200 CPUs for a single day. "That's always a challenge because, like those applications, sometimes they are not really meant to scale that high," he noted. The discovery that caching solutions like Redis are single-threaded can come as a surprising revelation when scaling to unprecedented levels.

### Expect the unexpected

Sometimes the most significant challenges come from completely unforeseen circumstances. Guillaume recalled being featured on France's main TV channel without any warning: "Everything crashed obviously because we were not ready for it." This highlights the importance of effective communication across departments, particularly between marketing and technical teams, regarding upcoming campaigns and their anticipated impact.

As Guillaume put it: "There is no worse feeling than your CEO coming and saying, 'Hey, we've missed I don't know, $1 million in revenue because the site was down.'" The key is remembering that these situations call for shared responsibility rather than blame. Looking back should be about learning; looking forward should be about improvement.

### Resist feature creep

A frequently overlooked challenge is managing feature requests that can compromise performance. Guillaume emphasized fighting unnecessary customization: "Try to stick with what your solution is actually doing. If you're using Magento, don't try to over-engineer it and rework everything because you're going to struggle with updates, maybe security, but the performance is going to be so bad."

Thomas highlighted the insidious nature of incremental degradation. A feature that requires only two SQL queries may seem harmless in isolation. "Two SQL queries don't make a difference, it's true," Thomas acknowledged. "But it's the same thing every other week, and when Black Friday comes, you have 200 more SQL queries."

### Automated testing: essential guardrails

While some view automated testing as controversial, both experts advocated for it as a critical safeguard. Automated tests catch not just functional regressions but performance regressions, ensuring that new features don't inadvertently harm existing functionality.

However, Thomas warned about a common pitfall: teams under pressure sometimes comment out failing tests to meet deployment deadlines, only to forget to address the underlying issues. "You should not have fixed it by tricking it, but fix the reason why your test is failing," he cautioned.

### Framework choices: stability over novelty

When discussing JavaScript frameworks, both developers advised pragmatism over trendiness. Guillaume uses Svelte and SvelteKit personally, but acknowledges that React and Next.js are more widely adopted due to their established ecosystems and extensive component libraries. Angular remains prevalent in enterprise environments due to the support of corporations.

The key principle: "If you want to release stuff and be stable and keep releasing it, stick to the basics for now at least," Guillaume advised. Experimenting with emerging technologies like Bun or Turbo is fine for side projects, but production applications benefit from mature, well-supported frameworks.

Thomas took this philosophy further: "I've used React for many years and I simply don't want to change because I'm not using—well, I'm more of a backend guy." His pragmatic approach resonates with many developers: use what you know unless there's a compelling reason to change. As he noted, if one day Facebook stops supporting React, "I would have to move, but till now React is good."

## The bottom line

Preparing for Black Friday requires a holistic approach that balances technical preparation, team readiness, and cross-departmental communication. The worst strategy, as Thomas bluntly put it, is doing nothing: "Do not if one Black Friday went bad, do not wait one year hoping that everything will be better in one year."

Success comes from treating high-traffic events as the best-case scenario they represent for business, while simultaneously preparing for the worst-case technical scenarios. Start testing months in advance, invest in observability, implement aggressive caching, create realistic testing environments, and ensure your entire organization understands the stakes and their role in the process.

Most importantly, design your entire setup with worst-case scenarios in mind—because in eCommerce, the best day for business can quickly become the worst day for technology if preparation falls short.

### [Before deploying AI agents: governance checklist | Upsun](https://upsun.com/blog/what-mid-market-it-teams-wish-they-knew-before-deploying-ai-agents/)

# What mid-market IT teams wish they knew before deploying AI agents

AI agents are quickly shifting from experimentation into day-to-day operations. That shift is showing up in the data. McKinsey’s latest State of AI research highlights both broader AI use and the growing focus on “agentic AI,” even as many organizations still struggle to scale safely. 

For mid-market IT teams, agents can feel like the unlock: automate repetitive workflows, reduce backlog pressure, and deliver more output without expanding headcount.

The lesson early adopters tend to learn later is simple: agents don’t just add productivity, but also a new operational surface area. If governance isn’t embedded early, the risks appear after deployment, when it’s hardest to unwind them.

Here is  what mid-market IT teams consistently wish they had in place _before_ AI agents reached production.

### What is an AI agent and why does it change governance requirements?

An AI agent is a system that doesn’t only generate output, it can also take actions across tools and services. In practice, that means an agent may be able to write code, query data, call APIs, trigger workflows, or modify records. Once deployed, it operates at machine speed and often across multiple systems.

That is why agents change governance requirements. Traditional governance assumes humans can intervene**.** Agents reduce or remove that window.

A helpful way to frame it is: copilots assist humans inside a workflow; agents _become part of the workflow itself_.

### What do teams underestimate before deploying AI agents?

Most teams underestimate how quickly agents stop being “tools” and start becoming infrastructure.

At the beginning, an agent is often limited in scope. One team owns it. It’s used for a narrow task. Access is granted pragmatically to make it useful. But usefulness spreads fast: more teams ask for it, more workflows depend on it, more data sources are connected, and more permissions are added.

By the time an organization recognizes the agent is business-critical, it may already have broad access without clear boundaries, auditability, or ownership.

### Which risks only become visible once agents run in production?

Several risks only surface after agents become part of real workflows.

1.  **Access expands quietly.** What started as “read-only” access grows into cross-system access as teams connect new tools and data sources. The agent becomes a convenience layer over systems that were previously separated by process.
2.  **Trust becomes implicit.** Teams begin treating agent outputs as stable because they “almost always  work.” When an agent is wrong, it often fails in subtle ways that don’t trigger alerts until the impact is real.
3.   **Accountability becomes unclear.** When an agent touches multiple systems, troubleshooting becomes harder because no single person “made the decision,” yet the organization still owns the outcome.

This is where teams feel the governance gap most acutely: when they try to answer basic operational questions and realize the evidence trail is incomplete.

### What’s the one thing teams regret not putting in place earlier?

The most common regret is not defining boundaries upfront.

Teams wish they had established:

-   what data agents are allowed to access
-   what actions they are permitted to take
-   where agents are allowed to operate (dev vs production)
-   what monitoring and review is required

Once agents are relied on in production, tightening controls feels disruptive. And when controls arrive only after a scare or an audit, governance becomes reactive and inconsistent.

### What trade-offs do early adopters only discover after deployment?

Early adopters often discover a false trade-off between speed and safety.

When governance is missing, teams move fast initially, then slow down later as incidents force controls in a hurry. Exceptions accumulate. Rules vary by team. Operational overhead increases.

When governance is designed into workflows early, teams tend to move faster over time. Guardrails reduce uncertainty. Changes become predictable. Trust improves because behavior can be explained and reviewed.

In other words, the trade-off is not speed versus safety. It is planned structure versus reactive friction.

### Why governance has to be embedded into agent workflows

Agent governance cannot rely on documentation alone. Policies that live in wikis are advisory. Agents require enforceable controls.

Effective governance shows up where agents operate:

-   access is explicit and scoped
-   environments are separated clearly
-   behavior is observable
-   unsafe actions are blocked before they execute

This is the difference between “we have a policy” and “the policy actually works.”

As AI systems become more dynamic and gain access to tools and services at runtime, new risks emerge that cannot be addressed through documentation alone. This reinforces why real-time governance needs to be designed into the architecture rather than added later.

### How platforms help teams govern AI agents without slowing delivery

Governance is easier when teams build on an AI-ready application platform that makes systems predictable.  
  
When environments, configuration, and deployments are standardized, teams can apply consistent rules without inventing bespoke controls for every agent integration. This matters most in mid-market teams, where governance needs to scale without creating new operational roles.

This is where a platform approach can help: not by “governing AI” on its own, but by making the underlying workflows governable.

### What Upsun provides before you deploy AI agents

Upsun doesn’t claim to solve AI governance end-to-end. What it does provide is a foundation that makes governance easier to embed into delivery workflows.

In practice, that includes:

-   **Declarative, Git-driven configuration** that makes environment and service setup explicit and reviewable
-   **Isolated environments and previews** that support safe testing before going production
-   **Clear separation between environments and data** to reduce accidental exposure
-   **Observability built into the platform** to understand behavior once deployed

These capabilities help IT teams design governed workflows that developers can actually follow, because they’re built into the way software is delivered, not bolted on afterward.

### What to do before deploying AI agents in production

Before agents reach production, mid-market IT teams should be able to answer, plainly:

-   Where are agents used today?
-   What data can they access?
-   What actions can they take?
-   What evidence trail exists when something goes wrong?

If those answers are unclear, risk already exists, even if no incident has happened yet.

### Governance first, scale second

AI agents will become more common, more capable, and more autonomous. The question is not whether teams adopt them. The question is whether adoption happens deliberately or spreads without structure.

The teams that scale agents safely tend to do one thing early: **they embed governance into workflows before agents become critical infrastructure.** That is what keeps speed high and surprises low.

**What to do next**

If AI agents are already part of your workflows, the next step isn’t choosing better models, it’s ensuring your platform can support experimentation without exposing production to risk. That means predictable environments, clear boundaries, and validation before deployment.

### [Why AI agents fail on fragmented stacks | Upsun](https://upsun.com/blog/why-agents-fail-on-fragmented-stacks/)

# The AI infrastructure gap: why agents fail on fragmented stacks

The initial hype of AI agents is hitting a hard reality: a clever prompt is not a production strategy.

As organizations move from experimentation to operationalizing AI in 2026, a systemic bottleneck has emerged: 

It is not the model's intelligence; it is the model’s **context and its access to the right tools**. 

When an AI agent lacks access to live, grounded platform data, it guesses. In a production environment, guessing is a liability that leads to costly hallucinations, security leaks, and broken workflows.

At Upsun, we built our own internal content agent, **AI-Brain**, to address this. 

We validated a core shift: building better agents is not about writing better prompts; it is about building better context. 

To move AI from a playground to a revenue-generating tool, you need a platform that treats **context and tools** as first-class citizens.

## **The 2026 ROI reckoning: the cost of "context rot"**

We are currently in a "reckoning" for AI investment. 

Forrester recently predicted that enterprises will defer 25% of planned AI spend because the gap between vendor promises and delivered value is widening.

A primary driver of this gap is **context rot**. 

In high-velocity engineering, reality changes every hour. Code is merged, documentation is updated, and security policies are tightened. 

If your AI agent relies on a "system prompt" written months ago, it is already obsolete. 

This leads to the **AI Rework Tax**: research shows nearly 40% of productivity gains are being lost to rework; time spent by humans fixing low-quality AI outputs.

To bridge this gap, your infrastructure must act as the authoritative source of truth for your agents.

## **The Upsun differentiator: unified context vs. scattered tools**

Most AI solutions today are scattered: your code lives on GitHub, your containers are in Kubernetes, your metrics are in a third-party dashboard, and your backups are in a separate S3 bucket. 

This sprawl makes it impossible for an AI agent to maintain a consistent view of your reality.

**With Upsun, everything is in one place: your code, infrastructure, metrics, logs, and databases.** 

Because the stack is unified, the context is inherently consistent. An AI agent on Upsun doesn’t have to hunt across fragmented tools; it can query the environment directly through the Upsun CLI to get accurate data in seconds.

### **What an agent looks like on a unified platform:**

**Prompt:** Clone my production environment and measure the performance impact of PHP 8.5.

```shell-session
# Step 1: Cloning production to a safe preview environment
$ upsun branch php-85 production 

# Step 2: Updating the declarative configuration to the new runtime
$ sed -i 's/php:8.4/php:8.5/g' .upsun/config.yaml 
$ git commit -am 'Update to PHP 8.5' 

# Step 3: Deploying to the new environment
$ upsun deploy 

# Step 4: Accessing live metrics and logs from the unified stack
$ upsun metrics 
$ upsun logs

[Analysis complete]

Average response time reduced by 20%. I identified deprecation logs related to the curl_close() function, as explained in the PHP 8.5 changelog.

Do you want me to fix the code in this environment and send a pull request for the team to review?
```

## **Moving governance into the platform layer**

With the EU AI Act's primary obligations taking effect in August 2026, governance is no longer optional. On Upsun, we treat governance as code.

By using standardized knowledge directories injected directly into an agent’s instructions, organizations ensure every AI interaction inherits the same security guardrails. 

Because Upsun is declarative and Git-driven, these rules are version-controlled and auditable. When a security officer updates a policy, every agent across your organization is updated instantly.

## **Safe experimentation in production-perfect previews**

One of the greatest hurdles to AI adoption is trust. 

Upsun’s preview environments provide the ultimate safety sandbox. Every AI-driven experiment can be tested in an isolated, production-identical clone.

To meet the needs of highly regulated markets, Upsun provides environment-level scoping for both users and agents. Your human teams can then validate the agent’s output in a live, functional environment. 

This "Governance Validation Layer" allows you to increase development velocity with AI while maintaining absolute control.

## **Innovation without infrastructure drag**

The goal of any AI initiative is to deliver value, not to manage plumbing. 

Independent research has shown that teams using Upsun’s modernization and automation features achieve a **219% Return on Investment (ROI)** over three years.

By providing a platform that handles container orchestration, security updates, and multi-cloud portability, Upsun allows your senior engineers to focus on the logic of the agents. We provide the "predictable world" that robots and AI agents need to be successful.

### **Technical Deep Dive**

For the architecture behind our internal AI-Brain agent, read the full implementation guide on the Upsun Developer Center.

-   **Govern AI without slowing teams**  
    Explore platform patterns for governed AI
-   **Experiment with AI safely on Upsun**  
    Start your free trial

### [Why manual data masking fails in 2026](https://upsun.com/blog/automated-database-sanitization/)

# What is automated database sanitization?

Automated database sanitization (or data masking) is the process of neutralizing personally identifiable information (PII) during the replication of production data to dev environments. Upsun automates this via the .upsun/config.yaml file, executing sanitization scripts within ephemeral preview environments. This Upsun-native workflow ensures developers test against realistic data distributions without exposing sensitive customer information, maintaining compliance with GDPR, HIPAA, and SOC2.

## I. Why manual data masking fails in 2026

_Key takeaway: Manual database dumps are the primary cause of "compliance lag" and security vulnerabilities in dev workflows._

For years, teams relied on scheduled `pg_dump` or `mysqldump` processes sanitized on separate staging servers. Upsun replaces this obsolete "Snapshot" approach because:

1.  **Latency:** Manual processes take hours; Upsun enables developers to work on fresh, sanitized data immediately.
2.  Inconsistency: Manual scripts miss new PII fields; Upsun allows sanitization logic to be versioned alongside code.
3.  **Insecurity:** Persistent staging servers are high-value targets; Upsun utilizes ephemeral environments to reduce the data footprint.

## II. The logic of "Sanitization-at-Clone"

_Key takeaway: Upsun utilizes copy-on-write file systems to allow for instant database branching followed by immediate, automated PII scrubbing._

By integrating the sanitization logic directly into the environment lifecycle (triggered via hooks in Upsun’s unified configuration file `.upsun/config.yaml`), the scrubbing becomes a mandatory gate. The logic follows a three-step "Branch-Mask-Serve" protocol:

1.  **Instant Branching:** The production volume is branched (not copied) using a copy-on-write mechanism.
2.  **Post-Provisioning Hooks:** As the environment initializes, a built-in hook (e.g., a `deploy` or `post-install` script) executes a sanitization suite.
3.  **Deterministic Masking:** The script replaces real names with dictionary aliases and scrambles emails while preserving referential integrity (e.g., ensuring `user_id` 123 remains consistent across all tables).

## III. Maintaining compliance in ephemeral environments

_Key takeaway: Ephemeral environments reduce the audit surface by ensuring sensitive data only exists during the active development lifecycle._

By using this method with Instant Data-Complete Preview Environments, Upsun allows developers to work with a "fresh" and "safe" mirror of production. This eliminates the need for developers to ever request access to raw production data for debugging.

## Frequently asked questions (FAQ)

**How do you sanitize PII in complex JSONB or NoSQL fields?**

Modern sanitization scripts use regex-based pattern matching to identify and replace values inside semi-structured data. By defining these in Upsun’s unified configuration file `.upsun/config.yaml` build hooks, you ensure that even as your schema evolves, the sanitization logic stays versioned with your code.

**Does automated sanitization slow down environment creation?**

If using a copy-on-write system, the "cloning" is instant. The only delay is the time it takes for your SQL update scripts to run. For most applications, this adds less than 60 seconds to the provision time which is a small price for 100% GDPR compliance.

**Is it better to use synthetic data or sanitized production data?**

While synthetic data is safest, it often fails to catch edge cases caused by complex real-world relationships. Sanitized production data is the "Gold Standard" because it preserves the distribution and scale of your data without the risk.

### [Automate compliance audits for AI workloads | Upsun](https://upsun.com/blog/compliance-accelerators-for-ai-workloads/)

# Compliance accelerators for AI workloads: reducing risk without slowing delivery

AI workloads introduce a new kind of compliance pressure. They move faster, touch more data, and operate across more systems than traditional applications.

For many organizations, existing compliance programs were designed around predictable software systems with clearly defined access paths. AI changes that model. Tools are adopted incrementally. Agents operate continuously. Data flows are harder to trace.

The result is familiar to compliance and IT teams alike: audits take longer, evidence is harder to assemble, and confidence in controls erodes.

This is where the idea of a compliance accelerator becomes relevant.

### What a compliance accelerator means in the context of AI

A compliance accelerator is not a new framework or certification. It is a set of platform capabilities and practices that reduce the manual effort required to meet compliance obligations as systems scale.

In the context of AI workloads, this means embedding controls into how environments are built, how access is granted, and how changes move toward production. Instead of relying on one-off reviews or manual evidence gathering, compliance becomes a byproduct of standardized workflows.

The goal is not to “solve compliance,” but to make it easier to maintain as AI usage grows.

### Why AI makes audits harder, not easier

AI workloads introduce several challenges that traditional audit processes struggle with.

AI tools often access data dynamically, rather than through fixed pipelines. Usage may span development, testing, and production environments simultaneously. Outputs can influence downstream systems without clear checkpoints.

When auditors ask how data is protected or how changes are reviewed, teams often find themselves reconstructing events after the fact. Logs exist, but they are scattered. Controls exist, but they are inconsistent. Evidence exists, but it takes time to collect.

Compliance slows down not because requirements changed, but because systems became harder to reason about.

### Where compliance teams feel the most friction

The heaviest compliance burden usually appears in a few recurring areas.

Evidence collection becomes manual and repetitive. Access reviews are difficult because permissions are granted across tools rather than centrally. Environment separation is assumed rather than enforced. Changes reach production without a clear audit trail that ties them back to review and approval.

Each of these issues adds friction. Together, they create audit fatigue for both IT and compliance teams.

### How compliance accelerators reduce audit fatigue

Compliance accelerators work by shifting effort earlier in the lifecycle.

When environments are standardized and access is defined declaratively, evidence is generated automatically as part of normal operations. When changes move through predictable deployment workflows, review and approval become visible. When environments are isolated, scope is easier to demonstrate.

Instead of preparing for audits as a separate activity, teams can point auditors to systems that already reflect compliant behavior.

This does not remove the need for audits, but it significantly reduces the time and disruption they cause.

### What controls can realistically be enforced automatically

Not every compliance requirement can or should be automated. Human judgment remains essential.

However, many controls lend themselves to technical enforcement. Environment isolation, access boundaries, deployment approvals, and change traceability are all areas where automation improves consistency.

By enforcing these controls at the platform level, teams reduce reliance on individual behavior. Compliance becomes a property of the system rather than a checklist people must remember to follow.

### Why platforms matter for compliant AI workloads

AI compliance is ultimately an infrastructure problem.

Without predictable environments and deployment workflows, compliance depends on trust and manual verification. As AI usage scales, that approach does not hold.

Platforms that standardize how applications are built and deployed make it easier to apply controls consistently. They also make compliance visible. Auditors can see how systems behave, not just how policies describe them.

This is why compliance accelerators are closely tied to platform design.

### How Upsun supports compliance acceleration for AI workloads

Upsun does not replace your compliance program. What it provides is a foundation that reduces the operational cost of maintaining one.

By offering declarative, Git-driven configuration, predictable environments, and built-in observability, Upsun helps teams produce the evidence compliance requires as part of everyday workflows. Isolated environments support safer testing. Version-controlled configuration supports traceability. Standardized deployments make reviews repeatable.

These capabilities allow IT and compliance teams to work from the same source of truth rather than assembling proof after the fact.

### When organizations benefit most from a compliance accelerator

Compliance accelerators become most valuable when AI usage reaches scale.

Organizations typically feel the need when AI tools are already in use across multiple teams, regulatory scrutiny is increasing, or audits are becoming more disruptive. At that point, the issue is not policy intent, but operational overhead.

Accelerators help teams regain control without slowing innovation.

### Compliance as an enabler, not a bottleneck

Compliance is often framed as something that slows progress. In practice, unclear or inconsistent controls are what create friction.

When compliance requirements are embedded into platforms and workflows, teams spend less time preparing evidence and more time delivering value. Confidence increases because behavior is predictable and demonstrable.

For AI workloads, this shift is essential. As systems become more autonomous, compliance has to keep pace without becoming a blocker.

### What to do next

If AI workloads are already part of your environment, the next step is understanding where compliance friction originates today. In many cases, the fastest path forward is reducing manual effort by embedding controls into the platform layer rather than adding more process on top.

### [Open source vs commercial AI: how to choose | Upsun](https://upsun.com/blog/open-source-vs-commercial-ai/)

# Open source vs commercial AI: choosing the right path for your business

_This blog is based on a presentation by Guillaume, Field Chief Technology Officer at Upsun, and Robert from Ilwiin Technology during the AI Action Summit. The original French presentation has been translated and edited for clarity and accuracy._

The AI field is advancing significantly, presenting organizations with the question: Should they choose open-source or commercial AI models? This choice impacts everything from costs and data privacy to long-term business strategy. Let's explore the key differences and help you make an informed decision.

## The current AI ecosystem

There are two main types of AI models: open-source models, which are freely available and accompanied by public code, and proprietary models, which are licensed and typically come with restricted access to code. Secondly, commercial models, which are paid services from tech companies like OpenAI, that you access through subscriptions.

The gap between these two approaches is narrowing. Open-source models now achieve performance levels comparable to those of commercial models, typically with a delay of about 6 months. Recent examples, such as Chinese models, have even matched the performance of leading commercial solutions.

## Open source AI: advantages and considerations

### **Key Benefits**

-   **Cost control**: Open source models eliminate subscription fees and reduce long-term costs. While you still need computing resources to run them, you avoid the marketing and acquisition costs built into commercial pricing.
-   **Data privacy**: Your data stays under your control. This is crucial for organizations that handle sensitive information or operate in regulated industries.
-   **No vendor lock-in**: You can switch between different models or providers without being tied to a single company's ecosystem.
-   **Transparency**: You can examine the model's behavior and understand how it processes information, though training data is often not fully disclosed.

### **Challenges to consider**

-   Technical complexity: Running open source models requires finding suitable hosting providers with GPU capabilities. It's not as simple as signing up for a service.
-   Resource requirements: You need technical expertise to deploy, maintain, and optimize these models effectively.
-   Infrastructure costs: Although the models are free, you still incur costs for computing power and storage.

## When commercial AI works better

### **Advantages**

-   Ease of Use: Commercial solutions offer plug-and-play simplicity. You can start using advanced AI capabilities immediately.
-   Professional Support: Companies provide customer service, regular updates, and technical assistance.
-   Reliability: Established providers offer stable, tested solutions with guaranteed uptime.

### **Drawbacks**

-   Rising Costs: Current pricing is heavily subsidized. As AI becomes more mainstream, costs will likely increase significantly.
-   Data Concerns: Your information passes through third-party systems, raising concerns about privacy and security.
-   Limited Control: You depend on the provider's decisions about features, pricing, and availability.

## The rise of small language models

A significant trend, as discussed by Guillaume, is the use of  Small Language Models (SLMs). These focused models perform specific tasks just as well as large general models but use far fewer resources. For functions such as document summarization, customer service, or content classification, small models yield excellent results at significantly lower costs.

As Guillaume noted, "we're moving toward more frugal models" that are "extremely efficient." This isn't trendy, but it's practical; many production systems in companies work better with smaller, specialized models than with massive general-purpose ones.

## Making the right choice for your organization

During the session, the speaker emphasized that successful AI implementations utilize multiple models working in tandem. This "agentic approach" breaks down complex problems into simpler components, with different AI models handling distinct parts.

Companies are building systems that utilize vision models to analyze images, language models for text, and specialized models for specific tasks, all orchestrated together. This requires engineering tools to manage these complex workflows.

### **Choose open source if:**

-   Data privacy is critical for your business
-   You have technical expertise in-house
-   Cost control is a priority
-   You want to avoid vendor dependence
-   You need customization for specific use cases

### **Choose commercial solutions if:**

-   You need immediate deployment
-   Technical resources are limited
-   You prefer predictable monthly costs
-   Professional support is important
-   You're testing AI capabilities before a significant investment

## Recommendation

During the session, the speaker emphasized that companies that succeed with AI focus on specific business problems rather than simply adopting AI in general. They start with use cases that are "at the heart of the business model" rather than trying to use AI everywhere. The most important factor is avoiding both technological and financial vendor lock-in. As AI technology advances rapidly, flexibility becomes increasingly valuable, as committing to a single approach becomes less viable.

## Cost considerations

Current AI pricing from major providers includes significant marketing and customer acquisition costs. As these companies mature and competition intensifies, pricing structures are likely to change. Organizations should plan for:

-   Potential price increases as subsidies end
-   Volume-based pricing for heavy usage
-   Different pricing tiers based on performance requirements

Whether you choose open source or commercial AI, success depends on:

1.  Clear Use Cases: Focus on specific business problems rather than general AI adoption.
2.  Pilot Projects: Start small with well-defined objectives.
3.  Team Training: Ensure your team understands both the capabilities and limitations of AI.
4.  Regular Evaluation: Monitor performance, costs, and changing requirements to ensure ongoing alignment.

## Conclusion

The choice between open source and commercial AI is not permanent. The most successful organizations maintain flexibility, regularly evaluate their options, and choose the right tool for each specific use case.

Open source AI offers cost savings, privacy control, and customization options, but requires technical expertise. Commercial AI offers convenience and support, albeit at higher costs and with reduced power. As the AI ecosystem continues to rapidly evolve, staying informed about new developments and maintaining a flexible approach will serve your organization better than locking into any single solution too early.

The future belongs to organizations that can effectively combine different AI approaches, choosing the right model for each task while maintaining control over their data, costs, and strategic direction.

### [Calculating the TCO of automated staging environments | Upsun](https://upsun.com/blog/tco-of-automated-staging-environments/)

# TCO of Automated Staging Environments

**What is the TCO of automated staging environments?**

The Total Cost of Ownership (TCO) of automated staging environments is calculated by combining direct infrastructure spend with developer productivity gains and the "Idle Resource Tax." Unlike legacy staging clusters that remain active 24/7, automated ephemeral environments use a "pay-for-what-you-provision" model. By triggering Instant Data-Complete Preview Environments only during the active lifecycle of a Git branch, organizations typically reduce cloud waste by 30-40% while eliminating the manual labor costs associated with environment synchronization and data masking.

### I. Calculating the "Idle Resource Tax"

_Key takeaway: Organizations paying for 24/7 staging environments are essentially paying for 128 hours of unused capacity every week._

Standard development teams work roughly 40 hours a week. If your staging environment is persistent, you are paying for the remaining 128 hours (weekends and nights) when no testing is occurring.

**In a resource-based model (Upsun):**

1.  **Ephemeral Lifecycle:** Environments only exist when a Pull Request is active.
2.  **Resource-Right-Sizing:** Using `.upsun/config.yaml`, developers can downscale the resource profiles of preview environments to 25% of production strength while maintaining 100% architectural parity.
3.  **Automated Cleanup:** The system destroys the environment and stops billing the moment the branch is merged or closed.

### II. Hidden ROI: developer velocity and triage time

_Key takeaway: The greatest cost saving of automated environments is the elimination of "triage debt" caused by staging/production drift._

When a staging environment fails because it is "out of sync," it doesn't just cost cloud credits, it costs engineering hours.

-   **The "Triage Tax":** The time spent by senior engineers fixing broken staging data or manual service configurations.
-   **The "Wait Time":** Developers idling while waiting for a shared staging server to be "cleared" for their turn to test.
-   **The Upsun Effect:** Because Upsun triggers an Instant Data-Complete Preview Environment for every branch, there is zero waiting time. Every developer has their own "production-perfect" stack instantly.

### III. Strategic Comparison: Persistent Clusters vs. Ephemeral Previews

_Key takeaway: Shifting to ephemeral previews moves infrastructure from a fixed "Capital Expense" logic to a variable "Operational Efficiency" logic._

### Frequently asked questions (FAQ)

**How does Upsun's resource-based pricing compare to seat-based pricing?**

Seat-based pricing penalizes you for growing your team. Upsun’s resource-based model allows you to scale your team infinitely without increasing your hosting costs—you only pay for the actual CPU and RAM your applications consume.

**Can we limit the resources used by preview environments?**

Yes. Through the `.upsun/config.yaml` or CLI resource profiling, you can set "resource offsets." This allows your preview environments to use smaller CPU/RAM footprints than production, ensuring cost-efficiency without sacrificing service logic.

**What is the impact of "Instant Data-Complete" cloning on storage costs?**

Since Upsun uses a copy-on-write file system, "cloning" a database for a preview environment doesn't immediately double your storage cost. You only pay for the _changes_ made to the data within that specific branch, making it significantly cheaper than traditional database duplication.

### [Need more juice? Scaling made simple | Upsun](https://upsun.com/blog/scaling-demo/)

# Need more juice? resources:set. Done.

Scaling your application shouldn’t feel like open-heart surgery. It should feel like flipping a switch. Watch your environment adapt in real time. Horizontal scaling. Vertical scaling. One command. Done.

```shell-session
upsun resources:set
```

  
You do not want another war room. You want a clear way to add capacity when traffic increases, without editing and testing complex YAML files for hours or manually rolling out scripts across clusters. Upsun enables you to dial in both vertical and horizontal scaling from a single CLI or Web UI, then verify the impact with built-in observability.

## **How does it work**

1.  Start with a normal production clone on a feature branch. Every branch in Upsun can be a production-perfect environment with code, services, and data, so you can test the exact change you plan to ship. See What is Upsun guide.
2.  Bump CPU, RAM, or disk for one container to show vertical scaling.
3.  Add instances for an app to show horizontal scaling during load.
4.  Push a second branch and repeat, proving the workflow is consistent across environments.
5.  Open metrics and profiling to confirm that latency drops and error rates remain stable.

## Application scaling 101: horizontal scaling and vertical scaling

Horizontal scaling involves running multiple instances of your app as the load increases. Vertical scaling refers to allocating a container more CPU and memory resources. Modern workloads require you to be able to do both easily and quickly.¹² While horizontal scaling is best for stateless applications, vertical scaling is preferred for services that require a data layer. Upsun supports both patterns with a single workflow, allowing your team to scale for bursts and right-size to a steady state.

## The Upsun way: one solution for both

You can change resources interactively or run explicit flags. Read resource configuration.

Vertical scaling:

```shell-session
upsun resources:set --size frontend:0.25,api:0.5 --disk api:2048
```

-   `--size` allows you to select a CPU amount. Each CPU amount is mapped to a RAM pairing via our container profiles based on runtimes.
-   `--disk` allocates storage per container.
-   The environment redeploys to apply changes. See the vertical scaling section.

Horizontal scaling:

```shell-session
upsun resources:set --count api:3

# or fan out across apps:

upsun resources:set --count '*:3'
```

-   The router distributes requests across instances.
-   The environment redeploys to apply the new count. See the horizontal scaling section.

Prefer to start tiny on previews and grow only when needed? Set a resource initialization strategy at branch or integration time. That way, every new environment begins at the right size automatically. Learn strategies.

## Developer workflow, not platform detours

Upsun is Git-driven. You describe your app and services in a single config, push a branch, and Upsun builds and deploys a production-like environment automatically. Learn the workflow. Because environments clone code and data, your branch testing is realistic, and you can sanitize sensitive records right in the pipeline. See database sanitization guide.

When your stack mixes runtimes, container images, and shared mounts, Upsun maintains a consistent state across instances for safe horizontal scaling. For memory and CPU tuning, container profiles expose sensible CPU and RAM pairings by workload type. Review profiles.

## Observability and APM built in

Tuning without telemetry is guesswork. Upsun integrates continuous profiling and application metrics, allowing you to validate that your scaling choice actually moves p95 latency, CPU saturation, and throughput in the right direction. See continuous profiling for PHP and other languages. Watch a short demo.

## Step by step

1\. **Baseline:** Run a quick load to obtain starting metrics. 

**Vertical scaling:**

```shell-session
upsun resources:set --size api:1 --disk api:4096
```

  
2\. Redeploy applies the change. Confirm CPU headroom and memory pressure improve while latency falls.

**Horizontal scaling:**

```shell-session
upsun resources:set --count api:3
```

  
3\. Hit the same test. Requests are distributed across instances. Confirm error rates stay low under burst.

4\. **Branch again:** Create a new feature branch. It inherits resources based on your initialization rules. Rinse and repeat. 

5. **Autoscaling option:** If you prefer a hands-off approach, enable native autoscaling to adjust the instance count based on CPU, RAM, or request latency thresholds. See the autoscaling guide.

## Why this helps your team

-   **Speed:** Scale in minutes, not days. Your branch behaves like production, so fixes are accurate.
-   **Quality:** Preview every change and run performance tests on environments that temporarily replicate production resources at a fraction of the cost.
-   **Consistency:** One CLI for both vertical and horizontal scaling across all services.
-   **Reduced toil:** No bespoke scripts or manual cluster surgery.
-   **Predictable cost:** Start with minimal resources on branches, scale only where telemetry proves value. See pricing and cost monitoring in Console.

If you prefer a visual landing page before diving in, explore Upsun features. For more language-specific examples and tutorials, visit the Developer Center.

## Try it yourself

Push your own code and see a full-stack environment scale in seconds.

Start a free trial. Connect your Git repo. Run `upsun resources:set` and let scaling be the least of your problems.

### **Sources**

1.  Kubernetes autoscaling concepts: horizontal vs vertical
2.  Kubernetes HPA walkthrough, definitions, and behavior
3.  Google Cloud framework, autoscaling to avoid overprovisioning 
4.  AWS Well-Architected Generative AI Lens, autoscaling improves efficiency and cost
5.  Kubernetes Vertical Pod Autoscaler, overview and operations

### [Add Postgres in one line, deploy in minutes | Upsun](https://upsun.com/blog/add-postgres-with-one-yaml-line/)

# Add Postgres with one YAML line.  Deploy in under a minute.

Let’s break down why this matters, and how it can change the way you approach building and running applications.

You want database power without getting bogged down in tooling and config. Most of your week should be building features, not hunting for connection strings or maintaining bespoke infra scripts. Developers tell us they just want to code and solve application problems, with minimal platform friction.

This post walks through how to add PostgreSQL to an Upsun project with a single YAML change, push to your repository, and let Upsun do all the work of deploying a new instance and finish in under a minute. Along the way, you get a production-grade preview environment per branch, safe data cloning with sanitization, and built-in observability that keeps you out of war rooms.

## Why Postgres, why now

PostgreSQL has become the most popular database, according to the Stack Overflow Developer Survey, with approximately 49 percent of developers using it in 2024.¹ That popularity comes from a mix of reliability, performance, and an ecosystem that keeps expanding.

There is another reason Postgres fits modern workflows: it pairs naturally with infrastructure defined as code. When your app, services, and policies live in declarative YAML, combined with proper migrations,  your database stops being a snowflake and starts being versioned, repeatable, and easy to automate.

## What the flow looks like

Here is the high-level path you will follow:

1.  Add one line to declare a managed Postgres service in `.upsun/config.yaml`. Upsun’s product pillar is simplicity through a single YAML file. 
2.  Commit and push. Upsun builds and deploys the new Postgres instance automatically, providing your branch with an up-to-date environment. 
3.  Ensure your application uses the environment variables that have been created automatically (DB\_\*) to connect to the Postgres instance.
4.   Continue developing your application and its features with a fully managed database. Each new branch will automatically create a preview environment that inherits a cloned copy of the database for testing purposes.
5.  Inspect metrics and logs to validate performance before you merge. Upsun integrates performance monitoring and code profiling for modern and legacy apps.

That is the path we show in the time-lapse demo: from one YAML change to a running Postgres-backed branch preview in under a minute.

## One-line Postgres in YAML configuration

If your project already has a `services:` section, you can declare Postgres with a single inline map:

```shell-session
services:

  db: { type: postgresql:17 }
```

See the PostgreSQL service reference for a complete documentation of the available options and configuration keys.

If needed, review the YAML structure overview, which explains the top-level keys in `config.yaml`.

Tip: Your editor can autocomplete Upsun YAML keys using our published schema. See editor autocomplete setup.

## Service provisioning that “just works”

Upsun’s managed services are provisioned from YAML and connected to your app with relationships. The Postgres page displays the canonical example, including environment variables such as `POSTGRESQL_HOST` and `POSTGRESQL_PASSWORD`, which are automatically injected for you. See PostgreSQL service reference.

To connect from your code, you can read the injected variables or use a convenient `DATABASE_URL` variable you define in a `.environment`. 

The docs include examples and CLI helpers such as `upsun sql` for direct access. Same reference page as above.

## Preview per branch, automatically

Every Git branch gets a live, production-grade environment that includes your code, filesystem data, and cloned services. That means feature branches and pull requests run with the same topology as production, which reduces surprises after merge.

Conceptually, a preview is just another environment in Upsun, managed alongside production and staging. See manage environments.

Why this matters: industry research ties faster, smaller, more frequent deployments to better performance outcomes. The DORA program’s four key metrics remain the standard for measuring delivery performance.² ³ When all your branches can be previewed and tested, right out of the box, you shorten lead time and increase deployment frequency without adding risk.

## Instant data cloning, with sanitization

When you branch in Upsun, the platform clones both code and data for that branch by default, so you can test against realistic datasets. You can then sanitize personal data in previews to stay compliant and safe. See sanitize databases overview and a PostgreSQL example for Symfony.

This automated flow reduces the pain and time needed to spin up new environments for testing. And removes any error-prone manual tasks from it. No long manual dumps and imports anymore!

## Database scaling from day one

Start simple with one service line, scale when you need to:

-   Scale the resources allocated to Postgres with one CLI command or two clicks!
-   Add multiple databases or users by defining endpoints under the `configuration` key. Same reference as above.
-   Keep the app stateless. If you run multiple application containers later, the managed database remains a single source of truth. 
-   Observe the different components directly in the platform and profile performance issues with Blackfire.

## A quick start you can try today

If you are new to Upsun, the “Configure your project” guide shows where `config.yaml` lives and how to pre-generate it. 

Prefer hands-on? This Laravel tutorial deploys a REST API on Upsun with Postgres support. See Laravel on Upsun in 10 minutes.

As you iterate, your AI assistants can even understand your stack through our Model Context Protocol servers, which can provide real-time infrastructure context. See connecting a Postgres MCP server.

## What you gain in practice

-   **Speed.** Smaller changes, faster deploys, less waiting.
-   **Simplicity.** One config.yaml governs apps, services, and policies.
-   **Standardization.** Same process across teams and repos.
-   **Security.** Managed services and environment-scoped credentials.
-   **Predictable costs.** Less bespoke infra to build and maintain.

If your team has felt the grind of too many tools and not enough flow, this is a way to get back to building. Your YAML drives service provisioning, your branches become safe places to test with real data, and your deployments get repeatable, fast, and confident. That is developer productivity, you feel the same day.

### Postgres deployment, YAML configuration, and developer productivity

If you remember only one thing, make it this: declare Postgres in YAML, push, and validate in a real preview before you merge. The rest follows naturally. Upsun provides the managed rails so your team can focus on features.

## Beyond Postgres

The same pattern applies to Redis, MongoDB, Elasticsearch, Kafka, Solr, and many other systems. Services are declared in YAML, committed to Git, cloned across environments, and managed automatically.

Think of it as **infrastructure as version-controlled code**. No hidden state, no mystery boxes. Just a predictable workflow that scales with your team.

## What to try next

The time-lapse demo demonstrates its speed. But the fundamental shift happens when you try it with your own project (for free).

Spin up an environment, add a service with one line, and see it deploy in under a minute. Push a schema change, clone the database, and test it without fear of breaking production.

That’s the moment when you realize: you’re not just saving time. You’re working differently.

## **Sources**

1.  Stack Overflow Developer Survey 2024, databases and productivity sections
2.  DORA research program overview and 2024 report hub
3.  Google Cloud blog, announcing the 2024 Accelerate State of DevOps Report

### [What’s New in Upsun Q4 2025 | More control, performance and velocity](https://upsun.com/blog/whats-new-in-upsun-q425/)

# Upsun product showcase - What's new in Q4 2025?

**What’s new in Upsun: Q4 2025**

Here at Upsun we've continued to focus on some of the core pillars that make us the platform that humans and AI agents love: stronger governance, predictable performance, operational efficiency, and platforms that scale with confidence. **More control with less overhead**.

## **App‑specific environment variables**

Managing configuration across large, multi‑application projects can quickly become a source of risk and operational drag. App‑specific environment variables introduce a cleaner, safer model by allowing variables to be defined per application instead of globally.

-   **Improved security posture:** Sensitive values like API keys or credentials are accessible only to the application that requires them, reducing blast radius.
-   **Reduced operational churn:** Changes affect only the relevant application, cutting down unnecessary rebuilds and redeployments.
-   **Better isolation at scale:** Teams can reuse variable names across applications while maintaining clear separation of concerns.

This feature is particularly valuable for organizations running complex, multi‑service architectures where governance and change control are critical. For more information, check out the documentation.

## **Composable images**

Composable images give teams full declarative control over application runtimes—without introducing the complexity of managing custom containers manually.

With composable images, you define exactly which runtimes, versions, binaries, and extensions your application needs. Upsun takes care of building a reproducible, production‑ready image that behaves consistently from development through production.

-   **Standardization without rigidity:** Support multiple runtimes or niche dependencies while maintaining platform consistency.
-   **Lower operational risk:** Reproducible builds ensure what runs in production matches what was tested.
-   **Future‑proof flexibility:** Avoid platform lock‑in caused by fixed runtime assumptions.

This approach balances developer autonomy with the predictability IT organizations require. For more information, check out the documentation.

## **Origin and Fastly alerts & metrics in Console**

Visibility is essential for cost control and reliability. Upsun now surfaces Origin and Fastly metrics directly in the Console, with the ability to configure alerts based on defined thresholds.

-   **Cost predictability:** Avoid surprise overages by monitoring usage in real time.
-   **Centralized observability:** Eliminate the need to jump between platforms to understand performance and traffic patterns.
-   **Proactive operations:** Alerts enable teams to respond before issues escalate.

* * *

## **Built for scale, governance, and confidence**

Every feature released in Q4 2025 reflects Upsun’s focus on helping organizations run critical workloads with confidence without sacrificing developer velocity. You code, we do the rest.

### [What is cloud infrastructure portability? | Upsun](https://upsun.com/blog/infrastructure-portability-and-multi-cloud-logic/)

# Infrastructure Portability and MultiCloud Logic

**What is cloud infrastructure portability?**

Cloud infrastructure portability is the ability to move application workloads between different cloud providers (such as AWS and GCP) without rewriting deployment scripts or reconfiguring service architectures. Unlike "active-active multicloud," which runs a single application across multiple providers simultaneously, portability focuses on standardization. Upsun allows you to use a provider-agnostic configuration file like Upsun’s `.upsun/config.yaml`, teams ensure their infrastructure definition remains consistent regardless of the underlying cloud project's hosting provider.

## I. Portability vs. Multicloud: Disambiguating the strategy

_Key takeaway: Strategic Multicloud in 2026 is about optionality and standardization, not active runtime distribution._

A common technical fallacy is that multicloud requires a single application to run on AWS and GCP at the same time. In reality, this "active-active" setup introduces extreme latency and networking costs. True Infrastructure Portability focuses on the Logic Layer:

1.  **Standardized Definitions:** Defining services (databases, caches, runtimes) in a way that the platform understands, regardless of the cloud vendor.
2.  **Provider Optionality:** The ability to choose the best provider for a specific project, perhaps GCP for a data-heavy app and AWS for a legacy enterprise service, while using the same deployment workflow.
3.  **Unified Management:** Managing all environments through a single interface, ensuring that a unified configuration file, like Upsun’s `**.upsun/config.yaml**`**,** behaves identically across different regions and vendors.

## II. Decoupling application definitions from cloud scripts

_Key takeaway: Hard-coded Terraform or CloudFormation scripts are the primary drivers of vendor lock-in._

When infrastructure is defined using provider-specific tooling, the application becomes "locked" to that vendor's proprietary API. To ensure true infrastructure portability, Upsun abstracts the provider layer, allowing the application logic to remain independent of the underlying cloud hardware.

-   **The Mechanism:** Upsun abstracts the provider layer. Instead of writing AWS-specific networking logic, you define a `relationship` in your configuration.
-   **Consistency:** Because the platform handles the translation to the underlying provider, your **Instant Data-Complete Preview Environments** look and act the same on an AWS-backed project as they do on a GCP-backed one.
-   **Entity Density:** This approach is vital for teams managing hybrid stacks involving **AWS, GCP, or Azure**, and specialized services like **PostgreSQL** or **Redis**.

## III. The "Diagnostic Hook": When to choose portability

_Key takeaway: Portability is the preferred strategy for organizations requiring regional flexibility and cost-negotiation leverage._

## Frequently asked questions (FAQ)

**Does Upsun run my app on AWS and GCP at the same time?**

No. Upsun provides choice of cloud provider at project creation. You gain portability and standardization that means your code and config are cloud-agnostic, but the application runs on the provider you selected for that specific project.

**What are the benefits of a "Provider-Agnostic" .upsun/config.yaml?**

It allows your engineering team to learn one set of configuration rules that work everywhere. Whether you are deploying a small Node.js app or a massive Drupal cluster, the logic for services, routes, and build hooks remains identical across all cloud providers.

**How does portability improve disaster recovery?**

If a specific cloud provider experiences a major regional outage or a price hike, having portable infrastructure means you can spin up your entire stack on a different provider significantly faster than if you had to rewrite your entire IaC (Infrastructure as Code) layer.

### [Translate Heroku Procfiles to service definitions | Upsun](https://upsun.com/blog/translating-procfiles-to-service-definitions/)

# Translating Procfiles to Service Definitions

**How do you translate a Heroku Procfile to Upsun service definitions?**

Translating a Heroku Procfile to Upsun involves mapping "process types" (web, worker, cron) to separate application blocks within a `.upsun/config.yaml` file. While Heroku uses a Procfile and buildpacks to define runtime commands, Upsun uses a declarative YAML structure to define runtimes, build hooks, and explicit service relationships (like PostgreSQL or Redis). This shift moves the application from process-based scaling (Dynos) to resource-based containerization, providing more granular control over CPU and RAM.

### I. Mapping process types to application definitions

_Key takeaway: Migrating from a Procfile requires re-declaring process types as isolated application containers for better resource efficiency._

In a Heroku Procfile, you might see a simple line like `web: bundle exec rails server`. On Upsun, this logic is moved into the `.upsun/config.yaml`. This isn't just a syntax change. It’s an architectural upgrade.

1.  **From Dynos to Runtimes:** Instead of generic "Dynos," you specify the exact runtime (e.g., `nodejs:22` or `python:3.12`).
2.  **Explicit Web Commands:** The `web` process from your Procfile becomes the `web.commands.start` instruction in Upsun.
3.  **Worker Isolation:** Background workers (like Sidekiq or Celery) are defined as separate application instances, allowing you to scale their CPU and RAM independently from your web traffic.

### II. Translating buildpacks into build hooks

_Key takeaway: Moving away from "black box" buildpacks to explicit build hooks ensures faster, reproducible deployments._

One of the biggest friction points in migration is the "magic" of buildpacks. Upsun replaces this with transparent Build and Deploy Hooks.

-   **The Mechanism:** Your `.upsun/config.yaml` defines a `hooks.build` section where you explicitly run `npm install` or `composer install`.
-   **Benefit:** This eliminates the "Buildpack search" overhead and allows you to use Instant Data-Complete Preview Environments to verify that your build logic works perfectly before it hits production.
-   **Tooling:** For those with complex legacy setups, tools like upshelf can help automate the initial discovery of these dependencies.

### III. Strategic Logic: From "Units" to "Relationships"

_Key takeaway: Explicit service relationships in .upsun/config.yaml prevent the "silent failure" common in legacy PaaS migrations._

In Heroku, database connections are often managed via invisible environment variables. Upsun requires you to define a `relationship` between your application and its services (e.g., a PostgreSQL or Redis service).

-   **Information Gain:** This "Explicit Relationship" model is what allows Upsun to be cloud-agnostic. Whether the project is created on AWS or GCP, the platform knows exactly how to wire the network between your app and your database.
-   **Portability:** Because you aren't relying on a specific provider's "Add-on" API, your application becomes a portable container that can move between cloud providers without changing a single line of your Procfile-replacement logic.

### Frequently asked questions (FAQ)

**Does Upsun support multiple Procfile-style processes in one project?**

Yes. You can define multiple applications within a single project directory. Each one can have its own resource profile (CPU/RAM) and its own scaling rules, allowing you to mirror a complex Heroku setup with much higher efficiency.

**How do I handle environment variables during migration?**

Variables that were previously in the Heroku "Config Vars" UI can be managed via the Upsun CLI or console. However, service credentials (like database URLs) should never be hardcoded; they are injected automatically via the `relationships` defined in your `.upsun/config.yaml`.

**Can I still use Buildpacks on Upsun?**

While Upsun prefers explicit runtime definitions for performance and clarity, the platform is designed to handle standard containerization logic. Most teams find that moving to explicit `hooks` in `.upsun/config.yaml` significantly reduces build times and "magic" errors.

### [What is resource-based cloud scaling? | Upsun](https://upsun.com/blog/resource-based-cloud-scaling/)

# What is resource-based cloud scaling?

Resource-based cloud scaling is a provision-based infrastructure model that allows developers to allocate precise CPU and RAM to individual services. Upsun utilizes this model to eliminate "resource stranding" and "bill shock" by ensuring that only user-defined resources are provisioned. Unlike elastic platforms where spikes in usage lead to unpredictable costs, Upsun provides granular vertical scaling control through the Console, ensuring performance matches the budget exactly.

## I. The problem with "Unit-Based" and "Elastic" scaling

_Key takeaway: Upsun eliminates the "inefficiency tax" of fixed tiers and the "surprise tax" of unmanaged elastic scaling._

In traditional cloud models, teams face two financial risks:

1.  **Fixed-Tier Inefficiency:** Traditional PaaS models (Dynos) force you into rigid tiers. If your Go application needs more RAM but no extra CPU, you are still forced to pay for a higher tier, resulting in Vertical Waste.
2.  **Elastic Bill Shock:** "Serverless" or elastic models scale automatically based on usage. While convenient, a traffic spike or DDoS attack can result in catastrophic, unmanaged cloud bills.

**To achieve predictable performance, Upsun provides:**

-   **Manual Precision:** You define the exact resources needed for your Upsun project.
-   **No Unrequested Provisioning:** Upsun will not provision additional resources without a specific request or pre-defined parameter change.
-   **Cost Stability:** Your bill is tied to your .upsun/config.yaml settings, not to a sudden surge in site traffic.

## II. The "Middle Path": Provision-based vertical scaling

_Key takeaway: Upsun allows architects to optimize service profiles—like memory-intensive caches or compute-heavy workers, without over-paying for unused cycles._

The Upsun "Middle Path" provides the automation of a PaaS with the financial control of IaaS. You manage your resources at the service level, ensuring that your Instant Data-Complete Preview Environments are as cost-efficient as your production stack is robust.

-   **The Mechanism:** Instead of picking a "tier," you define the resource profile in the .upsun/config.yaml. For example, a worker process can be assigned a specific 0.5 CPU to 4GB RAM ratio.
-   **Granularity:** Scaling is handled in precise increments. This "Right-Sizing" ensures you aren't over-provisioning just to meet a "standard plan" requirement.
-   **Predictable Auto-scaling:** Even when using auto-scaling, Upsun stays within the strict parameters defined by the user. You retain control over the ceiling of your cloud spend.

## III. Strategic TCO: Legacy PaaS vs. Elastic IaaS vs. Upsun

_Key takeaway: Upsun provides a managed platform experience where the user, not the traffic, controls the provisioned resource spend._

## Frequently asked questions (FAQ)

**Is Upsun's scaling harder to manage than "Auto-scaling"?**

No. Upsun simply requires you to be intentional. You define your resource needs via the platform, and Upsun handles the orchestration. This prevents the "bill shock" common in fully elastic environments where a simple configuration error can lead to thousands of dollars in unexpected charges.

**Can I downscale resources for my Upsun preview environments?**

Yes. This is a core advantage. Unlike competitors that force the same "plan" on all environments, Upsun allows you to provision minimal resources for your Instant Data-Complete Preview Environments through the management console, significantly reducing your total development TCO.

**How does provision-based scaling help with FinOps?**

It makes cloud forecasting simple. Since Upsun will not provision resources without a user-initiated request, your monthly spend is a direct reflection of your provisioned environments. This provides the transparency needed for enterprise-level budget management.

### [The paved road to production | Upsun](https://upsun.com/blog/paved-road-internal-developer-platforms/)

# The paved road to production: what good internal developer platforms look like

### **The adoption gap: why most IDPs fail**

When was the last time you asked a developer if they actually use the platform you built for them, or whether they’ve found a faster way around it?

We talk with companies every day who deal with this exact scenario.  They spend months or even years building their IDP.  Then a new project requires a stack or workflow that the IDP doesn’t support.  The developer is under pressure to deliver, so they spin up their own solution. 

This is why most IDPs fail quietly. The failure doesn't usually look like a system outage; it looks like a surge in Shadow IT. When a developer has to navigate thousands of lines of configuration, master secondary toolchains, and raise tickets just to spin up a staging environment, they will inevitably find a shortcut.

In the high-stakes environment of 2026, where velocity is a competitive mandate, a platform that requires manual intervention is a bottleneck, not an asset.

### **I. The "paved road" vs. the "golden cage"**

_Key takeaway: Platform engineering is only successful if it creates a "paved road": a frictionless path from code to production that enforces governance without slowing down the contributor. If your road is too rigid, it becomes a "golden cage" that developers will work to escape._

A useful platform gets out of the developer's way by making infrastructure operationally invisible. The standard should be simple: a developer should be able to create a production-identical environment directly from a Git branch without:

-   **Raising a ticket:** Provisioning should be an automated side effect of code branching.
-   **Reading documentation:** The path to production should be intuitive and driven by the tools developers already use (like Git).
-   **Learning new tooling:** Developers should focus on application logic, not mastering complex infrastructure primitives.

### **II. Making infrastructure operationally invisible**

_Key Takeaway: By standardizing on a unified configuration file, the entire application stack is defined as a portable contract. This allows the platform to automate the lower-level heavy lifting of environment management, making the infrastructure a background task rather than a manual chore._

Upsun is built on the principle that the developer’s primary interface should be their code. This creates a self-service model where the platform responds to Git commands:

-   **Preview environment:** Every time a developer branches code, Upsun automatically branches the infrastructure, creating a "production-perfect" preview environment.
-   **Byte-for-byte:** These environments are exact replicas of the production setup, including databases and services, eliminating "it worked in dev" bugs.
-   **Managed services:** Services like Postgres and Redis are provisioned as isolated containers within the same perimeter, managed by the platform rather than the developer.

### **III. Reclaiming the "DevOps tax"**

_Key takeaway: An effective IDP provides an "innovation refund" by eliminating the hidden cost of engineering time spent on manual toil. By shifting environment orchestration to a self-service model, you redirect your most expensive talent back to building revenue-generating features._

For the Head of Platform Engineering, a good IDP automates the undifferentiated heavy lifting of the delivery pipeline:

-   **Self-service data:** Developers can clone and sanitize production datasets for testing without opening a DBA ticket.
-   **Zero-ticket provisioning:** Scaling resources for a campaign or adding a new service becomes a simple configuration change in the YAML file.
-   **Reduced cognitive load:** By moving governance to the platform layer, developers are free to focus on product velocity.

### **IV. The strategic advantage: velocity as a service**

_Key takeaway: In 2026, the only true metric of a platform's success is its adoption rate. Modern IDPs allow teams to move from maintenance mode to market leadership by ensuring the right way to deploy is also the most frictionless path for the developer._

-   **Legacy platforms:** Require constant manual evidence collection, ticket queues, and infrastructure maintenance.
-   **Modern IDPs:** Standardize on a paved road to solve the velocity problem.

You reclaim your engineering roadmap by letting the platform handle the heavy lifting of orchestration.

### **Frequently asked questions (FAQ)**

**What is a "paved road" in platform engineering?**

It is a frictionless, pre-configured path that allows developers to get their code into production quickly and safely, with all necessary security and compliance measures built-in.

**How does an IDP prevent Shadow IT?**

Developers use Shadow IT when the official tools are too slow. An IDP prevents this by providing instant, self-service tools that are faster and more reliable than any unsanctioned workaround.

**What is the role of the unified configuration file?**

It is the single source of truth for your application's infrastructure. By defining everything in code, you ensure that every environment is reproducible, traceable, and version-controlled.

**Why is environment parity critical for an IDP?**

Without byte-level parity between dev, staging, and production, teams lose time fixing bugs caused by infrastructure differences rather than code errors. Parity ensures reality-based testing.

**Does this mean we don't need a DevOps team?**

No. It means your DevOps or Platform team stops doing "TicketOps" (manual tasks) and starts doing "ProductOps", building and improving the platform to provide even more value to the developers.

### [What is PaaS? Platform-as-a-Service explained | Upsun](https://upsun.com/blog/paas/)

# What is a PaaS? A definitive guide

A platform as a service (PaaS), also known as an application platform as a service (aPaaS) or cloud application platform (CAP), is one of the three major cloud computing service models. In our opinion,  it’s the only one that successfully delivers all benefits of the cloud to software developers, including control, cost-effectiveness, flexibility, and scalability.

Of course, other as-a-service models are still useful. In fact, all three main cloud computing models offer different advantages to organizations.

Software as a Service, or SaaS, gives you ready-made applications. It’s a popular choice for growth-focused startups, mid-market and enterprise companies, and teams with little to no software development knowledge. On the other hand, Infrastructure as a Service, or IaaS, can be advantageous for those who want more administrative control.  

However, for those who wish to streamline developer workflows, deliver products faster, and lower operational costs (all while enriching customization), a PaaS is the way to go. We’ll tell you why.

### **An overview of platform as a service**

The PaaS cloud computing model has several primary use cases. The most common are: 

-   **As an** **application development platform.** Thanks to integrated languages, frameworks and services, developers can use a PaaS to develop, customize, and upgrade cloud-based applications, websites and APIs (application programming interfaces).
-   **For agile development and DevOps.** A  PaaS is an alternative to DIY Kubernetes. It provides fully configured environments that automate software application lifecycles and management and creates agile development workflows.
-   **For analytics and business intelligence (BI).** A PaaS often comes equipped with tools that facilitate data analysis and mining. Teams can use this data to identify patterns, anomalies, and trends that drive strategic business decisions.
-   **For hosting and infrastructure.** Developers don’t have to worry about storage, servers, or any other kind of infrastructure with a PaaS. All of these elements are handled by the provider. Nothing needs to be manually set up, you only need to write your code.

But what is a Platform as a Service exactly, and how does it compare to SaaS?

### **What is a PaaS in cloud computing?**

A PaaS is a cloud computing model where a third-party host provides a business with a complete development and deployment platform. It supplies everything necessary for the development and delivery of web applications, automating the whole pipeline.

These resources enable developers to develop, deploy, and manage everything from simple, small-scale applications or websites to advanced and highly customized experiences. 

A PaaS can support the entire development lifecycle, from building and testing to the continuous maintenance and updating of applications. This can help clients avoid the expense, inflexibility, and labor-intensiveness of installing and maintaining resources.

In other words, PaaS providers such as Upsun build a platform so you don’t have to. They take on the associated costs, time, and risk—all while shouldering the responsibility of ensuring your app or site is available and a working infrastructure is maintained.

### **PaaS, IaaS, and SaaS**

So, now you have an idea of what a PaaS is and how it works, but how does it compare to the two other main cloud computing models on the market: IaaS and SaaS?

#### IaaS

Infrastructure as a Service (IaaS) provides businesses with the backend IT resources they need (networks, servers, and storage) to manage workloads in the cloud.   

IaaS provides a general data center for storage and dynamic scaling capabilities. It can support volatile or evolving applications, and it’s a viable solution for businesses experiencing unpredictable or rapid growth but lacking the finances to invest in backend IT hardware. 

Like other as-a-service models, it’s a good choice for companies looking to migrate away from the labor intensity of maintaining on-premise resources.  

However, IaaS is the most demanding of these three models. It only delivers infrastructure, leaving you responsible for operating systems, applications, middleware tools, and runtime. Plus, there’s no automation. Even for the most capable teams, this can be a significant drain on labor costs and productivity. 

So, if you opt for IaaS exclusively, it should only be because your business goals require extremely high levels of administrative control.

#### SaaS

Software as a Service (SaaS) refers to a model in which third parties build applications and deliver them to buyers via the internet as either a web application or a downloadable app.

With no restrictions on device or location, SaaS is incredibly popular with global and remote teams. Applications are painless to set up independently and facilitate collaborative working.   

Delivering feature-rich, ready-made applications for everything from email, office, and video conferencing to tax and project management, the productivity, workflow, and time-to-value benefits of SaaS are plentiful. 

However, SaaS’s ease of use and efficiency come at a cost. Not only do you have no administrative control, but SaaS offers very little in the way of customizability. Its integration capabilities also remain limited.   

It’s also vital to remember that just because you use a piece of software, it doesn’t mean you own it. The SaaS provider has complete ownership of the system and your overall control of everything - including data - is severely limited. 

If you want any degree of control over your application, either PaaS or IaaS would be a better fit.

#### PaaS

So, how does a PaaS compare to the other as-a-service models?  

A PaaS sits in the center of the cloud computing stack, acting as a middle-ground between IaaS and SaaS. It delivers the customization and flexibility of IaaS but streamlines workflows and improves time-to-market in a similar way to SaaS.   

As a result, DevOps teams can maximize their productivity. Unlike IaaS clients, they’re freed from the burden of OS management, software patching, load balancing, and other tasks. But they can also innovate, which is something SaaS clients can’t do.  

### **Benefits of a PaaS: From cost-efficiency to scalability**

Curious to know what using a PaaS in cloud computing can do for your business? Then let’s explore some of the most valuable benefits, starting with a favorite: scalability. 

#### Scalability

Some platforms require you to anticipate growth and scale up by buying expensive additional tooling. But if you don’t achieve that sustainable growth you expected, you end up with idle resources that drain cash flows and productivity, and that can seriously limit your operative productivity and reduce your bottom line.  

With a PaaS, you can purchase additional resources as you experience traffic spikes and deploy these for immediate effectiveness. If your traffic drops again, you can automatically scale back down with zero hassle.

Moreover, a PaaS allows this scalability to be applied across multiple apps and websites when needed. Multi-app scaling makes using a PaaS particularly efficient for businesses with several apps or a fleet of websites.

#### End-to-end cost-efficiency

Hosting requires significant capital investment into multiple resources. PaaS consolidates these resources and delivers them via one pay-as-you-grow model, meaning that start-ups and small businesses can forgo the expenses that come with building their own platform.

While IaaS is also cost-effective, it can generate unexpected costs if you’re not careful.

But unlike IaaS, PaaS providers handle maintenance, security patches, and updates, which reduces labor costs and other expenses that can creep up, like tooling costs. 

####  **Improved productivity and time efficiency**

Having immediate access to a fully equipped development environment empowers developers to build high-quality applications faster and more reliably. Without the need to build, install, and configure a backend infrastructure, your developers can seamlessly integrate with the development environment.

This enables them to get started straight away, speeding up your time-to-market.

#### Greater flexibility

Developers can access the shared software development environment from any location, improving remote working accessibility and collaborative productivity. 

#### No vendor lock-in

Advanced PaaS providers are cloud-agnostic solutions. Upsun, for example, is a multi-cloud option that uses open-source software to allow teams to migrate and operate workloads to different vendors without needing to undergo refactoring.

#### Built-in security and compliance

Abiding by strict security, privacy, and compliance requirements is a struggle with on-premise and even IaaS solutions. PaaS providers relieve you of this labor-intensive task by providing built-in security and compliance features across your cloud environment. 

Armed with compliance certifications, encryptions, access controls, patching, updates, and a host of other security measures, you can achieve reliable technical and organizational-level security.

### **Key PaaS solutions to consider**

So, what should you look for in a modern cloud Platform-as-a-Service solution? While your needs will vary depending on your business, there are a few essential features to look out for. 

#### Design, testing, and development tools

First and foremost, look at the development tools offered by the PaaS provider. As a rule, it should provide an integrated toolchain of all the essential tools you need to successfully build an application, including a source code editor, debugger, and compiler. 

#### Observability

Optimal performance and user experience for your websites and applications are crucial. The observability tools offered by a PaaS provider should give you actionable insights to improve your code and supply comprehensive performance monitoring. They should provide you with a real-time view of your resource usage and offer flexible scaling. 

#### Security and compliance

Your PaaS solution must help you keep your website or application safe, secure, and available at all times. It should offer protection from cyberattacks and comply with the numerous data security and privacy standards worldwide. Consider how your prospective provider handles data retention and backups and recoveries. Make sure your chosen solution takes security and compliance as seriously as you do.

#### Databases

A PaaS should have centralized database management capabilities and tools. It also allows developers to create, query, and maintain databases.

#### Infrastructure

A PaaS should have the same infrastructure offerings as IaaS: supplying and maintaining storage, servers, and network components. 

## Real customer wins

Developers love the platform for being able to launch apps and focus more on code. We handle infrastructure, scaling, and deployment. Here's what two teams have done with us.

### Open Strategy Partners: AI search with managed databases

Open Strategy Partners (OSP) runs its AI search system on our managed databases. Robert Douglass, their Entrepreneur in Residence, built a system with PostgreSQL, PGVector, ElasticSearch, and OpenSearch. While we maintain the databases, the OSP team can focus on what they do best - optimizing AI models for B2B tech clients. Their dev team values quick version testing and cost savings through shared dev environment resources.

### Witty Works: AI-augmented DEI language assistant

When Witty Works moved their DEI language assistant to Upsun, the results spoke for themselves. "We now scale on demand and deploy 60 times monthly through our automated GitOps pipeline - something we couldn't do before," says Marina Ziegler, Lead Developer.

The numbers tell the story: HR teams at Deutsche Bahn and Swiss Life now write inclusive job posts 60% faster. Marketing teams create content 57% quicker. Best of all? Companies see 20% more applications from diverse candidates. As Marina puts it: "We help build inclusive workplaces through better language. Upsun makes it happen."

### **Scale your apps with a preferred PaaS**

Effortlessly develop, deploy, and scale your enterprise-grade websites and applications with Upsun—a unified and secure multi-cloud scalable PaaS.  

We believe it’s critical for companies to develop agile fitness in fast-paced business climate. We offer robust PaaS protection, future-proofing your enterprise in the face of uncertainty.

Along with a fully-built infrastructure, our solution handles everything from data management to provisioning, auto-scaling, testing, observability, and security. 

Unlike many other PaaS providers, Upsun is a polyglot, multi-cloud platform. We support various frameworks and programming languages, so you can build exactly how you want.  PHP? Java? Go? Ruby? Django? If you can name it, you can build with it.

In fact, Gartner has recognized Upsun (formerly Platform.sh) in the prestigious Gartner Magic Quadrant for Cloud Application Platforms. Read the full announcement here.

Eliminating the need to build and manage infrastructure allows you to leverage faster deployment, sustainable scaling, and innovative, collaborative development. Instead of worrying about infrastructure, your developers can concentrate on what matters most—creating incredible applications that meet your customers’ needs. 

### Useful links

-   PaaS Pricing calculator - Estimate your costs

### [Upsun Dispatch™ is now open for prerelease](https://upsun.com/blog/upsun-dispatch-early-access/)

# Upsun Dispatch™ is available in prerelease

When we introduced Upsun Dispatch™ last week, we said we were building the platform layer for everything around the code. Today, you can **apply to join** as a founding design partner.

Starting July 1, 2026, a number of engineering organizations will join us in prerelease. This is a selective, high-touch collaboration with teams who want to help shape what comes next.

If you missed the introduction, you can catch up on Upsun Dispatch **here**.

## What the founding cohort is

This is not a beta program in the traditional sense. We’re not asking you to file bug reports in exchange for free access. We’re asking you to help us build Upsun Dispatch so teams can work faster and smarter.

We are looking for engineering teams already running AI workflows and hitting the limits of what individual tools can do. As a design partner, your team will influence which workflows get shipped, how the product handles scale, and where it needs to go deeper. 

Answers and insights will come from the organizations using the product in real conditions, in real everyday workflows.

In return, design partners get direct access to the core engineering and product team, real input on the product roadmap, and charter commercial terms that reflect a genuine partnership rather than a vendor relationship. 

## What prerelease actually means

Upsun Dispatch is set for public launch in September 2026. By then, the product will have been shaped by months of real usage, real feedback, and real design decisions.

The teams joining now will make those decisions with us. How human gates work by default. What the audit trail shows a security lead versus a CTO. These are the burning questions we’re hearing right now. Together, we’ll find the answers with the cohort.

## Upsun as the foundation

For the last 10 years Upsun (formerly Platform.sh) has been running production infrastructure for thousands of global customers. We took the same container primitives, the same infrastructure standards, and applied them to the agent workflow problem. 

## How to join

To move past individual AI tools and help build what comes next, apply for access at **upsun.com/dispatch**.

The cohort opens July 1. We welcome you to be part of what’s next.

### [Crafting a microservice that fits your needs | Upsun](https://upsun.com/blog/crafting-a-microservice-that-fits-your-needs/)

# Crafting a microservice that fits your needs

_This blog is based on Haylee Millar's talk at the Symfony 2024 conference. Haley is a Product Engineer at Upsun. We utilized AI tools for transcription and to enhance the structure and clarity of the content._

When faced with an aging system that needs new features, many development teams find themselves at a crossroads. Do you patch the old system and risk technical debt, or do you take the leap into microservices architecture? This is the story of how one team made that decision and what they learned along the way.

## What is a microservice?

A microservice is an independent service that talks to other services over APIs. Each service is loosely coupled and can be built, deployed, and scaled on its own. It does not have to own a database, but many do. The key is separation, so that one service can be changed without forcing changes across the entire app.

Think of it like a restaurant kitchen. In a monolithic approach, one chef handles everything – appetizers, main courses, desserts, and beverages. With microservices, you have specialized stations: a salad chef, a grill master, a pastry chef, and a bartender, each expert in their domain but coordinating to serve complete meals.

### Pros

-   **Scalability:** Add resources to services as needed, rather than scaling the entire app.
-   **Speed:** Smaller codebases facilitate faster development and deployment.
-   **Technology freedom:** Pick the stack that fits each service. You do not have to use the same language or framework everywhere.
-   **Failure isolation:** One service can fail gracefully without taking down the entire application. You can degrade performance rather than go offline.

### Cons

-   **Complexity:** More services mean more moving parts. Network calls replace in-process calls. Data may reside in more than one location, which makes consistency more challenging.
-   **Debugging:** It can be challenging to pinpoint the source of a problem in a distributed system. Strong logging, request IDs, and distributed tracing help.
-   **Security surface:** More services and more network paths mean more to secure.

## When to choose microservices

Microservices can be a suitable fit when multiple teams require autonomy, when different features evolve at varying speeds, and when you need independent development, deployment, and scaling for specific parts of the application. They are not the only answer. There are usually several ways to solve a problem. Select the approach that best suits your needs and constraints.

## The real problem we had to solve

Our team owns account management. We were running an internal site built on a Drupal monolith. We planned to retire it, but we had an immediate issue to solve: user abuse on the product.

We could have added new anti-abuse features to the Drupal app. We chose not to. Reasons:

-   We did not want to add weight to a system we planned to retire.
-   We wanted to move quickly without being constrained by Drupal-specific requirements.
-   We already had services outside of Drupal that integrated with it, like authentication and organizations.

We proposed a new microservice for implementing anti-abuse logic. It became the popular path in our discussions.

## The service we built: KYC

We created a Symfony microservice called Know Your Customer (KYC). KYC checks customer identity and risk. We started deliberately small so we could ship quickly and learn.

### **Starting small and smart**

We focused on five building blocks:

-   User data sync ensured the service had the necessary facts.
-   A user score endpoint for the support team.
-   Staff verification endpoint and the ability to block a user if abuse is detected.
-   Grant lists to let internal staff test and bypass when needed.

We kept ownership clear. KYC calculated a score, but it did not decide to limit resources. Our accounts service pulled the KYC score and decided whether to continue or halt a user action.

### **The stack and tools choices**

-   PHP with Symfony framework, so we could focus on logic rather than writing everything from scratch.
-   PHPUnit for testing.
-   GitLab CI/CD for continuous integration, delivery, and automatic deployment.
-   A scheduler for sync jobs and grant lists.  
    Common bundles and libraries: JOSE framework, LexikJWTAuthenticationBundle for JWT, CORS, Doctrine, and Doctrine Migrations.

From version 1.7 onward, we added Symfony Messenger to sync IP scores from an external service.

### **Hosting and workflow**

We hosted the service on our platform since we are a platform-as-a-service company. For teams curious about deploying Symfony, we demonstrated how to set up a demo app using the Symfony command line and how to initialize an existing project, add the necessary files, and deploy.

## How it evolved

We finalized the KYC design in **June 2022**. It took approximately **six months** to implement after the stakeholder agreement was reached. Since then, we have kept a steady release pace. At the time of the talk, we were at **version 2.23**.

What changed between 1.0 and 2.23:

-   More score types: overall risk, known customer, free trials, and testing.
-   Payment profiles that help decide which payment methods to allow.
-   External risk checks for IP and payment method.
-   Early steps toward machine learning.
-   Ongoing work to make the user score logic richer.

## What worked well

-   **Fast iteration:** KYC is a small service and not part of the monolith, allowing us to release quickly. We can push multiple releases in a day without risking the entire application.
-   **More features sooner:** The speed enables us to add useful features for the support team and steadily improve the scoring logic.
-   **Up-to-date stack:** Symfony and PHP stay current without being tied to an older system we plan to retire.
-   **Resource savings:** Faster development and targeted scaling result in time and cost savings.

## The challenges

-   **Data sync:** Keeping data in sync with the source of truth requires careful work.
-   **Complexity for support:** A new service introduces new paths for ticket management. Support now handles cases where users are blocked, which changes workflows.
-   **Distributed System Overhead**: Managing multiple services introduced operational overhead that didn't exist with the monolithic system.

## Q&A highlights

**Which tools helped most for microservices?**  
The biggest win was choosing Symfony. It is lightweight and modular, and we are already familiar with PHP. The bundles provided us with the building blocks we needed without requiring heavy custom tooling.

**Do you version your API endpoints, such as/v1 and /v2?**  
We have not done that so far, but it is a good idea to consider.

**How did you handle privacy?**  
We avoid storing personal data in KYC when it is not necessary. Instead, we use unique IDs to look up personal information in the accounts service when required. During sync, we ensure that we only move what is necessary.

**Do you share code across Symfony projects?**  
Not today. We started simple with the standard bundles. Shared packages could make sense later if the need grows.

**What about the Drupal monolith?**  
It still exists. We are moving in steps. You cannot rewrite everything at once. We piece out parts and reimplement them in a more modular way. Where possible, we seek existing products rather than developing everything from scratch.

**How did you handle external service sync and uptime?**  
Keeping user data up to date was the primary challenge. We added refresh logic and ensured that scores are calculated as soon as accounts are created. We use a syncing worker and an asynchronous path behind it, allowing us to cope when a score is not available immediately.

## Takeaways you can use

-   Start small. A thin slice with clear ownership can deliver value quickly.
-   Keep the decision point close to the domain. Let scoring reside in one service and enforcement reside in another, if that fits your architecture.
-   Invest in logs, request IDs, and tracing early. They pay off the first time a cross-service bug appears.
-   Plan for sync. Know your source of truth and design refresh paths from day one.
-   Expect some support change. New services often alter the flow of tickets.

Microservices are not magic. They are one way to move faster when teams need autonomy and parts of your system change at different speeds. For us, carving out KYC as a microservice allowed us to ship anti-abuse features quickly, keep our stack current, and avoid adding weight to a monolith that we plan to retire.

### [Easypara and Dn’D 30-day migration success | Upsun](https://upsun.com/blog/easypara-dnd-30-day-infrastructure-migration/)

# How Easypara, Dn’D & Upsun delivered a 30‑day infrastructure migration

Short on time? Watch the 5-minute executive summary right here—or scroll to the bottom when you’re ready for the full 40-minute deep-dive webinar.

When your e‑commerce site is the leading online parapharmacy in France, every minute of downtime stings. For Easypara, the pain became acute after its upgrade from Magento 1 to Magento 2: the legacy, self‑hosted infrastructure simply could not keep up, leading to frequent incidents and unacceptable outages.

What follows is the inside story told during our recent French‑language webinar of how Easypara, digital agency Dn’D and cloud platform provider Upsun (the new brand for Platform.sh) rallied around an ambitious 30‑day deadline, executed a seamless migration in the middle of summer holidays, and built a partnership that continues to drive innovation today.

## 1\. The tipping point: outages after the Magento 2 upgrade

Isabelle Sarrazin, CEO at Easypara, opened the conversation by recalling the “trigger event” in late 2022:

-   **Frequent downtime** after the Magento 2 launch was hurting revenue and brand trust.
-   Root causes ranged from technical complexity to missing incident‑response procedures.
-   A decisive change was non‑negotiable.

> “We had significant periods of unavailability. That accelerated our search for a partner who could guarantee stability and performance.” — **Isabelle Sarrazin**

## 2\. Choosing the right allies

Easypara began scouting for solutions in early 2023. Two key factors shaped their choice:

1.  **An existing Upsun ↔ Dn’D alliance**  
    _Dn’D_ was already an Upsun Solution Partner, bringing deep Magento expertise.
2.  **A unified, three‑party model**  
    Upsun would manage and secure the infrastructure, Dn’D would own application delivery, and Easypara’s team would focus on business growth.

> “We don’t do ping‑pong tickets. All three teams stay in sync, almost in real‑time.” — **Antoine Kociuba, Tech expert, Dn’D**

## 3\. The 30‑day challenge - during summer vacations

With incidents mounting, Easypara set an aggressive goal: **go live on Upsun in 30 days** (June → July 2023). The constraints:

-   **High traffic & large catalog** – a multi‑million‑row database, thousands of product images and invoices, numerous scheduled jobs.
-   **Summer staffing** – only one lead developer from Easypara could be dedicated full‑time.
-   **Learning curve** – Easypara’s engineers were discovering Upsun’s console, Fastly CDN, and Blackfire profiling for the first time.
-   Yet the teams delivered on time.

## 4\. Keys to success

## 5\. Results so far

Although precise numbers will be shared in a forthcoming case study, the webinar speakers highlighted:

-   **Dramatic reduction in unplanned downtime**
-   **Improved page‑load times** under peak traffic
-   **Operational peace of mind** for the Easypara IT staff, who can now focus on features instead of firefighting  
     

## 6\. Beyond the migration: a TV campaign & continuous innovation

The partnership did not stop after cut‑over. In autumn 2023, Easypara launched a national TV marketing campaign that triggered fresh traffic bursts. Upsun and Dn’D tuned the architecture in advance, proving that the collaboration model scales with the brand’s ambitions.

> “The same tri‑party approach carried us through the TV push. It shows this isn’t a one‑off project; it’s an ongoing relationship.” — **Ludiwine Fouquer, Upsun**

## 7\. What’s next?

-   **Enhanced observability** – deeper use of Blackfire and Upsun Metrics.
-   **Feature teams on Upsun** – Easypara plans to adopt preview environments for every new initiative.
-   **Continued joint webinars** – Expect follow‑ups focused on performance benchmarking and campaign readiness.

### [Why Upsun is better than managed Kubernetes | Upsun](https://upsun.com/blog/managed-kubernetes-alternative/)

# Why Upsun is a better alternative to managed Kubernetes platform

In the whirlwind world of cloud computing, choosing the right platform for your development and deployment needs is like picking the perfect tool from a well-stocked toolbox. Kubernetes has made a splash, becoming the go-to choice for container orchestration. But let’s be honest, managing Kubernetes can feel like taming a wild beast. Enter Upsun. Upsun offers a fresh, user-friendly alternative to managing Kubernetes solutions. Let’s dive into why Upsun is the rockstar your team needs, and how it stacks up against heavyweights like Amazon EKS, Google GKE, Azure AKS, SuSE Rancher, and RedHat OpenShift.

### Simplified management and operations

Upsun is like having a personal assistant for your infrastructure. It’s a fully managed Platform-as-a-Service (PaaS) that takes care of the nitty-gritty, so you can focus on what you do best: building and deploying killer apps. No more sleepless nights worrying about hardware, networking, or maintenance.

Contrast this with Managed Kubernetes solutions like Amazon EKS, Google GKE, Azure AKS, SuSE Rancher, and RedHat OpenShift. While these handle some infrastructure management, you’re still left juggling setup, CI/CD pipelines, storage management, and security configurations. It’s like being handed a Swiss Army knife when all you needed was a simple screwdriver.

Upsun takes full application management even further with explicit resource allocation for each component, allowing independent scaling and efficient resource usage. This is a game-changer for projects involving decoupled and composable architectures. More on this trend? Check out Gartner’s take on composable applications.

### Enhanced security and compliance

Given the increasing complexity and risk in modern systems, security is non-negotiable. Upsun comes armed with built-in security features and compliance with standards like SOC 2, PCI DSS Level 1, and HIPAA. Automated TLS certificates, DDoS protection, multifactor authentication, and a read-only file system are just the tip of the iceberg.

Managed Kubernetes solutions offer robust security as well, but require you to roll up your sleeves. Configuring network policies, managing secrets, and ensuring secure access fall squarely on your shoulders. It’s a lot of heavy lifting, especially if you don’t have a dedicated DevOps team. For a deeper dive in this topic, see how the Cloud Native Computing Foundation addresses these complexities.

### Resource efficiency and sustainability

Upsun is designed with your wallet and the planet in mind. Upsun’s usage-based pricing means you only pay for what you use — no more, no less. Plus, you get a 3% discount for deploying to low-carbon data centers to encourage greener hosting. On the flip side, Managed Kubernetes solutions like Amazon EKS, Google GKE, and Azure AKS can lead to higher costs. The need for additional tools, resources, and continuous maintenance can quickly inflate your budget.

### Developer experience and flexibility

Upsun supports a wide array of development stacks — PHP, Node.js, Python, you name it. Its Git-driven architecture ensures every infrastructure change is versioned and auditable. It’s like having a safety net that lets you swing higher.

In addition to this, features like unlimited preview environments, detailed application performance management, and flexible resource allocation. This kind of flexibility is ideal for teams handling dynamic, complex applications.

Managed Kubernetes solutions offer flexibility but come with a steep learning curve. Setting up CI/CD pipelines, managing secrets, and configuring network policies are tasks that require significant expertise. 

### When Managed Kubernetes solutions make sense

Let’s keep it real, there are times when Managed Kubernetes solutions are the right call. For example, if your organization has highly specialized infrastructure needs or requires extensive customization, platforms like SuSE Rancher and RedHat OpenShift might be your best bet. These platforms offer comprehensive tools for enterprise-grade deployments, including advanced monitoring, logging, and security features, which can be hugely useful for certain applications.

Companies with a strong DevOps culture and the expertise to manage Kubernetes clusters may also find Managed Kubernetes solutions more aligned with their operational models. The ability to integrate deeply with existing workflows and third-party tools can be a significant advantage.

### Notable names in the Managed Kubernetes market

Here’s a quick rundown of some big players:

-   Amazon Elastic Kubernetes Service (EKS): great for running Kubernetes on AWS, but requires significant setup and integration with other AWS services. Managing EKS can be complex and time-consuming.
-   Google Kubernetes Engine (GKE): robust and scalable, but users still need to handle networking, security, and other infrastructure components.
-   Azure Kubernetes Service (AKS): offers a Managed Kubernetes service on Microsoft Azure, but requires substantial setup and integration with other Azure services.
-   SuSE Rancher: simplifies deploying and managing Kubernetes clusters with powerful multi-cluster management capabilities.
-   RedHat OpenShift: an enterprise Kubernetes platform with developer and operational tools for managing hybrid cloud and multi-cloud deployments.

### An alternative to Managed Kubernetes

Upsun offers a streamlined, efficient, and secure alternative to Managed Kubernetes solutions. It abstract away the complexities of infrastructure management, provides robust security and compliance features, and promotes resource efficiency and sustainability. This allows development teams to focus on what they do best: building and deploying innovative applications.

However, Managed Kubernetes solutions like Amazon EKS, Google GKE, Azure AKS, SuSE Rancher, and RedHat OpenShift have their place — particularly for organizations with specialized infrastructure needs and strong DevOps capabilities. The choice ultimately depends on your specific requirements and resources.

For organizations looking to reduce complexity, improve time to market, and achieve cost efficiency, Upsun is a clear winner. Embrace the future of cloud development with Upsun and experience the benefits of a truly developer-focused platform.

Learn more about how you can use Upsun, start your free trial.

### [Configuring pgvector and Postgres for RAG | Upsun](https://upsun.com/blog/configuring-pgvector-postgres-for-rag/)

# Configuring pgvector and auto-scaling Postgres for RAG

_Key takeaway: High-performance RAG requires more than just an embedding model; it requires a database that can handle vector similarity at scale. By consolidating on Upsun’s managed PostgreSQL with pgvector, you eliminate the "Egress Tax" and gain a database that scales with your agentic demand._

### The hidden cost of fragmented vector search

Many teams start their RAG journey by bolting a standalone vector database onto their existing stack. 

In 2026, this is recognized as a primary driver of the "DevOps Tax.**"** Every time your AI agent moves data between your primary database and a third-party vector store, you are paying in latency, egress costs, and "context drift."

The solution is consolidation. By using PostgreSQL with the pgvector extension on Upsun, your embeddings live in the same table as your application data. One backup strategy. One security model. One source of truth.

### I. Tuning pgvector for production-grade retrieval

_Key takeaway: For workloads under 5 million vectors, HNSW (Hierarchical Navigable Small World) indexes on a properly sized Upsun instance provide single-digit millisecond queries._

To achieve production-grade performance, the configuration of your vector index is critical. On Upsun, you have the vertical headroom to tune your database for high-dimensional search:

-   **Memory-first indexing:** HNSW indexes perform best when they fit entirely in RAM. Upsun’s resource-based pricing allows you to surgically scale the RAM of your Postgres container without being forced to over-provision CPU.
-   **Transactional consistency:** Because embeddings and metadata are in the same transaction, your AI agent never retrieves a "ghost" document that has already been deleted from your primary store, a common failure in fragmented stacks.

### II. Scaling the "Intelligence Layer"

_Key takeaway: RAG pipelines are notoriously "bursty." Upsun allows you to scale your database resources independently and surgically, ensuring your vector search remains performant during indexing spikes without overpaying for idle compute._

A sudden influx of user queries or a massive document re-indexing job can spike database load instantly. Traditional managed primitives often force you into rigid instance tiers where you pay for high CPU just to get the RAM required for vector indexing.

**Surgical scaling in action:** 

Today, you can use the Upsun CLI or console to vertically scale your postgresql instance in seconds. Because the platform allows for independent allocation of vCPU and RAM, you can provide the specific memory overhead required for heavy HNSW indexing without over-provisioning the rest of your stack. This ensures that your self-correction loops and search queries remain responsive, regardless of the data volume.

### III. Validating RAG with Byte-level Clones

_Key takeaway: You should never test a new HNSW index or a schema migration in production. Upsun’s byte-level clones provide the only safe proving ground for RAG._

As discussed in The data context gap: why agents fail on fragmented stacks, the greatest risk to a RAG pipeline is the "Reality Gap."

-   **Production-parallel testing:** Before deploying a new embedding model or a change to your `vector_cosine_ops`, Upsun creates a data-complete preview. This is a 1:1 clone of your production data.
-   **Performance grounding:** You can benchmark the latency of your new vector index against the actual scale of your production data. If an AI agent suggests an unoptimized search query, you’ll catch the performance hit in the preview environment, not the live site.

### Optimize your RAG pipeline today

Don't let fragmented infrastructure be the reason your AI fails. By consolidating your vector and relational data on a platform designed for environment parity, you reclaim the innovation budget wasted on infrastructure plumbing.

**Future-proof your data strategy:**

-   **Consolidate your stack:** Enable pgvector on your managed postgresql instance today.
-   **Eliminate the egress tax:** Keep your embeddings and your app in a unified cluster to remove latency and hidden fees.
-   **Bridge the reality gap:** Read our piece on the data context gap: why AI agents fail without environment parity to see how to eliminate hallucinations at the infrastructure level.

### **Frequently Asked Questions (FAQ)**

**Doesn't cloning production data violate privacy regulations like GDPR?** 

It would if you cloned it blindly. Upsun allows you to define sanitization hooks in your deployment pipeline. The moment a branch is created, a byte-level clone is made, and a sanitization script (e.g., masking emails or stripping PII) runs automatically before any developer or AI agent gains access. You get the _shape_ and _scale_ of production data without the compliance risk.

**Does cloning a 500GB database for every branch explode our storage costs?** 

No. Upsun uses Copy-on-Write technology. When you clone an environment, you aren't physically duplicating 500GB of data. You are creating a "virtual" pointer to the existing data blocks. You only pay for the _changes_ (diffs) made within that specific branch. This makes "Data-Complete Previews" economically viable even for massive datasets.

**Will running an AI agent against a clone slow down our live production site?** 

Not at all. Because the clone is a logically isolated environment with its own dedicated resources, the AI agent can run heavy queries, re-index vector stores, or execute complex migrations without consuming a single CPU cycle from your production cluster.

**How is this different from a traditional "Staging" database?** 

Traditional staging is a "shared" resource that quickly becomes a graveyard of stale data and conflicting migrations. Upsun provides Ephemeral Parity: every single Git branch gets its own unique, fresh clone. When you delete the branch, the environment (and its data) vanishes, ensuring no "Shadow Data" sprawl.

**Can AI agents actually understand the infrastructure?** 

Yes, through the Upsun MCP Server. Instead of scripting API calls, your agent can create environments, add services, and monitor deployments using natural-language commands, grounded in the live state of your Upsun project rather than guesses about how your infrastructure is shaped.

### [Building infrastructure for AI agents | Upsun](https://upsun.com/blog/infrastructure-for-ai-agents/)

# Infrastructure for AI Agents: what platform teams need to build now

### The human bottleneck in an agentic world

If an AI agent in your development workflow needed to spin up a test environment tonight, how many manual steps would stand between the request and the environment being ready?

By early 2026, AI agents have transitioned from simple code assistants to first-class platform citizens. They are running test suites, analyzing performance, and triggering deployments. However, most internal platforms were built around human patience: a developer raises a request, waits for a pipeline, checks a dashboard, and approves a merge.

When the entity making the request isn't a person, waiting 20 minutes for a staging environment isn't just an inconvenience, it's a system failure.

### I. Designing for machine-speed infrastructure

_Key takeaway: AI-driven development requires infrastructure that operates at machine speed, meaning manual approval gates and slow provisioning must be replaced by deterministic, API-driven workflows. If your platform requires a human "in the loop" for basic resource allocation, it will fail to support agentic scaling._

A lot of platforms often rely on "TicketOps", manual steps disguised as automation. To support AI agents, platform teams must build for:

-   **Zero-latency provisioning:** Agents require environments that are ready in seconds, not minutes, to maintain the iterative velocity of AI workflows.
-   **Programmatic lifecycle management:** The entire infrastructure lifecycle, provisioning, scaling, and decommissioning, must be exposed via robust APIs.
-   **Deterministic configuration:** Agents need to interact with a declarative manifest (like a YAML file) that serves as a predictable contract between code and cloud.

### II. The agentic architecture: API-first by default

_Key takeaway: A platform built for AI agents is one where infrastructure is a side effect of code, accessible entirely through Git and APIs. This allows agents to treat infrastructure as an ephemeral utility rather than a static asset._

Upsun’s architecture is natively suited for this shift because it treats the developer (or agent) interface as a programmatic one:

-   **Git-driven branching:** An agent can create a production-identical environment simply by branching a Git repository.
-   **API-first provisioning:** Every capability within the platform is accessible via API, allowing agents to request "production-like" previews, run validation tests, and execute a tear-down without manual intervention.
-   **Instant data cloning:** Agents can work with real-world, sanitized data, in isolated sandbox environments ensuring their architectural or code changes are validated against production reality without the chance of affecting production.

### III. Moving beyond "self-healing" to "self-architecture"

_Key takeaway: The role of the platform team is shifting from managing individual infrastructure requests to building the high-level guardrails within which AI agents can autonomously optimize the application stack._

As AI agents begin to make more decisions, such as adjusting database resources or optimizing worker queues, the platform must provide the safety net:

-   **Codified guardrails:** Security policy lives in the platform itself. Build hooks reject non-compliant code before deploy, hardened images and immutable config prevent drift, and every change an agent makes is version-controlled in the unified config. The agent can move fast, but it can't move outside the rails.
-   **Automated orchestration:** The platform handles the lower-level heavy lifting (patching, networking, isolation), allowing agents and humans to focus on the high-value logic of the application.
-   **Traceable manifests:** Because the entire stack is defined in the unified configuration file, every change an agent makes is version-controlled and auditable.

### IV. Containment and recovery: assuming agents will eventually fail

_Key takeaway: Even with codified guardrails, an agent will eventually do something destructive. The question is how much damage it can do before anyone notices, and how quickly the platform can roll it back._

The agentic failure mode that should keep platform teams up at night is not the malicious agent. It is the confident, guessing agent. An autonomous coder resolving a routine credential mismatch can find an overbroad API token in an unrelated file, use it to "fix" the problem with a destructive call, and discover only afterward that the call hit production instead of staging. If backups live inside the volume that just got deleted, there is nothing to recover from. The whole sequence can finish in seconds, well below any human-in-the-loop response time.

Agent-native infrastructure has to assume this moment is coming. The platform's job is to make sure that when it arrives, the blast radius is small and the recovery path is short. Upsun's defense against this scenario is structural, not procedural:

-   **Genuine environment isolation.** Every Git branch is a fully separate environment with its own services, data, and routes. Staging and production do not share storage volumes, so an agent operating against one cannot accidentally reach into the other through a shared infrastructure handle.
-   **Backups stored separately from the primary data.** Production backups run automatically on a configurable schedule and are managed by the platform, not stored inside the volume they protect. Deleting an environment does not delete its backups. Restore is a first-class operation available via CLI or Console, and it can target a fresh non-production environment so the recovery itself can be validated before promoting to production.
-   **Git as the canonical infrastructure state.** The unified config file is the source of truth for services, runtimes, routes, and hooks. An agent that misconfigures the stack has not mutated hidden runtime state. It has made a commit, and the previous commit is one push away.

Machine-speed mistakes need machine-speed containment. After-the-fact monitoring and human reviewers cannot close a window measured in seconds. The controls have to be in the architecture: environments that are actually separate, backups that survive a destructive call, and a canonical state that can be rolled back without negotiating with anyone.

### V. The 2026 competitive mandate: operational invisibility

_Key takeaway: In an agent-native environment, the most valuable platform is the one that is operationally invisible. Success is defined by how little time an agent spends interacting with infrastructure primitives and how much time it spends delivering code._

-   **Human-centric IDPs:** Feature slow provisioning, manual ticket queues, and rigid "golden cages" that stifle autonomous agents.
-   **Agent-native platforms:** Utilize API-first, declarative paved roads that allow for the high-frequency, non-deterministic scaling patterns of AI-driven development.

Teams that continue to rely on manual workflows will find their AI initiatives bottlenecked by the very infrastructure meant to support them.

### Is your infrastructure ready for the agentic user?

The transition to AI-driven delivery isn't just about the code the agents write; it's about the infrastructure they can (or cannot) control.

**Prepare your agentic roadmap:**

1.  **Audit manual gates:** Identify every step in your pipeline that requires a human click. These are your agentic roadblocks.
2.  **API everything:** Ensure your infrastructure provisioning and lifecycle management are fully exposed via API.
3.  **Validate via branching:** Test how easily a machine-driven request can spin up an isolated, production-identical environment today.

### Frequently asked questions (FAQ)

**Why do AI agents need different infrastructure than humans?**

Agents operate with higher frequency and lower patience than humans. They require instant, programmatic access to environments to perform thousands of automated tests and iterations that would overwhelm human-centric ticketing systems.

**How does an API-first platform reduce friction for AI?**

An API-first platform allows agents to bypass dashboards and manual consoles, interacting directly with the infrastructure layer to provision what they need exactly when they need it.

**What happens to governance when agents control infrastructure?**

Governance moves from manual review to "Policy-as-Code." The platform team defines the security and budget guardrails within the manifest, and the platform automatically enforces these rules on every agentic request.

**What is the "Agentic New User"?**

This refers to a 2026 reality where the primary consumer of cloud infrastructure is no longer a human developer, but an autonomous AI agent making hundreds of architectural and deployment requests.

**Can existing Kubernetes setups support AI agents?**

While possible, the sheer complexity of managing K8s primitives often becomes a bottleneck. Standardizing on a declarative manifest like `.upsun/config.yaml` abstracts that complexity, making it easier for agents to operate safely and effectively.

### [Enterprise hosting solutions: secure, scalable & high-performance](https://upsun.com/blog/enterprise-hosting/)

# Enterprise Hosting: a solution for the ever-changing digital world

Having your websites and apps run smoothly at all times is crucial for business success, and having something go wrong can be catastrophic to your business. This success or failure rests on setting up and managing hosting, which is a complex and time-consuming process, especially if your tech team needs more experience.

With an enterprise hosting solution, everything is handled for you. You get infrastructure, management, security, scaling, and more all rolled into one. You also benefit from guaranteed uptime and dedicated support. 

Fully managed enterprise app hosting is at the top of the ladder in managed hosting solutions. For companies with high traffic volume, resource-intensive applications, and strict compliance requirements, enterprise hosting is critical to securing business continuity in the demanding, digital-first climate. 

In short, it’s a lot easier (and much more reassuring) to leave the complex stuff to an experienced expert provider. So, let’s take a closer look at enterprise hosting, its features, and how your business can benefit from a fully managed solution.

## What is enterprise hosting, and how is it different from regular hosting?

Enterprise hosting is a managed service delivering online infrastructure to large-scale organizations that depend on the web.

Along with hosting cloud-based web applications and data servers in an isolated environment, enterprise hosting provides management capabilities such as configuration, maintenance, and backup. The best providers also offer security features, scalability, and high reliability. 

The main difference between enterprise hosting and regular hosting is the scale. Enterprise hosting is designed specifically for larger sites with more complex needs. Enterprise providers typically offer greater server resources, infrastructure, and security.  

There are a few types of enterprise-managed hosting based on how much management you want to handle yourself:

**1\. Management Level Options**

-   Semi-managed hosting gives you access to dedicated server resources, but you're responsible for maintenance, security updates, and backups. This works well if you have technical staff who want control over the server environment.
-   Fully managed hosting means your provider handles all server management, security, maintenance, and backups. You focus on your business while they handle the technical work.

**2\. Infrastructure Options**

-   Dedicated servers, as the name suggests, your website or app has its own server( physical or virtual) that isn't shared with anyone else. 
-   Shared hosting means multiple websites share the same server resources (CPU, memory, storage). While more affordable, this can limit performance during traffic spikes.
-   Cloud-based hosting uses virtualized resources across multiple servers and data centers. This provides flexibility, automatic failover, and the ability to scale resources up or down as needed.

### Do you need enterprise hosting?

Any large-scale organization will need enterprise hosting to manage its app and web infrastructure. However, you might find that even small or midsize businesses need it too.

It’s not unusual for small or medium-sized business websites to generate high volumes of traffic. And sometimes, these high traffic volumes and resource demands can begin to challenge the provisions of shared hosting services. 

The last thing you want is for your website to crash under the pressure of the Black Friday/Cyber Monday sales or miss out on increased web traffic and potential revenue over Christmas because your shared server can’t handle the load.

Regardless of your business size, if your website requires reliably fast load times and guaranteed availability, enterprise hosting is a very smart choice. It will help you avoid latency, downtime, and the financial repercussions that these issues can cause.

Beyond performance, fully managed enterprise hosting services offer desirables that your business, big or small, can use to maximize operational efficiency and safety. This includes: A-list security and recovery measures, fully-maintained hardware, continuous software upgrades and patching, and 24/7 customer service support.

Let’s discuss some of these features in a little more depth. 

## Key features to look for in enterprise hosting

Enterprise hosting solutions often come with an array of features, many of which go beyond simply hosting to provide value to other business areas. As a rule, when choosing enterprise hosting, these are the features to look out for: 

**Multi-framework Support**

Choose a solution that supports multiple programming languages and frameworks.  This keeps your application future-proof without locking you into one single stack. The right tools and technologies are vital for your site or application. It doesn’t matter if you’re a beginner looking for a simple solution that allows you to manage pages in a content management system or a full-stack developer proficient in numerous coding languages. Look for a polyglot solution that supports multiple frameworks, from Django 4 to high-traffic Drupal hosting. 

Monoliths, microservices, stateless—it doesn’t matter. The best enterprise hosting services should accommodate every framework and architecture you need to succeed.

**Scalability**

Your enterprise hosting should grow with your business, handling traffic spikes and increased demand with minimal downtime or performance issues. Many providers offer automatic scaling, but this can lead to surprise bills when resources spin up unexpectedly during traffic surges or attacks. 

Ensure your enterprise hosting gives you control over scaling decisions, with transparent pricing so you know costs upfront. The best solutions provide real-time monitoring to help you understand when scaling is actually needed.

**Real-time Monitoring**

It’s crucial to keep a close eye on your website or application from development to production. The most robust enterprise hosting solutions allow you to monitor, profile, and test yours even before it is released. 

Choose a provider that offers you the tools to ensure performance and efficiency from the very beginning. Then, in production, keep track of server-side response time and memory usage. Solid enterprise hosting providers will alert you when something goes wrong or your code doesn’t behave as it should.

**Security**

 With the cyber threat landscape evolving at the same pace as cybersecurity, continuously defending your network against malicious attacks is paramount. Enterprise hosting services put security first, mitigating the risk of destructive hacking attempts and data breaches. 

Enterprise solutions come armed with a plethora of security-first features designed to protect even the most complex enterprise architectures. Security features you should look for include SSL encryption, DDoS protection, firewalls, patching, access controls, and more.

**Certifications and compliance**

 Is the enterprise hosting solution you’re considering compliant with SOC 2 Type 2? What about PCI? Does it meet location-specific or industry-specific data privacy requirements, such as GDPR and HIPAA?

This is something to look particularly closely at during your research. It’s critical for business continuity that you do everything you can to avoid the penalties of non-compliance.

**Service-level agreements (SLAs)**

Enterprise hosting providers should offer uptime guarantees that promise your website will stay online for a specific percentage of time each month. A good uptime guarantee is 99.9%, which means your site can only be down for a few minutes per month.

Also, ensure that you check for customer support availability. Enterprise providers should offer 24/7 customer support. High customer support availability means that if issues do arise, they can be fixed quickly and discreetly.

**Automated backups**

Data loss can have severe reputational and financial repercussions, so you need a solution that provides continuous and automated remote backup services. This protects your critical financial, sales, inventory, and customer data from loss. 

## Upsun's enterprise hosting solution

Upsun is a unified, polyglot, multi-cloud enterprise hosting platform. Designed for complex, high-traffic applications, we aim to infuse your business with essential elements that drive reputational and revenue prosperity. Here's how Upsun delivers on each essential enterprise hosting feature:

**Multi-framework Support**

Upsun supports 10 programming languages and 18 services, giving you flexibility to build applications your way. Whether devoted to Drupal? Enthusiastic about React? Faithful to Magento? Whatever your favorite frameworks are, you can mix and match microservices to meet intricate, future-proof business goals.

**Scalability**

You can combine vertical and horizontal scaling to optimize your system's performance, especially during high-demand periods. Adjust CPU, RAM, and instance counts through our CLI web console or API based on your specific traffic patterns and application demands. This granular control lets you match your application resources with real-time traffic patterns while maintaining cost predictability.

Our auto-scaling solution, Scalsun, is currently in beta, providing an opportunity for early adopters to shape its capabilities. As we refine this tool, you can also leverage our real-time metrics APIs to build tailored custom scaling solutions. This allows them to build custom scaling solutions tailored to your unique needs. Our support team works directly with you to help implement and optimize your scaling strategy.

**Real-time Monitoring**

Maintaining high uptime is essential for a positive user experience. Upsun contributes to application availability through robust, real-time monitoring of infrastructure health, including CPU, memory, and disk usage, to proactively address potential issues. We leverage a global network across multiple cloud providers (AWS, Azure, and Google Cloud)  to deliver performance worldwide. 

**For optimal global content delivery, you can integrate** Content Delivery Networks (CDNs) to make your apps even snappier and more accessible to users around the globe.

**Security and Compliance**

Upsun delivers enterprise-grade security with built-in features, SSL encryption, DDoS protection, firewalls, automatic security patching, and granular access controls. Beyond these protective measures, Upsun meets strict industry compliance standards. The platform has passed annual SOC 2 Type 2 for Security, Privacy, and Availability, and achieved PCI DSS Level 1 compliance across all supported cloud providers—Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). This means your business can trust that both security and regulatory requirements are handled at the platform level.

**Service-level Agreements**

Upsun guarantees 99.99% uptime (less than 5 minutes of downtime per month) with 24/7 support across five continents. This high availability reduces business risks and ensures issues are resolved quickly when they arise.

**Reliability**

Upsun ensures consistency across development, staging, and production environments through exact replicas using cluster cloning and immutable deployments. Each application component runs separately, preventing individual issues from affecting the whole system.

_That’s not all_

### Beyond the Basics

What separates good hosting from great hosting? The tools that empower your development team to that accelerate their workflow and work efficiently. Beyond our core enterprise features, Upsun offers features that modern development teams need:

**Git-driven deployments**: Every deployment is triggered by Git commits, making the process predictable and trackable.

**Instant preview environments**: Create perfect copies of your production environment instantly, complete with real data and configurations.

**Usage-based pricing**: Pay only for the resources you use, with transparent pricing that scales with your needs.

**Multi-app support**: Deploy multiple applications and services in a single project, perfect for microservice architectures.

## Take the next step

Enterprise hosting isn't just about better servers—it's about freeing your team to focus on what matters most: building great products and serving customers. When your hosting provider handles security, scaling, maintenance, and compliance, you eliminate the technical barriers that slow down growth.

The best enterprise hosting solutions adapt to your technology choices, whether that's WordPress, Express, or any framework your team prefers. What matters most is choosing a platform that delivers consistent performance, bulletproof security, and effortless scaling.

Experience the Upsun difference with a free trial. See how modern enterprise hosting can accelerate your development workflow and give you confidence in your infrastructure.

### [Best Netlify alternatives for your next project | Upsun](https://upsun.com/blog/best-netlify-alternatives/)

# Best Netlify alternatives for your next project

Netlify may be a household name in computing solutions, but it’s not the best choice for every business. Its infrastructure, pricing plans, and feature limitations might be too restrictive for some projects or developers’ preferences.

So let’s look closely at what to expect from Netlify, how popular alternatives stack up, and how to decide which platform is best for your cloud computing needs.

## Comparing cloud infrastructure platforms for deploying mobile and web applications, static sites, and more

It’s overwhelming to compare every detail across a huge number of platforms; that’s why we’re sharing a concise and direct comparison of each service. We’ll pit Netlify against 2 of the most worthy cloud computing alternatives, examining:

-   Available features: Comprehensive list of popular or notable features for each platform.
-   Available services: Not integrations — managed services. We include whether they’re 3rd party (requiring multiple subscriptions and contracts).
-   Workloads supported: The ability to support your preferred developer tools and code languages could make or break your choice of platform.
-   Cloud host providers: Who hosts each platform and what are the cloud options for end users?
-   Available geographies: From sustainability to availability, you should know where your platform’s servers are located and where your work will be deployed.
-   Security and compliance: Which tools meet the regulatory requirements for your industry when building apps, web pages, and more? How secure are they compared to alternatives?
-   Continuous integration/continuous deployment (CI/CD): Automated continuous deployment saves time, enabling your team to focus on iterative improvements.
-   Build time restrictions: Build limitations on your website or app can be time-consuming and costly, so you need to know upfront how each platform handles this. And when it comes to request timeouts, even a difference of a few seconds matters.
-   Commitment to sustainability: By 2040, data centers may account for 14% of global greenhouse gas emissions. That’s why it’s critical to know where your provider stands on sustainability.
-   Service tiers: What does scaling up from a free tier look like? Which features and functionality limitations come with each level of service?

## Netlify and alternatives at a glance

We’ll start with a full rundown of each platform, and then share a condensed table to compare these tools directly.

### Netlify

Netlify is a front-end platform living on the edge, literally. They serve static files directly at the edge without tapping servers. On the surface, that makes Netlify a decent choice to build and deploy static web projects — but there’s a lot more you should know.

**Available features:** Webhooks build triggers, Git-based deployments, global content delivery network (CDN), data unification, preview environments, visual editor asset optimization, collaboration, and atomic deployment, with add-ons for server-side analytics and metrics, customizable functions deployable as Application Programming Interface (API) endpoints, and code-free forms and submissions.

**Available services:** No managed services; you’ll have to integrate with other tools for data storage, large media management, search, and more.

**Workloads supported:** Full stack, edge functions, internet/web services, APIs, static sites, and background workers.

**Cloud host providers:** Netlify runs on Amazon Web Services (AWS).

**Available geographies:** Netlify features 70+ points of presence (POPs) globally and can deploy in 15 regions across 5 continents. Users can self-select deployments in:

-   Asia Pacific (APAC): Tokyo, Singapore, Sydney
-   North America: Central Canada, North Virginia, Ohio, North California, Oregon
-   South America: São Paulo
-   Europe: Ireland, London, and Frankfurt; Stockholm, Paris, and Milan are available through support

**Security and compliance:** Active distributed denial-of-service (DDoS) mitigation, secure code encryption, penetration testing, compliance data centers, free HTTPS certificates, single sign-on (SSO), and two-factor authentication (2FA). Compliant with:

-   System and Organization Controls 2 Type 2 (SOC 2)
-   Information Security Management 27001 (ISO 27001)
-   General Data Protection Regulation (GDPR)
-   California Consumer Privacy Act (CCPA)
-   Payment card industry self-assessment questionnaire (PCI for SAQ-A) requirements

**CI/CD:** Automatic deployment with Git hooks, command-line interface (CLI), and API.

**Build time restrictions:** Starter 300 minutes/month, Pro 25,000 minutes/month, Enterprise custom. You can buy extra build minute packs, but minutes expire each month with no rollover. You’ll hit request timeouts at 10–26 seconds, depending on your tier.

**Commitment to sustainability:** Netlify doesn’t have its own sustainability initiative, deferring to its cloud providers’ sustainability policies.

**Service tiers:** Free Tier is single-member, 1 concurrent build, 500 projects, 100GB bandwidth, and 300 minutes/month. Pro Tier offers up to 3 concurrent builds, 500 projects, 1TB bandwidth, and 25,000 minutes/month. Enterprise plans are customized.

### Upsun

Upsun is a highly customizable Platform-as-a-Service (PaaS) prioritizing ease of use, flexibility, and sustainability. Choose your repository options, then customize your project details with composable infrastructure. This customization makes Upsun one of the best Netlify alternatives: a well-rounded choice to deploy websites, apps, or any cloud computing project.

**Available features:** Built-in edge layer, 99.99% high availability, automatic scaling, persistent storage, no request timeout, exact preview environments that perfectly mimic production, instant provisioning, collaboration, complementary cron jobs, fine-tuned access controls, fast support response times, zero configuration, and Blackfire observability.

**Available services:** Upsun prioritizes in-house managed features.

-   Data and object storage (internal): Managed InfluxDB, Kafka, MariaDB/MySQL, Memcached, MongoDB, Network Storage, Oracle MySQL, PostgreSQL, Redis
-   Search (internal): Elasticsearch, OpenSearch, Solr
-   Other (internal): Headless Chrome, RabbitMQ, Varnish, Vault KMS

**Workloads supported:** Full stack, databases, web services, APIs, static sites, and background workers.

**Cloud host providers:** Multiple available regions and data centers with renewable energy sources — users choose from AWS, Google Cloud, Microsoft Azure, Orange, or OVHcloud.

**Available geographies:** 17 regions, 3 continents, 5 cloud options. Choose your site and cloud to deploy:

-   APAC: Sydney (AWS, Microsoft Azure)
-   North America: Central Washington (Azure), South Carolina (Google, 2 AWS regions), Montreal (AWS)
-   Europe: Stockholm (AWS), London (Google), Paris (OVHCloud, Azure, Orange), Frankfurt (Google), Dublin (3 AWS regions), Zurich (Google)
-   Enterprise clients can access 60+ POPs globally with managed CDNs.

**Security and compliance:** Advanced project isolation, carriage return and line feed (CRLF) injection blocking with Upsun Web Application Firewall (WAF), request smuggling header injection, response splitting, HTTP protocol enforcement, and built-in reverse proxy cache configuration for secure DDoS protection. Gaia-X member. Compliant with:

-   SOC 2 Type 2
-   GDPR
-   Canada’s Anti-Spam Legislation (CASL)
-   Germany’s Federal Data Protection Act (BDSG)
-   Personal Information Protection and Electronic Documents Act (PIPEDA)
-   Australian Privacy Act (APA)
-   Payment Card Industry Data Security Standard (PCI DSS) Level 1

**CI/CD:** Automatic deployment with Git hooks, CLI, API, and source operations (automated code updates).

**Build time restrictions:** No build time limits and no request timeouts — a major speed and performance advantage over other providers.

**Commitment to sustainability:** Upsun stands out here, too: sustainability is one of their core values. This provider offers 12x better CPU usage vs. Amazon Web Services Elastic Compute Cloud (AWS EC2). There’s even a 3% discount on resource usage when deployed to select green regions with data centers and servers powered by renewable energy.

**Service tiers:** Free Trial features unlimited users, 1 build, 2 environments, and 4.5 CPUs/12GB memory/20GB storage running concurrently. There are no fixed service tiers at Upsun. Instead, customize your plan with unlimited options using a transparent pricing calculator and only pay for the resources you use. Manage from your dashboard anytime. Everyone gets enterprise-ready service-level agreement (SLA), compliance, security, and access controls.

### Vercel

Vercel is a cloud hosting platform to create, store, and deploy front-end frameworks and static sites. It’s optimized for Next.js and is a good option for developers choosing this framework, but it may not be the ideal solution for full-stack. Vercel offers managed databases, storage, and other options like analytics — but it relies on 3rd-party tools, which can be a hassle for enterprise-level projects.

**Available features:** Automated builds, build hooks, simple rollbacks, global CDN, visual editing, Edge Network, instant rollbacks, collaboration, preview environments, and frontend observability.

**Available services:** Vercel uses 3rd-party tools for storage and other services.

-   Data and object storage (3rd party via Upstash): Managed PostgreSQL (Vercel Postgres), Redis (Vercel KV), Kafka
-   Use Vercel Blob for large file storage, Edge Config for low-latency global storage
-   3rd-party integration options for other services and features (analytics, search, etc.)

**Workloads supported:** Mainly supports Next.js and other Javascript frameworks, along with Edge functions and static websites.

**Cloud host providers:** Vercel Edge Network runs on AWS.

**Available geographies:** 18 regions, 6 continents, 1 IaaS option. Choose your site to deploy:

-   APAC: Mumbai, Hong Kong, Tokyo, Seoul, Osaka, Singapore, Sydney
-   North America: Cleveland, Washington DC, Portland Oregon, San Francisco
-   South America: São Paulo
-   Europe: Stockholm, Paris, Dublin, Frankfurt, London
-   Africa: Cape Town
-   Access 100+ POPs globally

**Security and compliance:** Hourly backups, Advanced Encryption Standard 256 (AES-256) and HTTPS Transport Layer Security (HTTPS/TLS) 1.3 data encryption, region-based failover and resiliency testing, enterprise infrastructure isolation. Compliant with:

-   SOC 2 Type 2
-   ISO 27001:2013
-   GDPR
-   PCI DSS
-   HIPAA
-   EU-US Data Privacy Framework

**CI/CD:** Automatic deployment with Git hooks, CLI, and API.

**Build time restrictions:** Free Tier is 6,000 minutes/month, Pro Tier is 24,000 minutes/month, Enterprise custom. You get 45 minutes per deployment, with request timeouts at 30 seconds.

**Commitment to sustainability:** Vercel doesn’t have its own sustainability initiative, deferring to its cloud providers’ sustainability policies.

**Service tiers:** Free (Hobby) is single member, 1 concurrent build, 200 projects, 100GB bandwidth, and 6,000 minutes/month. Pro is up to 12 concurrent builds, unlimited projects, 1TB bandwidth, and 24,000 minutes/month. Enterprise offers unlimited projects with custom options.

## Netlify alternatives comparison table

With so much to consider when looking for Netlify alternatives, it’s easy for businesses to lose sight of what’s most important. But if you’re looking for user-friendly flexibility with fewer limitations, more transparency, and a commitment to sustainability, give Upsun a try.

Which feature, detail, or quality is a non-negotiable for you when choosing PaaS tools? Leave a comment with your thoughts.

Sources: Netlify, Upsun, Vercel, AWS

### [Secure your AI agents with zero-trust sandboxes | Upsun](https://upsun.com/blog/why-your-ai-needs-a-sandbox/)

# The zero-trust agent: why your AI needs a sandbox, not a blank check

_Key takeaway: Granting AI agents unrestricted access to cloud infrastructure is an unacceptable security risk. Upsun provides a "zero-trust" framework by utilizing isolated, production-perfect preview environments that allow AI to be productive without the risk of a hallucinated production outage._

## The "blast radius" problem in AI-assisted engineering

In 2026, the primary hurdle to AI adoption is trust. You wouldn't give a junior developer root access on day one; you would give them an isolated environment and a senior engineer to review their Pull Requests. Yet, many teams are handing over production-level API tokens to LLMs that are statistically guaranteed to hallucinate.

This isn't just a security nightmare; it’s a reliability one. An agent doesn't need to be malicious to be dangerous; it just needs to be wrong about a resource limit or a service binding.

## I. Graduated trust through environment isolation

_Key takeaway: Infrastructure for the agentic era must be designed for graduated trust, where agents only earn the right to modify production state after proving logic in a version-controlled sandbox._

On Upsun, we treat governance as code. By providing a platform that handles container orchestration and isolation, we provide the "predictable world" AI agents need to be successful without infrastructure drag.

-   **Environment-level scoping:** To meet the needs of highly regulated markets, Upsun provides strict scoping for both users and agents. An agent can be restricted to a specific branch, preventing it from even "seeing" the production environment.
-   **Containerized guardrails:** Because every process on Upsun is isolated, a hallucinated "destroy" command or a resource-heavy loop is contained within a disposable preview environment.
-   **Infrastructure literacy:** Suggestions from an agent are grounded in your actual configuration (defined in `.upsun/config.yaml`), turning probabilistic guesses into deterministic actions based on your real environment.

## II. The "propose-and-test" workflow

_Key takeaway: AI agents must prove their logic in a byte-level clone of production before they are ever granted permissions to touch the live environment._

The real power of Upsun for AI-enabled development is the ability to validate fixes safely. By utilizing production-perfect preview environments, you create a secure "loop" for the agent:

1.  **Propose:** The agent identifies an issue or suggests an optimization, such as a new service binding or a performance fix.
2.  **Clone:** Upsun triggers an isolated, byte-level clone of production apps, services, and data in seconds.
3.  **Validate:** The agent applies the change to the preview environment. Human teams can then validate the output in a live, functional environment where failures carry zero risk to production.
4.  **Review:** Only once the change is proven to work in the preview environment is a Pull Request sent for human review and eventual merge into the main branch.

## III. Reducing the blast radius of innovation

_Key takeaway: The goal of "zero-trust" isn't to slow down development; it's to make high-velocity innovation sustainable._

In the "vibe coding" era, speed often comes at the expense of governance. Upsun balances AI autonomy with human decision-making by moving governance into the platform layer.

-   **Auditability:** Because Upsun is declarative and Git-driven, every action requested by an agent is version-controlled and auditable.
-   **Sustainable scaling:** As you scale from one developer to an entire organization using agents, the platform remains the ultimate source of truth and the human remains the ultimate authority.
-   **Cost predictability:** When an experiment is over, the branch is deleted and resources are instantly reclaimed, eliminating "staging waste" and unpredictable cloud bill shock.

## Beyond the blank check: the Upsun standard

Giving an AI a "blank check" to your cloud account is a relic of early-stage AI hype. For the enterprise, the path forward is deterministic governance. By hosting your AI context on Upsun, you ensure that your agents are "infrastructure literate" but strictly governed within a secure sandbox.

The question isn't whether you can trust the AI. It's whether you can trust the platform that isolates it.

## Frequently asked questions (FAQ)

**Does the AI ever see my actual production data?** 

Through Upsun’s production-perfect clones, an agent can interact with a replica of your production data in an isolated sandbox. This allows for "production-accurate" validation without any risk to your live site.

**How do we prevent "Shadow AI" infrastructure?** 

By defining your AI stack, including specific model versions and service relationships, in the unified configuration file, you treat the AI infrastructure as part of the application logic. This ensures every interaction inherits the same version-controlled security guardrails.

**Does running these isolated environments increase cloud costs?** 

Yes, every environment is a billable resource. However, Upsun allows you to define a lower resource profile for validation, and Git-driven integrations can automatically tear down these environments the moment a PR is merged to prevent "staging waste".

**What role does the Upsun MCP Server play in this?** 

The Upsun MCP Server serves as the authoritative, read-only bridge between the LLM and your environment. It allows the agent to "read" the configuration and services via a secure API without requiring root access to your cloud provider's console.

### [Fix Magento deployment headaches | Upsun](https://upsun.com/blog/magento-deployment-cloud-automation-pitfalls/)

# Common Magento deployment pitfalls and how cloud automation fixes them

Magento is a powerful e-commerce platform, trusted by businesses large and small for its flexibility and robust feature set. Yet, anyone who has managed a Magento project knows it can be an adventure, especially during deployment. Misconfigured environments, extension conflicts, and unpredictable performance can turn a routine release into a frustrating experience..

Fortunately, modern cloud platforms can streamline these deployments and minimize headaches.

In this article, we’ll look at the common pitfalls that affect Magento deployment and demonstrate how cloud automation and robust hosting solutions (such as Upsun, formerly Platform.sh) can keep you calm while your storefront keeps humming.

## **Common Magento deployment pitfalls**

### **1\. The dreaded “works on my machine” syndrome**

Let’s face it: Magento is resource-intensive. It has dependencies on PHP, MySQL (or other database engines), caching mechanisms like Redis, search engines such as Elasticsearch, and more. This complex ecosystem can lead to situations where code works flawlessly in a developer’s local environment but falls apart in production.

**Root causes:**

-   Inconsistent local setups.
-   Incompatible version differences (PHP, MySQL, etc.).
-   Dependency mismatches or untracked configurations.

**How cloud automation solves this:**

A consistent, automated build environment ensures your code is tested under the same conditions every time it’s deployed. Solutions like Upsun provide a configuration-as-code approach, where you define your entire stack (PHP version, databases, caching) in a configuration file stored in version control. With this, whether it's a feature branch or production infrastructure, whenever you spin up a new environment, you’re guaranteed the same configuration. No more “but it works on my machine” excuses**.**

### **2\. Extension conflicts and plugin nightmares**

Extensions are both a blessing and a curse. Magento’s extensive plugin ecosystem allows you to extend functionality easily. However, two or three conflicting extensions can turn your deployment into a debugging detective story.

##### **Root causes:**

-   Extension updates that introduce breaking changes.
-   Conflicting overrides in core files or modules.
-   Version conflicts between custom code and third-party modules.

##### **How cloud automation solves this:**

When you use a cloud platform that creates ephemeral environments for each feature branch, you can test all your extensions together before merging to production. This allows you to spin up a Magento environment, install or update your extension, see if something breaks, and catch conflicts early, without risking your main site. If everything checks out, you can merge confidently and ship your changes without downtime.

### **3\. Performance and caching pitfalls**

Magento’s performance depends on caching done right. Redis or Varnish can be a lifesaver, but setting them up and keeping them in sync with your Magento configuration can be tricky.

##### **Root causes:**

-   Misconfigured or absent caching layers.
-   Caches that don’t clear properly during deployments.
-   Fragmented caches can result when multiple nodes are not synchronized.

##### **How cloud automation solves this:**

A well-structured cloud environment lets you define each service—like Varnish or Redis—in a dedicated container (or service). You can script your build and deploy hooks to clear caches automatically, ensuring you don’t deploy stale data. On a platform like Upsun, you define these services in your project configuration. The environment is built with caching already integrated, and you can rely on consistent performance across staging and production.

### **4\. The database and data migration hassle**

Magento stores a lot of data. Keeping your database structure updated while ensuring no information is lost or corrupted can be stressful.

##### **Root causes:**

-   Schema changes introduced by Magento updates or custom modules.
-   Large, intricate data sets that are difficult to move between environments.
-   Risk of data loss or downtime during production migrations.

##### **How cloud automation solves this:**

A robust cloud workflow ensures you can clone an entire environment’s database and related resources for safe testing. With Upsun, for instance, a snapshot of your production database can be automatically copied to a staging environment. You can run database migrations in a safe sandbox, verify data integrity, and only then promote the changes. That alone saves hours of manual exports, imports, and potential “oops” moments.

### **5\. Overly long deployment windows**

Deployment windows that extend into the wee hours of the morning can be a sign of an overly manual process, or one that is simply too fragile.

##### **Root causes:**

-   Manual steps for building and testing the code.
-   Relying on a single staging environment shared by all teams.
-   Last-minute surprises are discovered right before production deploys.

##### **How cloud automation solves this:**

Continuous integration and delivery (CI/CD) pipelines, automated testing, and reproducible environments give you the confidence that each deployment is production-ready. On some cloud platforms, you can link a Git repository so that every time you push code, the platform automatically:

-   Builds and tests the application.
-   Deploys the code to a dedicated environment.
-   Report any failures.

All of this drastically shortens the deployment window. You’re not stuck waiting for manual steps or dealing with last-minute chaos.

### **6\. Lack of proper testing (or testing in production)**

We’ve all done it, especially under time pressure. But skipping proper testing or, worse, testing directly in production can be a recipe for downtime or even data loss.

##### **Root causes:**

-   Multiple teams are working on separate features, but only one shared staging environment.
-   Pressure to fix bugs or deliver features quickly.
-   Complex local setups that don’t mirror the production environment.

##### **How cloud automation solves this:**

Automated testing and ephemeral environments let you test code (and data) changes in isolation. With Upsun, you can automatically spin up a new environment on every Git branch. You can run functional tests, Selenium tests, or any suite of checks without interfering with the main site or other teams’ work. Once the tests pass, you merge the branch. This ensures each feature is fully vetted before it ever touches production.

### **7\. Security and compliance blind spots**

With Magento, security is paramount. Storing personal and financial data means you must be vigilant about patching, user roles, and secure deployments.

**Root causes****:**

-   Delayed application of Magento security patches.
-   Hardcoded credentials or unencrypted data in transit.
-   Manual deployment processes that forget to lock down sensitive areas.

#####   
**How cloud automation solves this:**

An automated build pipeline applies the latest patches and requires code reviews for any security-related updates. On a platform designed for compliance (PCI DSS, GDPR, etc.), many security best practices, like encrypted data at rest and in transit, are enforced by default. You’re also less likely to forget security patches when your environment’s management is handled declaratively and centrally.

### **8\. Scaling and infrastructure headaches**

Magento can be hungry when traffic spikes. Scaling horizontally might require more servers, load balancers, or containers. While manual scaling is possible, it often leads to guesswork and misconfiguration.

##### **Root causes:**

-   Unpredictable traffic surges (e.g., Black Friday, holiday sales, marketing campaigns).
-   Limited ability to autoscale on traditional hosting solutions.
-   Complexity in replicating databases and caching layers across multiple nodes.

##### **How cloud automation solves this:**

A cloud platform with built-in scaling can automatically spin up additional resources when traffic peaks. On some platforms, you can tweak your resources on the fly (CPU, RAM, disk space) without reconfiguring everything from scratch. Automated scaling ensures your Magento site stays responsive, even under heavy load, and automatically scales down once the rush is over, so you only pay for what you need.

### **9\. Relying on a single “hero” engineer**

All too often, there’s one person on the team who intimately understands how the entire Magento deployment pipeline works. If that person is on vacation or leaves the company, you’re in trouble.

##### **Root cause:**

-   Complex custom scripts or one-off processes that are poorly documented.
-   Infrequent knowledge sharing among team members.
-   Overdependence on manual steps maintained by a single individual.

##### **How cloud automation solves this:**

Putting your deployment logic in code means you have a single source of truth. Everybody on the team can look at the repository and see how services are defined, how data is migrated, and how caches are cleared. Tools like Upsun’s environment configuration files bring transparency, making it easier for new team members to hop in without needing a crash course from the “hero” engineer.

### **10\. Future-proofing your Magento deployments**

Magento isn’t static—it evolves through new releases, security patches, and community-driven updates. Your deployment strategy must be agile enough to handle the next wave of changes. What worked a year ago might be outdated now.

##### **Root cause:** 

-   Relying on manual or static processes that don’t adapt to new Magento versions.
-   Not leveraging automation to keep up with the speed of updates.
-   Overlooking new best practices in the Magento community.

##### **How cloud automation solves this:**

Cloud platforms are designed to handle frequent and automated updates, ensuring you're always in step with Magento’s latest requirements. Each environment is reproducible, making it easier to upgrade services (e.g., upgrading PHP or Elasticsearch versions). In addition, you can experiment with new Magento releases in a dedicated testing environment, safe from any impact on your live store.

### **Conclusion: Think beyond “just hosting”**

Magento deployment doesn't have to be stressful. The challenges we've discussed, environment inconsistencies, extension conflicts, and scaling bottlenecks, are all solvable with the right approach. Cloud application platforms like Upsun solve these deployment challenges by standardizing environments across development, staging, and production.

The solution comes down to consistency. When you treat your infrastructure and deployment processes as code, you remove the guesswork and manual steps that create problems. Automated builds, instant environment cloning, and integrated monitoring transform what used to be high-stress deployments into routine, predictable operations.

Here's what this means for your team: instead of spending time troubleshooting deployment issues, you can focus on building features that delight customers and drive business growth. Your developers gain confidence knowing their code will work the same way in production as it did in testing. Your stakeholders get reliable timelines and predictable outcomes.

Whether you’re an IT Manager, Technical Project Manager, or a Web Services Manager overseeing a Magento build, you can rest easier knowing there’s a better way. With the right cloud platform behind you, you’ll spend less time fighting fires and more time delivering the best possible e-commerce experience to your customers. After all, isn’t that the whole point?

_Ready to fix your Magento deployment headaches for good?_   
Learn how to deploy Magento on Upsun and keep your application running smoothly.

### [Scalable AI governance needs policy as code | Upsun](https://upsun.com/blog/scalable-ai-governance/)

# Scalable AI governance: why your policy needs a platform, not just a PDF

Most IT teams don’t lack AI policies. They lack policies that survive a Git push.

In many organizations, AI governance is a paper tiger. There are comprehensive documents outlining data usage, approved models, and risk management. On an auditor's desk, these policies look complete.

But inside the workflow, the reality is different. AI tools are being embedded directly into IDEs, CI pipelines, and internal automation scripts. When governance lives in a wiki rather than the deployment pipeline, it becomes "advisory". And under delivery pressure, advisory rules are the first to be bypassed.

For IT leaders, the goal isn't just to _have_ a policy; it's to make it **enforceable at scale**. This requires moving to policy-as-code: templates that map directly to technical controls.

## **Why traditional AI policies fail the "scale test"**

Traditional governance assumes a "pause and consult" model. It worked when systems were slow and manual reviews were the norm. AI doesn’t wait for a review board.

The breakdown isn't usually caused by bad intent; it’s caused by **friction**. If following the AI policy requires five manual steps and a ticket, teams will find the path of least resistance. To scale AI safely, the "right way" to deploy must also be the "easiest way."

## **The Library: 4 scalable AI policy templates**

To bridge the gap between intent and enforcement, your governance should be built from a library of reusable technical templates. Here is how to structure them.

### **1\. The AI API governance template**

**Focus:** Controlling "Shadow AI" and unsecured endpoints. **The enforceable guardrails:**

-   **Service whitelist:** Use platform configuration to restrict outbound traffic to approved providers only (e.g., Azure OpenAI vs. public endpoints).
-   **Credential injection:** Prohibit hardcoded keys. Require all AI secrets to be managed via platform-level environment variables, ensuring they never appear in source code.
-   **Network scoping:** Ensure AI traffic stays within your defined VPC or private network to prevent prompt data from traversing the public internet.

### **2\. The deployment boundary template**

**Focus:** Preventing unverified AI logic from reaching production. **The enforceable guardrails:**

-   **Mandatory preview environments:** Require every AI-related code change to be validated in an isolated, production-identical environment.
-   **Automated promotion logic:** Define "kill switches" in your CI/CD. If an AI service dependency fails a health check, the deployment is automatically blocked.
-   **Resource hard-caps:** Set CPU/RAM limits at the environment level to prevent "runaway" AI agents from spiking cloud costs.

### **3\. The Data handling and residency template**

**Focus:** Preventing IP leakage and maintaining GDPR/PII compliance. **The Enforceable Guardrails:**

-   **Context Isolation:** Use read-only database replicas for AI RAG (Retrieval-Augmented Generation) to ensure the model cannot modify production data.
-   **Regional Pinning:** Use declarative config to pin AI workloads to specific geographic regions (e.g., EU-West) to meet data residency requirements.
-   **Anonymization Layer:** Mandate a pre-processing service that strips PII from prompts before they leave your environment.

### **4\. The AI agent autonomy template**

**Focus:** Managing "write" access and accountability for autonomous agents. **The Enforceable Guardrails:**

-   **Human-in-the-Loop (HITL) Triggers:** Flag "high-stakes" actions (e.g., database schema changes) for manual approval.
-   **Machine-User IAM:** Assign agents their own role-scoped identities—never let an agent run on a "Super Admin" token.
-   **Immutable Audit Logs:** Every action taken by an agent must be logged with the same transparency as a developer’s Git commit.

## **The compliance accelerator: why the platform is the policy**

Templates alone don’t enforce governance; platforms do. If your infrastructure is fragmented, governance remains a manual "fire drill."

This is where **Upsun** transforms governance from a checklist into a competitive advantage. Upsun provides the infrastructure foundation that makes these templates executable:

-   **Git-driven configuration:** Your AI policy lives in your upsun.yaml. It is version-controlled, peer-reviewed, and becomes the "source of truth" for both humans and AI agents.
-   **Production-perfect preview environments:** This is your **Governance Validation Layer**. Every push spins up a clone of your entire stack. Your security team can see exactly how an AI agent interacts with your data in a safe, ephemeral environment _before_ it merges to production.
-   **Standardization by design:** Because Upsun is declarative, there is no "drift." A policy defined once is enforced identically across 10 or 1,000 projects, across AWS, Azure, or GCP.

## **From policy documents to enforceable guardrails**

The organizations that scale AI successfully in 2026 won't be the ones with the longest PDFs. They will be the ones that treated governance as a system requirement.

By embedding your AI governance into your delivery workflow, you turn security from a "blocker" into a "guardrail," allowing your team to innovate with AI at the speed of a startup with the safety of an enterprise.

### **Take the Next Step**

### [Enterprise Drupal: evolve and host more apps | Upsun](https://upsun.com/blog/enterprise-drupal-hosting/)

# Enterprise Drupal: why hosting all your apps on one platform matters

For many enterprises, Drupal has been the backbone of their web operations for years. It’s a battle-tested CMS that handles complex content needs with elegance. But business needs have evolved. Today, it’s rare for a company to rely only on Drupal. They are spinning up Python APIs, .NET backend services, Node.js apps, Java microservices, and expanding their digital ecosystems around Drupal’s core. Even Drupal projects themselves are now a mix of technologies with a decoupled frontend or external dependencies.

Managing this growing tech diversity the old way, with separate hosting environments and disjointed processes, is a fast track to operational complexity. The smart move? Consolidate. Host Drupal and all your new applications together on a single cloud application platform.

Let’s dive into why companies that already rely on Drupal should think seriously about extending their hosting strategy, and how a platform like Upsun, formerly Platform.sh, makes it painless.

## **Expanding beyond Drupal: the natural next step**

Even with the emergence of new CMS solutions, Drupal still shines at powering enterprise-grade websites, portals, and content hubs. But it's rarely the whole story anymore.

_Source: https://w3techs.com/technologies/details/cm-drupal_

Your data team may be building a Python-driven recommendation engine, or your CRM team is deploying a Springboot Java API. Marketing wants a Node.js headless frontend for innovative UX experiences. New apps emerge fast, and they're often in languages Drupal wasn't built to handle.

The challenge: **How do you keep scaling your digital stack without creating a fragmented mess**?

Trying to bolt each new app onto its server, cloud account, or hosting vendor will quickly create silos, duplication, and security nightmares. Instead, the smartest path is to **extend your existing Drupal hosting into a unified application platform** — one that’s already built for running any runtime or service.

Upsun, for instance, doesn't just excel at hosting Drupal (though it absolutely does). It also natively supports over 70 frameworks and languages, letting your Drupal site and your new Python, .NET, or Node.js services live together, with the same governance, security, and deployment flows.

This way, Drupal remains the core of your digital platform, while new services and applications extend its capabilities seamlessly and securely.

## **Simplified infrastructure management**

Managing a Drupal site already comes with enough complexity, including updates, modules, and security patches. Now imagine adding a separate cloud account for a Node.js service, a different container cluster for Python microservices, and a Windows Server for .NET APIs. It's a recipe for sprawl and inefficiency.

With a single cloud platform, your Drupal site and your new apps sit side-by-side. **One dashboard, one set of tooling, one bill**. Less context-switching for your team, no additional learning curve, and less surface area for mistakes.

Upsun enables teams to manage their Drupal deployments and their additional services from the same place, using standardized workflows. That’s less cognitive overhead and a lot less time wasted coordinating between fragmented systems.

As Forrester noted in its 2023 Total Economic Impact™ study, companies adopting unified platforms reported major operational streamlining, **reducing duplicated infrastructure and tooling overhead by over 40%**.

## **Consistent environments and processes**

You already know the pain: Drupal behaves one way locally, another way in staging, and throws curveballs in production. Now multiply that by three if you have Python, .NET, and Node.js apps all hosted differently.

Consistency is king. A cloud application platform ensures that your Drupal environment and your new app environments are **defined as code**, reproducible from dev to prod. Whether it’s a Django REST API, a Symfony backend, or your main Drupal site, they all deploy with the same principles.

Upsun uses a Git-based configuration approach (Infrastructure as code) that ensures every application — Drupal or otherwise — follows a repeatable, predictable path from code to cloud.

Having a deterministic build and deploy pipeline removes “works on my machine” bugs, speeds up QA cycles, and lets your teams focus on building, not firefighting. Bringing peace of mind to the team in charge of deploying and running these applications.

## **Faster development and deployment cycles**

New apps are often born around existing Drupal sites because business teams need features Drupal wasn’t built for: a real-time inventory API, an AI-driven search engine, a mobile-optimized experience.

On traditional hosting setups, adding new services often means provisioning separate servers or cloud accounts, manually configuring environments, and setting up isolated monitoring, security, and compliance controls, a process that can involve multiple teams, approval workflows, and weeks of coordination.

With a cloud application platform like Upsun, you can spin up new projects as easily as cloning your Drupal staging site. Want a test environment where your new Python API talks to the Drupal CMS? Click a button. Done.

That kind of speed is a serious competitive advantage. It enables real DevOps practices: feature branching, ephemeral environments, automated tests — not just for your shiny new services, but for your core Drupal site too.

**Faster iterations mean faster innovation.** Your digital stack stops being a weight and becomes a launchpad.

## **Cost savings and resource efficiency**

Running a standalone Drupal hosting contract, plus a separate cloud subscription for new apps, plus a managed service for a backend API… costs add up. Fast.

By hosting everything — Drupal plus diverse apps — on one cloud application platform, you consolidate spending. You optimize resource usage dynamically across services. And you avoid the hidden tax of managing too many vendors.

Forrester found that organizations consolidating to a platform model (like Upsun) achieved a **219% ROI** over three years, largely by reducing fragmented infrastructure and IT operating costs.

Plus, teams spend less time maintaining and troubleshooting fragmented systems and more time delivering features, which translates directly into higher business value.

## **Enhanced security and compliance**

Drupal teams are already used to the constant need for patches, updates, and compliance hardening. As we can see, 39.4% of Drupal sites are running an “End-of-Life” version no longer maintained. Only 3% are on the latest one.

_Source: https://w3techs.com/technologies/details/cm-drupal_

Now add new apps and stacks into the mix, each on their own unmanaged cloud hosting… and both your attack surface and technical debt could balloon in weeks.

A single cloud platform brings your security posture up across the board. Patches, backups, encryption, access controls — all managed uniformly across your Drupal site and every new app you deploy.

Gartner estimates that through 2025, 90% of companies that fail to control public cloud use will inappropriately share sensitive data, mainly due to misconfiguration. A managed cloud application platform greatly reduces this risk by automating the security baseline across all services and adding guardrails to avoid such vulnerabilities

Upsun is compliant with major standards like SOC 2 and GDPR, meaning your team inherits those protections automatically across all apps, not just Drupal.

Add 24/7 monitoring support and security teams, and all your bases are now covered to avoid a dramatic breach.

No loose ends, no forgotten servers.

## **Scalability and future-proofing**

Your Drupal site is only part of your digital future. New needs will emerge: APIs, personalization engines, mobile integrations, and headless frontends.

By building on a cloud platform that embraces **multi-language, multi-framework diversity natively**, you future-proof your stack.

Upsun already supports over 70 languages and frameworks out of the box, from Go to Rust to Elixir. Whatever your next project demands, you won’t need a new hosting partner or a replatforming exercise. You’re ready.

Scaling up is simple too. Whether you need to triple your Drupal capacity for a holiday rush or horizontally scale a Python AI service, it’s the same scalable, resilient platform underneath.

**One platform. Infinite growth paths.**

### Final thoughts

If your company already trusts Drupal for its critical web presence, you’re in a perfect position to evolve smartly.

Rather than patch together new hosting solutions every time a new app pops up, extend your existing investment: Drupal plus everything else, hosted together on a single cloud application platform.

Upsun makes this evolution seamless, letting you focus on innovation, not infrastructure firefighting.

The digital future isn’t Drupal alone. It’s Drupal **plus** the services and apps that will power your next decade of growth.

You’re better off building that future **on a unified foundation.** Get started with Upsun.

### [Cut IT complexity and downtime, scale smarter | Upsun](https://upsun.com/blog/cut-it-complexity-scale-smarter/)

# How to cut IT complexity, stop outages, and scale without the stress

Today's IT managers face a growing list of challenges, including keeping teams productive,  their infrastructure scalable, and their applications running without disruption. Traditional hosting providers make these problems worse by keeping you in the dark about how your systems work. When issues happen, IT teams end up spending a lot of time trying to diagnose problems they can't see.

At Upsun, we believe IT leaders should demand more from their infrastructure solutions. In our recent webinar, we explored the critical issues affecting IT teams and how a smarter platform approach can transform operations. Let’s dive into three key takeaways that can help IT leaders eliminate downtime, scale intelligently, and keep their teams focused and well-rested.

### **1\. The visibility gap: Why IT leaders are moving away from opaque hosting providers**

Traditional hosting providers often operate without providing deep insights into system performance. IT teams are left in the dark, struggling with:

-   **Lack of real-time monitoring**: Without access to detailed infrastructure metrics, diagnosing and fixing issues becomes a guessing game.
-   **Delayed troubleshooting**: Outages drag on because support teams cannot pinpoint root causes quickly.
-   **Unpredictable downtime costs**: A lack of visibility can lead to prolonged outages, costing organizations thousands in lost revenue and productivity.

Modern cloud application platforms are changing the game by offering real-time dashboards, detailed logging, and performance metrics. For example, Symfony leverages Upsun's Observability Suite to optimize SQL queries, boosting site performance by 3x—without major code changes. By identifying bottlenecks early, IT teams can proactively resolve performance issues rather than reactively firefighting problems.

### **2\. Scaling without adding complexity: The modern approach to infrastructure growth**

Scaling infrastructure used to mean adding more servers, more hardware, and ultimately, more complexity. The old approach of “throwing more hardware at the problem” no longer cuts it.

Instead, IT teams need:

-   **Intelligent automation**: Autoscaling should dynamically adjust resources based on real demand, ensuring efficient use of infrastructure without unnecessary costs. 
-   **Infrastructure as code**: Treating infrastructure like software enables repeatable, scalable deployments while reducing human error.
-   **Right-sizing**: Scaling down when traffic decreases is just as important as scaling up during peak loads, preventing wasted resources and costs.

One of the biggest challenges IT leaders face is maintaining balance, ensuring infrastructure scales with business needs without introducing unnecessary complexity. By leveraging a platform that automates scaling decisions and optimizes infrastructure dynamically, IT teams can focus on innovation rather than infrastructure maintenance.

### **3\. Choosing the right platform to keep IT teams focused, productive, and well-rested**

Alert fatigue, context switching, and middle-of-the-night wake-up calls—these are all symptoms of poorly optimized IT operations.

IT managers must ask themselves:

-   Are my teams spending more time fixing infrastructure than improving applications?
-   Are we constantly reacting to issues instead of proactively preventing them?
-   Are we relying on a few key people with specialized knowledge, creating a risk when they leave?

With a cloud application platform that prioritizes self-healing infrastructure, intelligent alerting, and proactive monitoring, IT teams can spend less time firefighting and more time driving business value. The return on investment (ROI) extends beyond just cost savings—it impacts productivity, team morale, and overall business agility.

### **Evaluate your platform with these key questions**

Before choosing an infrastructure provider, IT leaders should carefully evaluate their options. Here are three critical factors to consider:

-   **Support and SLAs**: Does the provider offer true 24/7 support with clear uptime guarantees? Is there a limit on the number of support tickets you can open?
-   **Ease of migration**: How seamless is the transition to the new platform? Will it introduce unnecessary complexity into your environment?
-   **Total cost of ownership**: Does the provider cover edge security, storage, application monitoring, and performance optimization, or will you need to manage those separately?

IT leaders often underestimate the hidden costs and complexity of managing infrastructure without a fully optimized platform. A smarter approach eliminates these inefficiencies, allowing teams to focus on innovation rather than infrastructure maintenance.

If you are looking to reduce downtime, streamline scaling, and enhance team productivity, our experts are here to help. Book your one-on-one consultation today to explore how our cloud application platform can empower your IT team and drive long-term success. For the full version of the webinar, click here.

### [Stop environment drift with branch-based parity | Upsun](https://upsun.com/blog/eliminating-environment-drift-branch-parity/)

# Eliminating environment drift through branch-based infrastructure parity

Environment drift occurs when staging and production configurations diverge, leading to a 30% increase in deployment failures. To resolve this, engineering teams must adopt a "branch-to-environment" model where infrastructure is declared as code and environments are ephemeral, data-complete, and isolated for every feature.

## I. What causes environment drift in modern CI/CD?

_Key takeaway: Upsun prevents structural environment failure by replacing shared, long-lived staging servers with isolated, branch-based parity._

In high-velocity development, "works on my machine" is usually the result of a discrepancy in the service mesh. If production uses PostgreSQL 16 and Redis 7, but staging is running legacy versions or shared instances, the testing signal is compromised.

**To achieve full infrastructure parity and eliminate deployment risk, a platform must provide:**

1.  **Declarative Definitions:** Infrastructure must be versioned alongside the code within the .upsun/config.yaml.
2.  **Service Isolation:** Upsun ensures every developer works in a dedicated environment to prevent state contamination.
3.  **Automatic Provisioning:** Environments are "spun up" the moment a Pull Request is opened, driven by the standard Upsun definition file.

## II. The logic of data-complete preview environments

_Key takeaway: Upsun's data-cloning mechanism prioritizes testing accuracy by ensuring every preview environment is a production-parallel mirror._

True parity requires State Parity. Upsun solves this diagnostic pain point through a specific, integrated mechanism:

-   **The Mechanism:** When a new Git branch is detected, the Upsun platform parses the `**.upsun/config.yaml**` requirements and clones the production volume instantly.
-   **Technical Logic:** Instead of slow manual refreshes, this uses Upsun’s copy-on-write file system to create a zero-weight snapshot of production data.
-   **Privacy and Security:** Upsun executes integrated sanitization hooks automatically to scrub PII (Personally Identifiable Information), ensuring GDPR compliance before the preview URL is live.

## **III. Scaling resource-based infrastructure for 2026**

_Key takeaway: Upsun’s resource-based allocation reduces infrastructure TCO by 25% compared to seat-based or process-based scaling._

As teams scale, the cost of "always-on" staging clusters becomes unsustainable. The 2026 industry standard is Ephemeral Infrastructure. By only paying for the CPU and RAM utilized during the active lifecycle of a feature branch, organizations eliminate the "Idle Resource Tax."

## Frequently asked questions (FAQ)

**How do I define service relationships in an Upsun preview environment?** 

The best practice is to use Upsun’s declarative file, `.upsun/config.yaml`, to map applications to services (e.g., PostgreSQL, Redis). This ensures the relationship is natively wired by Upsun, mirroring the production topology exactly.

**Can Upsun trigger an Instant Data-Complete Preview Environment for every branch?** 

Yes. By using the Upsun branch-based workflow, every code push allows the platform to provision a mirrored stack with cloned production data, eliminating manual staging updates.

**Is it possible to maintain provider optionality with Upsun?** 

Yes. By standardizing the environment definition in the `.upsun/config.yaml`, Upsun decouples the application from the cloud provider. This allows the same logic to work regardless of whether the Upsun project is hosted on AWS or GCP.

### [Real-world data makes AI agents reliable | Upsun](https://upsun.com/blog/ai-agent-testing-production-clone/)

# Why you need real-world data to evaluate your AI agents

## Problem: A lab demo is not a production test

If an agent only performs on a curated notebook, it is not production-ready. Real customers expect reliability across dozens of apps, strict compliance, and predictable costs. That is the daily reality for IT middle management.

Recent research shows the gap between benchmark wins and real tasks. On GAIA, humans scored 92 percent while a top model with tools managed about 15 percent.¹² AgentBench finds similar agent shortfalls in interactive environments that look more like the messy, stateful world your systems live in.³⁴

For leaders accountable for uptime and risk, “works on my laptop” is not a test plan. You need to let agents touch your own data, tools, and edge cases, without touching production.

## Upsun solution: evaluate against a safe production clone

Upsun provides every Git branch with a live, production-grade environment that includes cloned services such as databases and caches. That means you can spin up a realistic production clone in minutes. See how environments map to branches and how preview environments inherit data for realistic testing.

Need to protect sensitive fields while keeping data shape and distributions? Use custom sanitization patterns so preview databases are useful and PII-free. Read the sanitizing guide and examples.⁵

Upsun is built for both humans and AI agents. It exposes structured config and predictable APIs, and your assistants connect through MCP servers for rich, real-time context about your stack. Deploy MCP servers on Upsun and wire PostgreSQL MCP to a clone safely.

## AI agent testing needs production data

A credible **AI agent evaluation** plan exercises your RAG pipelines, tool calls, timeouts, retries, permissions, and failure paths on the same schemas and services you run in production. Upsun’s branch-per-environment approach standardizes the workflow and reduces the “unknown unknowns” that only appear with real workloads.

Quick start:

```shell-session
# Create an isolated prod clone for agent testing

upsun branch agent-evals
```

```shell-session
# Tail logs while agents run their scenarios

upsun log -e agent-evals app
```

See CLI reference.

## RAG evaluation in your production clone

Do not just eyeball outputs. Like classic application testing, run proper **RAG evaluation** against your org’s content. A practical framework scores three things: context relevance, groundedness, and answer relevance.⁶ 

Many toolkits can handle AI evaluations, but if you are just starting, Langchain is your best bet to start creating and running your LLM tests. 

In Upsun, you can run these evaluations as part of your branch workflow and maintain observability with logs and continuous profiling. See log access and profiling.

## Wire the MCP and A2A workflows to real services

Agents improve when they can actually fetch, transform, and write through the interfaces your teams use today. With Upsun, MCP, and agent-to-agent patterns can run in the cloned environment against your real APIs and data models, so you catch permission gaps, throttling, or schema drift long before release. Explore developer articles.

## Implementation details: from lab demo to production 

1.  **Create a production clone per feature branch.** Each branch gets an environment with cloned services and assets.
2.  **Sanitize sensitive data.** Use the Upsun patterns to replace PII while maintaining realistic structure and distributions.⁵
3.  **Connect your agent to real tools.** Add MCP servers and any A2A workflows against the clone’s URLs.
4.  **Automate RAG evals.** Evaluate the relevance, groundedness, and quality of your answers in your content. Track and compare improvements and regressions per branch.⁶⁷
5.  **Observe everything.** Stream logs and profiles to catch timeouts, rate limits, and memory leaks early. Profile performance with our included Blackfire service.  See observability overview.
6.  **Merge to production.** Validate under stress and load, then merge with confidence into production.

## Why Upsun is the best platform for this

-   **Speed and simplicity.** A single YAML config drives multi-service orchestration and repeatable environments.
-   **Standardization.** Consistent delivery across teams reduces surprises and simplifies audits.
-   **Security and compliance.** Policies and protections operate up to the application layer.
-   **Multi-cloud options.** Keep cost control and vendor freedom as you scale.

## Sources

1.  GAIA: a benchmark for General AI Assistants (arXiv)
2.  GAIA: a benchmark for General AI Assistants (ICLR 2024 proceedings)
3.  AgentBench: Evaluating LLMs as Agents (ICLR 2024 proceedings)
4.  AgentBench: Evaluating LLMs as Agents (ar5iv HTML) 
5.  Sanitizing databases on preview environments (Upsun Docs)
6.  IBM RAG Cookbook: Result evaluation and the RAG triad 
7.  NVIDIA NeMo Microservices: RAG evaluation type 
8.  NVIDIA NeMo Evaluator overview 
9.  Increase observability with logs and profiling (Upsun Docs)
10.  Ragas metrics overview
11.  Ragas evaluate API

### [Yes, 99.99% uptime is now possible | Upsun](https://upsun.com/blog/99-99-uptime/)

# Yes 99.99% uptime is now possible, and here is how

IT leaders are judged on reliability across dozens of apps. Yet teams are thin, estates are hybrid, and platform sprawl makes every release a gamble. The result is toil, inconsistent practices, and budget spent on firefighting instead of modernizing.

Meanwhile, your users and stakeholders expect “always on.” That usually means an uptime target of 99.99%, or roughly 52 minutes of downtime per year.¹ If you chain multiple cloud services, your composite availability can fall below the headline SLA unless you design for failure.²

## **Where competitors set the bar**

Uptime commitments vary widely by provider and plan. Here is a snapshot from public sources:

-   Netlify’s enterprise offer advertises a 99.99% uptime SLA.³
-   Vercel’s enterprise tier markets a 99.99% uptime SLA and documents SLA terms.⁴ ⁵
-   Azure App Service lists a 99.95% SLA for apps.⁶
-   Google Cloud Run documents a 99.95 %monthly uptime objective.⁷

These benchmarks confirm that four nines (99.99%) is achievable with the right architecture and contract, but the responsibility to achieve it still falls to your team. Composite SLAs across dependencies often end up lower than any single component.²

## **How teams actually reach 99.99%**

Hitting four nines is less about a single feature and more about a disciplined delivery model. On Upsun, the path is opinionated and practical:

### **1) Standardize production with Git-driven configuration**

Codify environments, services, routing, policies, and scaling in a single config.yaml tracked in Git. This eliminates drift and makes disaster recovery predictable. Read the docs.

### **2) Create a production-grade preview for every branch**

Every branch gets a complete, isolated environment that mirrors production, including services. That means breaking changes surface before they hit customers, not after. See how previews work.

### **3) Clone data instantly with built-in sanitization**

Developers test with realistic datasets without exposing sensitive information. Safe, fast data cloning shortens mean time to detection and reduces incident risk. Learn more in our DevCenter.

### **4) Orchestrate many services without duct tape**

Upsun’s multi-service orchestration and opinionated routing replace brittle scripts. Scale predictable patterns across teams rather than build bespoke pipelines. Platform leaders get guardrails that free engineers to move faster.

### **5) Observe everything with integrated APM and logs**

Built-in monitoring and profiling give developers and SREs the same picture. You find the “why” behind latency and error spikes before customers do.

### **6) Operate across clouds with a single control plane**

Multi-cloud support helps with vendor freedom and data sovereignty while maintaining a single way of working. Leaders get cost visibility and standardization across estates.

## **What “99.99% on Upsun” really means**

For IT middle management, the value is not just the number. It is how the platform makes the number achievable with your current team size:

-   **Speed**: Branch previews and automated builds remove waiting, so fixes ship quickly.
-   **Quality**: Production-grade test environments cut escaped defects and noisy rollbacks.
-   **Consistency**: A single YAML config enforces patterns across teams and apps.
-   **Reduced toil**: Patching, policies, and guard rails are handled centrally.
-   **Predictable cost**: Standardized delivery reduces bespoke tooling and hidden run costs.

## **Technical blueprint: from 99.9% to 99.99%**

Use this simple sequence to move toward four nines without exploding scope.

1.  **Stabilize the baseline**  
      
    -   Define SLOs per user journey.
    -   Instrument golden signals and alert on SLO burn, not raw errors. Link monitoring to runbooks.
2.  **Eliminate change risk**  
      
    -   Enforce branch previews by policy. No PR merges without environment health checks and smoke tests.
    -   Clone production data with sanitization for realistic load and edge cases.
3.  **Design for failure**  
      
    -   Prefer managed services with documented SLAs above 99.95% where available.⁶ ⁷
    -   Avoid single-region bottlenecks. If a service supports multi-zone or regional control planes at 99.95% or above, use them.⁷ ⁸
    -   Compute composite availability for any critical dependency chain before launch.²
4.  **Shorten incident loops**  
      
    -   Integrate APM traces with deploy metadata so you can correlate regressions to commits.
    -   Use preview environments to reproduce incidents fast, then ship hotfixes confidently.

## **Why now: the market has normalized around high nines**

Enterprise vendors have converged on higher uptime commitments for premium tiers. Both Netlify and Vercel publish at four nines on their enterprise plans.³ ⁵ Major cloud serverless runtimes document 99.95% targets.⁶ ⁷ Teams that still run bespoke pipelines and one-off environments bear the hidden tax of change risk. Upsun standardizes the path to production, so your small team can run like a larger one. That is why our messaging for platform leaders emphasizes buy-over-build, multi-cloud options, and a 99.99% SLA.

## **Bottom line for IT middle management**

If your mandate is reliability with a limited headcount, four nines is achievable. The winning formula is standardized delivery, production-grade previews, safe data cloning, and integrated observability. Upsun exists to package that formula so your teams spend less time firefighting and more time moving the roadmap forward.

## **FAQ: quick math and definitions**

-   **How much downtime is 99.99%?** About 4 minutes 23 seconds per month, 52 minutes 36 seconds per year.¹
-   **Will multiple services lower my effective uptime?** Yes. Composite uptime across dependencies is often lower than any single SLA. Plan architecture accordingly.²
-   **Do public cloud SLAs guarantee app availability?** No. Cloud SLAs cover the specific managed service. Your app uptime depends on design, testing, and operational discipline.⁶ ⁷

## **Sources**

1.  Uptime and downtime with 99.99 percent SLA
2.  Composite cloud availability, Google Cloud Blog
3.  Netlify for enterprises: “99.99% uptime SLA”
4.  Vercel Enterprise: “99.99% uptime SLA”
5.  Vercel Enterprise SLA terms
6.  SLA for Azure App Service: 99.95 percent
7.  Google Cloud Run SLA: 99.95 percent SLO

### [Best Magento hosting strategy for enterprise teams](https://upsun.com/blog/diy-vs-managed-vs-upsun-vs-adobe-commerce-cloud-for-enterprise-magento/)

# Which hosting strategy wins for enterprise Magento?

When you’re running an enterprise-level Magento store, you can’t afford to leave infrastructure decisions to chance. With large product catalogs, high transaction volumes, and complex integrations, your hosting choices can directly impact your bottom line and your sanity. The right solution gives you the performance, reliability, and scalability you need while reducing complexities, maintenance overhead, and cost. The wrong solution could leave your team buried in support tickets, or worse: alienate your customers when performance lags.

Let’s explore the pros and cons of three popular hosting approaches—DIY cloud hosting, managed hosting, and Upsun, formerly Platform.sh, and see how they all compare to Adobe Commerce Cloud. By the end, you should have a clearer picture of which approach best supports your enterprise Magento store.

## 1\. DIY cloud hosting

What it is: A DIY (do-it-yourself) cloud hosting setup places your Magento infrastructure on cloud providers like AWS, Azure, or Google Cloud—but you still manage the configuration, software stack, security, and scaling strategies. Essentially, you rent the virtual hardware instead of owning physical servers, but you’re still in charge of most operational details.

**Pros**

-   Total control: You choose the cloud provider, instance types, operating systems, and when and how to update. This freedom can be attractive if you need specific configurations or network connections with your existing infrastructure.
-   Deep customization: Because you decide which services and configurations to use, you can tailor your environment to your application’s exact needs—from virtual machines or container orchestration to specialized caching layers.

**Cons**

-   Potentially unpredictable costs: While you avoid large capital expenditures, cloud expenses can balloon if you’re not vigilant about usage, scaling, and reserved instances. Surprises on the monthly bill can become a headache.
-   Challenging compliance: Because you manage everything on top of the virtual hardware, any compliance requirement will put your team under pressure to meet the hundreds of controls to meet standards like PCI-DSS or SOC2. Any gap in compliance could lead to massive fines by the regulators. 
-   Complex maintenance: Even in the cloud, you’re on the hook for OS-level patches, security hardening, performance tuning, and troubleshooting. This can tax your team’s bandwidth and skill sets.
-   Scaling challenges: The cloud can theoretically scale quickly, but poorly configured auto-scaling rules or resource misallocations often lead to downtime or performance bottlenecks. Managing this effectively still requires expertise and careful planning.

**How it compares to Adobe Commerce Cloud**

Adobe Commerce Cloud is a fully hosted and managed environment for Magento, taking care of server provisioning, patches, and many day-to-day operational concerns. By contrast, DIY cloud hosting demands more hands-on work, though you maintain fine-grained control over every aspect of the environment. That control can be beneficial if you need customized solutions or want to optimize costs independently. However, the trade-off is increased complexity and a greater operational burden compared to the convenience of a managed service like Adobe Commerce Cloud.

## 2\. Managed hosting

In a managed hosting setup, you lease server resources from a hosting provider. The provider handles some operations like patching, security hardening, and server monitoring, while you maintain and optimize your eCommerce application. The level of flexibility varies from one provider to the other.

**Pros**

-   Less maintenance overhead: While you still configure your Magento store, the hosting provider tackles a large portion of the infrastructure tasks (OS updates, hardware replacements, etc.).
-   Predictable costs: You pay a monthly or annual subscription for specified resources, avoiding huge upfront hardware expenses.
-   Basic support included: Most managed hosts offer 24/7 support for infrastructure issues, which can be a lifesaver when something goes wrong at 3 AM.

**Cons**

-   Potential inflexibility: Many managed hosts provide standard server configurations with limited customization. If your Magento store requires special caching layers or unique software setups, you may hit roadblocks.
-   Shared environments: In some cases, “managed” can still mean shared environments. If you don’t opt for a dedicated server, your store performance might be impacted by other tenants on the same platform.
-   Still not fully automated: While you offload some responsibilities, your dev teams still must handle code deployments, environment consistency, and performance optimization. You’re partially relieved of ops, but not entirely.

### **How it compares to Adobe Commerce Cloud**

Adobe Commerce Cloud is also a managed service—but by Adobe. With many managed hosting providers, you’ll still do plenty of heavy lifting for your Magento store. Adobe Commerce Cloud includes enterprise-level integrations, but typically has a more rigid structure, meaning less flexibility for custom requirements. Both reduce your infrastructure headaches compared to DIY cloud hosting, but you might still not have the level of automated DevOps many modern eCommerce stores require.

## **3\. Upsun**

Upsun is a modern, fully managed, end-to-end hosting solution for web applications. It’s designed with developers in mind, focusing on a “build and deploy” approach that abstracts complex infrastructure tasks. For Magento Open Source and Adobe Commerce, Upsun offers a powerful solution that supports complex projects and demanding performance needs.

**Pros**

-   Instant environment cloning: One of the Upsun hallmarks is environment cloning. With the click of a button, you can create a perfect copy of your production environment (including data), allowing you to test new features or upgrades without risking your live site.
-   Fully integrated DevOps pipeline: Upsun automates everything from code testing to deployments. With built-in CI/CD, your development teams spend less time wrestling with manual processes and more time innovating.
-   Effortless scaling: Whether you see a spike in traffic during a holiday sale or you’re expanding internationally, you can scale resources up or down in just a few clicks. No downtime, no months-long procurement cycles.
-   Global infrastructure footprint: Upsun runs on top of major cloud providers like AWS, Google Cloud, and Azure, giving you the choice of multiple regions worldwide for low-latency, high-performance hosting.
-   Security and compliance out of the box: Comprehensive security features, including automated backups, built-in TLS/SSL management, advanced WAF, and various compliance certifications mean peace of mind for enterprise teams.

**Cons**

-   Learning curve: If your dev teams have only worked on traditional hosting setups, adopting Upsun might require a short learning period to fully embrace the Git-driven workflow.
-   Not a commodity host: If you’re looking for the cheapest possible server to “just host” a Magento site, you’ll find cheaper options. Upsun is about delivering a full DevOps and infrastructure solution that saves time and money in the long run.

### **How it compares to Adobe Commerce Cloud**

Both Upsun and Adobe Commerce Cloud share core capabilities such as automated scaling, environment cloning, and CI/CD pipelines, because Adobe Commerce Cloud is powered by Upsun technology. However, several key differences are important for enterprise decision-makers:

-   **Pricing model**: Adobe Commerce Cloud uses a GMV (Gross Merchandise Volume) pricing model, meaning your costs are tied to store revenue. This model bundles the Enterprise license cost into the overall price. By contrast, Upsun pricing is perfectly created to fit your needs. Upsun charges based on actual resource usage, so if you require the Magento Enterprise edition, you’ll need to purchase that license separately.
-   **Support and user experience**: Adobe Commerce Cloud provides integrated support for certain Magento applications and runs on its established, legacy console, which may limit flexibility and access to the latest features. Upsun, while offering similar infrastructure automation, delivers a more modern developer interface and broader application support.
-   **Functionality and flexibility:** Although both platforms offer similar automated scaling and CI/CD pipelines, Upsun stands out by allowing you to work with multiple frameworks and languages beyond Magento. This versatility eliminates vendor lock-in and is particularly valuable for organizations considering Magento Open Source or mixed-technology environments, whereas Adobe Commerce Cloud is strictly focused on the Magento ecosystem.

These distinctions help clarify your platform options: Adobe Commerce Cloud may offer cost advantages via its bundled Enterprise license and GMV pricing, but Upsun provides greater flexibility and a more contemporary management experience if you require a multi-framework approach or plan to utilize Magento Open Source. 

## 4\. Putting it all together

For Enterprise Magento or Adobe Commerce, you have to think in terms of _total cost of ownership_ (TCO), business agility, security, and developer productivity. Let’s break it down:

-   **Scalability**: DIY cloud hosting: Scaling involves configuring cloud resources—often using features like auto-scaling groups or container orchestration. Although adding capacity is easier than buying physical hardware, you still have to carefully plan and monitor usage to prevent performance bottlenecks or cost overruns.
-   **Managed hosting**: Easier than DIY cloud hosting, but may be limited by your contract or the physical resources of the hosting provider.
-   **Upsun**: Automated scaling on major cloud infrastructures. Scale as needed, paying only for the resources you use.
-   Adobe Commerce Cloud: Has built-in scaling within Adobe’s infrastructure, but lacks the multi-cloud flexibility of Upsun.

-   **Maintenance and updates:**
    -   **DIY cloud hosting**: You’re in charge of your own virtual machines or containers, handling OS patching, security hardening, and performance tuning. While you avoid maintaining physical servers, the burden of routine upkeep in the cloud still falls on your team.
    -   **Managed hosting**: The host handles OS-level updates, but you’re still in charge of the Magento stack.
    -   **Upsun**: Fully managed DevOps pipeline, from building to deployment. Automated updates and security patches.
    -   Adobe Commerce Cloud: Similar to Upsun, application security patches can be applied via composer.
-   Deployment and testing:
    -   DIY cloud hosting: Deployments can still be somewhat manual unless you set up your own CI/CD pipelines. You must also coordinate how data and configurations are replicated across test environments, which can become complex without built-in cloning features.
    -   Managed hosting: Some managed hosts offer staging areas, but often it’s limited to only a single environment or a partial data set.
    -   Upsun: Seamless environment cloning for every feature branch. Test code and updates in parallel without manual copying or risky merges.
    -   Adobe Commerce Cloud: Provides a staging environment, but the process of replicating data and code can be more cumbersome, with less granularity or automation than Upsun.
-   Security and compliance:
    -   DIY cloud hosting: Your cloud provider handles physical data center security, but you’re responsible for securing OS-level configurations, applying patches, and ensuring compliance with industry regulations. Advanced measures like WAF, intrusion detection, or specialized compliance certifications require additional work.
    -   Managed hosting: Basic server security is handled, but advanced compliance or custom security implementations can be extra or unsupported.
    -   Upsun: Built-in redundancies, automated backups, integrated WAF, and compliance certifications. Fine-grained permissions and ephemeral environments help you shift left in your security approach.
    -   Adobe Commerce Cloud: Includes PCI compliance for payment data and Adobe’s security baseline, but you have less visibility into the underlying infrastructure than a dedicated environment on Upsun.
-   Cost and ROI:
    -   DIY cloud hosting: Avoiding physical hardware expenses is an advantage, but monthly cloud bills can be unpredictable if your workloads aren’t carefully managed. You also need skilled staff to optimize and monitor usage, adding to operational costs.
    -   Managed hosting: More predictable than DIY cloud hosting, but specialized Magento support or add-ons can drive up costs.
    -   Upsun: Pay for only what you use, with no hidden costs for environment cloning or CI/CD automation. Reduces DevOps overhead, giving your teams more time to innovate.

Adobe Commerce Cloud: A high-end solution bundled with Adobe’s ecosystem. While it offers top-tier features and support, the pricing model is based on gross merchandise value (GMV). As your store’s revenue scales, costs can rise quickly—even if you don’t need all the bundled functionality.

## The bottom line: Why Upsun?

Running a successful enterprise-level Magento/Adobe Commerce store means juggling multiple priorities: speed, reliability, security, and the ability to pivot quickly. DIY cloud hosting can be appealing if you want full control over your resources. However, managing provisioning, scaling, and maintenance can become a major drain on your team’s time, especially when spikes in traffic or unexpected issues arise. Managed hosting offers an improvement, freeing your teams from some maintenance tasks, but you might still run into rigid configurations and limited automation.

Adobe Commerce Cloud provides a holistic solution, automating infrastructure under Adobe’s umbrella. But if your organization demands more flexibility or you want to orchestrate custom integrations, you may find yourself constrained by what the platform allows.

Upsun, by contrast, is designed to streamline every stage of Magento/Adobe Commerce development and operations. Automating infrastructure, CI/CD, environment cloning, and security compliance ensures your team can deploy new features faster, test at will, and scale effortlessly, all while controlling costs. Plus, with hosting regions worldwide through AWS, Google Cloud, and Azure, you can serve customers across the globe with minimal latency.

### Key takeaways

-   DevOps at scale: A robust pipeline that handles everything from commits to deployments.
-   On-demand environments: Spin up a clone of your entire site (data included) for every feature branch or hotfix.
-   Multicloud advantage: Choose from various data centers around the world, distributing workloads to meet local regulations and reduce latency.
-   Unified workflow: A single platform for building, deploying, and running your Magento/Adobe Commerce store, removing friction between dev, ops, and business teams.

Future-ready: Whether you’re integrating a new payment gateway or shifting to headless commerce, the flexibility and advanced tooling by Upsun let you adapt quickly to emerging demands.

## Conclusion

When it comes to enterprise-level Magento/Adobe Commerce hosting, there’s no one-size-fits-all solution. DIY cloud hosting might be right if you want granular control over your environment, but it demands significant oversight and time commitment for configuration, maintenance, and scaling. Managed hosting reduces maintenance, but might limit your configuration and automation options. Adobe Commerce Cloud offers all-in-one convenience but can lock you into Adobe’s ecosystem with less customization freedom.

Upsun stands out by delivering the best of all worlds: flexibility, reliability, security, and powerful automation. It’s built to let you innovate rapidly, test fearlessly, and scale without headaches. If your mission is to provide a fast, secure, and evolving eCommerce experience without drowning your teams in operational overhead, then Upsun may be the perfect fit.

In the fast-paced landscape of enterprise eCommerce, your platform should free you to think beyond the basics of hosting. With Upsun, you don’t just get servers and storage—you get a fully integrated cloud solution that empowers your business to focus on what truly matters: delivering a stellar experience to your customers and driving revenue.

_Ready to learn more about hosting your Magento/Adobe Commerce site on Upsun?_  
Check out the Upsun Magento offering and see how easily you can transform your eCommerce operations, from DevOps to deployments on a single, powerful platform.

### [Why Terraform and Kubernetes slow application teams | Upsun](https://upsun.com/blog/why-terraform-and-kubernetes-slow-application-teams/)

# The cognitive tax of Terraform and Kubernetes for application developers

Terraform and Kubernetes are powerful tools. They are also two of the most common sources of friction between application teams and the infrastructure they depend on.

When delivery slows down or incidents happen, it is tempting to frame the problem as a skills gap: developers do not understand infrastructure well enough. In practice, that framing misses the point.

The real issue is not a lack of ability. It is a mismatch between who these tools are designed for and who is often expected to use them. This gap between what developers are hired to do and what they are asked to manage creates a cognitive tax. It slows delivery, increases risk, and drains energy.

**Why infrastructure tools drain developer time**

Most application developers don’t want to worry about infrastructure. From a developer’s perspective, infrastructure should simply _be_: predictable, available, and consistent across environments. When it fades into the background, teams move faster. When it demands attention, it pulls focus away from product work, which then affects your customer’s experience.

Yet ask most developers where their time actually goes, and you'll hear the same answers:

-   Fixing failed deploys that worked yesterday
-   Updating Terraform files for small config changes
-   Chasing IAM or networking errors, they did not design
-   Keeping dev, staging, and production "close enough."

None of these ships product value. Yet it demands focus, context switching, and constant re-learning.

Terraform and Kubernetes make this worse by requiring developers to think explicitly about infrastructure behavior. They expose concepts like resource lifecycles, dependency graphs, networking, permissions, and failure domains. None of these are inherently bad, but they assume a mental model that most application developers don't operate in day to day.

## **Why Terraform and Kubernetes are hard to reason about without infra context**

The difficulty isn't syntax. It's causality. Understanding what a configuration change _does_ is not the same as understanding _when_ it applies, _where_ it propagates, or _what else_ it might affect. Small changes can have non-obvious side effects, especially when the state is shared across environments or teams.

For someone whose primary mental model is application logic, requests, data flow, and business rules, this kind of reasoning is expensive. It requires context switching into an entirely different domain, often under time pressure.

Application developers rarely get time or training to build that depth. So they operate with partial understanding. That partial understanding leads to predictable outcomes:

-   Changes that look safe but break production
-   Copy-pasted configs that drift over time
-   Fear-driven workflows where nothing is touched unless necessary

Most outages caused this way are not due to carelessness. They come from tools that require infrastructure expertise but are used by people hired for application work.

 For a deeper look at how Kubernetes complexity accumulates, see The hidden cost of “just using Kubernetes".

### **The hidden cost of forcing infra tools into app workflows**

When application developers are pushed to work at the level of infrastructure primitives, a few predictable things happen.

Teams slow down, not because the work is harder, but because every change requires extra validation and second-guessing. Developers become cautious. Reviews focus on configuration risk instead of product intent. Small changes feel heavier than they should.

Over time, infrastructure knowledge concentrates in a few people. Others avoid touching it. Bus factors grow. Delivery becomes uneven.

### **Partial understanding creates fragile systems**

Many real-world system outages don't come from reckless changes. Most often, they result from limited knowledge.

A developer makes a reasonable change based on local context. The configuration validates. The deployment succeeds. And yet, something downstream behaves unexpectedly — a permission boundary is crossed, a service is rescheduled, a resource is recreated instead of updated.

When developers are asked to manage infrastructure primitives, these failure patterns appear constantly:

-   A small config change triggers a large redeploy
-   An environment differs slightly, but enough to cause bugs
-   A permission fix solves one issue and creates another
-   A staging fix never reaches production

From the outside, this can look like carelessness. From the inside, it's usually the result of subtle abstractions that leak.

The deeper problem is that developers are forced to think about too many things at once. Feature logic, infrastructure logic, deployment logic, and environment differences all compete for attention. Cognitive overload increases error rates. That is human, not technical.

This is why teams often respond to incidents by adding more rules, more reviews, or more process rather than addressing the underlying mismatch. 

## **What developers should and shouldn’t own**

Some infrastructure concerns now feel outdated for application teams:

-   Manually creating or cleaning up environments
-   Debugging config drift between stages
-   Writing YAML to describe runtime basics
-   Recreating production conditions by hand

These tasks persist mostly out of habit. Modern platforms can handle them automatically, with guardrails instead of choices. A "boring" workflow is a good one: predictable, repeatable, and uneventful.

Removing the infrastructure burden doesn't mean ignoring infrastructure. It means shifting ownership.

**Developers should own:**

-   Application code
-   Runtime configuration that affects behavior
-   Data models and migrations
-   Performance at the code level

**The platform should own:**

-   Environment creation and teardown
-   Service wiring and networking
-   Scaling, routing, and baseline security
-   Consistency across dev, staging, and production

When infrastructure noise is reduced, planning changes. Teams estimate features instead of deployment risk. Releases become smaller and more frequent.

## **How Upsun removes the cognitive tax**

Upsun eliminates the infrastructure burden for application developers. Instead of managing Terraform state and Kubernetes manifests, developers define their application using Upsun configuration files stored alongside their code.

Every Git branch automatically becomes a complete, isolated environment: a full clone of the application and its services, including configuration and data. Here is how Upsun addresses the specific pain points developers face:

-   **"Fixing failed deploys that worked yesterday"** — Upsun guarantees environment parity. The same config deploys to development, staging, and production. No drift, no surprises. When you back up an environment, you get a fully consistent snapshot of your whole application.
-   **"Chasing IAM or networking errors"** — Databases, caches, and search engines are managed inside the cluster with no external single points of failure. Declare what you need in your config file. No IAM policies, no VPC configuration, no security group rules to debug.
-   **"Keeping dev, staging, and production close enough"** — They are not "close enough." They are identical. Same YAML, same infrastructure, same behavior. Each child environment can sync code and data down from its parent, so you are always testing against real conditions.
-   **"Fear-driven workflows"** — Instant preview environments let you test any change against real production data before merging. Break things safely, then delete the branch. When the experiment is over, deleting the branch tears everything down automatically, saving compute costs and mental overhead.

The Upsun CLI fits directly into existing workflows. Commands like **upsun push** and **upsun branch** create environments and deploy changes in seconds. GitHub and GitLab integrations automatically spin up environments for pull requests and merge requests. When a branch is created, an environment is created; when the branch is merged, the environment is removed.

Perhaps most importantly, Upsun configuration stays stable over time. No syntax changes between versions that force rewrites or learning curve resets. Your infrastructure knowledge compounds rather than depreciates.

That shift, from managing primitives to building products, is what platforms like Upsun make possible.

### [Drupal deployment pitfalls and cloud fixes | Upsun](https://upsun.com/blog/drupal-deployment-pitfalls-and-cloud-fixes/)

# Common Drupal deployment pitfalls and how cloud automation fixes them

Deploying a Drupal 10 or Drupal 11 application can feel like walking through a minefield of potential problems. Even a well-built Drupal site can stumble during deployment due to a few common pitfalls. For IT managers and technical project leads, understanding these pitfalls and how cloud automation can solve them means fewer late-night emergencies and smoother launches. 

In this article, we’ll explore the most frequent Drupal deployment challenges (environment inconsistencies, dependency management, configuration drift, end-to-end testing, security risks, and scaling issues) and see how a Cloud Application Platform like Upsun can fix them. Let’s dive in with short, focused sections that you can quickly scan and apply.

## **Environment inconsistencies**

We’ve all heard a colleague say, _“But it worked on my machine!”_ Environment inconsistencies occur when your development, staging, and production environments differ in configuration. Perhaps the PHP version or database engine is slightly different on prod, or a caching setting is enabled in one environment and not another. These differences turn into unexpected bugs at the worst times. For example, a Drupal module might behave differently if a PHP extension is missing in production, or if file permissions and PHP memory limits vary between servers. The **pitfall** here is not maintaining parity between environments, which leads to surprises during deployment.

**How cloud automation solves this:** A cloud platform can ensure every environment is an identical twin of production. Upsun, for instance, allows you to clone the entire production stack (code, database, and configuration) into a staging environment through its environment cloning feature. This process creates a replica of your production environment, making it straightforward to test changes with real data and configurations. This means your devs are always testing on an environment that mirrors production—no more “snowflake” servers or mysterious prod-only bugs. Configuration files and environment variables can be managed consistently across all environments.

 In practice, this approach follows the dev/prod parity principle: keeping environments as similar as possible to catch issues early. By automating environment setup, a Cloud Application Platform eliminates the “works on my machine” syndrome and standardizes Drupal’s operating conditions across the board.

## **Dependency management issues**

Modern Drupal relies on Composer for managing PHP dependencies, modules, and libraries. For centralized dependency management to be effective, it must be applied consistently across environments. It is important to have an automated process for installing and updating dependencies, and to avoid, for instance, manually copying files (including the vendor directory) between environments, which can lead to inconsistencies and human error. 

**How cloud automation solves this:** The key is to let automation handle dependencies the same way everywhere by creating a deployment process that will rely on Composer and treat the composer.lock as gospel. A platform like Upsun can be configured to automatically run composer install during the build phase of deployment, using the exact versions specified in composer.lock. This guarantees that if it worked in testing, the same modules and libraries (down to the version) will be present in production. No more “it works on dev but not on prod” due to missing or inconsistently installed dependencies. By automating Composer runs and keeping dependencies in sync, cloud deployment platforms prevent Composer nightmares. The result is a consistent Drupal codebase everywhere, with no surprises.

## **Configuration drift**

Drupal 8 introduced robust configuration management, storing site settings, views, and content types in YAML files that can be exported and imported. In theory, this means you can develop configuration changes (say, a new content type or updated view) in a dev environment and deploy them to production in a controlled way. **In practice,** teams often encounter _configuration drift_. This pitfall happens when configuration changes are applied ad-hoc on one environment (like a quick fix on the production site’s admin interface) and not tracked in code. Over time, the configs in production drift away from what’s in version control. The next deployment might inadvertently overwrite or clash with those changes, leading to missing features or broken settings on the live site.

Manually managing Drupal config across multiple environments is error-prone. You might forget to run drush config:export, or forget to import configs on production after deployment. Even small discrepancies, like a toggled setting or enabled module, can cause bugs that are hard to trace.

**How cloud automation solves this:** Cloud platforms tackle config drift by encouraging an “everything as code” approach. With Upsun, for example, you can automate Drupal’s config import and database updates as part of the deployment process. Every time you deploy, a post-deploy hook can run drush updb (to apply any pending database schema changes) and drush cim (to import the committed configuration changes). This ensures that your production environment is always in sync with the config in Git. There’s no chance to skip a step—automation does it every time. Moreover, because you can easily spin up ephemeral environments that include the latest config and production data, your team can test config changes on a real data set before merging to production. This workflow catches config integration issues early and prevents untracked changes from sneaking into production. In short, cloud automation treats Drupal’s configuration as a first-class citizen in the deployment, eradicating drift and the mysterious bugs it causes.

## **End-to-end testing**

You’ve made a small change to your Drupal codebase. Maybe it’s a theme style or script tweak, or a View exposed filter label configuration change, or a change to a text format filter. Or maybe it’s a larger change: a new module, a new entity type, a restyled menu. How carefully have you tested your change? Are you sure your change to a content entry form won’t result in a 500 error? Are you sure that your Twig template changes will work for every content variation they render?

**How cloud automation solves this:** Because deploying a new feature to a development or a staging environment can be done in a consistent, replicable way on consistent, replicable infrastructure, you can apply automated testing to that environment and be assured the results will hold in production. For instance, you might have a test step in CI that requests every page in the sitemap to confirm no 500 status codes. Or you might apply Lighthouse performance testing to make sure your layout shift has not increased, or visual regression testing to confirm a style change hasn’t broken layout in unexpected places. Whatever the test suite, those green checkmarks in the CI mean that you can deploy to production with confidence in your code changes.

## **Security risks in deployments**

Security is a paramount concern for any web application, and Drupal is no exception. A common pitfall in deployments is the lag in applying security updates or misconfigurations that introduce vulnerabilities. In a manual deployment setup, critical updates to Drupal core or modules may be delayed because the process is cumbersome. The result? Your site could be running with known security holes. 

We’ve seen how dire this can be: for example, the infamous Drupalgeddon2 vulnerability in 2018 impacted over a million Drupal sites and allowed remote code execution if not patched promptly​. 

In less dramatic fashion, leaving a development module (like Devel) enabled on production, or displaying verbose error messages, can leak sensitive info to attackers. Another risk comes from how secrets and credentials are handled—hard-coding API keys or database passwords in config files that get shared or leaked can compromise security. Overall, manual, non-repeatable deployment processes tend to create openings for security lapses, either through neglect or simple human error.

**How cloud automation solves this:** A managed cloud platform greatly reduces these risks by making secure practices the default. For one, automated deployments mean you can apply updates quickly across all environments. When a security patch for Drupal core is released, your team can push the update through a continuous deployment pipeline (with robust integration testing) and have it live in production in minutes, not days. This agility is critical when facing zero-day exploits. 

Additionally, Upsun and similar platforms handle a lot of security hardening under the hood: isolating your application containers, enforcing read-only production file systems (so an exploited site can’t easily modify system files), and providing TLS/HTTPS by default. They also offer built-in secret management—so database passwords, API keys, etc., can be injected as environment variables and not stored in code or repo. 

Finally, by eliminating manual server configuration, cloud automation ensures that things like file permissions, PHP settings, and other security-related configurations are consistent and vetted. The platform essentially guides your Drupal deployment to follow best practices (like disabling PHP execution in the uploads directory, using the correct file permissions, and keeping software up to date). The outcome is a Drupal site that’s not only easier to deploy, but also much harder for attackers to crack.

## **Scaling challenges**

Your Drupal site might start on a single server with moderate traffic, but what happens when your marketing team’s campaign brings in a flood of visitors, or your eCommerce Drupal store hits a seasonal peak? Scaling a Drupal application presents another set of pitfalls. The challenges include: ensuring the site can handle high traffic without downtime, scaling out across multiple servers, and maintaining performance under load. 

Traditional deployments on self-managed infrastructure require significant effort to scale: you might need to provision additional servers or containers, set up load balancers, configure a CDN or caching layer, and make sure the database can handle more reads/writes. Without automation, this often involves manual adjustments and could lead to mistakes (like forgetting to include a configuration for a new server in the cluster, resulting in one slow node dragging everything down). 

Even after scaling out, if your application isn’t built for concurrency (for example, writing files to a shared directory improperly or not using a shared cache), you might hit consistency issues. A poorly planned scaling strategy can degrade the user experience—slow page loads or, worst-case, crashes during peak traffic.

**How cloud automation solves this:** A Cloud Application Platform simplifies scaling by abstracting away the heavy lifting. With Upsun, scaling vertically (more resources per node) or horizontally (adding more application instances) is typically a configuration change or a simple command, not an overhaul. The platform takes care of provisioning new servers, updating routing rules, and ensuring each instance has the same code and configuration. This ties back to environment consistency—whether you have one instance or ten, they all run the same code, so you won’t get odd behavior on the additional nodes. 

Cloud automation also integrates caching and performance tooling out of the box. For example, you can easily add a Redis cache or activate Drupal’s built-in caching, knowing the platform will persist cache data appropriately. During a traffic surge (say your Drupal-based eCommerce site runs a flash sale), a cloud platform like Upsun allows you to quickly scale resources up or down to handle the increased load. You can adjust CPU, memory, and storage allocation per environment, or add additional application instances through horizontal scaling configuration changes.

The result is resilience and flexibility: your team can confidently handle growth or spikes without firefighting. And since these scaling operations are tested and repeatable, you avoid the pitfalls of manual scaling (like misconfigured servers or late-night deployment panic). Ultimately, cloud automation lets you meet user demand seamlessly, keeping your Drupal site speedy and available when it matters most.

## **Conclusion**

Deploying Drupal doesn’t have to be a nail-biting ordeal. The common pitfalls, environment inconsistencies, dependency chaos, config drift, integration testing, security gaps, and scaling pains are all solvable with the right approach. The theme you might have noticed is automation and consistency. By leveraging a managed cloud platform such as Upsun, teams can automate away the error-prone parts of Drupal deployments. This means your developers spend less time retracing steps or fixing production-only bugs and more time building features that drive your business forward. 

We know these pains because we’ve lived them, and we also know that modern DevOps tools and Cloud Application Platforms can all but eliminate them. In the end, avoiding deployment pitfalls isn’t about luck; it’s about using the best practices and tools available. With Drupal and cloud automation in your toolkit, you can deploy updates and new sites with confidence, knowing that the platform has your back on the tricky parts. 

Want to experience these benefits firsthand? Our getting started guide for Drupal on Upsun walks you through setting up your first project and implementing these automated deployment practices.

Happy (and hassle-free) deploying!

### [Magento performance best practices for faster storefronts](https://upsun.com/blog/magento-best-practices/)

# Best practices for optimal infrastructure performance with Magento

Magento is a powerful eCommerce platform that drives thousands of online stores worldwide. Its flexible, scalable, and feature-rich environment makes it a top choice for retailers across diverse industries.

However, Magento’s extensive feature set and complexity can create performance bottlenecks, especially as businesses scale. Growing product catalogs, high traffic volumes, and intricate checkout processes can strain site performance, leading to slower load times and reduced conversion rates.

By following key best practices, developers, site administrators, and eCommerce architects can ensure their Magento stores scale efficiently, delivering both high performance and a seamless user experience.

This article explores the recently relaunched Magento 2 Community Edition template on Upsun, highlighting the built-in optimizations. These enhancements incorporate Magento’s best practices alongside our deep experience in hosting and scaling the platform.

## **One-click Magento deployment on Upsun**

One of the biggest advantages of Upsun is the one-click Magento deployment feature, which simplifies the setup process. This pre-configured environment includes:

-   **ECE Tools** for automated cloud deployments
-   **Fastly CDN** **integration** for improved performance
-   **Optimized Redis** **caching** for enhanced speed  
     

## **The latest Magento optimizations for maximum efficiency**

Let’s start with the composer.json file from this repo. This file provides the building blocks of the application. We’ve included the following to make life easier for your development workflow:

```Javascript
"magento/ece-tools": "^2002",
    "fastly/magento2": "*",
    "markshust/magento2-module-disabletwofactorauth": "*",
    "n98/magerun2-dist": "*"
```

#### These packages enhance the Magento experience on Upsun

-   Ece-tools simplifies building and deploying on Upsun by detecting the platform and adjusting the application configuration using our provided environmental variables. 
-   We also include the Fastly module, our CDN of choice. Additionally, we include a separate package that disables two-factor authentication (necessary because development environments aren’t always able to send verified mail) and; 
-   n98 magerun tool, which can be called from within your application using:     

```Javascript
vendor/bin/n98-magerun2
```

The composer file also uses the mirror https://mage-os.org/distribution/  

Using the https://repo.magento.com/ mirror requires authentication. If you wish to use it, just follow the instructions in the repository.

#### **The next important step file in the repository is** **.magento.env.yaml**  

  
 This file is the heart of the application Magento configuration and contains a lot of small performance and stability enhancements.

-   In our configuration, for caching alone, we’ve added multiple performance enhancements, a separate Redis Session service, L2 Caching, and Stale Cache, and Preloading of certain cache keys—all now enabled by default.
-   We adjusted the cron and consumers to process only 250 messages at a time. Ensuring all consumer crons run, but do not run indefinitely. You can adjust crons and increase this value on larger plans.
-   The Static Content Deployment (SCD) is set to the quickest and shortest deployment times possible with Magento using a compact SCD strategy. If you add or remove modules, make sure to use the below snippet to push the correct state:

```Javascript
vendor/bin/ece-tools config:dump
```

Our .upsun/config.yaml file has been updated with new services to support the latest version of Magento. It also has two MariaDB tweaks, which help with long-running indexing processes:

```Javascript
optimizer_switch: “rowid_filter=off”
optimizer_use_condition_selectivity: 1
```

#### **Last but definitely not least is the .upsun/config.yaml**

  
 We’ve added additional read-and-write endpoints for the database service. And if you deploy the template on a highly available cluster, the multiple endpoints will be available for Redis, too. 

-   The build hook installs nvm and node, just in case you use a PWA within your build and/or MagePack. It then uses the ece-tools process to build and complete SCD. 
-   The last line of the build is a small change; it ensures all crons delivered to the application are set to run sequentially, not in parallel. If you have ample resources, you can choose to remove this line.
-   Ece-tools handles the deployment and post-deployment processes, detecting and updating necessary configurations and application upgrades.
-   The cron section has been updated to handle the sequential cron process. Now, there’s a cleanup process for the reports folder and a 10-day log rotation for application logs.

Locations are the standard for the Magento application, with the addition of examples for an Apple Pay pass-through. We often see Apple Pay domain verification as a merchant requirement.

## **Three essential Magento best practices for peak performance**

Along with the template and the best configuration for the application, we recommend these best practices when using Magento.

### 1\. Use Content Delivery Networks (CDNs)

A CDN like Fastly can offload traffic and reduce Time to First Byte (TTFB) globally. By leveraging CDNs, you can improve page load speeds by up to 60%, as shown in real-world implementations.

#### **CDN recommendations:**

-   Reduce automated flushes: Check Fastly for excessive cache flushes—automated flushes triggered by misconfigured modules can defeat caching entirely.
-   Leverage key Fastly features: Upsun includes additional Fastly features to enhance performance.
-   Full page cache for Fastly CDN: All operations act on the CDN exactly as if performed on your infrastructure instances.
-   Fastly Image Optimizer (Fastly IO): Use this to offload image transformation to the Fastly cloud, reducing latency and improving initial content delivery speed to your end users. Fastly IO is included with your Fastly service; you can enable it from your Adobe Commerce admin panel. For full details, please see the Adobe Commerce Cloud documentation.
-   You only need to keep a single high-resolution copy of each image on the server. Fastly provides an appropriately sized image for thumbnails and slow or low-resolution devices. It works on common image formats like .png, .jpeg, and .gif.
-   The Fastly Image Optimization snippet consists of VCL code to perform image optimization on the Fastly edge nodes.
-   Two-stage cache: Replies are cached both close to the customer and close to your Adobe Commerce server.
-   Force TLS: When enabled, this setting redirects all HTTP requests to HTTPS.
-   Edge Access Control Lists (ACLs): This can manage IP addresses that are used to allow or block access to resources.
-   Error/Maintenance page: With this feature, set up a custom 503 page with your branding.
-   Basic authentication: You can toggle HTTP basic authentication to restrict access to a website.
-   Geo-IP: You can redirect visitors to the storefront based on their country code or restrict access for countries where you don’t do business.

### 2. **Optimize server-side performance**

Exploring key integrations and toggling the right settings can drastically improve the performance of your Magento store.

**Server-side optimization recommendations:**

-   Set memory limits: Set appropriate `php.ini` memory limits for server stability. For most environments, 512MB or 1GB is sufficient. Excessive limits (e.g., 4GB) may indicate underlying performance issues and should prompt further investigation.
-   Proper error recovery: Restart Nginx and PHP processes after significant fixes or changes to remove orphaned workers and ensure efficient resource utilization. End users can do this via _runsv, systemctl,_ or _pkill._
-   To keep admin backend pages from timing out, Magento typically gets configured with _max\_execution\_time_ of at least 600s (10 minutes). But when things break down, you end up with orphaned PHP workers trying to return requests to clients who have already given up on receiving those requests, or worse, to clients who have already refreshed the page. That’s why this is critical to speed up recovery after a service failure.
-   PHP and web server configuration: Optimize PHP-FPM settings to ensure you don’t run out of memory for your PHP workers. 
-   Database tuning: Explore MySQL or MariaDB performance optimization strategies such as database indexing, query caching, and using read-write separation in multi-server environments. Regularly analyze and optimize slow queries using tools like `mysqlslowdump` to prevent outages caused by poorly performing queries.
-   Run Mysqlanalyze often—at least after every service and application upgrade, but ideally on a regular schedule.
-   Ensure that tables are optimized during maintenance windows. This can release disk space and help improve performance.  
     

### 3\. Leverage performance monitoring and profiling tools

Performance optimization isn’t a one-time initiative, it’s an ongoing process. Continuous monitoring and testing are essential to maintaining stability.

#### **Monitoring and profiling recommendations:**

-   Blackfire: Use tools like Blackfire to monitor and profile Magento’s request-response cycle, identifying areas of improvement.
-   Magento Profiler: Utilize Magento’s built-in profiler to measure database query execution time, block rendering time, and memory consumption.
-   Continuous load testing: Implement load-testing frameworks such as Apache JMeter and Gatling to simulate high-traffic scenarios and benchmark system performance under stress.
-   Modules: When facing a performance problem, can you reproduce the problem with only core modules? If not, it's the modules.   
     

### **Final takeaways: don’t just add more resources—fix the root cause**

A major piece of advice from our recent Magento webinar was to avoid simply adding more resources to address performance issues. Instead, focus on diagnosing and fixing underlying bottlenecks.

By following these best practices and configuring your Magento store correctly, you create a foundation for seamless scalability. With the right optimizations in place, you can focus on growing your business instead of troubleshooting platform issues.

Have questions about optimizing your Magento site on Upsun? Reach out, we’re here to help.

## Ready to future-proof your Magento store?

Experience effortless scaling, built-in performance optimizations, and streamlined workflows with Upsun. 

**Next steps:**

-   Try our Magento template with a free 15-day trial
-   Contact our team for migration assistance
-   Schedule a demo to see these optimizations in action

Questions about optimizing your Magento site? Our specialists are here to help you achieve peak performance.

### [The cloud optionality blueprint to end lock-in | Upsun](https://upsun.com/blog/standardizing-the-stack-to-end-vendor-lock-in/)

# The cloud optionality blueprint: standardizing the stack to end vendor lock-in

_Key takeaway: Real cloud strategy isn't about running the same workload everywhere at once; it’s about the freedom to move when you need to. By standardizing the unified configuration file, Upsun enables true cloud optionality, moving provider migration from a re-architect project to a data move project._

## Cloud providers don't want you to be portable

The “sticky cloud” is a business model. Cloud providers don't just sell compute; they sell ecosystems designed to be difficult to exit. Every time a team adopts a proprietary database, a specialized serverless runtime, or a provider-specific IAM policy, the cost of moving increases exponentially.

In 2026, the CTO’s biggest challenge isn't finding a cloud provider; it's maintaining leverage over the ones they already have. Without an exit strategy, you aren't a partner; you’re a tenant with no move-out rights.

## Distinguishing live multicloud from cloud optionality

_Key takeaway: Live multicloud is a technical burden; cloud optionality is a strategic asset. You don't need to run on two clouds at once; you need the ability to switch on terms you control._

The market has conflated two very different concepts.

-   **Live multicloud:** Actively running the same workload across multiple providers simultaneously. This is expensive, requires massive "glue" teams to manage differing runbooks, and often results in least common denominator architecture.
-   **Cloud optionality:** The ability to move your entire stack (applications, services, and data) to a different provider with minimal friction.

Upsun focuses on cloud optionality. We provide the standardization layer that allows you to treat the cloud as a commodity. By defining your application layer, service definitions, and deployment pipelines in a portable `.upsun/config.yaml`, you decouple your architecture from the provider's proprietary trap.

## The unified configuration file: migration as a data move

_Key takeaway: When the stack is standardized via a unified configuration file, the hard work of migration shifts from re-architecting to data synchronization._

On a traditional DIY stack, moving from AWS to GCP requires a multi-month audit. You have to map AWS-specific services to GCP equivalents, rewrite Terraform scripts, and re-train the team on new dashboarding and security protocols.

On Upsun, that effort has collapsed. Because the unified configuration file remains constant across providers:

-   **Integrated services stay the same:** Whether your MariaDB or Redis is an integrated service on AWS or OVHcloud via Upsun, the configuration is identical.
-   **Standardized service versions:** All services defined in your configuration haven't been modified in any way to keep you locked in. They are standard, open-source versions that you can migrate easily to another cloud or even on-premise.
-   **Deployment pipelines stay the same:** Your CI/CD doesn't care which underlying provider you use.
-   **The developer experience stays the same:** There is no "per-cloud" runbook divergence.

The project changes from a high-risk architectural overhaul to a predictable operational task: plan the data migration, test production-perfect clones in the target environment, and then synchronize data for a seamless transition.

## Pragmatic simplicity over the "Kubernetes tax"

_Key takeaway: True portability shouldn't require a dedicated team of 20 SREs. Upsun delivers Kubernetes outcomes without the complexity lock-in of manual orchestration._

Competitors often suggest that "bringing your own cloud" (BYOC) or managing your own Kubernetes clusters is the only way to avoid lock-in. 

This is the hidden Kubernetes tax. You trade provider lock-in for significantly more toil and a hidden tax on senior engineering capacity.

Upsun offers a different path:

1.  **Standardized environments:** We manage orchestration, scaling, and maintenance, removing most of the operational glue that typically slows teams down.
2.  **Global reach:** Upsun provides options for AWS, Azure, GCP, IBM Cloud, and OVHcloud in multiple regions.
3.  **Cost governance:** When you have cloud optionality, you can move workloads to a different provider to take advantage of better regional pricing or specific compliance requirements (like moving a project to OVHcloud for localized European data sovereignty).

## Taking back control

Cloud optionality is about de-risking your business. It allows you to say "no" to price hikes and "yes" to better regional availability. By using Upsun to standardize your infrastructure, you ensure that your team stays focused on building features, not managing the divergent quirks of five different cloud consoles.

The cloud should be your engine, not your cage.

## Frequently asked questions (FAQ)

**Does Upsun support "Active-Active" multicloud deployments?**

Upsun primarily focuses on cloud portability and optionality. While we enable you to deploy the same application stack to any major provider using identical workflows, our goal is to provide the portability needed to facilitate your own automated cross-cloud failover and disaster recovery strategies without the complexity of managing multiple proprietary stacks.

**How does Upsun handle data migration during a provider switch?**

Because Upsun manages your integrated services, we facilitate the export and import of data across providers using the same CLI tools you use for local development. Our production-perfect preview environments allow you to test the entire migrated stack before you flip the switch.

**Can I move from a proprietary AWS service to a standardized one on Upsun?**

Yes. We help teams decouple from proprietary sticky services (like AWS RDS or SQS) by moving them to integrated services, such as PostgreSQL, MariaDB, RabbitMQ, or Kafka, within the unified application spec. Because these services haven't been modified to keep customers locked in, your stack remains portable and ready to move to any other cloud provider, or even on-premise, without an architectural overhaul.

**What is the "Kubernetes tax" you mention?**

The "Kubernetes tax" refers to the massive amount of engineering time, salary, and mental overhead required to build and maintain a custom Kubernetes platform just to achieve portability. Upsun gives you those outcomes out of the box, without having to operate those systems directly.

### [Upsun’s AI story: how to be part of the successful 5%](https://upsun.com/blog/how-to-be-in-the-successful-5-percent-of-ai-pilots/)

# Upsun’s AI story: the 5% path from pilots to production value at scale

## **If your AI pilot “works,” it might still be failing**

Here’s the uncomfortable truth: most companies do not have an AI problem. They have a delivery problem wearing an AI costume.

MIT’s Project NANDA research has been widely cited for a brutal headline statistic: roughly 95% of corporate generative AI pilots fail to produce measurable business impact or returns, while only about 5% break through to meaningful outcomes. (Yahoo Finance) The models are impressive. The demos are dazzling. The budgets are real. And yet the results rarely survive contact with production workflows.

If you are leading an AI initiative, that number should not depress you. It should focus you.

Because the “5%” are not necessarily the companies with the biggest GPU spend, the flashiest chatbot, or the loudest AI rebrand. The 5% are the ones that treat AI like any other production capability: versioned, tested, observable, secure, and repeatable. They build systems where AI can be evaluated against real data, in real environments, with real governance. They connect pilots to workflows, not slides. And they stop confusing experimentation with delivery.

That is where Upsun’s AI story starts.

We are not here to sell hype. We are here to help teams ship. We are here to help you get your Proof of Concept (PoC) reliably into production.

Our strategy is simple: focus on helping our customers in the three places where AI outcomes are won or lost.

1.  Support our customers’ AI goals by giving them the platform foundations that make AI reliable in production.
2.  Support AI-augmented development workflows so teams can build and iterate faster, with less friction and less guesswork.
3.  Use AI wisely inside Upsun, solving the problems that genuinely block progress instead of bolting on a chatbot and calling it innovation.

If you want to be in the successful 5%, you do not need more AI theater. You need a better path from idea to production.

## **1\. Support our customers’ AI goals without pretending everyone needs GPUs**

Let’s address the question we get right away.

“Where are the GPUs?”

We do not offer GPU infrastructure in Upsun today, and that is intentional.

Most companies we speak with are not training foundation models. They are not running large-scale inference fleets on their own hardware. They are building products that consume best-in-class models through APIs and services, then wrapping those capabilities with company-specific context, governance, and user experience. That is not a compromise. It is the dominant pattern.

So instead of building a GPU catalog to check a box (and waste a lot of time and resources), we put our effort where it helps the majority of teams succeed: everything around the model.

Because models are not the hard part anymore. The hard part is making AI features behave like production software.

**For more info:** _If you’re weighing GPU spend for an AI feature rollout,_ _**this deep dive**_ _breaks down when GPUs actually matter, and why most AI applications run fine on CPU_

### **What teams actually need to ship AI features**

When AI initiatives stall, it is rarely because “the model wasn’t smart enough.” More often it is because the system around the model was not designed for:

-   repeatable environments
-   consistent configuration
-   production-like testing
-   isolation and safety controls
-   fast iteration across branches
-   observability and debuggability
-   cost predictability

In other words, teams succeed or fail where platforms either help or hurt.

Upsun’s thesis is that AI workloads look like modern applications: they span multiple services, they evolve quickly, and they need to be governed like everything else. That is exactly what a cloud application platform should excel at.

### **Flexible runtimes are not a nice-to-have, they are an AI requirement**

AI has a funny effect on technology stacks: it makes them more diverse, not less.

A team might ship a Node.js API, a Python retrieval service, a background worker for document processing, and a small PHP admin interface, all in the same product. Another team might have a .NET application that calls model APIs, with a Python microservice for evaluation harnesses and batch jobs. AI multiplies this “glue code,” and glue code shows up in whatever language makes sense.

That is why runtime flexibility matters.

Upsun is designed to support common and less-common runtimes across languages and frameworks, with Git-driven configuration and predictable deployment flows. That means AI teams can choose the right tool for each part of the system without having to beg an internal platform team for exceptions or wait months for a bespoke runtime.

This is also why “API-centric” matters. AI products are API products. They integrate with model providers, data sources, observability stacks, queues, and internal services. A platform that makes integrations awkward will quietly kill AI momentum.

### **The real differentiator: isolated environments with real data**

If we had to pick one reason AI projects fail in production, it would be this:

Teams do not test AI behavior under production-like conditions.

They test prompts in a notebook. They test a small dataset. They test with “happy path” inputs. Then they ship, cross their fingers, and hope.

That approach fails for normal software. With AI it fails faster and louder, because the edge cases are the product. Small data quirks, formatting differences, missing fields, or stale context can flip outputs. Evaluations that look great in a controlled environment can crumble when exposed to the messy reality of actual users.

So our platform story for AI starts with environments.

Upsun’s Git-driven approach enables teams to spin up isolated environments per branch, with configuration tracked and versioned. Pair that with production-like data workflows (including cloning and sanitization patterns where appropriate), and teams can validate AI features under realistic conditions before they hit users.

This is not just about correctness. It is about confidence.

AI features are inherently probabilistic. You cannot eliminate uncertainty, but you can eliminate guesswork about whether your system behaves the same way in dev, staging, and production.

That is how teams move from “this seems fine” to “we can ship this.”

### **AI safety and governance start with environment discipline**

A lot of AI risk is not “Skynet.” It is operational.

-   A developer points a test environment at a production database by mistake.
-   A prompt change bypasses a moderation step.
-   An evaluation harness runs against the wrong model version.
-   A feature branch leaks sensitive data into logs.
-   A new integration quietly increases token spend 10x.

These are not exotic failures. They are basic delivery failures.

The best risk reduction is boring infrastructure hygiene: isolated environments, secrets management, clear service boundaries, and predictable config. If your platform makes those things easy, AI becomes safer by default.

That is the kind of “AI support” that matters for most teams. Not a GPU checkbox. A system that makes shipping AI reliable.

## **2\. Support AI-augmented development workflows beyond “vibes”**

There is another trend that is easy to misunderstand.

AI-augmented development is not just autocomplete.

Yes, code assistants inside IDEs are useful. But the bigger shift is that development workflows are becoming agent-assisted end-to-end. People are using AI to reason about architectures, generate scaffolding, write tests, update configs, triage logs, and propose fixes.

If you want a blunt description for non-technical stakeholders, “vibe coding” captures the vibe, but not the reality. Real teams still need rigor: reviews, guardrails, reproducibility, and accountability.

So we ask a different question:

How do we make Upsun a platform that AI agents can use safely and effectively, while keeping humans primary in the loop?

### **Documentation that AI can actually read is now product infrastructure**

Teams do not just read docs anymore. Their tools read docs.

That changes what “good documentation” means. It is no longer enough to have pages that look nice. Docs need to be structured, consistent, and machine-consumable, so assistants can retrieve the right information without hallucinating.

That is why we invest in:

-   clean, structured documentation that can be mirrored and consumed reliably
-   clear examples with copy-friendly snippets
-   explicit schema validation and publishable config definitions
-   artifacts like llms.txt that help AI tools find authoritative sources

These details sound small. They are not.

In an AI-augmented workflow, bad docs do not just slow humans down. Bad docs become bad outputs at scale.

### **MCP and “platform-aware” agents are the next step**

As agentic workflows mature, developers will expect assistants to do more than write code. They will expect agents to understand the platform they deploy on.

That is where MCP (Model Context Protocol) becomes interesting.

With MCP-style integration, an AI assistant can retrieve authoritative platform context: configuration schemas, best practices, environment details, and operational constraints. Instead of guessing how to structure a config file or how to wire services together, the assistant can query the source of truth.

Upsun’s direction here is straightforward: give customers MCP options that reduce friction and increase correctness.

That includes ideas like:

-   an MCP server that exposes relevant Upsun knowledge and workflows safely
-   schema-first tooling so config generation is validated, not improvised
-   curated context packs (for example, “Context7 MCP” style patterns) so assistants use the right docs and examples

The principle is more important than any single implementation: we want customers to spend less time fighting tooling and more time shipping.

### **Vector databases are where “AI apps” stop being demos**

If you are building AI features that go beyond a chatbot, you end up needing retrieval. You need a place to store embeddings, run similarity search, and attach real-world metadata and filters so your application can fetch the right context at the right time. In other words, you need a vector database or a vector-capable data layer.

Upsun supports that workflow in a pragmatic way.

If you want a dedicated vector store, you can run **Chroma** as part of a multi-application project on Upsun. Chroma is a popular an open-source vector database designed for AI applications that need to store, query, and manage embeddings efficiently,  and outline how to configure it as a Python application with persistent storage across deployments.

You can also run **Qdrant**, which is a vector similarity search engine and vector database designed for semantic matching and filtering-heavy use cases. Again, Upsun supports running it as a standalone application in a multi-application project, keeping it isolated, configurable, and persistent across deploys.

This matters for AI-augmented development because retrieval is not something you validate by reading code. You validate it empirically:

-   Does the ingestion pipeline generate stable embeddings across versions?
-   Does retrieval change when dependencies change?
-   Does your prompt behave differently when the vector index is rebuilt?
-   Are you accidentally leaking sensitive data in the retrieved context?

Branch-based environments make these questions testable. Your AI agent can build an environment from a branch, run ingestion against a cloned dataset, evaluate retrieval quality, and give you evidence, not vibes. That is the difference between “demo ready” and “production ready.”

### **Composable image: multi-runtime apps without duct tape**

AI workflows also tend to break the “one runtime per app” assumption.

A very common pattern looks like this:

-   A web API runtime (Node.js, PHP, or Java) serving requests and orchestrating calls to LLM APIs
-   A Python runtime for ingestion, embedding generation, evaluation harnesses, or background workers
-   A vector store (Chroma, Qdrant, OpenSearch, or a Postgres-based strategy) connected via internal networking
-   A pile of native dependencies that do not fit neatly into a single language toolchain (PDF parsing, image processing, system libs, etc.)

Upsun’s **composable image** is built specifically for this reality. It enables you to install several runtimes and tools in your application container, and it is built on **Nix**, which means you can pull from a very large package ecosystem and keep builds deterministic and reproducible.

Just as importantly, Upsun’s composable image is explicitly designed for **multiple runtimes in a single application container**. In a composable image, you can add multiple runtimes to a single application container via configuration, so your Node API and Python worker can coexist without inventing a fragile build process from scratch.

Because it is configuration-driven, it is also AI-friendly. Your assistant can propose changes to the exact config that defines how your environment is built, not just code that assumes the runtime magically exists.

Upsun also supports the practical details teams always get stuck on:

-   Declaring multiple runtimes (for example PHP plus Node.js plus Python)
-   Adding runtime-specific extensions (for example, PHP extensions) and additional packages via Nixpkgs
-   Keeping dependencies explicit and reproducible, which is critical when your AI pipeline needs to behave the same way across dev, preview, staging, and production

And if your vector approach leans on Postgres for parts of the stack, Upsun supports enabling PostgreSQL extensions through configuration, rather than through manual ops steps. Upsun documents enabling extensions under `configuration.extensions` in `.upsun/config.yaml`, and notes that extensions must come from the supported list.

### **The point is not “AI everywhere.” It is “AI that can ship.”**

Put these pieces together and the philosophy becomes clear:

-   MCP gives your AI tools context about the stack.
-   Branch environments give you a safe, production-grade place to validate changes against cloned services and real data.
-   Vector databases and composable, multi-runtime builds turn retrieval workflows from brittle prototypes into repeatable systems.

That is AI-augmented development the way it should be: less “look what the model wrote,” more “here is the environment, the data, the retrieval layer, and the proof that it works.”

## **3\. Use AI wisely inside Upsun to solve the right problems**

The third part of our AI story is internal, but it shows up in the customer experience.

We are using AI in Upsun, but we are selective. We are not interested in “AI for AI’s sake.” We do not want to ship a generic chat widget, rename the company, and call it a roadmap.

We want to apply AI where it removes real friction.

And we want to do it in a way that respects a hard reality: most AI pilots fail because they never connect to the workflow. (Computerworld)

So our product AI strategy starts with workflow blockers.

### **Step one: help users generate configuration safely**

One of the biggest onboarding cliffs in modern platforms is configuration.

New projects often stall at the same point: the developer has code, but needs the right platform configuration to deploy it correctly. They have to choose runtime settings, define services, wire routes, set build steps, handle environment variables, and more.

That is exactly the kind of task AI is good at, if you constrain it properly.

Our first step has been using AI to help customers create config files. That does not mean “free-form prompt and hope.” It means guided generation, grounded in the platform’s schema, with validation and human review.

This is a perfect example of “use AI wisely.”

-   The problem is real and common.
-   The output is structured and verifiable.
-   The value is immediate: faster time to first deployment.
-   The risk is manageable because the result can be validated.

You do not need a chatbot for that. You need an assistant that understands your platform’s rules.

### **What we learned: structure beats cleverness**

Config generation taught us something important:

AI is most useful when you pair it with constraints, context, and a tight feedback loop.

When you give the model structure (schemas), authoritative context (docs), and validation (CI checks or platform validation), you get outputs that are dramatically more reliable than “prompt engineering” alone.

This lesson scales beyond config.

It applies to:

-   environment creation
-   service wiring and discovery
-   safe secret handling
-   deployment workflows
-   troubleshooting and debugging flows
-   operational recommendations

In other words, the best product AI features look less like conversation and more like automation with intelligence.

### **The next step: agents that help customers operate, not just deploy**

Once you can generate config safely, the next logical move is to help customers reason about what happens after deployment.

That is where agentic capabilities can bring real value, especially when paired with observability.

Imagine an assistant that can:

-   look at a failed deployment and explain the most likely cause
-   point you to the exact config setting or log line that matters
-   propose a change as a pull request, not as a paragraph
-   set up a preview environment automatically so you can validate the fix safely
-   compare behavior across environments to detect regressions

That is the direction we are moving toward: AI that helps customers get from “something broke” to “it is fixed and verified,” faster.

Again, the point is not to replace engineers. The point is to remove the repetitive investigation work that drains teams and slows delivery.

### **Why this matters: AI adoption is now an execution test**

The MIT “GenAI Divide” framing resonates because it captures what many leaders feel: adoption is high, transformation is low. (Yahoo Finance)

That gap is not closed by buying more tools. It is closed by building better systems.

So when Upsun uses AI inside the product, we treat it like any other capability:

-   Does it reduce cycle time?
-   Does it improve reliability?
-   Does it increase developer autonomy?
-   Does it stay transparent and controllable?
-   Can it be tested, validated, and observed?

If the answer is no, it is probably a demo, not a product feature.

## **The Upsun AI story in one sentence**

We are building a platform where AI work is not a special project, but a normal, repeatable, production-grade workflow.

That is how customers stop living in pilot purgatory.

And it is how teams start behaving like the 5%: not by chasing novelty, but by mastering execution.

Because the real competitive advantage in the AI era is not access to models. It is the ability to ship, learn, and improve faster than everyone else, without breaking trust.

Upsun exists to make that boring, powerful loop easier.

-   Git-driven everything, so environments and infrastructure stay consistent.
-   Flexible runtimes, so teams can use the right tools for AI workflows.
-   Isolated environments and production-like testing, so teams can evaluate AI safely.
-   AI-augmented development support, so customers spend less time on setup and more time delivering value.
-   Pragmatic product AI, applied where it actually removes friction.

No gimmicks. No rebrand theater. Just a platform that helps you ship.

**If you are building AI features and you want them to survive beyond the demo:**

-   Create a free Upsun account and deploy a branch-based preview environment for your next AI change.
-   Or, if you are evaluating platforms for a larger rollout, contact sales to discuss governance, multi-cloud options, and how Upsun supports production-grade AI delivery.

### [Eliminate the hidden costs of manual setups | Upsun](https://upsun.com/blog/why-manual-debugging-setups-are-a-hidden-factory/)

# The reality check: why manual debugging setups are a hidden factory

The first 70% of a debugging cycle is usually spent on "plumbing", the undocumented toil of syncing databases, matching service versions, and aligning networking to mimic a production failure. 

This manual setup is a hidden factory that consumes senior engineering capacity and delays recovery. True velocity is found by eliminating the infrastructure variables that make bugs hard to reproduce.

### The high cost of manual reconstruction

Most engineering teams treat debugging environments as disposable, one-off creations. When a critical incident occurs, a developer often spends the first hour manually recreating the production state: matching Node.js versions, aligning Redis persistence configurations, and syncing database schemas. 

This manual labor creates “the Rework Loop”: the measurable productivity loss that occurs when developers must rebuild their infrastructure from scratch before they can begin investigating the code.

Most teams are treating context-switching as a people problem when it is an infrastructure problem. And that misdiagnosis is costing them more than they realize. 

### Why environment drift stalls recovery

When the environment is a variable, the "fix" is often a guess. To achieve high-velocity recovery, the environment must be a constant, not a variable. 

**You can start the Upsun free trial to see how standardized environment definitions eliminate this setup tax.**

### From manual plumbing to instant parity

Instead of treating the environment as a static configuration you build from scratch, Upsun treats your infrastructure as a forkable asset. 

By codifying your services once in a version-controlled definition, you enable your team to create a production-identical clone with a single `git push` or a click in the console.

To see how these function in a live workflow, you can watch our 3-minute technical walkthrough on automating environment parity.

### Reclaiming senior engineering capacity

The business impact of the "Hidden Factory" is not just lost time; it is the opportunity cost of pulling senior talent away from feature development to perform repetitive infrastructure tasks. 

Every hour spent "plumbing" a local environment is an hour not spent improving the product or reducing technical debt. 

Standardizing these environments allows junior developers to triage issues with the same environmental accuracy as senior architects, reducing key-person dependency and increasing total team output.

### Landing the fix

The teams that escape “the Rework Loop” share a common trait: their infrastructure is designed to keep developers in flow, not pull them out of it. 

Upsun is built on that premise; it automates the environment parity that usually requires a dedicated DevOps team. 

By forking your entire production stack into an isolated branch, you move directly from a reported bug to an active investigation without the setup tax.

### **Frequently asked questions (FAQ)**

**How does cloning differ from a traditional staging server?**

A traditional staging server is a shared, static resource that requires manual resets and often suffers from data rot. Cloning on Upsun creates a fresh, isolated environment for every branch, meaning multiple developers can triage different production bugs simultaneously without collisions or manual cleanup.

**Does this require rewriting my existing application?**

No. Standardizing your environment on Upsun involves defining your existing services (like your web server, database, and cache) in a configuration file. This codifies what you already have into a repeatable format that the platform uses to generate clones.

**How do you handle sensitive production data during a clone?**

Upsun allows you to use automated hooks to sanitize or anonymize data during the cloning process. This ensures developers have the "production-state" context needed to find a bug without exposing PII or violating compliance standards.

**What happens to the clones once the bug is fixed?**

Because environments are tied to Git branches, they are as ephemeral as the code itself. Once a branch is merged or deleted, the environment is automatically decommissioned, eliminating the "zombie infrastructure" that typically inflates cloud costs.

**Can I clone complex architectures with multiple microservices?**

Yes. Since the entire stack is defined in your configuration, Upsun clones the relationship between all services, including their specific versions and networking logic. This ensures the clone behaves exactly like the production cluster, regardless of complexity.

### [The hidden costs of production incidents | Upsun](https://upsun.com/blog/that-production-incident-cost-more-than-downtime/)

# That production incident cost more than downtime

Every developer knows the sudden, cold spike of adrenaline that comes with a P0 alert. The site is down, the Slack channel is overwhelmed with notifications, and the "war room" is officially open.

In the immediate aftermath, leadership looks at one metric: downtime. They calculate the lost revenue per minute and the hit to brand reputation. But for the engineering team, the official resolution of the incident is only the beginning. 

The true cost of a production failure is found in the manual work required to align environments after an emergency patch. When a fix is deployed for immediate resolution, it often bypasses standard CI/CD workflows, creating a week of undocumented toil that stalls the roadmap.

Of course, manual reconciliation is only half the battle. The other half is the time lost before the fix even begins. If you want to see how much of your debugging cycle is actually spent on "environment plumbing" versus solving the problem, it’s worth looking at how instant environment cloning can reduce that triage tax by up to 70%.

## The manual reconciliation nightmare

When a fix is pushed and the dashboard turns green, the incident is technically "closed." However, for the engineering team, the next 48 hours are dominated by manual reconciliation.

In an emergency, fixes are often "quick hacks" or manual adjustments made directly on a production server to restore service. 

This creates immediate environment drift. The developer must now recall every temporary change, stashed fragment of code, and manual database tweak to ensure the upstream repository eventually matches the live state.

This "glue work" is undocumented and high-friction. It becomes exponentially more difficult when dealing with state-dependent features (especially for non-deterministic issues like LLM hallucinations), where a manual patch might restore service but fail to address the underlying data context that caused the failure.

_**For more info:** Understand how production-perfect environments eliminate the need for manual reconciliation._ _Explore Preview Environments on Upsun__._

## The "staging scrap" and the momentum tax

The most underestimated cost of an incident is the momentum tax. 

When a senior developer is pulled off a feature to troubleshoot a production fire, they do not simply resume work the moment the site is back up.

Context switching in a fragmented environment is a structural hurdle. Without isolated, on-demand test environments, teams are often forced to "scrap" their shared staging instance to mirror the production state for triage. This creates a high-friction "cleanup" cycle:

-   **Evicting the roadmap:** You aren't just stashing your own work; you're often clearing out a stack of mid-sprint changes from other developers just to make room for the production mirror.
-   **Leaving breadcrumbs:** Developers spend hours leaving "manual breadcrumbs" (notes on specific service versions, database tweaks, and configurations) hoping they can piecemeal the staging environment back together later.
-   **The reconciliation day:** If the stashed changes were complex, it can take a full day just to restore the staging environment to its pre-incident state.

While data shows it takes 23 minutes to regain deep focus after a switch, the SME reality is worse: if you don’t have a deterministic way to restore your workspace, you haven't just lost a few hours; you've effectively deleted the entire team's roadmap progress for the day.

This is why many teams are moving toward standardized debugging template packs to automate that scaffolding

## Trust debt: why one crash slows the next three releases

A major incident doesn't just break your code; it breaks your team's confidence. This "Trust Debt" changes the behavior of the next several release cycles, usually for the worse.

When a deployment process is non-deterministic, the risk of accidental change feels unmanageable. 

To compensate, organizations often revert to manual defensive gates: extra sign-offs, "frozen" code periods, and slow procedural hurdles. This creates a vicious cycle:

1.  The "approved path" becomes slow and painful, so changes become less frequent.
2.  Less frequent changes lead to larger, "bulkier" deployments.
3.  Larger deployments are inherently riskier, increasing the likelihood of the next incident.

To break this cycle, teams must move from "Policy as PDF" (manual checklists) to Policy as Code, where guardrails are versioned and enforced by the platform itself.

## The post-mortem as a "data reconstruction" incident

The traditional post-mortem often feels like a second incident because it relies on reconstruction rather than data. 

If the fix was an impulsive workaround or a "quick hack" applied directly to a server, reproducing the "why" for an audit is an exhausting chore.

**When code changes aren’t tracked via Git during a fire, finding the actual fix becomes a forensic mystery.** 

Multiple developers may be working in tandem, applying manual changes to the production environment until the issue is resolved. The post-mortem then drains even more engineering capacity as the team tries to figure out who actually fixed the issue and how, balancing the need to address technical debt with the risk of further outages.

By using production-perfect clones, the "crime scene" is preserved exactly as it was. 

Because Upsun forces a Git-driven workflow even during an emergency, every change is versioned and reviewable, turning the post-mortem into a data-driven report rather than a guessing game.

_**For more info:** Learn how to move from "hope-based" security to automated, versioned truth._ _Read the YAML configuration overview__._

## Next steps: ending the triage tax

To stop the hidden factory from consuming your roadmap, you have to move from "heroics" to a deterministic architecture.

1.  **Audit your "Shadow War Room":** Track the hours your team spends on "clean-up" and data reconciliation in the 72 hours following your next fix.
2.  **Establish a "Golden Path":** Use `.upsun/config.yaml` to ensure that every environment is a byte-for-byte replica of production, making reproduction instant.
3.  **Eliminate the "Staging Scrap":** Move to a workflow where every branch gets its own isolated environment, so you never have to destroy your current work to fix a production fire.

## Frequently asked questions (FAQ)

**Does moving to a standardized platform like Upsun actually speed up recovery?**

Yes. By using copy-on-write (CoW) technology, Upsun allows you to clone the entire production state (code, data, and services) into a new branch in seconds. This eliminates the "setup tax" and lets developers start fixing the bug immediately.

**How does this prevent the "Trust Debt" mentioned?**

Upsun makes deployments deterministic. Because you are testing the fix in a preview environment that is identical to production, you gain the mathematical certainty that the fix will work, reducing the need for manual gates and bureaucracy.

**What happens to the "quick-fix" code in an emergency?**

On Upsun, you are forced into a Git-driven workflow. You can't "hack" the production server directly. This ensures that every emergency change is versioned, reviewable, and never forgotten, preventing the need for manual "clean-up" later.

**Can we still use our existing observability tools during an incident?**

Absolutely. Upsun bakes observability like Blackfire into the environment. You can validate that your fix hasn't introduced a new performance bottleneck before you ever merge to the main branch.

**How do automated environments help with post-mortems?**

Since every environment is defined by code and Git history, the "evidence" is built-in. You don't have to guess what changed; you can simply "diff" the infrastructure configuration of the failing branch against the previous working state.

### [Stop PCI DSS 4.0 audit toil | Upsun](https://upsun.com/blog/stop-the-pci-dss-4-0-audit-toil/)

# Stop the PCI DSS 4.0 audit toil: a guide to inherited controls

_By standardizing the unified configuration file, Upsun enables true cloud optionality, moving provider migration from a re-architect project to a data move project._

### **The 2026 compliance cliff**

As of early 2026, the transition to PCI DSS 4.0 is no longer a future roadmap item; it is the baseline for any organization handling payment data. 

But for fintech founders and CISOs, the new standard introduces a systemic challenge. Requirements for secure development (Section 6) and ongoing monitoring (Section 11) now mandate high levels of traceability across the entire delivery pipeline.

The "audit toil" is a direct result of fragmented infrastructure. If you are building on raw cloud primitives, your team is responsible for the "undifferentiated heavy lifting" of OS hardening, patch management, and network isolation for every single environment.

### **I. The power of inheritance: Reducing the audit scope**

_Key takeaway: By building on infrastructure that operates within a PCI DSS certified environment, you streamline the management of infrastructure-level burdens like OS hardening and physical network segmentation. This inheritance narrows your audit scope, allowing your team to focus on application-level logic rather than the underlying plumbing._

In a traditional cloud model, the shared responsibility often leaves the most complex configuration tasks in the customer’s lap. Upsun shifts this boundary through inherited controls. Because security and compliance are applied at the platform level and managed centrally, you build on a pre-certified foundation.

-   **What you inherit:** You reduce the operational burden of physical security, network segmentation, and OS hardening by leveraging the platform’s managed controls.
-   **Integrated managed services:** Unlike fragmented managed databases, Upsun managed services like Postgres, Redis, and OpenSearch are defined in your project config and provisioned as isolated containers within the same compliant perimeter as your application.

By building on a platform that has already satisfied the infrastructure-level requirements of PCI DSS Level 1, your internal audit focus shrinks to application-level logic and user access.

### **II. Satisfying Requirement 6 with a platform contract**

_Key takeaway: Upsun satisfies the rigorous environment separation and traceability mandates of Requirement 6 through its architecture. While the platform enforces infrastructure isolation, organizations remain responsible for secure coding practices, application vulnerability management, and their broader SDLC governance._

One of the most persistent toil drivers in PCI 4.0 is the mandate for a secure software development lifecycle (SDLC). Auditors require strict separation between pre-production and production environments—a setup that is often manually "wired" and prone to configuration drift.

This is where Upsun’s standardized environments become your most valuable audit asset:

-   **Byte-level clones:** Every time a developer branches code, Upsun creates a byte-level clone of the entire production setup, including databases and services. This provides the "exact replica" for testing that auditors demand, without manual configuration.
-   **Traceable infrastructure:** Because your entire stack is defined in a single configuration file (.upsun/config.yaml), the audit trail is absolute and verifiable. Every infrastructure change is version-controlled, providing the continuous proof that PCI 4.0 requires.

By using a unified application spec, you automate the environment separation checkbox, allowing your security team to focus on high-level SDLC requirements like code reviews and developer training.

### **III. Moving to a "Continuous audit-ready" state**

_Key takeaway: The devops tax in fintech often peaks during the "annual scurry"—weeks spent hunting down logs and manual patch records. Upsun mitigates this by moving security left into the platform architecture, replacing manual evidence collection with automated, deterministic infrastructure._

The "DevOps Tax" in fintech often peaks during the annual scurry of weeks spent hunting down logs and manual patch records. Upsun eliminates this by moving security left into the platform architecture:

1.  **Automatic patching:** The platform handles automatic and transparent security-patching of every infrastructure component. Your team no longer needs to track or manually apply infrastructure-level fixes.
2.  **Deterministic networking:** Container isolation reduces the risk of misconfiguration typically associated with manual network controls. By automating the connectivity between your app and its services, you eliminate the need for manual VPC rules that are prone to leaks or human error.
3.  **Integrated logging:** Audit-ready logs are centralized and managed at the platform level, ensuring you meet Requirement 10 without additional wiring or third-party tools usually required for raw cloud primitives.

### **IV. The fintech advantage: Innovation over inspection**

_Key takeaway: For a fintech startup, every hour spent on infrastructure-level compliance is an hour stolen from your product's competitive edge. By shifting the focus from infrastructure maintenance to application security, you reclaim the engineering capacity needed to lead the market._

-   **Legacy compliance:** Requires a constant cycle of manual evidence collection, OS hardening, and ongoing infrastructure maintenance.
-   **Upsun compliance:** Inheriting a pre-certified baseline allows your team to significantly reduce and streamline infrastructure-level documentation. Instead of generating evidence from scratch, you simply map the platform's existing certifications to your specific audit requirements.

By inheriting the platform's certified controls, you don't just pass the audit; you reclaim your engineering roadmap. You move from maintenance mode to market leader by letting the platform handle the heavy lifting of regulatory plumbing.

### **Is your infrastructure audit-ready?**

The 2026 deadline for the most stringent PCI 4.0 controls is already here. If your team is still manually collecting evidence for OS patches and network rules, you are paying a tax you can't afford.

**Prepare for your next audit:**

-   **Identify your gaps:** Evaluate your current shared responsibility matrix. How much undifferentiated heavy lifting is your team still performing?
-   **Reclaim your velocity:** See how a standardized environment can inherit the core of your technical controls.
-   **Scale with confidence:** Learn how fintechs use Upsun to maintain Continuous PCI 4.0 Compliance while shipping daily.

### **Frequently asked questions (FAQ)**

**What are inherited controls?** 

They are security measures managed by the platform (like OS patching and network isolation) that you get to check off your audit list for free.

**How does this help with Requirement 6 (Secure SDLC)?** 

Auditors want proof that your dev and prod environments are separate. Our platform enforces this at the architectural level, with every branch creating an isolated clone for testing.

**Is our data actually separate?** 

Yes. We use deterministic networking and container isolation. Your application is the only thing that can touch your data, no manual VPC rules required.

**What about the 12-character password rule?** 

PCI 4.0.1 mandates 12-character minimums and MFA for everyone. The platform enforces these access controls across your team and any automated agents.

**What is the "repro gap"?** 

It’s the failure that happens when dev data doesn't match prod. We solve this with instant, byte-level clones so you’re always testing against reality, not a guess.

### [European data sovereignty without the toil | Upsun](https://upsun.com/blog/european-data-sovereignty-without-byoc-complexity/)

# The sovereignty without toil guide: why compliance shouldn’t require a Kubernetes tax

_Key Takeaway: True data sovereignty isn't about managing your own cloud accounts; it’s about where your data resides and how it is governed. By utilizing a unified configuration file to deploy on sovereign infrastructure like OVHcloud, Upsun provides standardized sovereignty without the complexity of “Bring Your Own Cloud”._

## **Is your BYOC strategy just a Kubernetes tax in disguise?**

In 2026, the push for European data sovereignty has led many organizations toward BYOC models. The logic seems sound: "If we own the cloud account, we own the compliance.".

However, “control” does not equal “compliance”.

When you "Bring Your Own Cloud," you also bring your own security patches, your own IAM misconfigurations, and your own high-availability failures. This is the Kubernetes tax: the hidden cost of senior engineering hours required to keep disconnected primitives in sync just to satisfy a regulatory checkbox. For an enterprise, this isn't leverage; it’s a drain on the bottom line.

## **I. Standardized sovereignty vs. manual control**

_Key takeaway: You don’t need to manage the cloud to be compliant; you need a platform that enforces compliance by design._

While some competitors focus on self-serve BYOC for GDPR, Upsun focuses on standardized sovereignty. We decouple the _location_ of the data from the _burden_ of the infrastructure.

-   **Sovereign infrastructure by default:** Upsun provides native support for providers like OVHcloud, ensuring your data remains within European jurisdictions on infrastructure built for the EU market.
-   **The Unified Configuration File:** Compliance is not a manual task; it’s a line of code. By selecting a sovereign region in your unified configuration file, the platform automatically provisions the environment with the necessary enterprise-grade certifications (SOC 2, PCI DSS, HIPAA) already in place.
-   **Integrated Services:** Your databases (PostgreSQL, MariaDB) and caches (Redis) are managed within the same sovereign boundary, eliminating the risk of data "leakage" across non-compliant third-party add-ons.

## **II. The greener margin: efficiency as a requirement**

_Key takeaway: In the European market, sustainability is no longer a "nice to have", it is a procurement mandate._

True sovereignty in 2026 includes environmental responsibility. Many BYOC setups result in over-provisioned, idle compute that inflates both your bill and your carbon footprint.

-   **Surgical resource allocation:** Upsun’s unified configuration file allows you to define exactly the resources your application needs, preventing the over-provisioned instances waste typical of standard cloud instances.
-   **Built-in sustainability:** By selecting low-carbon regions, teams meet ESG mandates and can receive a 3% greener region discount, directly improving the unit economics of every deployment.
-   **Operational velocity:** Instead of managing plumbing, your team focuses on delivering logic. You gain the outcomes people adopt Kubernetes for (portability and scaling) without the manual toil.

## **III. Reducing risk through platform governance**

_Key takeaway: A standardized platform provides better security outcomes than a fragmented, owned cloud._

The greatest risk to sovereignty isn't the provider; it’s human error in configuration. BYOC models increase the surface area for these errors.

-   **Automated guardrails:** Upsun manages the container orchestration and security patches. The platform acts as a protective layer, ensuring that your sovereign data is hosted in an environment that is hardened by default.
-   **Production-perfect previews:** Validate compliance changes in an isolated, byte-level clone of your production environment before they go live. This ensures that a security update or a regional move doesn't break your application.

## **Beyond vendor lock-in**

The goal of a modern CTO isn't to own more servers; it’s to provide the business with the freedom to move and the security to scale. Choosing standardized sovereignty on Upsun means you are no longer locked into a single vendor's ecosystem or burdened by the plumbing of a custom-built cloud.

The cloud should be your engine, not your cage.

* * *

## **Frequently asked questions (FAQ)**

**Does Upsun meet GDPR and European data isolation standards?** 

Yes. Upsun is suitable for enterprise environments and meets major compliance standards, including GDPR, SOC 2, and PCI DSS. We offer specific data isolation options and cloud region selection within Europe (including OVHcloud) to ensure full sovereignty.

**How is this different from Northflank’s BYOC?** 

While BYOC gives you the keys to the cloud account, it also gives you the responsibility of managing it. Upsun provides a managed, unified experience where the infrastructure, integrated services, and security are handled by one provider under a single SLA, eliminating DevOps toil.

**Can I move an existing AWS workload to a sovereign European provider?** 

Absolutely. Because your stack is defined in a unified configuration file, moving from AWS to a sovereign provider like OVHcloud is a matter of changing the region declaration and planning the data move, rather than a total re-architecture.

**Is sovereign hosting more expensive?** 

Actually, it can be more cost-effective. By using surgical resource scaling and taking advantage of greener region discounts, many teams find that their total cost of ownership (TCO) is lower on Upsun than managing a fragmented BYOC setup.

### [How storytelling and empathy shape better technical documentation](https://upsun.com/blog/storytelling-empathy-technical-writing/)

# Beyond the horizon: How Kemi Elizabeth Ojogbede used storytelling to build better tech

Welcome to _Beyond the horizon_, a monthly series celebrating the people who shape Upsun’s culture, innovation, and heart. In this month’s edition of _Beyond the Horizon_, we're featuring Kemi Elizabeth Ojogbede, one of the many voices behind Upsun, shaping every developer's experience: our documentation. As a Senior Technical Writer, Kemi works closely with teams across the company to turn complex product knowledge into guidance that's clear, accurate, and genuinely useful—so users can build with confidence.

Kemi's path into tech is anything but traditional, and that's exactly what makes her perspective so powerful. With roots in storytelling, journalism, and data science, she brings a mix of curiosity and craft to her work—grounded in a belief that empathy in engineering isn't "soft". Instead, it's a technical skill that changes how we communicate, how we design, and who we make space for.

In her story, she also speaks candidly about navigating the industry as a Black woman and how the absence of representation can quietly shape confidence and belonging. Rather than waiting to see herself reflected, she chose to be the representation she was looking for: showing up, speaking up, and making space for others to feel less alone in tech.

### **Tell us a bit about yourself. What do you do at Upsun and most importantly, who are you outside of work?**

> I’m a Senior Technical Writer at Upsun, where I manage our developer-facing technical documentation. I sit within the Developer Advocacy team alongside a brilliant group of engineers, developer advocates, and fellow writers. My role is highly collaborative: I work closely with product managers and engineers across the company to understand both new and existing features, then translate that knowledge into documentation that’s clear, accurate, and genuinely useful for our users.
> 
> Because my job is to explain complex systems in a way that’s actionable and approachable, I make a point of understanding things deeply before I write about them. That curiosity and willingness to ask questions  is a big part of how I work.
> 
> What really draws me to technical writing is my belief that empathy is a core technical skill. I transitioned into tech from a background in journalism and later data science, and during my master’s in Data Science I remember how overwhelming it could feel when concepts weren’t explained with learners of different levels in mind. That experience stayed with me. I care deeply about education and knowledge-sharing, and I try to bring that mindset into everything I write. I like meeting people where they are, and helping them move forward with confidence.
> 
> For a long time, I thought being empathetic, bubbly, and emotionally expressive wasn’t compatible with working in engineering. I assumed I needed to be tougher, quieter and a bit more detached. Over time, I’ve realised the opposite is true: empathy isn’t a weakness in tech, it’s a strength. It helps us design better products, write better documentation, and build more inclusive experiences.
> 
> Outside of work, I’m very much a girly nerd. I love anime (Naruto, Demon Slayer and Chainsaw Man are my favourites) as much as sci-fi and horror films (My favourite films are The Matrix and Hereditary). I'm a big theatre fan, and you’ll usually find me reading fiction, writing prose, or singing along to musical soundtracks in my spare time (especially Hamilton or The Waitress).

### **If you could describe your journey in one sentence, what would it be?**

> If I had to describe my journey in one word, it would be unconventional. I haven’t taken a traditional route into technical writing, but I’ve come to see that as one of my biggest strengths.
> 
> When I was younger, I dreamed of becoming the next Shonda Rhimes. I’ve always been obsessed with writing, storytelling, and communication. Looking back, what fascinated me most wasn’t just storytelling itself, but the challenge of communicating experiences and ideas in a way that people could truly understand. In many ways, that’s still what I do today - just through technical documentation rather than TV scripts.
> 
> I studied English with Creative Writing for my undergraduate degree, followed by a master’s in Contemporary Literature and Cultural Theory. I worked in journalism and Content Marketing before deciding to pivot into tech, where I completed a second Master’s degree in Data Science. Learning Python became my gateway into engineering, particularly through working with NLP techniques like sentiment analysis and text tokenisation.
> 
> Throughout my career, learning and teaching have been constant themes. I even wanted to be a university lecturer at one point (my nickname at home is still “Professor”). I’m a strong believer in curiosity and knowledge-sharing. I wouldn’t know what I do today if I hadn’t been willing to ask questions, feel uncomfortable, and learn out loud. That mindset is what ultimately led me to technical writing: a role where communication, empathy, and technical understanding meet.

### **What's a challenge you've faced and how have you grown from it?** 

> Being a Black woman in tech comes with its own set of challenges. For much of my career, I've often been the only person from a diverse background on my team. That lack of representation can be isolating, and for a long time, I internalised it as a sign that maybe I didn't fully belong in this industry.
> 
> At times, that feeling held me back. I hesitated to put myself forward because I couldn't see people like me reflected in those spaces. Over time, though, I realised that waiting to see yourself represented can become its own barrier.
> 
> So instead, I decided to be the representation I was seeking.
> 
> If I couldn't see Black women represented in tech or developer-facing roles, I wanted to be visible myself. That decision is a big part of why I’ve pushed myself to speak at conferences and get more involved in developer advocacy. I care deeply about helping people feel less alone and letting them know that there’s space in tech for many kinds of voices, personalities, and experiences.

### **Is there someone at Upsun who played a key role in your journey or made your experience possible?**

> Greg Qualls had been incredibly impactful in my journey at Upsun. 
> 
> Greg’s unwavering belief in bringing authenticity, emotional intelligence, and personality into tech reminded me that empathy isn’t separate from good engineering. He always considers the human behind the user, developer, or client, and that perspective has completely shaped how I approach our documentation: How will people learn this best? Will they understand the feature? Is it accessible? 
> 
> Beyond that, he gently encouraged me to step into visibility, speak at conferences, and let my enthusiasm shine, showing me that being fully myself is a strength.

### **As we say at Upsun, 'Your greatest work is just on the horizon.' What's the next horizon you're excited to reach on your journey?**

> I want to make our documentation as clear, accessible, and inclusive as possible, so no one feels left behind when learning our product. My goal is to set a gold standard for documentation, ensuring that anyone using Upsun - from first-time users to experienced users - can succeed with confidence and ease. At the same time, I'm excited to expand my public speaking presence, sharing insights on communicating complex ideas in ways anyone can understand while fostering empathy, clarity, and accessibility in tech.
> 
> By making our docs more inclusive and sharing what I've learned publicly, I hope to inspire others to contribute and bring their authentic selves to their work, helping create a culture where everyone can thrive. I'm a writer and lifelong learner at heart, and I'm confident that my perspective and voice can create meaningful impact, both through the work I produce in documentation and the ideas I share with the wider tech community.

As we wrap up this month's journey, Kemi's story reminds us that clarity is never just technical; it's deeply human. Her commitment to thoughtful communication, inclusive learning, and meeting people where they are reflects the kind of care that strengthens our product and our culture. We're grateful to have Kemi shaping how developers experience Upsun, and showing what's possible when empathy and expertise work side by side.

Join us next month as we continue to spotlight the people whose stories shape our culture and expand what's possible at Upsun. 💙

### [Continuous integration & deployment guide (CI/CD) | Upsun](https://upsun.com/blog/continuous-integration-and-continuous-deployment/)

# Continuous integration and continuous deployment (CI/CD) explained

Modern software development moves fast, but manual testing, building, and deployment processes don't. Continuous Integration/Continuous Deployment (CI/CD) automates these critical workflows, enabling teams to ship features quickly while maintaining quality and minimizing production issues. While CI focuses on automatically testing and building code changes, CD can mean either Continuous Delivery (preparing code for release) or Continuous Deployment (automatically releasing to production). Understanding this distinction is crucial for implementing the right strategy for your team. 

This article will guide you through the fundamentals of CI/CD, share proven best practices, and explore advanced techniques that can transform your development workflow, including how modern platforms like Upsun can enhance your CI/CD pipeline with production-like preview environments.

## **What is continuous integration (CI)?**

The **CI** in **CI/CD** stands for continuous integration, which involves the automatic running of tests and building of code on a remote server whenever changes are pushed. This process ensures that the latest commit in each branch passes all checks and can be safely released or merged into the main branch.

Common platforms for running CI include Jenkins, GitLab CI, and GitHub Actions. The examples in this article use GitLab CI.

The basic CI process includes code-style checking, running different types of tests, and building the project. On GitLab CI, such a pipeline would look like this (using the Node ecosystem for illustration):

```shell-session
# .gitlab-ci.yml
stages:  # stages are executed in strict order of the list
  - build
  - test 
  - deploy

build-code:  # name of the job
  stage: build
  script:
    - npm install # install dependencies
    - npm run build # build code
    
code-style:
  stage: test 
  script:
    - npm install # install dependencies
    - npm run lint # check code style
    
unit-tests:
  stage: test 
  script:
    - npm install # install dependencies
    - npm run test:unit # run unit tests
```

Automating the code-checking process saves time and improves release safety by detecting bugs early. However, this only scratches the surface of what CI can accomplish. In larger projects, CI pipelines often extend far beyond just three stages.

Building a CI pipeline for a complex codebase may include the following:

-   Multistage complex build processes require multiple actions to be accomplished. For instance, a microservices architecture might involve independently building, testing, and packaging multiple services before deploying them together.
-   **Parallel and distributed job execution**. A CI pipeline for a frontend and backend monorepo can run linting, unit tests, and code coverage checks for each component in parallel, reducing total build time.
-   **Incremental builds**. In large projects, only rebuilding modules that have changed since the last commit can dramatically speed up iteration cycles, for example, in a gaming engine repository where assets and core logic evolve independently.
-   **Time and resource optimization of the processes**. Utilizing job matrix configurations to optimize builds for different environments (for example, testing an API on Node.js versions 16, 18, and 20) while minimizing redundant workflows.
-   **Dependency management and dependency caching.** Efficiently caching large dependencies, like Docker layers or npm packages, to avoid downloading them for every build, especially in environments with limited bandwidth.
-   **Integrating different testing frameworks.** Ensuring seamless execution of Jest for unit tests, Cypress or Playwright for end-to-end testing, and Postman for API contract testing.
-   **Handling flaky tests**.  Implementing retry strategies when testing a real-time messaging system that may occasionally fail due to race conditions.
-   **Collecting and reporting metrics.** Visualizing trends in build success rates, test coverage, and pipeline execution times via dashboards to quickly identify bottlenecks or regressions.

These are just some examples. A well-designed CI pipeline can be tailored to address specific project needs, from improving build performance to enhancing code quality and team collaboration.

## **What is continuous delivery (CD)?**

Once the code has been built and tested in the CI stage, continuous delivery (CD) takes the build from the integration step and prepares it for release. This includes deploying the build to the staging or production environment, running another set of end-to-end tests, and uploading the binary to an internal registry.

The examples here use GitLab CI and the Node ecosystem, but the same logic can be implemented on any CI/CD platform, like Bitbucket Pipelines or GitHub Actions.

To extend the previous code sample with CD, you would add deploy stages to deploy the build to the staging or production environment:

```shell-session
stages:
  - test
  - build
  - deploy-to-staging
  - deploy-to-production

deploy-to-staging:
  stage: deploy-to-staging
  script:
    - npm install # install dependencies
    - npm run deploy:staging # deploy to staging

deploy-to-production:
  stage: deploy-to-production
  when: manual # this stage can be started only manually, if the developer wants to deploy the build to production
  script:
    - npm install # install dependencies
    - npm run deploy:production # deploy to production
```

Basic automated deployments, like the deploy-to-staging step in the example above, are a good starting point for smaller projects or straightforward use cases. However, larger or more complex projects typically require additional techniques to enhance safety and control; you'll learn more about these later.

The deployment-to-production step in the example is designed to be manual instead of automated. The choice between automated and manual deployments depends on several factors, including the frequency of desired releases, test reliability, regulatory requirements, and management practices.

Using CD and automating delivery processes provides faster feedback on release quality, which supports lower-risk, more predictable releases.

## **What is continuous deployment?**

Continuous deployment is a form of continuous delivery where any code change that passes all checks is automatically deployed to production. While continuous delivery emphasizes having every change ready for deployment, continuous deployment takes it one step further by removing the manual approval step altogether.

To implement continuous deployment using the pipeline from the previous section, remove the `when: manual` flag from the `deploy-to-production` stage. If you don't need to deploy to the staging environment (assuming you are confident in the CI tests as the primary safeguard for code quality), you can also omit the `deploy-to-staging` stage:

```shell-session
deploy-to-production:
	stage: deploy-to-production
	script:
		- npm install # install dependencies
		- npm run deploy:production # deploy to production
```

  
Continuous deployment offers the same benefits as continuous delivery: reduced manual effort, improved release consistency, and the ability to deliver high-quality updates continuously. However, it requires robust automated testing and monitoring, as code changes are deployed without manual review, increasing the risk of issues in production. It also demands a significant investment in infrastructure and processes to ensure reliability and enable quick rollbacks if needed.

**Note**_: While both continuous delivery and continuous deployment use "CD" as an acronym, the subsequent part of this article will use "CD" to refer to continuous deployment._

### **CI/CD pipeline architecture (putting together the complete picture)**

Here's how continuous integration and deployment typically work in a DevOps pipeline:

1.  **Code Push**: The developer pushes code changes to their VCS repository, GitLab, GitHub, Bitbucket, etc.
2.  **Build & Test**: CI automatically runs tests and builds the code on the CI/CD platform
3.  **Deploy**: If the CI stage passes all checks, CD deploys the code to staging or production environments
4.  **Live Application**: The updated application is now live and accessible to users

As you can see, a complete pipeline involves many systems:

**Behind the scenes, each code push triggers:**

-   Security scanning and quality checks run automatically
-   Tests execute in parallel to minimize build time
-   Sensitive data (API keys, credentials) is securely injected via secret management
-   Dependencies are cached to speed up subsequent builds
-   Database migrations apply automatically during deployment

**The pipeline execution involves several parallel processes:**

-   Static security tools scan code changes for vulnerabilities.  
-   Tests run in parallel to speed up execution.  
-   Test results are sent to a test management platform.  
-   Once the final build artifact is generated, it's stored in the artifact repository and deployed to the appropriate environments.

This is just one example pipeline; additional components may be needed depending on your app's requirements.

## **Advanced CI/CD techniques**

As mentioned, if you have a smaller project, a basic automated deployment, like the example used earlier, would be a good starting point. However, larger or more complex projects typically require additional techniques to enhance safety and control.

One approach is using feature flags to deploy code with features that are hidden from users until they're deemed stable, allowing for incremental releases and easy rollback if necessary. There are different types of feature flags, such as release toggles, which enable gradual feature rollouts, and experiment flags, used for A/B testing.  For example, an e-commerce website might develop a new search filter but keep it hidden behind a feature flag until thorough testing is complete, so it can be activated instantly when ready.

You can also use "canary releases" and rollbacks to mitigate the risks of introducing bugs, performance issues, or unintended user impacts during new feature rollouts. A "canary release" involves deploying to a small segment of users first. You can then collect metrics and ensure the feature performs as expected. If issues arise, you can roll back the release for this small group, making the process faster and less risky. You can take things up a step by automating rollbacks based on the metrics you chose earlier. Automation also allows you to avoid manually handling database migrations when there are rollbacks. These techniques can help you roll out smooth, incremental deployments to your users.

Monitoring and feedback tools are essential for gaining a comprehensive view of your services, thus ensuring a safe rollout and enabling quick rollbacks if issues occur. Tools like Blackfire.io are valuable additions to the release process. Key metrics to monitor include error rates, request latency, deployment progress (especially for canary deployments), feature flag success and failure rates, and user engagement metrics. These insights help identify problems, such as increased errors or user abandonment, prompting rollbacks if necessary. Monitoring tools also enable configurable alerts and rollout-specific dashboards to track critical metrics, thereby improving observability and contributing to the safe and efficient release of updates.

### **Best practices for CI/CD implementation**

There are also some best practices you can follow to improve workflows while enhancing the reliability and security of the CI/CD process.

### **Test automation**

Test automation in CI/CD ensures changes are fully tested without manual intervention, saving time and reducing risk. Following the test pyramid, unit tests at the base, integration tests in the middle, and end-to-end (E2E) tests at the top, coverage and speed are balanced, ensuring issues are caught at the right level without overloading the pipeline.

Key elements, such as code coverage, mutation testing, and data management, further enhance CI/CD testing. Code coverage helps verify essential areas are tested, while mutation testing identifies weak spots by checking if tests catch intentional errors. Managing test data through mocks or snapshots enhances reliability and repeatability, thereby improving the overall quality of the software. For efficiency, running tests in parallel, selectively running impacted tests, and isolating environments can optimize test time and stability.

**Optimizations**

Optimizing CI/CD pipelines is crucial for minimizing the waiting time for developers and, therefore, deploying changes faster. Also, optimizing pipeline time is crucial for controlling costs, as most platforms charge based on usage time and resources consumed. Here are three examples of how you might optimize your pipeline:

-   **Caching dependencies.** By storing and reusing previously downloaded libraries or modules, you can avoid redundant installations, saving both time and billable minutes during pipeline runs.
-   Running jobs in parallel. This allows multiple checks to execute simultaneously, significantly cutting down overall build and test times. For example, a large set of end-to-end tests can be divided into smaller subsets and run in parallel, completing the process much faster.
-   Optimize test suites. Run critical tests first to catch failures early and save time by not running further jobs if tests fail. One of the most effective optimization techniques is implementing a mechanism to run only tests affected by recent changes.

Other optimizations include optimizing Docker images and efficiently managing dependencies, both within the CI job and those used for the build. 

**Security**

CI/CD processes have distinct security requirements if you want to ensure the pipeline and applications remain protected from vulnerabilities. This includes taking a multifaceted approach to identify vulnerabilities at different stages of development and deployment. Static Application Security Testing (SAST) scans source code or binaries to identify security vulnerabilities early in development. Dynamic Application Security Testing (DAST) analyzes running applications to detect issues like injection attacks and configuration flaws. Software Composition Analysis (SCA) examines third-party dependencies and libraries for known vulnerabilities and license compliance. These tools work together to secure applications throughout the development and deployment lifecycle.

The example pipeline above uses static security tools in the code quality checks step to check for vulnerabilities in the code. To implement dynamic security testing in a running app, you can set up an additional job that waits for the build to be generated, pushes it to a preview environment (possibly one hosted on Upsun), and then runs a DAST tool (like the OWASP Zap) to run security checks on it. 

Sensitive data, like API keys, should be securely stored and injected into pipelines. You can use the built-in secrets management of your CI/CD platform to encrypt the stored data and safely inject it into the pipeline code. If you have advanced requirements, such as dynamic key generation or a flexible permissions system, you might want to use external services, like HashiCorp Vault or AWS Secrets Manager.

If your pipeline publishes any artifacts, like builds or test results, it's important to secure them from unauthorized access so that no one can access private information generated by your pipeline. You can also add a step for vulnerability scanning of artifacts to ensure that no sensitive data was accidentally injected and that it does not include potentially harmful code.

## **What’s next**

This article explored the core concepts of CI/CD, best practices for implementation, and advanced techniques that can transform your release process. The key benefits of CI/CD include faster time-to-market, improved reliability, reduced manual errors, and the ability to scale development workflows for complex projects.

**But here's the challenge**: Even with solid CI/CD pipelines, testing in production-like environments remains a bottleneck. Most teams struggle with environment inconsistencies, limited staging resources, and the inability to test with real data safely.

**This is where Upsun enhances your existing CI/CD workflows.** Rather than replacing your CI/CD platform, Upsun integrates seamlessly with GitHub Actions, GitLab CI, Jenkins, and other tools to solve the deployment and testing challenges that pipelines alone can't address.

Instead of managing complex deployment infrastructure, your CI/CD pipeline can focus on what it does best, building and testing code, while Upsun handles the deployment, environment provisioning, and production-grade hosting.

Ready to enhance your CI/CD pipeline? Start your free Upsun trial and experience seamless deployments with production-like testing environments that integrate with your existing workflows.

### [Why platform architecture matters for AI agent safety | Upsun](https://upsun.com/blog/what-happens-when-you-delete-everything/)

# What happens when you delete everything? Three minutes, or thirty hours.

Last year, at the annual conference for an open source framework you've definitely heard of, I walked up to the founder in a room outside the main stage. He was hunched over his laptop, frantic. We've known each other for a few years.

"What's going on? Is everything okay?"

He looked up with the specific shade of white people only get when they realize they've made a big mistake.

"I deleted everything."

Not "something broke." Not "I think there's a problem." He had wiped out the environment he'd spent considerable time preparing. The version he was about to launch live from the stage in thirty minutes, in front of a couple thousand developers, plus the livestream.

Then his face shifted. He said, "Hold on. Upsun has automated backups."

One button. Three minutes later, everything was back. The demo, the data, the configuration. He had time before he walked out to add a slide to the deck thanking us for saving his ass.

I tell that story a lot. Usually as a funny conference moment. This week it stopped being funny.

## **New week, a different founder**

A founder named Jer Crane runs a SaaS company called PocketOS. Last Friday, as covered in The Register, his AI coding agent, Cursor running Claude Opus 4.6, decided to fix a credential mismatch by deleting his production database on Railway. It took nine seconds. The agent found an unrelated API token with broad permissions, hit a Railway endpoint, and removed the volume. The volume-level backups went with it, because Railway stores them in the same volume.

Then Crane waited about thirty hours, mostly through the weekend, before Railway's CEO stepped in personally on Sunday evening to recover the data.

Read the postmortem. Crane handled it well. He's honest about the human errors involved. Railway's CEO, Jake Cooper, was direct about what happened: "if you (or your agent) authenticate, and call delete, we will honor that request." Their API followed classical engineering semantics. You called destroy, it destroyed.

Crane summed up what changed: “An API key should only be accessed by a human, which is true and has always been the case. Now, when a computer is in control and you do not know what it is doing, what happens?”

## **What "enterprise safeguards" truly mean**

The backup architecture is the headline, and not just a marketing spin. Upsun runs one automated backup per day for production environments by default, with a configurable schedule that can do more if you want. Those automated backups are always live, so they don't pause your site to run. And here is the part that matters for this situation, quoted directly from the physical storage location section of the docs: "Backups are stored as binary large objects separate from your environments. This storage is replicated over multiple data centers in different locations within the region your project is hosted in."

Read that again. Separate from your environments. Replicated across data centers. That is the structural difference. The framework founders’ "delete everything" was a destructive operation against his environment. The snapshot of his environment was not in the same storage, so it survived.

There is a second layer of protection beneath that. When a project is deleted on Upsun, the platform takes a final "tombstone" backup of active environments and the Git repository, retained for between 7 days and 6 months. Even a complete project deletion leaves a recovery path.

Byte-level environment cloning is the related capability for preview and staging work. Every Git branch or pull request can spin up a byte-level clone of production, data and services included, so your testing surface matches your production surface. The same architecture that makes that fast is the architecture that makes restoration fast.

Compliance and certifications held directly by Upsun: ISO 27001, SOC 2 Type 2, PCI DSS Level 1, HIPAA, and TX-RAMP, plus validation for IBM Cloud Financial Services. Are the reason your security team will let you ship.

None of that is novel. Every one of those features exists because someone, somewhere, ten years ago, had a Friday evening just like Crane's and we built the thing that would have helped prevent this from happening.

## **The trade-off the AI era exposes**

AI augmented coding platforms optimize for one thing, which is the speed of a developer (or an agent) going from intent to running code. They do that well. The cost, until recently, was that the surface area of "a destructive action" was small enough that a careful human could keep track of it.

The agent changed the math. An autonomous coding agent can issue more API calls in nine seconds than a human will issue in a week. It will find tokens you forgot you generated. It will read documentation you forgot you wrote. And it will, occasionally, decide to delete your production database to fix a typo.

The question is not whether your platform's marketing says it is safe. The question is whether the platform's API treats a destructive call from your agent the same way your enterprise security policy treats a destructive call from an intern. If the answer is "the same," you have a problem your contract did not warn you about.

Upsun has been running production workloads for enterprises for more than a decade. The reason we have automated backups, isolated snapshot storage, byte-for-byte cloning, and YAML-defined infrastructure is not because it sounded good in a pitch deck. It's because we have watched enough Friday nights go sideways to know what protects you from them.

## **Three minutes**

The framework founder walked on stage that day. He launched his project. He thanked us from the stage in front of his community. The bit about the deletion became part of his keynote because, in his telling, the recovery was the most boring possible thing that could have happened. Push the button, wait three minutes, keep going.

That is the bar. Not zero failures, because anyone who promises zero failures is selling you something. Recovery is so boring, it becomes a slide.

Crane said something at the end of his postmortem that I keep thinking about. "The appearance of safety, through marketing hyperbole, is not safety." He is right. The safeguards are the safeguards, or they are not. They work on a Friday at 5pm or they do not.

### [Stop losing engineer hours to infrastructure | Upsun](https://upsun.com/blog/engineering-time-lost-to-infrastructure/)

# How much engineering time is your infrastructure consuming?

_Key takeaway: Most engineering teams underestimate the time infrastructure demands from them. The hidden cost isn't in provisioning, it's in the accumulated friction of environment drift, manual handoffs, and repetitive infrastructure maintenance that quietly consumes hours your team should be spending on product._

## **The cost your sprint board doesn't capture**

Most engineering teams are careful about what they measure: how much the team ships, how fast features move from idea to production, or how quickly they recover from failures. 

What rarely appears on any dashboard is the hours spent keeping infrastructure running, not improving it, not scaling it, just keeping it stable enough to ship.

This isn't negligence. It's a structural blind spot. Infrastructure work doesn't open a ticket. It doesn't come up in a retrospective unless something broke. It builds up quietly in context switches, in debugging sessions that were "probably an environment thing," in Slack threads where someone is waiting on access they should already have.

The result is a hidden tax on your engineering capacity, and most teams are paying it without knowing.

## **The hidden infrastructure cost is eating your engineering sprints**

_Key takeaway: Without a limit on infrastructure management tasks, it will pull engineers away from product and consume as much engineering time as you allow until you look for it._

Infrastructure tasks rarely announce themselves as a pattern. Each one looks like a one-off, a quick fix, a minor config change, a small upgrade. But they reappear every sprint without fail, and because no single task feels significant enough to escalate, the cumulative cost never gets measured or challenged.

The most common recurring infrastructure costs per sprint look like this:

-   **Environment parity**: Developers spending time debugging failures that only show up in staging or, worse, only in production. The cause is usually a configuration that has quietly diverged between local, test, and live environments.
-   **Configuration drift**: Staging and production diverge gradually and silently until the gap between them makes test results unreliable and releases risky
-   **Dependency and runtime upgrades**: Version updates that should be routine become multi-day efforts because of undocumented dependency chains and untested interactions across environments
-   **Internal infrastructure requests**: Service configuration, access management, and pipeline changes that pull senior engineers away from product work to handle operational support

Left unchecked, infrastructure work expands to fill whatever engineering time your team makes available. Most organizations have no ceiling on this, which is precisely why the cost keeps growing.

## **How infrastructure debt quietly becomes a senior engineering problem**

_Key takeaway: Infrastructure interruptions don't distribute evenly; they disproportionately consume the engineers whose time your product depends on most._

Infrastructure work doesn't distribute evenly across a team. Junior engineers typically can't diagnose a broken Kubernetes config or a misfiring CI pipeline independently, which means the interruptions land on the engineers whose time is most expensive and whose judgment is hardest to replace.

The pattern compounds quickly. Each infrastructure interruption doesn't just cost the time it takes to fix; it breaks the sustained focus that hard engineering problems require. A senior engineer pulled out of deep product work to handle an infrastructure ticket, and loses significant cognitive ground before they can return to where they were. Do that several times in a sprint, and the impact on delivery is substantial even if the individual tasks seem minor.

## **The platform you're building instead of your product**

_Key takeaway: Every engineering team that manages its own infrastructure layer is making a product investment  and for most, it's the wrong one._

Before a single line of product code gets written, most teams burn significant time on infrastructure setup. This is usually framed as Sprint 0 which is  necessary overhead that happens once and gets out of the way. The problem is that Sprint 0 never actually ends.

Every subsequent sprint carries hidden infrastructure work inside it, arriving at the worst possible moments: during a release, ahead of a demo, in the middle of an incident. The typical sprint-level infrastructure burden includes:

-   Debugging pipeline failures that block a release.
-   Investigating environment mismatches that invalidate test results.
-   Configuring services for new features:  IAM roles, networking rules, connection strings.
-   Applying patches and runtime updates across multiple environments.
-   Responding to internal tickets from teams waiting on infrastructure changes.

Over time this creates a parallel system of infrastructure knowledge that lives partly in config files and partly in individual engineers' heads:  fragile, undocumented, and increasingly expensive to maintain as teams grow or change.

## **How Upsun removes infrastructure from your engineers' queue**

Upsun is built to remove the operational burden of infrastructure management from engineering teams, so engineers spend less time on ops and more time building the products and features that actually matter.

Instead of managing Terraform modules, Kubernetes manifests, and cloud provider consoles, teams define their entire stack in a single configuration file that lives in Git alongside the application. 

### **Environments that provision automatically from Git**

When an engineer pushes a branch, Upsun spins up a complete, isolated environment: database, services, networking, and configuration included. When the branch is merged or deleted, the environment goes with it. There are no long-lived environments to babysit, no configuration drift to chase, and no tickets to raise before a test environment is available.

### **Production-like data without the risk**

Upsun branches environments at the data layer, creating a byte-level clone of the production database in minutes. Engineers test against real data rather than synthetic seeds that may not reflect real-world conditions  which means bugs that only appear with production-scale data get caught before they reach production. Teams can configure a sanitisation hook to automatically scrub sensitive data before it is cloned into a preview environment.

### **Service configuration without the manual work**

Adding PostgreSQL, Redis, Elasticsearch, or RabbitMQ to a project means declaring it in a configuration file. Upsun handles provisioning, networking, and credentials automatically, no IAM policies to write, no connection strings to copy across environments, no security groups to configure. Services are available in the environment the moment the branch is pushed.

### **Scaling handled by thresholds**

Traffic doesn't arrive on schedule, and manual scaling forces engineers to predict patterns they can't fully know. Upsun's autoscaling adds or removes instances based on CPU and memory thresholds your team defines. Engineers set the parameters once; the platform handles the rest.

## **What to do next**

Audit your last three sprints and measure how much engineering time was spent on infrastructure work rather than product delivery. This includes pipeline failures, environment issues, access requests, service configuration, and runtime maintenance. Then attach that time to the cost of the engineers who handled it. 

That gives you the real number: not what infrastructure costs to run, but what it costs your business in lost engineering capacity.

Once you have that number, the next step is clear: reduce the operational work that your engineers should never have been doing in the first place.

Explore Upsun’s DevOps and platform engineering solution to see how automated environments, Git-driven infrastructure, and built-in service management can take infrastructure off your team’s queue. 

## **Frequently asked questions** **(FAQ)**

**How do I know if infrastructure work is taking too much engineering time?**  
A good sign is when the same kinds of work keep appearing every sprint: pipeline fixes, environment issues, access requests, service configuration, runtime updates, and release troubleshooting. If senior engineers are repeatedly pulled away from product work to handle these tasks, infrastructure is already consuming too much of your team’s time.

**What is the hidden infrastructure tax?**  
The hidden infrastructure tax is the engineering time lost to operational work that keeps systems running but does not directly move the product forward. It includes repeated work like fixing broken pipelines, dealing with environment drift, managing service changes, and handling internal infrastructure requests.

**Can you reduce infrastructure overhead without giving up control?**  
Yes. The goal is not to remove control from engineering teams. The goal is to remove repetitive manual work. Teams should still define their application needs, but the platform should automate provisioning, deployment, scaling, and service management rather than having engineers handle those tasks manually.

**How does Upsun reduce time spent on infrastructure?**

Upsun provisions environments automatically when a branch is pushed, declares services in configuration rather than requiring manual setup, and governs scaling through defined thresholds rather than reactive engineering decisions. The recurring operational tasks that consume engineering time are handled by the platform rather than by your team.

### [Migrate to reproducible environments | Upsu](https://upsun.com/blog/developer-guide-for-migrating-to-reproducible-environments-without-rewriting/)

# Developer guide for migrating to reproducible environments without rewriting

The primary obstacle to adopting reproducible environments is often the assumption that environment parity requires containerizing legacy monoliths from scratch or abandoning stable CI/CD pipelines. 

In reality, reproducibility is about capturing application intent through configuration rather than rebuilding the application itself.

This guide outlines a non-disruptive, incremental path to migrating your workflow to production-identical environments without touching your core codebase. 

You can **start the Upsun free trial** to see how a configuration-first approach allows you to spin up production clones of your existing stack in minutes.

### Phase 1: Assessing the "drift surface area"

Before moving any code, you must identify where your environments currently diverge. Drift usually hides in three specific layers of your stack:

-   **The runtime engine:** Does "Node 20" mean the latest `20.x.x` on a developer’s laptop but a specific, frozen `20.10.0` in production?
-   **The OS and shared libraries:** Are developers on macOS while production runs on Debian? Differences in `glibc` versions or image processing libraries are classic sources of "works on my machine" bugs.
-   **The service topology:** Are shared services like Redis, Solr, or MySQL running different versions or configurations across stages?

The goal is to map every relationship and version requirement into a single source of truth. To see how these versioned definitions function in a live incident response scenario, you can watch our 3-minute technical walkthrough on automating environment parity.

### Phase 2: The "sidecar" migration (configuration first)

You don’t need to migrate the entire stack at once. 

Start with a single feature branch or a low-risk internal service. Instead of rewriting your deployment scripts, you codify your infrastructure in a single file in Upsun, this is `.upsun/config.yaml`.

This approach acts as a "sidecar" to your code. It doesn't change how your app functions; it simply tells the platform how to host it.

**Steps to validate the first clone:**

1.  **Define the app:** Point the config to your existing build steps (e.g., `npm install` or `composer install`).
2.  **Define the services:** Explicitly list your current database and cache versions to match production.
3.  **Validate on a branch:** Push the config to a new Git branch. If the environment builds and the app starts, you have achieved a production-identical clone for that branch without changing a single line of application logic.

### Phase 3: solving the data context gap

A reproducible environment is useless if it’s empty. The most common friction point in adoption is the lack of "real" data for debugging. 

To increase conversion to a Production Quality Assurance (PQA) workflow, you must bridge the data gap safely.

-   **Sanitized production clones:** Instead of manual database dumps, use platform-level hooks to automate the cloning of production data into your preview environments.
-   **Automated sanitization:** Use `post_provision` hooks to run PII-scrubbing scripts. This ensures developers are debugging with the "shape" and "scale" of real data without violating security policies.
-   **Storage parity:** Ensure your mount points and media storage (S3, local mounts) are mirrored in the temporary environment so file-handling bugs are caught before the merge.

### Phase 4: Maintaining velocity with familiar tooling

For a migration to stick, the new workflow must be faster than the old one. It should not require learning a new proprietary CLI for daily tasks.

-   **Minimal workflow changes:** The environment should provision automatically upon `git push`.
-   **Interface Parity:** Whether you prefer the terminal, a web-based console, or a programmatic REST API, you should have full platform control via CLI and API. This ensures you can manage environments, review logs, and trigger deployments without leaving your existing terminal workflow.
-   **Deterministic rollbacks:** Because the environment is defined by a Git-driven state, rolling back is simply a matter of redeploying a previous commit. This eliminates the fear of breaking the dev server.

### Phase 5: measuring the impact on triage

Success isn't measured by the passing build, but by the reduction in "Ops work" for developers.

-   **MTTR (Mean Time to Recovery):** Track how long it takes to reproduce a production bug. If you can spin up a clone with sanitized data and the exact production runtime in under five minutes, your triage time will drop by orders of magnitude.
-   **The escalation rate:** Monitor "Works on my Machine" tickets. When Dev, Staging, and Prod are identical, these tickets disappear.

### Next steps: moving toward zero-drift

The transition to reproducible environments is a journey from "it works for me" to "it works everywhere." 

By starting small and using a configuration-first approach, you provide your team with the stability of production without the friction of a rewrite.

**Ready to see it in action?** 

Explore how to define your first reproducible environment in `.upsun/config.yaml` or **request a technical demo** to see how Upsun eliminates the "Environment Drift" tax.

### [Debug LLM hallucinations with real data | Upsun](https://upsun.com/blog/why-llm-hallucinations-require-production-state-branching/)

# Debugging the black box: why LLM hallucinations require production-state branching

The most frustrating sentence in modern engineering is no longer "it works on my machine." It is: "It worked in the playground."

When an LLM-powered feature, such as a RAG-based search, an autonomous agent, or a dynamic prompt engine, fails in production, it doesn’t throw a standard stack trace. It returns "slop," hallucinations, or silent retrieval failures. 

Standard debugging workflows fail during triage because LLM hallucinations cannot be reproduced using static mocks or clean seed data. AI behavior is non-deterministic and tied directly to the organic state of live production data. 

To resolve an AI-related bug, an engineer must reproduce the exact interaction between the code, the specific model version, and the real-time data context.

The only way to move from "slop" to a fix is to eliminate the variables between the failure and the investigation. You can **start the Upsun free trial** to see how atomic environment cloning provides the data context required to make these failures reproducible.

### The entropy gap: why synthetic data fails RAG

Most Retrieval-Augmented Generation (RAG) pipelines fail not because of the LLM, but because of the vector database context**.** 

If a user reports that the AI gave a wrong answer about a specific technical document, reproducing that in a dev environment with a "fresh" database import will almost always result in a "Pass."

This happens because synthetic dev databases lack the entropy of production, the years of schema migrations, inconsistent metadata tagging, and overlapping vector embeddings that exist in the live instance. 

To see how this looks in a live environment, you can watch our 3-minute technical walkthrough on how to branch production state for immediate triage.

**The technical fix: atomic vector branching**

To debug a RAG failure, you need a production-perfect clone of the entire stack. This means your branching operation must include:

-   **The relational database:** For the metadata filters.
-   **The vector store:** For the actual embeddings.
-   **The application logic:** To ensure the chunking strategy matches.

By cloning the binary state of the production vector store into an isolated preview environment, you can run the exact same query against the exact same "dirty" data.

### Context window drift and resource constraints

AI bugs are frequently context-dependent. A prompt might work perfectly when you test it with a 500-word sample, but hallucinate when it’s fed the full 12,000-word history of a real customer.

In a standard, resource-constrained dev environment, these failures are often masked by silent timeouts or memory-related truncations that the developer mistakes for "model quirkiness."

**The technical fix: surgical scaling for triage**

Reproducing an AI bug requires resource parity**.** If production runs on a high-memory profile to handle large context windows, your debug environment must match it.

Using guaranteed resource profiles, engineers should upscale their preview clones to match production CPU and RAM. 

This allows you to verify if the "hallucination" was actually a result of the infrastructure killing a process mid-inference or truncating a context window due to memory pressure.

### **The "stateful" hallucination: versioning the AI stack**

We often treat LLMs as stateless APIs, but the AI feature is highly stateful. The output is a product of:

1.  **The prompt template** (in your code).
2.  **The model version** (the specific API or local model weights).
3.  **The context data** (the current state of the database).

If any of these three variables differ between your machine and production, the bug is unreproducible.

**The technical fix: infrastructure-as-code for AI**

By defining your AI infrastructure, including your specific model versions and service relationships, in `.upsun/config.yaml`, you treat the AI stack as part of the application logic.

When a bug is reported, you don't just checkout the code; you checkout the environment. This ensures that your local triage sandbox uses the exact same service mesh and versioning as the incident site.

### Automated sanitization and compliance guardrails

The primary reason engineers don't debug with real data is security**.** 

You cannot allow PII (Personally Identifiable Information) to flow into a developer's local environment or a third-party LLM during a debug session.

However, if you scrub the data too aggressively, such as replacing all names with "User\_1," you might break the very data relationships (like foreign key lookups) that the AI is struggling with.

**The technical fix: sanitization hooks**

The solution is to move sanitization from a manual script to a platform-level hook**.** Upsun allows you to define sanitization scripts that run during the cloning process. This ensures that the Context Dataset remains technically valid for LLM triage while being legally compliant for developer access.

-   **Atomic anonymization:** Data are scrubbed before the environment URL is accessible.
-   **Relationship preservation:** Use deterministic hashing to mask PII while keeping data relationships intact so the AI's logic remains valid.

### The "investigative gap" in AI

The time between an AI "hallucination" and a developer seeing that hallucination in a test environment is the investigative gap**.** In traditional architectures, this gap is infinite because the state is never perfectly mirrored.

By moving to a platform that supports copy-on-write (CoW) cloning, you reduce that gap to seconds. You stop guessing why the model "felt" off and start seeing exactly which data record triggered the failure.

### Next steps: ending the AI debugging nightmare

To move from "guessing" to "deterministic AI triage," your team needs to implement three shifts:

1.  **Stop using static mocks:** If you are debugging AI, you are debugging data. Use production clones.
2.  **Codify the stack:** Move your AI service definitions into your YAML configuration.
3.  **Automate sanitization:** Ensure your build hooks handle the PII scrubbing so your developers can work with realistic context safely.

**Ready to see a production-identical AI stack in action?**

-   Explore the Upsun documentation
-   **Start your free 15-day trial**

### [Upsun climate action plan: 2025 footprint and 2031 goals | Upsun](https://upsun.com/blog/2025-climate-action-plan-progress/)

# Cloud has a climate cost. Here's our plan to reduce ours.

Cloud hosting is not invisible. Every project deployed, every resource provisioned, every region selected carries a real energy cost, and that energy cost has a climate cost. At Upsun, we've known this for a while. What we're sharing today is where we stand, what we measured, and what we've committed to doing differently from 2026 onwards.

Our ambition is calibrated to what we can credibly deliver, and we think being upfront about that matters more than overpromising.

## **What we measured**

In 2025, we completed our third (since 2023) full carbon footprint assessment using the GHG Protocol methodology, with Greenly as our climate partner and measurement expert. Our total emissions for the year were 2.57 kt CO2e, or 11 tC02e per employee. 

Here's how that breaks down by category:

-   Digital infrastructure: 62%
-   Travel and commute: 23%
-   Services purchases: 8.1%
-   Activities and events: 3.8%
-   Product purchases: 2.3%
-   Food and drinks: 0.6%
-   Other: 0.2%

The headline finding is straightforward: digital infrastructure dominates our footprint, and within that, cloud services account for roughly half of our total company emissions, or around 1,200 tCO2e. That's the number we need to move.

We opted to conduct a voluntary double materiality assessment in 2025 to further align with evolving sustainability reporting standards. It confirmed what the numbers already suggested: energy consumption, emissions, and electronic waste are our most significant areas of environmental impact. These indirect impacts from the value chain aren’t fully within our control, therefore it is vital to onboard our key stakeholders in this climate journey.

## **Why cloud emissions are the priority**

As a fully remote company, we don't have a large physical footprint in the traditional sense. We've eliminated most commuting-related emissions by design, and our Paris headquarters runs on 100% renewable energy. We keep company-wide gatherings once every 18 months. These choices help, but they don't address the core issue.

Our cloud services run on data center infrastructure that requires electricity, cooling, and physical equipment. When that energy comes from high-carbon sources, the emissions are real and measurable. Nearly half of our company footprint traces back to those underlying infrastructure choices, which means that's where we have to focus.

## **Our commitments, in plain numbers**

In 2026, we've built a new climate strategy around three concrete targets, all measured against a 2024 baseline and a 2031 target.

### **1\. Revenue carbon intensity: -27% by 2031**

Rather than committing to an absolute reduction (which would be an unrealistic commitment due to our known dependence on the value chain, and the widespread and exponential adoption of AI), we're committing to reducing our carbon intensity per unit of revenue. Our current intensity stands at approximately 88 tCO2e per million euros of ARR. Our target is to bring that down to 62 by 2031, striving for a 27% reduction.

This approach lets us grow while actively decoupling that growth from emissions growth. It requires discipline across every team.

### **2\. Greener regions: 60% of projects by 2031**

We define a "greener" region as one where the energy carbon intensity is below 100 gCO2e/kWh. In 2025, 22% of our customer projects were hosted in such regions, up from 16% in 2024. Our target is to reach 60% by 2031.

This is the lever with the most direct impact on both Upsun’s and its customers’ our cloud emissions. The energy grid powering a data center is the single biggest variable in a cloud deployment's carbon footprint, and we can influence that through the choices we make available to customers and the ones we steer them toward.

To support this, we already apply a 3% discount for projects hosted in greener regions. We're also redesigning our onboarding flow in 2026 to surface greener options earlier and make region migration easier. Additional product-level initiatives are planned for 2027.

### **3\. Ongoing optimization: 2-4% annual emission cuts**

An internal study in January 2026 found that resource-efficiency improvements can reduce cloud carbon emissions by 2-4% on average each year. Our SRE and FinOps teams are already driving this work continuously. More efficient resource usage is good for costs and good for emissions, which means this effort sustains itself.

## **What else contributes**

Beyond cloud-specific action, we're maintaining a few corporate commitments that contribute to the broader target:

-   Keeping our Paris headquarters on 100% renewable energy through our EDF energy contract.
-   Deploying a new IT Equipment Purchasing and Sustainable Management Policy to reduce the environmental impact of our hardware fleet and move toward more circular practices. Our target is a 17% reduction in related carbon intensity by 2031.
-   Holding business travel emissions flat at 2025 levels, even as the company grows.

## **What we're not claiming**

We're not claiming to have solved cloud sustainability. We're not offsetting our way to net zero. We're not positioning this as leadership in the climate space. 

With three years of experience in cloud emission tracking, we know that carbon footprinting is a moving exercise requiring continuous methodological refinement. While our current modeling does not yet account for internal and external AI usage, we are committed to integrating these metrics in our measurement and revise our forecasts accordingly, as soon as our climate experts finalize a robust framework for inclusion.

What we are doing is measuring honestly, setting targets we believe we can hit, and building the internal processes and product features to make greener cloud choices more accessible to our customers. The 3% greener region discount has been live for a while. The onboarding redesign is in progress. The optimization work is ongoing. We'll report on progress annually.

## Collaborating with Watershed for our next chapter 

To launch and implement our new climate plan, we are teaming up with Watershed, the globally recognized CO2 monitoring platform. We are excited to integrate our current measurement and new targets and roadmap in their tools and to tap into the technical knowledge of their climate experts to refine our current approach. By leveraging their great level of automation and AI, we aim to improve the tracking and maximize the reduction of our cloud and corporate emissions. 

## **A note on the current methodology**

Our 2025 carbon footprint was calculated with Greenly using the GHG Protocol methodology, covering Scopes 1, 2, and 3: direct emissions from our own operations, indirect emissions from the energy we consume, and the broader value chain emissions we don't fully control but still influence, including our cloud infrastructure providers, business travel, purchased goods and services, and employee commuting. It is important to note that both internal and external AI usage has been excluded from the calculations. The 2.57 kt CO2e total reflects the full picture, with no categories excluded. Scope 3 is where most of our footprint lives, and it's also the hardest category to reduce, which is why our strategy focuses on the levers where we have the most direct influence.

Want to understand your project's carbon footprint or explore migrating to a greener region? Our team is available to help. You can also view our available regions and their energy carbon intensity on our website.

### [Cloud portability: what it is and how to achieve it | Upsun](https://upsun.com/blog/what-is-cloud-portability-and-how-to-achieve-it/)

# What cloud portability actually means and how to achieve it

## **The difference between multicloud and portable**

_Takeaway: Having workloads on two clouds is not the same as being able to move workloads between them freely. Portability is about the friction of movement, not the number of providers in use._

Most teams that call themselves multicloud are not portable. They have separate workloads siloed on separate providers, each with its own toolchain, deployment pipeline, and set of operational conventions. Moving anything between those environments means starting from scratch.

That is not portability. That is redundancy with extra operational weight.

True cloud portability means your applications, services, and data can move between cloud environments without significant reconfiguration. The code stays the same. The deployment process stays the same. What changes is the underlying provider or region, and that change should be a deliberate choice, not a migration project.

## **Why portability is harder than it looks**

_Takeaway: Lock-in is not usually a single decision. It accumulates incrementally. Each provider-specific integration adds friction to any future move._

The technical barriers are real. Providers layer proprietary autoscaling policies, networking add-ons, and identity integrations on top of open technologies like Kubernetes and PostgreSQL, reintroducing lock-in above the open-source baseline.

The organizational barriers are equally significant:

-   Teams build deployment scripts, CI pipelines, and monitoring configurations per-provider.
-   Application configuration often contains provider-specific environment variables, endpoints, or SDK calls.
-   Data stored in proprietary formats or managed services becomes expensive to extract.
-   Data portability and interoperability concerns consistently rank as the most discussed themes in relation to vendor lock-in among IT decision-makers.

A 2026 survey of 540 IT professionals found that 94% of organizations are concerned about vendor lock-in, with 84% specifically concerned about data sovereignty.

The gap between concern and action persists because the tooling most organizations use embeds provider assumptions at the infrastructure layer. Configuration files reference AWS-specific resource names. Environment variables point to Azure-hosted endpoints. By the time portability becomes urgent, the codebase has already absorbed years of provider-specific decisions.

## **What cloud portable infrastructure actually means** 

_Takeaway: Portable infrastructure means the deployment process describes application requirements, not provider-specific commands. The provider becomes a parameter, not a dependency._

Portability requires that your infrastructure configuration be written in a form that travels with your code rather than being tied to a specific provider's framework, console or CLI.

The practical requirements are:

1.  **Provider-agnostic deployment pipelines.** Your build and deploy process should not need to know whether it is running on AWS or GCP. It should describe what the application needs, not where it lives.
2.  **Configuration that is version-controlled and portable.** Infrastructure decisions should live in files committed to your Git repository, not in a cloud provider's dashboard.
3.  **Workload placement decisions made at the platform level.** The platform should handle provider-specific differences, so the team does not need to maintain separate expertise per cloud.
4.  **Data residency controls without workflow fragmentation.** Placing data in a specific region for compliance reasons should not require a different deployment process for that workload.

This is the model Upsun uses for multicloud deployments. Infrastructure choices are managed through portable YAML files that are version-controlled alongside application code, and a consistent platform layer handles provider-specific differences. The same workflow deploys to AWS, Azure, Google Cloud, IBM, or OVHCloud depending on what region you select during project creation. Selecting the optimal cloud provider for each project requires no change to how the application is built or operated.

It also means that your engineers only need to understand one configuration and interface for all major providers.  They don’t have to deal with context switching as they move from application to application.  

That matters because it separates the _where_ from the _how_. Engineers do not need to learn a new deployment model each time a workload moves or if it is determined an application should be with a certain cloud provider. They configure the application once and choose the provider and region independently.

## **The compliance and resilience case**

_Takeaway: Portability is the prerequisite for both real data sovereignty and credible resilience. Without it, multi-cloud is theater._

Two specific pressures make portability a practical requirement rather than a theoretical preference:

1.  **Data residency.**   
    Regulations such as GDPR in Europe require that certain categories of data be stored and processed in defined jurisdictions. A financial services team can deploy European customer data to OVHCloud in Germany and US data to AWS in Virginia using the same pipeline. Without portability, that's two pipelines, two sets of configurations, two operational runbooks. The compliance requirement didn't change; the operational cost doubled.
2.  **Resilience planning.**   
    Distributing workloads across providers is only a meaningful disaster recovery strategy if those workloads can actually be moved or failed over. Upsun's portability model allows teams to build cross-cloud failover systems using portable configurations and repeatable workflows. An organization that runs equivalent workloads on Azure and AWS using a consistent platform can recover from a provider-level event. One that has deeply embedded provider-specific dependencies cannot.

A team whose pipeline references AWS-specific resource names and endpoints can't fail over to Azure; they can redeploy, but that's a migration project under pressure, not resilience. Without portability, multicloud is theater. 

## **Where to start**

Portability is not a one-time migration. It is an architectural posture that teams need to maintain consistently. Practically, that means:

-   Keeping application configuration in version-controlled YAML rather than provider dashboards.
-   Avoid managed services with no standard exit path unless the trade-off is deliberate and documented.
-   Treating provider and region selection as operational decisions, not architectural ones
-   Testing that workloads can actually move, not just assuming they can.

The goal is not zero cloud-provider integration. It is controlled integration, where the cost of moving is low enough that provider selection remains a genuine choice.

* * *

## **Frequently asked questions (FAQ)**

**What is the difference between cloud portability and multicloud?**

Multicloud means running workloads on more than one provider. Cloud portability means that workloads can move between providers without rebuilding pipelines or rewriting configurations. A team can be multicloud and completely locked in at the same time. Portability is about the friction of movement, not the count of providers.

**What does cloud-portable infrastructure require in practice?**

Four conditions need to be true: deployment configuration lives in version-controlled files rather than a provider's dashboard; your pipeline describes what the application needs, not where it runs; provider and region selection are handled at the platform level; and data is stored in formats that can be migrated without a bespoke project.

**How does cloud portability support data residency compliance?**

Without portability, meeting regulations like GDPR across different regions typically means maintaining separate pipelines per geography. A portable model lets teams deploy to region-specific providers using the same configuration and workflow; when the region changes, the process does not.

**Should you build an internal platform for portability or adopt one?**

Building gives you control but creates a permanent maintenance obligation. Every new provider requirement becomes an engineering project, and your most senior engineers end up managing infrastructure instead of shipping product. An adopted platform absorbs that cost by design.

### [Give AI coding assistants live platform context | Upsun](https://upsun.com/blog/ai-coding-assistants/)

# AI coding assistants are only as good as the context you give them

AI coding assistants have quickly become part of everyday development. Teams now rely on them to explain unfamiliar code, suggest configuration files, debug errors, and accelerate delivery across the stack.

But as these tools move from experimentation into real production workflows, a consistent pattern is emerging:

**AI breaks down at the platform boundary.**

The moment guidance needs to reflect how a real platform behaves (its configuration syntax, deployment model, supported services, and operational constraints), generic AI answers start to fail. And the more critical the system, the more costly those failures become.

## The hidden failure mode of AI-assisted development

Most AI coding assistants are trained on static data: public repositories, documentation snapshots, and examples that may already be outdated by the time a model is released.

That works well for:

-   Language, syntax, and idioms
-   General programming concepts
-   Framework-level patterns

It works poorly for:

-   Deployment configuration
-   Platform-specific behavior
-   Version-sensitive features
-   Operational edge cases

The result is subtle but dangerous. AI answers often sound confident and complete while quietly being wrong for _**your**_ environment. Configuration files look valid. Advice appears authoritative. But errors only surface later, during deployment, under load, or in production.

## Why is this problem getting worse, not better

Modern platforms evolve continuously. Documentation changes weekly. Configuration schemas shift. Defaults are tightened for security or compliance. New services and constraints are introduced as platforms mature.

At the same time:

-   AI adoption is accelerating across engineering teams
-   Junior engineers rely on AI earlier in decision-making
-   Platform knowledge is increasingly encoded in tooling, not tribal memory

This widens the gap between what AI knows and how platforms actually work today.

That gap shows up as:

-   Invalid or deprecated configuration copied into production
-   Misunderstood deployment models
-   Increased debugging time for advice that never matched the platform in the first place

For platform and engineering leaders, this is no longer just a productivity issue. It is an operational and governance issue.

## The missing ingredient: live, authoritative platform context

The models themselves are not the problem. The missing ingredient is live, authoritative context at answer time.

To be reliable inside real development workflows, AI assistants need:

-   Current documentation, not training-time snapshots
-   Version-specific guidance
-   Platform-aware explanations
-   Clear boundaries around what _is_ and _is not_ supported

This is why retrieval-based approaches (where AI tools pull trusted information at query time) are becoming essential for professional software teams.

Put simply:

**AI-assisted development requires infrastructure-level thinking, not just smarter prompts.**

## What context-aware AI workflows actually look like

When platform context is available at query time, AI stops guessing and starts grounding its answers in reality.

That enables a class of workflows teams increasingly expect:

-   Asking an AI assistant how to deploy _on your platform_, not in theory
-   Generating configuration that matches current syntax and constraints
-   Debugging deployment issues using up-to-date platform behavior
-   Learning platform concepts without leaving the editor
-   Onboarding new engineers without relying on tribal knowledge

These workflows are not about convenience. They reduce risk while increasing speed, and they scale across teams instead of living in individual developer setups.

**Note**: This workflow requires AI assistants that support the Model Context Protocol (such as Claude Desktop, Cursor, or Windsurf) and local setup by the developer. While Context7 makes Upsun documentation available, each developer needs to manage their own MCP configuration.

## Bringing live Upsun documentation into AI assistants

Upsun documentation is accessible through Context7, a documentation retrieval system built on the Model Context Protocol (MCP). 

Instead of relying on whatever information an AI model was trained on, Context7:

-   Fetches the latest version-specific Upsun documentation.
-   Injects it directly into the AI assistant’s context.
-   Ground responses in authoritative, current sources.

From a developer’s perspective, the assistant becomes a guided interface to the platform, not a guessing engine. Questions about deployment, previews, services, or configuration are answered based on how Upsun works today.

(Technical setup details are covered in the Dev Center guide linked below.)

## Why this matters beyond developer convenience

For individual developers, context-aware AI saves time. For teams and organizations, it fundamentally changes the risk profile of AI adoption.

When AI answers are grounded in a live platform context:

-   Fewer mistakes reach production
-   Senior engineers spend less time correcting configuration errors
-   New hires ramp faster without breaking guardrails
-   Platform standards are reinforced instead of bypassed

This maps directly to the priorities platform leaders care about:

-   Consistency without blocking autonomy
-   Faster delivery without increasing operational risk
-   Scaling teams without scaling operational toil

AI does not replace platform engineering, but it can amplify it if the platform is designed to support it.

## AI tooling alone is not enough

There is a growing misconception that “AI readiness” is primarily about choosing the right assistant or model.

In practice, AI-assisted development is only as strong as the infrastructure beneath it. Platforms that maintain clear, stable, and publicly accessible documentation enable third-party tools like Context7 to provide AI-assisted workflows. Upsun's approach to declarative configuration and comprehensive documentation makes this possible without requiring platform-specific AI integration

Without this foundation, AI becomes another source of inconsistency rather than leverage.

## Building AI-assisted workflows on Upsun

Upsun is designed around the idea that modern development workflows, AI-assisted or not, require standardization without rigidity.

Key characteristics that matter in an AI-augmented workflow include:

-   Declarative, Git-driven configuration that makes platform rules explicit
-   A consistent environment model that reduces ambiguity
-   Production-grade previews that allow safe experimentation
-   Clear documentation that reflects real platform behavior

Upsun documentation naturally works with Context7 to ensure developers can access platform guidance through AI-assisted workflows. As AI becomes more deeply embedded in development workflows, this distinction becomes increasingly important. Teams that treat AI as “just another tool” will struggle to govern it. Teams that treat AI as part of their platform architecture will move faster, with fewer surprises.

## Explore it yourself

If you want to see how context-aware AI-assisted development works in practice:

-   **Read the technical setup guide** for connecting Upsun documentation via Context7
-   **Explore AI-ready development workflows on Upsun**, including previews, standardized environments, and AI-friendly platform patterns

These resources show how live platform context turns AI from a helpful assistant into a reliable part of your delivery workflow.

### [Enforce MFA for orgs, reduce risk of unauthorized access | Upsun](https://upsun.com/blog/enforce-mfa-for-your-organization/)

# Enforce MFA for your organization, reduce the risk of unauthorized access

At Upsun, we're committed to providing the highest level of security for your projects and data. That’s why we're excited to announce a new feature designed to enhance the security of your organization: Enforce Multifactor Authentication (MFA). While we’ve always had MFA available for Upsun users, you’ll now need to enable it to access organizations.

## What’s MFA, and why is it important?

Multifactor authentication adds an extra layer of security by requiring users to verify their identity through multiple methods before accessing sensitive information or systems. This industry-standard approach significantly reduces the risk of unauthorized access.

## Benefits of enforcing MFA on your organization

When enabled, all members of your organization will be required to enable MFA on their user accounts to access any organization resources and projects via SSH or API (including through the Upsun console and CLI).

Organization administrators can enable or disable enforcing MFA on their organization, and they can also generate and send email reminders to users who haven’t yet enabled MFA. This feature helps ensure all members of your organization comply promptly with the new security requirement.

## How to enforce MFA on your organization

This feature is available with the _User Management_ add-on for Upsun and for all Enterprise/Elite organizations on Platform.sh. Once upgraded, access your organization _Security_ tab, and enable MFA.

Read more in our public documentation  

By enforcing MFA, you’re taking a significant step toward ensuring the safety and integrity of your data and projects. Stay secure!

### [Instant data cloning for developing cloud-based apps | Upsun ](https://upsun.com/blog/data-cloning-the-game-changer-for-developing-cloud-based-applications/)

# What is instant data cloning? The game changer for developing cloud-based applications

What sets Upsun apart, is its unparalleled ability to **instantly clone data** from a running production application.

This groundbreaking feature equips developers with exact replicas of their production environments within minutes, revolutionizing the way they build, test, and deploy software. 

In this blog post, we'll explore what data cloning is, why this capability is a game-changer, and how it significantly enhances the development process.

## **The developer's challenge**: how to maintain accurate and efficient development environments

To test changes reliably, developers need environments that mirror production setups. However, creating these exact replicas is complex and time-consuming. As a result, developers end up with environments lacking the full functionality of the production environment, reducing their efficacy. 

Without proper database replication, testing is incomplete and unreliable, leading to more work when issues emerge later.

### **Slow environment setup**

Traditional methods of creating accurate development environments require manually configuring services, databases, and dependencies, taking hours or even days. This delays project timelines and reduces productivity. Modern methods often only create environments for static or stateless applications, missing critical components like databases, message queues, and files.

### **Inconsistent data across environments**

Data inconsistencies between development and production environments pose significant challenges. Developers often work with outdated datasets that don't reflect the production state, leading to bugs, faulty tests, and features that fail in production. This wastes time and resources as developers scramble to fix issues.

### **High costs of maintaining multiple environments**

Maintaining multiple environments is both time-consuming and costly, requiring substantial hardware and software resources. This adds a significant financial burden to organizations.

### **The risk of downtime**

In addition to setup and data consistency challenges, there's the risk of system downtime. Quick recovery from system failures or data loss is crucial. Traditional backup and recovery methods are often slow and unreliable, leading to prolonged downtime and severely impacting business operations.

In summary, the developer's dilemma is multi-faceted, and each challenge significantly affects the efficiency and effectiveness of the development process.

## **The solution**: instant data cloning of product environments 

Upsun revolutionizes this process by offering the unique capability to instantly clone an entire production environment, including all critical data and services. 

This feature is a game-changer, providing developers with exact replicas of production environments within minutes.

### **Why data cloning for development environments matters**

Cloning data from a production environment is crucial for quality and speed in software development. Here’s why:

#### Realistic testing conditions

Cloning the data ensures that the development environment is an exact replica of production, capturing all user interactions, edge cases, and data variations. This realism helps developers identify and address issues that would only surface under real-world conditions, leading to more reliable testing and fewer surprises during deployment.

#### Isolated development 

Each developer can work in their own isolated environment, eliminating conflicts and enabling parallel development. This isolation increases productivity and ensures that one developer’s changes do not impact others.

#### Rapid iterations

Quickly spinning up development environments means that developers can test, receive feedback, and refine their code more swiftly, accelerating the development cycle.

#### Efficient debugging

Many bugs are data-dependent and might not appear with simplified or synthetic test data. Using real production data helps uncover such bugs early in the development cycle, reducing the risk of issues slipping into production. This consistency simplifies debugging, making it easier to reproduce and fix issues, thus enhancing overall code quality.

#### Performance testing

Real data volumes allow for accurate load, stress, and volume testing. Developers can measure and optimize the application’s performance under conditions that closely mirror actual production loads, leading to better resource management and user experience.

#### Data integrity and security

Ensuring data integrity during cloning means that the application’s behavior remains consistent across different environments. Additionally, Upsun offers mechanisms to scramble, encrypt, or anonymize sensitive data, as well as fine-grained access policies, maintaining security while allowing comprehensive testing and mitigating risk.

#### Stakeholder collaboration

Preview environments with real, live data can be shared with stakeholders, expediting approvals, speeding up QA processes, and keeping projects on schedule. This real-time feedback loop enhances communication and alignment across teams.

#### Efficient disaster recovery

Instant data cloning also ensures improved disaster recovery, allowing for quick restoration from backups.

#### Increased confidence in deployment

Knowing that the code has been tested with real data in an environment identical to production boosts confidence in the deployment process. This reduces the chances of post-deployment issues and downtime, ensuring smoother releases.

## **How it works**: copy-on-write with Ceph

Upsun's instant data cloning leverages an incredibly smart copy-on-write mechanism based on Ceph RBDs which use RADOS capabilities including snapshotting, replication, and strong consistency. 

Here's a breakdown of how it works for different Upsun main capabilities:

#### **Clone a production environment**

Every time a production environment is cloned (aka _branched_ in Upsun, following the Git terminology) a snapshot of the disk is taken. This snapshot only involves copying the metadata at that particular point in time, making the process highly efficient and independent of the data size (Upsun can _clone_ a 1TB MySQL or PostgreSQL database instantly).

This snapshot serves as the foundation for the development environment.

From this snapshot, only the changes (writes) are subsequently stored on the development environment's disk. This means that the base environment remains unaltered, while any changes made in the development environment are recorded independently. This method ensures a fast, consistent, and accurate replication of the production environment without unnecessary duplication of data.

#### **Take and restore a backup**

The same trick is applied for backups. When creating a backup, Upsun will take a Ceph snapshot, and then stream the snapshot’s disk to an external bucket (like S3). This ensures that the backup can be restored with confidence to its exact state at that specific point in time, guaranteeing full data integrity and recoverability.

#### **Refresh a development environment**

When an existing development environment needs to be updated with production data (aka _synchronization_ in Upsun), a new snapshot of the production environment is taken and used as the new base for the development environment. This ensures that all development environments are always in sync with the latest production data.

#### **The efficiency of snapshots**

The beauty of this system lies in its efficiency. Snapshots are quick to make because they only involve copying metadata, and the copy-on-write mechanism ensures that only changes are stored, not entire datasets. This allows Upsun to offer incredibly fast cloning, backing, restoring, and synchronizing operations. Effectively eliminating the delays and resource consumption associated with traditional methods of exporting datasets, or relying on external providers.

In summary, Upsun’s use of copy-on-write with Ceph not only accelerates the creation and management of development environments but also ensures data accuracy and integrity. This advanced methodology is another factor that sets Upsun apart in the field of modern application development.

## **Automatic, instant data cloning for development environments**

Upsun was designed from the ground up with instant data cloning as its core feature, providing an unmatched competitive advantage in the realm of software development. 

Instead of relying on cumbersome processes like data export and import that can take hours, or being limited to cloning static applications, Upsun delivers fast, reliable, and fully functional replicas of entire production environments in just minutes. 

Additionally, by not relying on third-party providers for providing databases or message services (like PostgreSQL, Redis, and Kafka), Upsun avoids all the extra costs associated with bandwidth, data transfer, writes, and storage charges. This means that development teams can focus on what they do best—developing, testing, and deploying high-quality software—without worrying about time delays, data inconsistencies, or spiraling costs.

In summary, Upsun’s instant data cloning solves the long-standing challenges of setting up and maintaining accurate and efficient development environments, making it an invaluable asset for any development team. With Upsun, you get faster setup times, more reliable testing conditions, lower costs, and an overall smoother development experience. 

### Useful links

-   What is .env file?

### Watch this video

### [Solve the data context gap for AI agents | Upsun](https://upsun.com/blog/grounding-rag-pipelines-real-world-data/)

# The data context gap: why agents fail on fragmented stacks

_Key takeaway: AI agents and RAG pipelines only reach production-grade accuracy when they are developed against byte-level clones of real production data. Without environment parity, the "repro gap" leads to inevitable AI failure._

### The reality gap in agentic AI

In 2026, the competitive moat for an enterprise isn't the LLM you choose; it's the context you provide it. We are moving toward agentic systems: AI tasked with real-world outcomes like inventory stabilization or financial auditing.

However, most AI agents are currently developed in a vacuum. This creates a massive data context gap (or "Repro Gap"), where an agent operates on a hallucinated version of your infrastructure because it lacks access to the scale, complexity, and specific constraints of your production data.

### **I. Why RAG and Agents fail on fragmented stacks**

_Key takeaway: Most agentic failures are not intelligence failures; they are context failures. If the agent doesn't know the live state of your data, its suggestions will fail the moment they hit production._

Traditional development workflows are built on fragmentation, which creates three major failure points for AI:

1.  **Stale mock data:** AI assistants write code against "sampled" data that lacks the edge cases of your actual production cluster.
2.  **The repro gap:** The time wasted recreating production-grade environments manually. When the staging environment doesn't match production, AI-generated migrations often cause database locks or data constraint violations.
3.  **Fragmented backing services:** When your vector database, search engine, and relational store are managed in different silos, the AI agent loses the unified source of truth required for complex reasoning.

### **II. The solution: instant data cloning**

_Key takeaway: Upsun’s byte-level clones allow you to spin up an exact copy of your entire production setup, including all data and service configurations, in under a minute._

To bridge the gap, every developer and AI agent needs a Production-Parallel Sandbox. On Upsun, every Git branch automatically triggers a byte-level clone of your production environment.

-   **Byte-accurate parity:** These aren't just snapshots; they are production-perfect environments. You can give an AI agent an isolated sandbox in ~60 seconds to test a new RAG retrieval strategy against real-world data volumes.
-   **Copy-on-write technology:** Using verified copy-on-write mechanic, agents can run destructive tests or heavy data-cleansing scripts without any risk or performance impact on the live site.
-   **Zero prep time:** By eliminating manual data seeding, teams realize up a significant reduction in deployment time, moving from "vibe" to "verified" faster than ever.

### **III. Scaling with confidence: independent resource allocation**

_Key takeaway: Upsun allows for surgical vertical and horizontal scaling of backing services, ensuring your RAG pipelines have the dedicated headroom they require._

In the AI era, database performance is the primary bottleneck. Upsun's standardized environment solves this today by allowing you to:

-   **Independent scaling:** Unlike legacy platforms, you can scale your PostgreSQL or OpenSearch containers vertically (RAM/CPU) without being forced to scale your entire application.
-   **Predictable performance:** By validating scaling behavior in a data-complete preview, you ensure your production agents won't hit a wall.

### **IV. The 2026 competitive advantage: moving from maintenance to innovation**

_Key takeaway: By standardizing infrastructure as a version-controlled Unified Application Spec, organizations eliminate "undifferentiated heavy lifting," allowing senior engineers to pivot from pipeline maintenance to core product value._

In 2026, the organizations that win are those that treat infrastructure as a managed dependency rather than a manual chore. When your infrastructure is decoupled from your application logic, your most expensive engineers spend most of their time on "shadow infrastructure" sprawl and firefighting delivery pipelines.

By adopting a deterministic unified configuration file (`.upsun/config.yaml`), you provide your AI agents with a machine-readable map of your entire world, from postgresql instances with the vector extension to opensearch clusters. This consistency is what closes the "Context Gap."

This removes the mechanical friction that usually drains engineering cycles, ensuring your agentic loops have the predictable environment they need to succeed and reclaiming your innovation budget in the process.

### **The next step for modernization architects** 

The "DevOps Tax" is highest when your AI is forced to work in the dark. Grounding your agentic loops in a data-complete environment turns your infrastructure into a measurable strategic advantage.

**To begin closing your context gap:**

-   **Evaluate your repro gap:** Measure how many engineering hours are lost to recreating production-state bugs.
-   **Audit your data context:** Determine the age of the data your AI agents are currently using for testing.
-   **Standardize your stack:** Explore how standardized environments eliminate environment drift by enforcing 100% parity across every branch

### **Frequently asked questions (FAQ)**

**Doesn't cloning production data violate privacy regulations like GDPR?** 

It would if you cloned it blindly. Upsun allows you to define sanitization hooks in your deployment pipeline. The moment a branch is created, a byte-level clone is made, and a sanitization script (e.g., masking emails or stripping PII) runs automatically before any developer or AI agent gains access. You get the _shape_ and _scale_ of production data without the compliance risk.

**Does cloning a 500GB database for every branch explode our storage costs?** 

No. Upsun uses Copy-on-Write technology. When you clone an environment, you aren't physically duplicating 500GB of data. You are creating a "virtual" pointer to the existing data blocks. You only pay for the _changes_ (diffs) made within that specific branch. This makes "Data-Complete Previews" economically viable even for massive datasets.

**Will running an AI agent against a clone slow down our live production site?** 

Not at all. Because the clone is a logically isolated environment with its own dedicated resources, the AI agent can run heavy queries, re-index vector stores, or execute complex migrations without consuming a single CPU cycle from your production cluster.

**How is this different from a traditional "Staging" database?** 

Traditional staging is a "shared" resource that quickly becomes a graveyard of stale data and conflicting migrations. Upsun provides Ephemeral Parity: every single Git branch gets its own unique, fresh clone. When you delete the branch, the environment (and its data) vanishes, ensuring no "Shadow Data" sprawl.

**Can AI agents actually understand the infrastructure?** 

Yes, through the Upsun MCP Server. Instead of scripting API calls, your agent can create environments, add services, and monitor deployments using natural-language commands, grounded in the live state of your Upsun project rather than guesses about how your infrastructure is shaped.

### [Why code review is not infra validation | Upsun](https://upsun.com/blog/why-code-review-is-not-infrastructure-validation/)

# Beyond the pull request: why code review is not infrastructure validation

_Key takeaway: Code review and infrastructure validation are distinct problems. While AI can review syntax, only an active, data-complete environment can validate system-wide state. Upsun provides the_ _unified configuration file_ _needed to turn "looks good to me" into verified production-readiness._

## The "blind spot" in AI-assisted development

In 2026, the primary cause of AI-generated bugs isn't a lack of logic; it is a lack of context.

As AI agents begin to generate more code, the volume of pull requests (PRs) is exploding. The response from platform providers has been to automate the bottleneck. The promise is simple: use an LLM to classify PRs, auto-approve the "low-risk" ones, and get back to shipping.

But "low-risk" is a code-level judgment. A CSS tweak that triggers a massive re-render, or a config change that misaligns a Redis instance, is a site-wide outage that no static analysis will catch. AI can review your syntax, but it cannot validate your infrastructure.

## I. Turning infrastructure into a readable dependency

_Key takeaway: A PR isn't just a request to merge text; it is a request to validate a full-stack state including code, services, data, and the relationships between them._

Standard CI/CD pipelines and AI-assisted reviews focus on verification (_does the code pass a test?_). They almost entirely ignore validation: _does this specific version of the application actually run against a production-shaped environment?_

When we treat a PR as a text-only event, we ignore the three pillars of system integrity:

1.  **The application:** The code, binaries, and runtime instructions.
2.  **The services:** The versioning and configuration of Redis, MariaDB, Solr, or RabbitMQ.
3.  **The data:** The actual state of the database that the code must interact with.

**Syntax vs. state**

AI can catch logic errors in a diff. Only a running environment catches "silent killers" like service connection timeouts or failed schema migrations.

**The unified configuration file** 

By defining your stack in `.upsun/config.yaml`, the platform understands the dependencies before the first line of code is executed. This file acts as the source of truth, ensuring the AI agent isn't guessing how the application connects to its persistent storage.

## II. Validating against a production reality

_Key takeaway: Upsun can trigger an_ _Instant data-complete preview environment_ _for every branch, providing a byte-level clone of production apps, services, and databases via copy-on-write._

The missing link in the modern development workflow is environment integrity. To move safely, your "sandbox" must match your "production" reality exactly. 

Traditional "staging" environments are notorious for being "close enough" to production, which is exactly where regressions live.

-   **Byte-level clones:** The build either succeeds against real services and real data, or it doesn't. You are no longer testing against a "mock" database or a stale dump from three months ago. Upsun spins up an exact copy of your entire production setup, creating byte-level copies for testing and development in less than a minute.
-   **Git as the control plane:** Because Upsun uses Git to manage the application and environment lifecycle, infrastructure configuration is versioned alongside application code. This removes most of the operational glue work that typically slows teams down.
-   **Branch visibility:** Teams can wire the environment build status into their CI/CD workflows. If the container doesn't spin up or the configuration is invalid, the platform provides immediate feedback, moving the goalpost from a subjective "looks good to me" to an objective "the environment came up clean."

## III. Why AI can't hallucinate a container build

_Key takeaway: while LLMs are probabilistic and prone to hallucination, a container build is deterministic. Infrastructure validation provides the ground truth that AI-assisted reviews lack._

AI agents are designed to be convincing, not necessarily correct. They can argue that a change is "low risk" based on the text of a PR. They can even simulate a code review that looks perfect to a tired senior engineer.

However, an AI cannot hallucinate a successful container build against production-shaped data. In a world where agents are generating a majority of your code, your infrastructure needs to be the "adult in the room."

-   **Deterministic guardrails:** By using `.upsun/config.yaml`, you establish a deterministic environment that doesn't care about the AI's "vibe." It only cares if the configuration is valid.
-   **Scaling governance:** As your PR volume increases, the human review bottleneck shouldn't be replaced by "AI blindness." It should be replaced by automated validation. This eliminates the risk of "shadow infrastructure", where unvalidated code lingers in the pipeline.

## Beyond the local vibe: scaling AI context for the enterprise

The transition from "vibe coding" to production-grade engineering requires a platform that understands the high stakes of the enterprise. When your developers, human or AI, work on Upsun, they aren't working in a vacuum. They are working within a governed, version-controlled unified configuration file.

This ensures that the agility provided by AI doesn't come at the cost of your system's stability. 

When a branch is deleted, the environment can be torn down automatically, saving compute costs and mental overhead. Whether you are deploying a minor UI fix or a major architectural refactor, the platform ensures the environment is the ultimate validator.

## Frequently asked questions (FAQ)

**Does triggering a preview environment for every PR increase cloud costs?**

Every environment uses billable resources, but Upsun is designed to eliminate "staging waste." You can define Lightweight resource profiles for your previews in .upsun/config.yaml to minimize costs, and use automated environment teardown (or auto-suspend) to ensure you only pay for resources while they are actively being reviewed.

**Can this process be automated for all cloud providers?**

Yes. Upsun provides options for AWS, Azure, GCP, IBM, and OVHCloud in multiple regions. Because the unified configuration file is standardized, the validation process remains identical regardless of your choice of cloud provider.

**How does this integrate with my existing AI code review tools?**

Upsun acts as the "ground truth" layer.  Your AI tools can suggest and review code, but Upsun provides a reproducible environment against which you can perform automated or manual checks. While the platform reports whether the environment builds successfully, you can utilize the Upsun CLI and API to run deeper validation suites against the live clone.

**What happens if a "low-risk" PR fails the environment build?**

If a configuration error, service timeout, or resource limit prevents the environment from spinning up, the developer (or the AI agent) receives a detailed log from the platform. This allows for immediate remediation based on platform feedback rather than waiting for an incident in production to reveal the flaw.

### [Upsun multi-cloud PaaS: the 2026 choice for tech leaders](https://upsun.com/blog/multi-cloud-paas-tech-leaders-are-choosing/)

# Why Upsun is the multi-cloud PaaS technical leaders are choosing in 2026

In a recent technical evaluation by Journal du Net (JDN), Upsun (formerly Platform.sh) was recognized for its ability to "pull ahead" (_tire son épingle du jeu_) in a fiercely competitive market dominated by cloud giants and specialized pure players. While hyperscalers offer raw power, Upsun’s strategic fusion of enterprise reliability and AI-ready agility has redefined expectations for modern PaaS.

## **Bridging the gap between complexity and speed**

The core challenge for technical leaders in 2026 is no longer just moving to the cloud, but managing the subsequent surge in complexity. As development cycles compress, traditional cloud models often slow down roadmaps due to unmanageable DevOps toil and inconsistent environments. Upsun addresses this by providing a standardized, "human and robot-friendly" platform that simplifies the entire application lifecycle.

Unlike platforms like Heroku, which are physically constrained to a limited number of AWS regions and can struggle with scalability, Upsun lets you deploy to AWS, Azure, Google Cloud, IBM, and OVHcloud using identical workflows. For European enterprises, the ability to run on sovereign infrastructure like OVHcloud provides a critical path to compliance without losing the speed of a modern PaaS.

## **The comparative landscape**

The JDN analysis evaluated Upsun against other major PaaS players, highlighting its unique position as a comprehensive, multi-cloud solution that balances power with ease of use:

## **The "production-perfect" advantage**

A celebrated technical strength noted in the comparison is Upsun's approach to environment management. While other platforms offer basic review apps, Upsun provides "byte-for-byte" clones.

Every Git push can trigger an environment replica that mirrors your production setup exactly, including configuration, code, and live data. This allows teams to test UI, backend, and AI components with realistic data, virtually eliminating the risk of "staging drift" or late-stage surprises during deployment.

## **Economic transparency and ESG leadership**

In an era of volatile cloud spend, Upsun’s Flex pricing model offers granular, container-level control. Users pay only for the resources they provision (e.g., 1GB RAM and 0.5 CPU cores), with costs scaling linearly with actual activity.

Furthermore, as a B-Corp certified organization, Upsun leads in sustainability by providing real-time CO₂ tracking and a 3% "Greener Region" discount for hosting in energy-efficient data centers. This ensures that technical growth remains aligned with environmental and business objectives.

_For more detailed insights, view the original report at_ _Journal du Net (JDN)__._

### [How global fluency turned into inclusive leadership](https://upsun.com/blog/global-fluency-and-inclusive-leadership/)

# Beyond the horizon: How Adel Jalabi turned global fluency into inclusive leadership

Welcome to _Beyond the horizon_, a monthly series celebrating the people who shape Upsun’s culture, innovation, and heart. This month, we meet Adel Jalabi, Upsun’s Manager, Talent Acquisition & Inclusion.

Adel’s story isn't a traditional corporate climb; it’s a journey defined by what he calls "global fluency." Having moved from Syria to Canada at age 12 and later living and working across five different countries, including Qatar and South Korea, Adel has spent his life navigating new cultures and perspectives.

Today, he uses that lived experience to lead our recruitment and Diversity, Equity, Inclusion, and Belonging (DEIB) initiatives. For Adel, inclusion isn’t a corporate buzzword; it’s about creating a space where "bringing your whole self to work" is the standard, not the exception.

In his story, Adel shares how his non-linear path led him to Upsun, the challenge of staying true to his values as an activist and member of the LGBTQIA+ community, and why he believes a diverse, "global" mindset is exactly what the future of tech needs. 

### **Tell us a bit about yourself. What do you do at Upsun and most importantly, who are you outside of work?**

> I’m Adel Jalabi, and I manage Upsun’s Talent Acquisition team while also overseeing our DEIB (Diversity, Equity, Inclusion, and Belonging) program. I’ve been with Upsun for a little over a year and a half. My team and I focus on attracting and hiring exceptional talent while making sure every candidate who interacts with Upsun has a thoughtful and positive experience throughout the recruitment process. Alongside that, I help lead initiatives that ensure our culture truly reflects our commitment to inclusion and belonging. 
> 
> I live in Guelph, a small town near Toronto, Canada, with my partner and our two dogs. I love spending time outdoors (especially hiking and exploring nature) and traveling whenever I can. So far, I’ve visited over 30 countries, and travel has been one of the most meaningful ways I’ve learned about people, cultures, and perspectives different from my own. I’m also an avid reader and usually go through at least three books a month, mostly fiction.
> 
> Travel has also shaped another important part of who I am: I’m very politically aware and involved in different activist circles. Seeing different parts of the world and learning about people’s lived experiences has made me deeply conscious of social and political injustices, and that awareness continues to influence how I engage with the world.

### **How would you describe your journey so far in one word or phrase, or how would you describe the story or perspective you’d like to share here?** 

> If I had to describe my journey in one phrase, it would be “global fluency". My path hasn't been linear or traditional; it's been shaped by curiosity and a desire to experience the world beyond what's familiar.
> 
>  I moved to Canada from Syria at the age of 12, a transition that fundamentally shaped who I am today and fueled my curiosity about the world.  
> 
> Growing up, I moved frequently and lived in five different countries, which gave me an early appreciation for different cultures and perspectives. After university, I took my first big step abroad by moving to Qatar, where I began my professional career as an HR Specialist in the hospitality industry. From there, I followed my curiosity again and moved to South Korea, where I lived and worked for two years at an English Learning Center. Living abroad has always brought me a deep sense of excitement. Immersing myself in completely new cultures has been one of the most rewarding sources of both personal growth and perspective in my life.

### **What’s a challenge you’ve faced and how have you grown from it?** 

> One of the most persistent challenges I’ve faced has been navigating the tension between my professional identity and my personal values as an activist and a member of the LGBTQIA+ community. Early in my career, particularly while living and working in diverse global regions with varying social climates, I often felt I had to 'mute' certain parts of myself to fit into traditional corporate structures and societal norms.
> 
>  It took a while, but I've finally grown to realize that my lived experiences and international exposure are actually one of my greatest professional assets. I’ve learned that true inclusion isn't just about fitting in; it’s about creating spaces where people don't have to compromise their identities to succeed. This challenge turned into a professional goal to always ensure that my team and I don't just hire for skill, but we foster an environment where 'bringing your whole self to work' is a reality, not just a buzzword.

### **Is there someone at Upsun who played a key role in your journey or made your experience possible?**

> Jenna Zucchet has been instrumental in my journey and in making this experience possible. Jenna and I worked together at Shopify, and I was in between jobs, taking a short career break after a very stressful two years working in the Healthcare industry. She reached out with an opportunity to provide some consulting work for what was then Platform.sh, now called Upsun, which, at the time, I knew very little about. 
> 
> Taking this consulting project was the spark I needed. Jenna's trust in my expertise allowed me to see the potential of what we could build here. What started as a short-term engagement quickly evolved into a full-time role where I could lead Talent Acquisition and DEIB. Jenna has been a constant advocate and a sounding board, helping me navigate the transition into the tech space and empowering me to take ownership of the culture-driven initiatives I'm passionate about.

### **As we say at Upsun, 'Your greatest work is just on the horizon.' What's the next horizon you're excited to reach in your journey?** 

> The next horizon for me is to continue to evolve our DEIB program from foundational initiatives into a deeply embedded, sustainable part of Upsun's DNA. As we scale, I'm excited to build frameworks that ensure equity isn't just a goal, but a natural outcome of how we operate.
> 
> My story helps shape this for others by proving that there is no 'standard' path to success at Upsun. I want to show my colleagues and future candidates that their unique, non-linear backgrounds are exactly what we need to innovate. 

  
Thanks for joining us on this month’s journey. Beyond the horizon is all about the stories that shape who we are. We hope you’ll return next month as we continue celebrating the people who inspire our culture and move Upsun forward. 💙

### [Eliminate DevOps toil in regulated SaaS | Upsun](https://upsun.com/blog/eliminate-devops-toil-in-regulated-saas/)

# How to eliminate DevOps toil in regulated SaaS

In regulated industries like fintech, healthcare, and government, DevOps teams often find themselves acting as human compliance gateways. 

The pressure to maintain strict security standards while accelerating release cycles creates a compliance tax: a heavy burden of manual environment setups, security review tickets, and the inevitable scramble for evidence before an audit.

This manual labor, or toil, is more than a drain on productivity. It creates a dangerous gap between policy and actual operations. 

When environments are configured manually, they eventually stop being identical, leading to environment drift that causes both deployment failures and audit findings.

**For regulated SaaS teams, the question is not whether compliance is required, but how it is enforced.**

### **Deep dive: the compliance tax on developer velocity**

The cost of compliance toil is often discussed anecdotally, but the data is clear: manual operations significantly reduce engineering throughput.

Industry research shows that more than **57% of developer time** is spent firefighting performance, reliability, and security issues instead of building new features. 

In regulated environments, this number is often higher due to added review cycles and manual controls layered on top of delivery workflows.

The problem compounds further upstream. **61% of professional developers** report spending over 30 minutes per day simply searching for answers: debugging environment inconsistencies, chasing access approvals, or working around infrastructure limitations. 

These are not hard engineering problems; they are symptoms of systems that rely on manual coordination rather than automation.

Nowhere is this more visible than in environment management. 

Manual patching and configuration changes slowly turn environments into "snowflakes": systems that work today but cannot be reliably reproduced tomorrow. Over time, production diverges from staging, staging diverges from development, and the organization loses confidence in its own release process.

During an audit, this drift becomes a liability. If an environment cannot be recreated from a known-good definition, teams are forced to explain why it looks the way it does: a conversation auditors rarely enjoy.

### **The operating model shift**

For regulated SaaS teams, eliminating DevOps toil requires an operating model change from manual enforcement to governance by design.

This shift replaces human bottlenecks with system-level guarantees.

### **Technical breakdown: "policy as code" in practice**

The phrase _policy as code_ is often overused. In practice, its value depends entirely on where enforcement happens.

#### **Git as the control plane**

Upsun uses Git as the control plane for infrastructure and application configuration. 

This means every change to runtime versions, service definitions, network exposure, and access rules is captured as a commit with a hash, an author, and a peer review.

For technical evaluators, this matters because it creates a single source of truth. There is no parallel universe of changes made through a cloud console at 2 a.m.. Every modification is traceable, reviewable, and reproducible.

#### **Machine-readable governance without gridlock**

Upsun’s configuration file allows platform and security teams to define guardrails once and enforce them everywhere: without blocking developers with ticket queues.

For example, a security team can prevent databases from being exposed to the public internet simply by not defining a public route for them. Developers cannot accidentally bypass this rule because the platform will not deploy configurations that violate it.

This approach enables guardrails without gridlock: developers retain autonomy within safe boundaries, while platform teams eliminate entire classes of risk by design.

#### **Audit-ready history by default**

In traditional cloud environments, answering a basic question like "Who changed this security rule?" often requires digging through fragmented logs: assuming they exist at all.

With Git-driven configuration, the answer is immediate. The commit history shows what changed, when it changed, and who approved it. Compliance becomes an emergent property of the delivery workflow, not a separate process bolted on afterward.

### **Operationalizing compliance inheritance**

Upsun’s compliance certifications, including **SOC 2 Type II, PCI DSS Level 1, ISO 27001, and HIPAA**, are not just badges. Their real value lies in the workload they remove from DevOps teams.

#### **The shared responsibility model, clearly defined**

Upsun assumes responsibility for the underlying infrastructure layers:

-   Operating system patching
-   Network isolation and segmentation
-   Container hardening and runtime security
-   Physical data center security
-   Platform availability and resilience

Customers retain responsibility for the application layer:

-   Application logic
-   Data classification
-   Identity and access decisions at the application layer

This clarity prevents duplicated effort and reduces the need for bespoke internal controls that slow delivery.

#### **Automated, machine-verifiable evidence**

Upsun’s built-in access logs, deployment histories, and carbon reporting are not just observability features: they are audit artifacts generated automatically.

For ESG, security, and compliance audits, this means teams can provide verifiable, machine-generated data instead of manually assembled screenshots and spreadsheets. Evidence collection becomes a query, not a project.

#### **Uptime as a compliance requirement**

For regulated SaaS providers, uptime is not merely a performance metric: it is often a contractual and regulatory obligation.

Upsun’s **99.99% uptime** **SLA** provides contractual guarantees that reduce the risk of breaching customer SLAs or regulatory commitments. This shifts availability from an aspirational goal to an enforceable standard, backed by the platform.

### **Expanding the before vs. after: an audit cycle in practice**

#### **The old way: the "war room"**

Two weeks before an audit, DevOps enters triage mode. 

Engineers gather screenshots from cloud consoles, export access logs, reconstruct timelines, and answer questions about systems they did not personally configure. Work stalls, feature development slows, and stress rises.

#### **The Upsun way: system-level proof**

With Upsun, the audit conversation changes entirely. The DevOps lead provides:

1.  A link to the **Trust Center**.
2.  A **Git repository** showing configuration and change history.
3.  **Upsun hosted application** access and deployment logs.

The role of DevOps shifts from evidence gatherer to system architect: explaining how compliance is enforced by design, not by heroics.

### **The outcome: audit-ready by default**

By moving governance from static PDFs into the active delivery pipeline, organizations turn audit fire drills into routine verification.

The real win is reclaimed capacity. 

By reducing the operational toil tied to environment management and compliance paperwork, DevOps teams can stop firefighting and focus on building the features that move the business forward.

Upsun serves as a force multiplier for security and compliance teams by providing intelligent automation that aligns with company policies.

**Ready to eliminate compliance toil?**

-   **Start your free 15-day trial**
-   **Explore compliance and governance solutions**

### [Auto-scaling infrastructure for e-commerce | Upsun](https://upsun.com/blog/auto-scaling-infrastructure-for-e-commerce-flash-sales/)

# Peak traffic without the panic: auto-scaling infrastructure for ecommerce flash sales

_Key takeaway: Upsun replaces manual, high-stress peak traffic prep with automatic scaling, keeping your ecommerce site fast and available during flash sales while you only pay for the resources you consume._

For every ecommerce team, an outage means lost revenue, failed checkouts, and a flood of support tickets. For most stores, this gets worse during peak events like Black Friday and flash sales. Despite this, most teams still prepare for peak traffic the same way they did years ago: manually, cautiously, and with a lot of stress.  

The cost of failure is immediate. A slow page or timeout doesn’t just frustrate users but directly cuts revenue. Even small delays can reduce conversions significantly, and outages during peak events can cost millions.

Despite this, most teams still prepare for peak traffic the same way they did years ago: manually, cautiously, and with a lot of stress.

## The problem: peak traffic is treated like an emergency

_Key takeaway: manual scaling processes create an expensive paradox where teams cannot ship improvements during their most profitable periods._

Most ecommerce teams treat peak traffic as a planning exercise. The standard approach looks like this:

-   **Weeks of load testing** to simulate expected traffic volumes.
-   **Manual infrastructure scaling,** provisioning additional servers, adjusting database connection pools, and increasing cache capacity.
-   **Code freezes** two to three weeks before the event to reduce deployment risk.
-   **War room staffing** with on-call engineers camped out over the peak weekend.

This works. But it's expensive, stressful, and fragile. It ties up engineering capacity for weeks. It assumes you can predict exactly how much traffic will arrive and from where. And it creates a paradox: the events that generate the most revenue are also the ones where your team is least able to ship improvements.

The deeper issue is this approach treats scaling as an engineering emergency rather than a platform capability. If your infrastructure requires manual intervention to handle a traffic spike, the infrastructure is the bottleneck.

## What auto-scaling actually means 

_Key takeaway: True auto-scaling must address the entire stack, including workers and background jobs, not just the web server._

"Auto-scaling" gets used loosely in ecommerce. Adding a CDN isn't auto-scaling. Caching your homepage isn't auto-scaling. These help, but they don't address what happens when your application servers, workers, and database connections hit capacity.

Platform-level auto-scaling means the infrastructure itself responds to demand. On Upsun, autoscaling works through vertical or horizontal scaling: automatically adding or removing application and worker instances or resources based on real-time CPU and memory usage. Peak traffic becomes a predictable outcome of configuration, not an engineering emergency.

Here's what that looks like in practice:

**1\. You define thresholds**

Instead of guessing how many servers you'll need for Black Friday, you set scale-up and scale-down thresholds. If CPU usage stays above your threshold for a defined period, Upsun adds instances or resources. When the load drops, it removes them. You control the boundaries. The platform handles the response.

**2\. Scaling covers apps and workers**

Traffic spikes don't just hit your web server. They pressure queue workers processing orders, background jobs handling inventory updates, and cache layers serving product data. Upsun's autoscaling applies to both applications and workers, so the full stack responds not just to the layer behind your load balancer.

**3\. Vertical scaling handles the rest.**

For services like MySQL, Redis, and Elasticsearch that don't scale horizontally the same way, Upsun provides per-environment vertical scaling, adjusting CPU, RAM, and disk allocation per container. You can allocate more resources to production than to staging, and adjust ahead of a known event without rebuilding your infrastructure.

**4\. You only pay for what you use.**

Manual pre-scaling means paying for peak capacity around the clock, even when traffic is normal. With usage-based autoscaling, instances spin up when needed and scale back down when they're not. Your infrastructure cost tracks your actual demand, not your worst-case forecast.

## What this means for small teams

For ecommerce companies with small DevOps teams or without a dedicated DevOps team at all, this changes the staffing equation.

Manual peak prep demands deep infrastructure expertise and significant time. Autoscaling with defined guardrails means a smaller team can handle peak events without pulling engineers off feature work. The platform provides visibility into when scaling happens, what triggered it, and what it costs through metrics dashboards and configurable alerts.

Instead of requiring your team to predict traffic and manually provision resources, the platform observes actual demand and responds. Your team sets boundaries. The infrastructure does the rest.

## The bottom line

The ecommerce sites that go down during peak traffic are not failing because their teams didn't work hard enough. They're failing because their infrastructure forces humans to do what software should handle automatically.

Flash sales and seasonal spikes aren't surprises. They're known events with predictable characteristics. The infrastructure should handle them without a two-week engineering mobilization.

That's the difference between a platform that treats scaling as an emergency and one that treats it as a configuration setting. 

_Upsun provides horizontal autoscaling for applications and workers, vertical scaling for all services, and per-environment resource configuration, all with a predictable and transparent pricing._ _Start a free trial_ _or_ _learn more by exploring how autoscaling works__._

## Frequently asked questions (FAQ)

**Does Upsun support multi-cloud auto-scaling?**

Upsun provides the choice of cloud provider (AWS, Azure, IBM Cloud, OVHcloud or GCP) at the start of a project to ensure standardization and portability. However, a single application does not scale across multiple cloud providers simultaneously.

**How does Upsun handle database scaling during a spike?**

While application instances scale horizontally, databases scale vertically. You can use Upsun to adjust CPU and RAM for your database containers to handle increased connection loads without manual migration or downtime.

**Will auto-scaling lead to unpredictable monthly bills?**

No. You set the maximum boundaries for how far the application can scale. This gives you the flexibility to handle spikes while maintaining strict control over your maximum possible spend.

### [Stop the 30% DevOps tax and reclaim your budget | Upsun](https://upsun.com/blog/reclaiming-the-30percent-devops-tax/)

# The innovation budget audit: reclaiming the 30% "DevOps tax"

### The 2026 engineering paradox

We are currently living through the greatest expansion of coding velocity in history. Recent data confirms that while AI-related packages are being updated 2x more frequently than their non-AI counterparts, the expected "software surplus" has not yet arrived.

For most VPs of engineering, this creates a frustrating contradiction: your developers are using agentic IDEs to iterate at 200 mph, but your time-to-market hasn't moved**.** Why? Because the "last mile" of deployment is still trapped in a 2015 paradigm. Your infrastructure remains a series of manual toll booths.  

This friction is the DevOps tax: the silent drain on your innovation budget that occurs when high-priced senior engineers spend their afternoons debugging VPC peering and RDS maintenance windows instead of building product.

### I. The anatomy of the 30% cloud waste

_Key takeaway: The devops tax is a hidden drain on innovation budgets, consuming up to 30% of engineering cycles. By routing AI-driven requests through a unified configuration file, organizations can enable agentic autonomy via the MCP while eliminating the shadow provisioning that drives infrastructure sprawl._

According to the BCG, the average enterprise is losing nearly a third of its cloud budget to "cloud waste." This isn't just a technical oversight; it is a direct result of how high-velocity AI development interacts with legacy cloud primitives.

BCG identifies the primary drivers of this 30% waste that Upsun addresses by design:

-   **Decentralized procurement:** AI agents and "vibe coders" request new services independently, leading to uncontrolled "shadow" provisioning.
-   **Overprovisioning:** Teams size for peak demand rather than actual usage, leading to oversized, idle instances.
-   **Data storage inefficiencies:** Redundant copies created during manual staging and testing cycles lead to bloated storage costs.

#### **Governed autonomy: enabling AI without the shadow IT**

The risk of decentralized procurement isn't just human; in 2026, AI agents and "vibe coders" often request services independently, leading to uncontrolled shadow provisioning. Upsun solves this by acting as the governance layer for agentic workflows.

-   **Provisioning via MCP:** By using the model context protocol (MCP), AI agents can suggest and provision new services directly. However, because these requests must pass through your unified application spec, they are never "shadow" services.
-   **The guardrails:** Every AI-driven change is defined in your unified configuration file. This ensures that even if an agent provisions a new redis or postgresql instance, it is automatically optimized for your specific resource limits and inherited security controls.

By routing AI autonomy through a version-controlled spec, you gain the velocity of agentic development without the fragmentation of uncontrolled cloud spend.

### **II. Moving from "infrastructure-as-a-hobby" to strategic assets**

_Key takeaway: Custom-built internal developer platforms often become undifferentiated heavy lifting; top-performing teams prioritize "innovation liquidity" by outsourcing cloud plumbing to a standardized platform._

Many VPs of engineering believe that building custom internal platforms on top of cloud primitives is a competitive advantage. In reality, for most companies, this is undifferentiated heavy lifting**.** 

When engineers are forced to manually "wire" every new service an AI agent suggests, they are no longer developers, but rather high-paid janitors for the cloud.

In 2026, the competitive advantage is innovation liquidity: the ability to move capital from maintenance to market-leading features instantly. 

By shifting to a unified configuration file (via `.upsun/config.yaml`), you eliminate the manual "wiring" that leads to the waste BCG identified. You aren't just buying a hosting platform; you are buying back the brainpower of your engineering team.

### **III. The economic shift: From OpEx to Alpha**

_Key takeaway: Modern infrastructure must be viewed as a force multiplier rather than a depreciating asset; a standardized platform drops the "cost per feature" as an organization scales its AI development._

To shift the needle on ROI, engineering leadership must reframe infrastructure from a recurring cost center into a driver of innovation liquidity.

-   **Legacy infrastructure as a "depreciating asset":** In a manual environment, every new AI-generated feature adds a layer of "maintenance debt." As the codebase grows, the cost to support it increases, effectively trapping capital in the "how" of the cloud rather than the "what" of the product.
-   **Upsun as a "force multiplier":** By using a unified configuration file, infrastructure costs scale with application intent, not manual labor. This creates a standardized foundation that allows AI agents to deploy safely, meaning the marginal cost per feature actually drops as the organization scales.

By reclaiming the 30% waste, the organization transitions from merely maintaining "plumbing" to generating Alpha: the ability to out-innovate the competition by moving capital into market-leading features at zero-to-low marginal operational cost.

### **IV. The 90-day innovation roadmap: From toil to liquidity**

_Key Takeaway: Reclaiming an innovation budget requires a phased migration: auditing current sprint toil, piloting a platform contract for AI projects, and standardizing the spec across the organization._

Reclaiming your budget isn't a "flip-the-switch" event. To successfully transition from imperative primitives to a declarative platform contract, we recommend a phased approach:

-   **Day 1–30: The toil discovery phase.** Audit your last three sprints. Identify every Jira ticket related to environment setup, database syncing, or cloud permissioning. If these tasks account for more than 15% of your capacity, you are officially paying the DevOps tax.
-   **Day 31–60: The "proving ground" pilot.** Select one high-velocity AI project. Move its infrastructure to an Upsun platform contract. Measure the difference in "lead time to deployment" between this pod and your legacy teams.
-   **Day 61–90: Standardizing the spec.** Use your pilot results to justify decommissioning fragmented "shadow infrastructure" and consolidating your innovation budget into a single, governed platform.

### **Reclaim your budget today**

The DevOps tax is not an inevitability; it is a strategic choice. If your engineers are currently spending more time on the "how" of the cloud than the "what" of your product, your innovation budget is being audited by its own inefficiency.

In the agentic era, the teams that win are not the ones who write the most code—they are the ones with the Innovation Liquidity to deploy that code instantly. 

By shifting to a Deterministic Platform Contract, you eliminate the manual "wiring" and shadow infrastructure that leads to the 30% waste identified by BCG.

Stop paying the tax. Start shipping the surplus.

-   **Consult with our experts:** Book a technical walkthrough. 
-   **Calculate your requirements:** See how a right-sized Upsun deployment compares to your current costs.

### **Frequently asked questions (FAQ)**

**How much can we actually save?** 

By targeting the 30% of addressable cloud waste identified by BCG, teams often see immediate returns through automated rightsizing and the elimination of redundant staging environments.

**Does this mean I need fewer DevOps engineers?** 

No. It means your DevOps engineers can move from "manual plumbing" to platform architecture. Instead of fixing broken subnets, they focus on higher-level goals like security governance, cost-optimization, and AI strategy.

**How does this impact our cloud bill?** 

By eliminating "shadow infrastructure" (orphan RDS instances and unoptimized S3 buckets) through a centralized config, organizations typically see a significant reduction in direct cloud provider spend.

### [The hidden cost of scaling ecommerce | Upsun](https://upsun.com/blog/the-hidden-cost-of-scaling-ecommerce-on-hyperscalers/)

# The hidden cost of scaling ecommerce on hyperscalers

_Key takeaway: Hyperscaler pricing models often penalize e-commerce growth due to unpredictable egress fees and unbounded auto-scaling, but moving to a resource-based allocation model allows teams to treat infrastructure costs as a deliberate business decision rather than a post-campaign surprise._

Ecommerce traffic doesn't grow linearly. It spikes, and every spike rewrites your cloud bill. A flash sale, seasonal surge, or Black Friday can drive traffic up within hours, revenue follows, and so does your cloud bill. For most ecommerce teams, the real problem isn’t performance. Hyperscalers like AWS, Azure, and Google Cloud handle scaling reliably. The problem is cost behavior.

The issue isn’t that hyperscalers are inherently expensive. It’s that their pricing model doesn’t map cleanly to how ecommerce actually behaves: variable, bursty, and campaign-driven. The result is a cloud bill that’s hard to predict, harder to explain, and often larger than expected.

## Why ecommerce workloads break predictable pricing

_Key takeaway: Ecommerce teams often over-pay for idle capacity because raw hyperscaler pricing is not designed for bursty, event-driven traffic._

Most cloud pricing rewards stable usage. Ecommerce doesn’t work like that. You’re not optimizing for average traffic, you’re optimizing for peak events. This changes how costs behave.

Teams typically fall into one of two patterns:

-   **Over-provisioning**: paying for idle capacity to survive peak traffic.
-   **Reactive autoscaling**: paying for sudden, unplanned scale during spikes.

Both work technically, but financially, it's risky.

## Where hyperscaler costs spiral

_Key takeaway: Success becomes a liability when compute, egress, and database costs scale without natural business-logic limits._

Let’s make this concrete. These are the four most common places e-commerce teams lose cost control.

### 1\. Autoscaling compute: success becomes expensive

When traffic surges, autoscaling spins up additional compute instances. But on a hyperscaler, each instance bills per second of usage across CPU, memory, and networking.

During a campaign:

-   Traffic spikes instantly.
-   New instances spin up to absorb the load.
-   You pay for every second of that additional capacity.

The problem is unbounded scaling.

There’s no natural limit tied to business expectations.  A four-hour flash sale that drives 5x traffic can generate a compute bill that's disproportionate to the revenue it produced. 

**2\. Data egress fees add up quietly**

Every product image, video, and asset served globally comes with a cost: data transfer out.

This is where many teams get caught off guard.

-   A homepage redesign increases image size.
-   A campaign drives international traffic.
-   A CDN cache miss rate increases.

Individually, these seem minor. Combined, they create significant egress charges, especially across regions.

Unlike compute, egress costs are:

-   Hard to predict.
-   Poorly surfaced in dashboards.
-   Disconnected from feature changes.

### 3\. Database scaling: the hidden bottleneck tax

Ecommerce platforms are database-heavy: product catalogs, inventory, orders, customer sessions, etc. Under campaign load, your database is the line item that grows fastest.

To handle this, teams:

-   Upgrade instance sizes.
-   Add read replicas.
-   Increase IOPS and storage throughput.

Each of these is billed separately. And unlike stateless compute, databases are harder to scale down quickly. So you often keep paying for peak capacity long after the campaign ends.

**4\. Multi-service architectures multiply the problem**

A modern ecommerce stack runs an application layer, a database, a cache, a search index, queue workers, and often a separate CDN. On a hyperscaler, each of these services has its own pricing tiers, scaling rules, and transfer fees. Managing costs across them requires dedicated tooling, FinOps expertise, or both. For most ecommerce teams, neither is available.

This creates two problems:

**1\. Cost fragmentation**  
You don’t have a single view of “what this environment costs.”

**2\. Operational overhead**  
Engineering time spent managing infrastructure instead of improving the product.

In practice, this means you’re not just paying for infrastructure, but you’re also paying for the complexity of managing it.

## What predictable infrastructure pricing looks like

_Key takeaway: Shifting to resource-based provisioning allows costs to be attributable to specific environments rather than a fragmented list of services._

The solution is a pricing model that matches how ecommerce traffic spikes actually work. On Upsun, infrastructure costs are tied to resource allocation: CPU, memory, and disk you assign to each environment. You can see what you're using, what it costs, and adjust it per environment without navigating a dozen separate service dashboards.

Upsun runs on the same hyperscaler infrastructure: AWS, Google Cloud, IBM Cloud, OVHcloud, and Azure, but bills you for the resources you provision, not the dozens of underlying services that make them work.

This changes the cost equation in concrete ways:

-   **Egress becomes observable:** Upsun operates as a platform layer above the hyperscalers, abstracting away the regional tiers and cross-zone transfer charges that make hyperscaler data transfer unpredictable and surfacing it as a single metered line item in your console.
-   **Scaling has defined limits:** Upsun's autoscaling lets you configure CPU or memory triggers, scale thresholds, and minimum and maximum instance counts per environment. The cost ceiling isn't a guess; it's a number you chose.
-   **Costs are tied to environments, not services:** Instead of managing separate pricing for compute, database, cache, search, and CDN, each with its own scaling rules, Upsun provides a unified management layer. _A_ single dashboard, a single invoice for everything Upsun runs, and one place to see what's driving costs.  
      
     

## The real question is predictability

_Key takeaway: Modern infrastructure should turn cost into a pre-launch decision rather than a post-event autopsy._

The real question is not "how much does cloud cost?" It is "can you predict what you will spend before the campaign goes live?"

For most ecommerce teams on raw hyperscalers, the honest answer is no. The pricing is too complex, the billing is too delayed, and the gap between the people driving traffic and the people managing infrastructure is too wide.

A platform that makes cost visible, predictable, and attributable before the traffic arrives doesn't just reduce spend. It turns cost into a decision rather than a surprise.

_Upsun provides transparent, resource-based pricing with per-environment configuration and real-time cost visibility._ _Start a free trial_ _or_ _explore Upsun's pricing model__._

## Frequently asked questions (FAQ)

**How does Upsun simplify hyperscaler billing?** 

Upsun provides a unified management layer. Instead of receiving a fragmented bill for dozens of separate services across different regions, you receive one invoice based on the CPU, RAM, and disk allocated to your environments.

**Can I limit my maximum spend during a flash sale?** 

Yes. Through the Upsun console, you can set the maximum number of instances for horizontal scaling. This ensures your infrastructure grows to meet demand without exceeding your budget.

**Does Upsun charge extra for deploying on different clouds?** 

Upsun provides the flexibility to choose your cloud provider at project creation. Because you are billed based on resource allocation rather than specific provider services, your costs remain predictable regardless of whether you choose AWS, IBM Cloud, OVHcloud, Azure, or GCP.

### [Machine learning inference with PHP explained | Upsun](https://upsun.com/blog/ml-inference-in-php-by-example/)

# ML inference in PHP by example: leverage ONNX and Transformers on Symfony

_This blog is based on a presentation by Guillaume_ _Moigneu_ _at the Symfony 2024 conference._ 

Machine learning and AI are no longer limited to Python and Node.js. PHP developers can now run AI models directly in their applications using modern tools and libraries. This guide shows you how to implement machine learning inference in PHP using ONNX and Transformers.

## What are transformers?

Transformers are a type of neural network architecture that revolutionized AI around 2016-2017. Before transformers, running machine learning models was slow and could not process data in parallel effectively.

### Key Benefits of transformers:

-   **Faster processing** - Can handle multiple tasks simultaneously, unlike older sequential models
-   **Better context understanding** - Analyzes relationships between words through "self-attention" mechanisms
-   **Parallel processing** - Can work on various data points at once, making large-scale processing feasible
-   **More efficient resource usage** - Optimized for language processing and NLP tasks
-   **Enabled modern AI** - Made models like GPT and BERT possible by solving fundamental performance issues

### How transformers work

When you send text to a transformer model, it goes through several steps to understand and process your input. First, the model performs tokenization, splitting your text into smaller pieces called tokens. These tokens are usually words, but can sometimes be smaller parts of words depending on the model.

Next comes the crucial self-attention mechanism, where the model analyzes relationships between all the tokens. This is what makes transformers special - they can understand how different words relate to each other in context. One word can mean completely different things in different situations, so the model needs to figure out the relationships between words to understand what you're actually trying to say.

The model then performs context mapping, using neural networks to process these relationships repeatedly. It feeds the parameters through multiple iterations, trying to understand the full meaning of your input. Finally, it generates an output based on all this contextual understanding, whether that's completing a sentence, classifying text, or answering a question.

For example, if you write "Symfony is a great framework for \_\_\_", the model analyzes the relationships between "Symfony," "framework," and "great" to predict what comes next.

## Getting started with PHP machine learning

To run machine learning models in PHP, you need:

-   **Transformers PHP Library**
-   **FFI Extension** 
-   **ONNX Models** 

### **Installation**

```shell-session
composer require codeboost/transformers-php
```

**Important Note**: The library downloads architecture-specific packages. Make sure you have the right version for your system (ARM64 for M1 Macs, AMD64 for Intel machines).

## Practical use cases

### **1\. Text Classification**

Text classification helps you automatically categorize text content. Perfect for:

-   Analyzing user comments (positive/negative)
-   Spam detection
-   Content moderation
-   Review analysis

#### **Example: Amazon Review Analysis**

Guillaume demonstrated this concept by running a Symfony command that analyzed Nintendo Switch reviews. Here's an illustrative example based on the approach he described:

```shell-session
use Codeboost\TransformersPHP\Pipeline;

// Create a text classification pipeline
$pipeline = Pipeline::create('text-classification');

// Analyze reviews from your database
$reviews = $database->getReviews();
$results = [];

foreach ($reviews as $review) {
    $score = $pipeline($review->text);
    $results[] = [
        'review_id' => $review->id,
        'sentiment' => $score['label'], // 'POSITIVE' or 'NEGATIVE'
        'confidence' => $score['score']
    ];
}
```

**Real Results**: In a test with 108 Nintendo Switch reviews:

-   79 positive reviews (73%)
-   29 negative reviews (27%)
-   Processing time: ~14 reviews per second on standard CPU

### **2\. Image classification**

Automatically categorize and tag uploaded images. Use cases include:

-   Adding alt text to images
-   Content filtering
-   Automatic tagging
-   Object detection

#### **Example: Hot Dog Detection**

The speaker demonstrated this with a live hot dog detection app. Here's an illustrative example based on his description:

```shell-session
use Codeboost\TransformersPHP\Pipeline;

// Create image classification pipeline
$pipeline = Pipeline::create('image-classification');

// Load image using GD or ImageMagick
$image = imagecreatefromjpeg('uploaded_image.jpg');

// Classify the image
$result = $pipeline($image);

// Results: ['label' => 'hot dog', 'score' => 0.95]
```

**Performance**: Nearly instant results on small servers (under 1 second for typical web images).

### **3\. Text generation**

Generate text automatically for:

-   Alt text for images
-   Product descriptions
-   Content suggestions
-   Metadata generation

#### **Example: Text Completion**

Guillaume demonstrated this by asking, "Can a taco be considered a sandwich?" Here's an illustrative example based on the approach he showed:

```shell-session
use Codeboost\TransformersPHP\Pipeline;

// Create text generation pipeline
$pipeline = Pipeline::create('text-generation', [
    'model' => 'flan-t5-small',
    'temperature' => 0.7 // Controls creativity (0-1)
]);

$prompt = "Can a taco be considered a sandwich?";
$response = $pipeline($prompt);

// Result: "Yes, a taco is a sandwich made of bread"
```

**System Requirements**: Runs on 2 CPU cores with 2GB RAM. Response time: 1-2 seconds.

## How it works behind the scenes

### **1\. FFI Extension**

The Foreign Function Interface (FFI) extension for PHP is not really a new extension, but it hasn't been used a lot until recently. FFI allows you to actually call C libraries directly and execute code directly without any translation. This is great because instead of using CGI and those kinds of old methods, you can actually run those libraries independently and way faster.

FFI has helped a lot with performance, and you could use it for many different things, like calling binaries and similar tasks. Guillaume mentioned that transformers are architecture-dependent, which is basically because they use FFI to actually run C code behind the scenes.

### **2\. ONNX (Open Neural Network Exchange)**

ONNX solves a major problem in machine learning. When you create and train a model, you typically use a specific framework like Google's TensorFlow or PyTorch. However, this creates a significant limitation: if a model was created with TensorFlow, you can't use it in a PyTorch production environment, and vice versa. You're locked into using the same framework for both training and inference.

ONNX provides a solution by creating a standard format that works across all frameworks. This open standard was developed through collaboration between major industry leaders, including Samsung, Apple, and others. With ONNX, you can train a model in any framework, convert it to the ONNX format, and then run it anywhere, regardless of the original training environment. 

### **3\. Model Sources**

#### **Hugging Face hub**

If you want to try a lot of different things,  go to Hugging Face. They have nearly a million models available right now, and you can test most of the models online as well. You will find all those different categories like video classification, question answering, table question, token classification, and whatever else you might need. 

You will also find something that matches your use case. Maybe you're going to need to try and test, but find something that meets your needs that you can use with the library afterwards. They also have a category where you can find all the ONNX models, so you're sure they're actually compatible with what you want to do.

#### **SmallML initiative**

Something kind of new that emerged like six months ago is a new model category done by Hugging Face, also called SmallML. The goal is to produce models that are able to nearly output large texts like ChatGPT or Claude would do, but bundled in like 500 megabytes or less. This is great because 500 megabytes you can still load on most machines around, even if you've got a GPU on your own machine. You can actually run it through Ollama or whatever you want, or that PHP Transformer library as well.

## Production deployment options

-   **For small models (Text/image classification)**

For text and image classification tasks, you can run these models directly on your PHP servers without any issues. The speaker demonstrated this running on a really small machine with two CPUs and two gigabytes of RAM, and it worked quite well. The models themselves are not really large; for example, the text classification model he used was like two megabytes, so it's fast to run and you can deploy it anywhere. It's super easy to implement in your real production applications today.

-   **For large language models**

Here you have three options:

1.  **External APIs**
    -   OpenAI, Claude, etc.
    -   Easy to implement
    -   No control over uptime or responses
2.  **Hosted Model Endpoints**
    -   Deploy your own model on GPU infrastructure
    -   Hugging Face Inference Endpoints
    -   More expensive, but you control the model
3.  **Self-Hosted**
    -   Complete control
    -   Requires GPU infrastructure
    -   You handle all operations and maintenance

## Best practices and testing

### **Model selection**

-   Start with popular models on Hugging Face
-   Test multiple models for your specific use case
-   Popular models typically have better accuracy
-   Look for active development and regular updates

### **Testing your models**

1.  Create test datasets - Manually label 200+ examples
2.  Run comparisons - Test model output against known results
3.  Monitor inconsistencies - Same input should give consistent output
4.  Check edge cases - Test with punctuation changes, typos

### **Important warning**

Always monitor AI-generated content in production. Models can produce unexpected or harmful outputs. Consider:

-   Content filtering
-   Human review for sensitive applications
-   Fallback mechanisms
-   Regular monitoring and alerts

## Conclusion

PHP developers can now leverage machine learning directly in their applications without external dependencies. While there are limitations (no GPU support yet), the current capabilities are sufficient for many real-world use cases.

The combination of FFI, ONNX, and the Transformers PHP library makes it possible to:

-   Analyze user-generated content in real-time
-   Automatically classify and tag images
-   Generate helpful text content
-   Build smarter web applications

Start small, test thoroughly, and gradually expand your use of AI in PHP applications. The future of PHP and machine learning is just getting started.

### [AWS RDS vs. Upsun: Stop the hidden cloud tax | Upsun](https://upsun.com/blog/aws-rds-vs-upsun/)

# AWS RDS vs. Upsun: the egress cost audit

### **The cloud bill’s "invisible" line item**

If you are managing a Postgres instance on AWS RDS, you likely know your instance's hourly rate by heart. But a silent productivity and margin-killer is hiding in your monthly statement: operational overhead and data complexity**.**

In a standard RDS deployment, you are not just paying for the storage and the compute. You are paying for the "undifferentiated heavy lifting" of manual networking. 

In 2026, as AI-driven applications demand massive data throughput for RAG and vector searches, the cost of managing these "managed primitives" is stalling engineering velocity.

### **I. The anatomy of the RDS connectivity trap**

_Key takeaway: Traditional cloud primitives (RDS) are isolated blocks that mandate manual "wiring", VPC peering, IAM policies, and security groups, creating an "orchestration tax" that wastes up to 30% of cloud spending on undifferentiated heavy lifting._

Traditional cloud primitives are designed as isolated blocks that require manual orchestration. When you run RDS, you are "taxed" in time and complexity every time you need to connect your application to your data:

-   **Manual networking:** Navigating VPC peering, security groups, and connection strings.
-   **IAM complexity:** Managing over-privileged policies just to ensure "it just works."
-   **Provisioning guesstimation:** Paying for "Provisioned IOPS" and static instance sizes you may not fully utilize.

According to BCG (2025), up to 30% of cloud spending is wasted due to this type of decentralized procurement and overprovisioning. RDS is a primary driver because its model incentivizes fragmented architectures that require constant manual intervention.

### **II. Integrated managed services: The platform contract advantage**

_Key Takeaway: Upsun replaces manual networking with a unified configuration file (_`_.upsun/config.yaml_`_). By defining service relationships rather than connection strings, you eliminate credential sprawl and ensure your infrastructure is as version-controlled as your code._

Upsun takes a fundamentally different approach. We don't view the database as a standalone primitive; it is a core component of your standardized environment.

By using integrated managed services, Upsun provisions services as managed containers defined in `.upsun/config.yaml`

-   **Relationships replace wiring.** Declare a service relationship in `.upsun/config.yaml`; Upsun provisions it inside your project's isolated network and injects credentials at runtime. No VPC rules, security groups, or connection strings to manage.
-   **Surgical scaling:** Unlike RDS's rigid instance tiers, Upsun provides resource-based, per-second billing with predictable resource allocation. You scale the exact vCPU and RAM your application needs.
-   **Version-controlled infrastructure:** Your entire data stack: databases, search engines, and their relationships are defined in a single, version-controlled file: `.upsun/config.yaml`.

### **III. The audit: managed primitives vs. integrated services**

_Key takeaway: When auditing RDS alternatives, the true savings are found in innovation liquidity. Upsun collapses the distance between application and data by replacing rigid instance tiers and manual staging refreshes with surgical resource scaling and automated connectivity._

When you audit an AWS RDS alternative, the "sticker price" is only the beginning. The real savings are found in the reclamation of engineering hours.

  
 

### **IV. Why architects are moving to Git-driven data**

_Key takeaway: Moving to Git-driven data eliminates the "Repro Gap" via byte-level clones, allowing teams to test AI logic against real-world production replicas in seconds without the egress costs or security risks of manual RDS data refreshes._

Lead DevOps engineers and architects are moving away from RDS to reclaim innovation liquidity.

1.  **Production-perfect previews:** Upsun allows you to branch an environment and create a byte-level clone of everything (databases, files, and configuration) in seconds. You can test AI logic against real data without the egress or time costs of a manual RDS refresh.
2.  **Eliminating credentials management:** Because services are integrated, there are no connection strings to copy and paste. This removes a massive security vector and a common source of deployment failure.
3.  **FinOps by default:** With per-second billing and no hidden inter-service fees, your infrastructure costs finally align with your actual application usage.

### **Stop paying the complexity tax**

If your infrastructure management is growing faster than your product features, it’s time to audit your data plane. AWS RDS was built for a world of manual orchestration; Upsun was built for the automated reality of 2026.

**Audit your current RDS spend:**

-   **Audit your spend:** Use the frameworks in our Innovation budget audit: Reclaiming the 30% "DevOps tax" to identify your specific efficiency gaps.
-   **Check your utilization:** Are you paying for provisioned performance that sits idle 70% of the time?
-   **Switch to Integrated Services:** Discover how a standardized environment protects your margins and your velocity.

### **Frequently asked questions (FAQ)**

**Is AWS RDS actually a "primitive"?** 

Yes. While RDS manages the database engine, you still have to manually wire the infrastructure: VPC peering, Security Groups, and IAM roles. On Upsun, the database is an **integrated managed service**; the platform automates the network and credential mapping via your `.upsun/config.yaml`.

**What is the "Connectivity Tax" on my AWS bill?** 

It’s the combined cost of:

-   **Data transfer fees:** Charges for moving data between AZs or regions.
-   **Management yoil:** Engineering hours spent on manual networking and IAM policy maintenance.
-   **Overprovisioning:** Paying for rigid instance tiers to handle peaks that only occur 10% of the time.

**How does Upsun eliminate connection strings?** 

Through declarative relationships. When you define a service in your config file, Upsun creates a secure internal route and injects credentials as environment variables. This removes secrets from your code and eliminates "credential sprawl."

**Can I run pgvector for RAG on Upsun?** 

Absolutely. Upsun supports managed PostgreSQL with pgvector. Because you can scale RAM and CPU independently, you can provision the high memory required for HNSW indexes without paying for an oversized RDS instance.

**How do "Byte-level Clones" solve the Repro Gap?** 

Manual RDS refreshes take hours. Upsun uses copy-on-write technology to create instant, 1:1 replicas of your production data for every Git branch. This ensures your AI agents and developers test against reality, not stale junk data.

### [Ecommerce migrations without code freezes | Upsun](https://upsun.com/blog/how-preview-environments-reduce-migration-risk/)

# Ecommerce replatforming without a revenue freeze: how preview environments reduce migration risk

_Key takeaway: Upsun eliminates the need for code freezes during ecommerce migrations by using instant, data-complete preview environments to validate replatforming efforts against production-grade data without interrupting the live store._

Ecommerce replatforming is one of the highest-stakes decisions an online retailer makes, and for most, the biggest risk is what happens to revenue during the migration.

The standard playbook: freeze feature development, lock the codebase, build the new environment in a sandbox, and flip the switch on launch day. For weeks or months, your team ships nothing new while competitors keep iterating. And when the cutover finally happens, you're betting everything on a single deployment going right the first time.

Industry data consistently shows that the majority of ecommerce data migration projects exceed their budgets, timelines, or both. Poorly planned migrations routinely lead to significant losses in organic traffic and revenue that can persist for months. The damage compounds: lost SEO equity, broken payment and ERP integrations, and customers who tried to buy during the cutover window and went somewhere else.

The problem is that the traditional approach forces a trade-off that shouldn't exist: migrate or grow, but not both.

## Why code freeze costs more than the migration

_Key takeaway: Stopping feature development for a migration creates a secondary "innovation debt" that can be more expensive than the replatforming itself._

During a typical migration, the development team stops shipping features to the production store. Everything waits:

-   New checkout flows that would improve conversion
-   Promotional landing pages tied to upcoming campaigns
-   Payment integrations customers are already asking for
-   Performance optimizations that directly affect bounce rates

Ecommerce conversion is sensitive to small changes, so every UX improvement that doesn't ship during a freeze is revenue the team loses.

The freeze also creates a backlog. By launch day, the team has months of pent-up feature work to push through on a stack they're still learning. This is where post-launch instability comes from, not from the new platform, but from the rush to make up lost time.

## The testing gap that breaks migrations

_Key takeaway: Testing against partial or "stubbed" data sets creates a false sense of security that leads to months of post-launch firefighting._

Before looking at the solution, it's worth understanding where the gap sits.

**1\. Staging environments don't match production**

Most replatforming projects test in environments built on partial data. The database is a subset, or weeks old. Third-party services are stubbed out. Environment variables differ.

Bugs that depend on real data don't surface until launch:

-   Edge cases in product catalogs that only appear at full scale
-   Pricing logic that behaves differently with live customer segments
-   Search indexing issues invisible in a trimmed dataset

**2\. Big-bang cutovers leave no room to recover**

Most migrations launch everything at once. There's no way to incrementally validate changes under real conditions. If something breaks a payment integration, a redirect map, or a checkout flow, the impact is immediate and store-wide.

Rolling back is painful, sometimes impossible without data loss.

**3\. False confidence leads to months of firefighting**

The pattern is predictable: teams test against partial data, everything passes, the launch goes ahead. Then the first 90 days become a cycle of triaging production issues that real data would have revealed earlier.

## Preview environments eliminate the freeze entirely

_Key takeaway: Copy-on-write cloning allows developers to validate 1TB databases in minutes, ensuring the migration branch is a perfect replica of production._

Instead of building a migration in a sandbox that doesn't reflect reality, teams need the ability to clone their entire production stack: application code, databases, services, files, and environment variables into an isolated environment, run the migration there, and validate it against real data before touching production.

This is what preview environments with production data make possible on Upsun. Every Git branch gets its own full environment, cloned from production using an instant copy-on-write mechanism that works regardless of data size. A 1TB database clones in minutes, not hours, because the system snapshots metadata rather than copying the full dataset. Only the changes you make in the branch get written separately.

In practice, this means an ecommerce team can run a replatforming project as a branch. The production store keeps running and continues to receive feature updates. The migration branch gets the full production dataset, the real integrations, and the actual environment configuration. 

Developers can test checkout flows with real payment processors, validate product catalog behavior at full scale, and verify that URL redirects work correctly to preserve SEO.

When the migration is ready, it merges, not as a big-bang cutover, but as a tested, validated deployment.

## What this looks like in an ecommerce migration

_Key takeaway: Shifting to a composable architecture becomes a series of validated merges rather than a single high-risk deployment._

Consider a team moving from a monolithic ecommerce setup to a composable architecture. On Upsun, they create a branch from production. Upsun clones the full environment : the application, the MySQL or PostgreSQL database, Redis cache, Elasticsearch index, and file storage. The branch is a complete, isolated replica.

Developers rebuild the frontend against a headless API layer in the branch. They test with the actual product catalog, real customer data (anonymized as needed), and live integrations. Stakeholders preview it via its own URL.

Meanwhile, production keeps shipping. New promotions go live. Checkout optimizations deploy. Security patches apply. The store doesn't stop.

When the migration branch passes validation, it merges to production through the same Git-driven deployment pipeline the team already uses. 

## The replatforming question isn't "when", it's "how"

_Key takeaway: Risk tolerance, not conviction, is the primary bottleneck for ecommerce modernization._

Most ecommerce teams already know they need to migrate. The delay isn't conviction; it's risk tolerance. A feature freeze during peak season is unthinkable. A botched migration that tanks organic traffic for three months is career-ending.

Preview environments change the risk calculation. The migration runs in parallel, is tested against real conditions, and is merged when ready. The store never stops selling. The team never stops shipping.

If your replatforming plan requires a code freeze, it's worth asking whether the infrastructure is the bottleneck — and whether a platform that eliminates that constraint changes the timeline entirely.

_Upsun provides instant, data-complete preview environments for every Git branch, including full database clones, service replication, and isolated testing._ _Start a free trial_ _or_ _explore how preview environments work__._

### Frequently asked questions (FAQ)

**Does cloning production data into a preview environment slow down the platform?** 

No. Upsun uses a copy-on-write snapshotting mechanism. This means that cloning even massive databases is nearly instantaneous and does not impact the performance of the production environment.

**How do we handle sensitive customer data in preview environments?** 

Upsun allows you to define worker scripts in your configuration that automatically anonymize or scrub sensitive PII (Personally Identifiable Information) during the cloning process, ensuring compliance with GDPR or PCI standards while maintaining data utility.

**Does this support migrations between different cloud providers?** 

Upsun provides the choice of cloud provider at project creation. While you cannot run a single environment across multiple clouds simultaneously, the standardization of the platform allows you to move your entire stack between AWS, GCP, or Azure with minimal reconfiguration, making it an ideal "abstraction layer" for cloud-to-cloud migrations.

### [Why your ecommerce dev team ships slow | Upsun](https://upsun.com/blog/why-your-ecommerce-dev-team-ships-slower-than-your-competitors/)

# Why your ecommerce dev team ships slower than your competitors (and how to fix it)

Ecommerce teams rarely think they have an infrastructure problem. In most ecommerce engineering teams that experience delays in product launch or ship slower than they want to, the instinct is to call it a capacity problem: “We need more developers”,  “We need a bigger DevOps team”, or “We need more time before the next campaign”. 

The bottleneck is rarely the number of developers. The real issue is usually simpler and harder to spot:

**Your infrastructure is quietly slowing the handoffs between writing code and shipping it.**

The uncomfortable part: most of the friction is invisible until you map it.  It doesn't show up cleanly in a retro, because each piece of it looks like "just how things are."  And in ecommerce, where releases are tied to campaigns, promotions, and revenue windows, these delays compound fast. 

## Infrastructure bottlenecks that slow ecommerce teams

_Key takeaway: Most engineering friction is invisible because it is treated as a normal part of the development lifecycle rather than a fixable bottleneck._

Here is what the friction actually looks like when you map it. Five patterns recur across ecommerce engineering teams:

1.  **One shared staging environment:** Developers queue to test against the only staging that exists. QA waits on developers. Releases stack up behind whoever broke it last. The cost is serialized work: a team of eight ships like a team of three, and nobody can quite point to where the time went.
2.  **Manual deployment pipelines:** Hand-rolled CI scripts, brittle YAML, and a release engineer who is the only person who remembers why a particular build flag exists. Tribal knowledge becomes a single point of failure, and onboarding a new developer means teaching them the pipeline before they can ship anything.
3.  **Staging that doesn't match production:** "It worked in staging" bugs reach production because the test environment was never a true copy of it. When staging is an approximation rather than a clone, you aren't testing the thing you're shipping. You're testing something that resembles it.
4.  **Security and compliance bolted on per project:** Every new service triggers a fresh review. PCI scope creeps as new components touch cardholder data. Audit prep eats a sprint that was supposed to be feature work. Compliance becomes a tax on every release instead of a property of the platform underneath.
5.  **Shadow IT:** A frustrated developer spins up a personal cloud account "just to unblock a prototype," and three months later, it's running something the business depends on. Ungoverned environments, surprise invoices, and audit findings follow. The workaround exists because the sanctioned path was too slow, not because the developer was careless.

Each one is a small drag. Compounded across a year, they are the difference between shipping monthly and shipping weekly. It adds up faster than most leads expect. Before any product work even starts, teams commonly spend an entire sprint, days of full-team effort,  just standing up infrastructure and CI pipelines. That is feature development time lost before a single line of product code ships.

## Why "we need more people" is usually the wrong answer

_Key takeaway: Adding headcount to a broken process only increases the number of people waiting in the same queue._

DevOps talent is expensive and scarce, and most ecommerce engineering orgs run lean platform teams by design. Adding headcount doesn't solve a queueing problem; it adds more people to the same queue.

There is also a structural reason this is hard to see from inside. IT leadership tenure is short. The infrastructure decisions made by the previous team lead become the tech debt of the current one, who often inherits constraints they didn't choose and can't easily unwind. Throwing engineers at inherited friction is how you burn budget without moving the ship date.

## What changes when you remove the friction

_Key takeaway: Moving environment logic into a standardized platform layer allows developers to focus entirely on code._

The fix is not a new framework or another layer on top of Kubernetes. It is moving the friction out of your team's day and into the platform layer.

1.  **Every branch becomes its own environment.** The shared staging queue goes away when every branch can run as its own environment. Instead of waiting for the one staging slot to free up, a developer pushes a branch and gets an isolated stack, with data cloned from the parent environment. QA, product, and engineering end up working in parallel against environments that look like production, rather than serializing behind whoever is currently using staging.
2.  **Deployment is** `**git push**`: When the platform reads your configuration from the repository, the same file deploys to every environment. A developer pushes to a branch, and the platform provisions or updates the environment to match. Rolling back is reverting a commit. There is no separate runbook for "how we ship to prod," because the workflow is the same one your team already uses for code review.
3.  **Preview environments are clones, not approximations**: Bugs you catch in preview are bugs that would have hit production. A checkout edge case that only triggers with real cart data will reproduce in preview, because the data is real. Data-dependent bugs, the ones that make ecommerce hard, stop hiding until production. It uses real cart data and reproduces immediately because the data is real.
4.  **Compliance lives at the platform layer.** When the underlying platform is already certified (ISO 27001, SOC 2 Type 2, PCI DSS Level 1, HIPAA), your team inherits those controls instead of re-implementing them project by project.  Audit prep stops eating sprints because the evidence auditors are asking for is already produced by the underlying platform.
5.  **Governed self-service kills shadow IT.** When developers can spin up sanctioned environments in a minute, they stop reaching for the unsanctioned workaround. Governance becomes the path of least resistance instead of the obstacle to route around.

## Rethinking developer velocity in ecommerce

_Key takeaway: High-velocity teams succeed because they have eliminated the "infrastructure tax" that slows down their competitors._

If your team is shipping slower than your competitors, the question isn't "how many more engineers do I need?" It's "how many hours per week is each engineer spending on infrastructure they shouldn't have to think about?" Multiply that by your team size. Compare it to the cost of one new hire. The math usually surprises people.

The teams that ship faster than yours are not necessarily smarter or better staffed. They have just stopped paying the infrastructure tax that you are still paying. Every hour their developers are not spending on broken staging, brittle pipelines, and audit prep is an hour going into the product. 

That is the gap Upsun closes. Not as a faster way to host your application, but as a way to give your existing team back the days they are currently losing to infrastructure they should not have to think about.

## Frequently asked questions (FAQ)

**How does having an environment for every branch impact our cloud costs?** 

Upsun uses a provision-based pricing model. While you can have unlimited preview environments, you only pay for the resources (CPU, RAM, disk) you provision to them. 

**Can we really inherit PCI compliance from Upsun?** 

Yes. Upsun is a PCI DSS Level 1 Service Provider. By running your application on our platform, you inherit the physical and network security controls required for compliance, significantly reducing the surface area of your own audits.  You only need to worry about making sure your application is compliant.

**How does the data cloning handle large production databases?** 

Upsun uses an instant copy-on-write mechanism. Even for multi-terabyte databases, the system snapshots metadata rather than copying bits. This allows you to have a data-complete preview environment in minutes without any performance hit to your production site.

**Learn more**

-   How data cloning changes preview environments
-   Five ways platforms reduce shadow IT
-   Git-driven environments and infrastructure as code
-   Why cloud fragmentation is slowing teams down

### [How a non-linear path shaped leadership in developer advocacy](https://upsun.com/blog/nonlinear-devrel-leadership/)

# Beyond the horizon: How Ana Cidre turned a non-linear path into leadership

Welcome to _Beyond the horizon_, a monthly series celebrating the people who shape Upsun’s culture, innovation, and heart. In this month’s edition, we’re featuring Ana Cidre, Director of Developer Advocacy at Upsun and one of the key voices shaping how developers experience our platform today and in the future. 

Ana’s journey to DevRel leadership wasn’t linear, and that’s exactly what makes her perspective so powerful. With a background spanning Fine Arts, international business, and software engineering, she brings a rare blend of creativity, strategy, and technical credibility to her work. She believes unconventional paths aren’t detours — they’re advantages. Each chapter sharpened her ability to see problems from multiple angles and design for real human experience.

In her story, Ana speaks candidly about stepping onto technical stages when few women were doing so, building communities where inclusion is intentional, and redefining what advocacy means in an AI-native world. It’s a reflection on leadership, visibility, and designing for what’s next without losing sight of the people at the center.

### **Tell us a bit about yourself. What do you do at Upsun and most importantly, who are you outside of work?**

> I'm Ana Cidre, Director of Developer Advocacy at Upsun. I lead our small advocacy team where we tackle Advocacy, Developer Experience (DX) and Documentation. We work closely with marketing to amplify our developer-focused content and strategy, with engineering to provide feedback and build tools developers actually use, and with the product team to ensure we're building what developers need. My team focuses on creating technical content that developers trust, shaping developer experience across the platform and maintaining documentation that serves both human developers and AI agents.
> 
> Outside of work, I'm based in Santiago de Compostela, Spain, though I'm originally from London. That cross-cultural experience shapes how I think about communication, accessibility and building products for global audiences. My path to this role wasn't traditional: I started with a Fine Arts degree and a Master's in International Business Economics before moving into software engineering. That diverse background taught me to see problems from multiple angles and value different perspectives.
> 
> I'm also a community builder at heart. I founded ngSpain, an Angular conference that brings together developers across Spain and beyond, and started GalsTech to support women in tech in Galicia because I believe diverse voices make our industry better and we need more intentional spaces for underrepresented groups.

### **If you could describe your journey in one word or phrase** **what would it be?** 

> Non-linear! My journey from Fine Arts to international business to frontend engineering to DevRel leadership wasn't efficient by traditional standards. But that non-linearity is my strength. Each transition taught me to learn quickly, question assumptions and bring unexpected connections to technical challenges. The art background taught me about human experience and communication. The business training gave me strategic thinking. The engineering years gave me credibility. The DevRel work lets me combine all of it.
> 
> I want others with unconventional backgrounds to know their diverse experiences aren't detours but they're what make their perspective valuable.

### **What’s a challenge you’ve faced and how have you grown from it?** 

> I decided to take the leap into speaking when my good friend Sherry List and I finally got up on stage because we didn't see many people who looked like us (women) speaking at technical conferences. Having her be part of that journey was what got me on stage in the first place. We did it together.
> 
> Being a female speaker came with its perks and absurdities. The upside? Never queuing for the bathroom. The downside? People backstage asking if I was there with my boyfriend, clearly unable to compute that I might actually be one of the speakers.
> 
> The bathroom situation really tells you everything you need to know about the gender ratio.
> 
> Speaker dinners where I'm mistaken for event staff. Technical talks followed by questions clearly testing whether I actually understood the code I just presented. 
> 
> I realised I had a choice: try to blend in or just focus on doing solid technical work. However, the real shift came when I had my daughter. I wanted things to be different for her where there are fewer assumptions about who belongs in technical spaces and fewer barriers to overcome.
> 
> That's why I helped build ngSpain and GalsTech. Not separate spaces, but intentionally inclusive technical communities where diverse speakers would be the norm. Small contributions, but hopefully they make the path a bit easier for others.
> 
> I still speak at conferences and try to mentor other women stepping into speaking when I can. I hope that each woman who shares technical work makes it a little less unusual for the next one. Not pulling down walls so much as finding the doors and holding them open.

### **Is there someone at Upsun who played a key role in your journey or made your experience possible?**

> Fabien has been incredibly supportive of the advocacy work at Upsun. What stands out is his understanding of advocacy as a strategic discipline that shapes how developers experience and adopt products, rather than just a marketing or community function.
> 
> When I talk about exploring the shift from Developer Experience to Agent Experience, or how we might think differently about documentation in an AI-native world, he's open to those conversations. That willingness to engage with emerging ideas from leadership makes it possible to do work that looks beyond the immediate. That trust to investigate emerging patterns and learn alongside the industry is valuable. It's the kind of support that creates room to try things and see what resonates.
> 
> I also want to mention Florian and Guillaume, our field CTOs. They've been generous with their time helping me get up to speed with the product and understand the technical details that matter to our users. As peers, they've made it easy to integrate with the team and ask the questions I needed to ask. That kind of patient, collaborative support makes a real difference when you're learning a new platform.

### **As we say at Upsun, 'Your greatest work is just on the horizon.' What’s the next horizon you’re excited to reach in your journey?**

> The next horizon is redefining what developer advocacy means when AI agents are primary consumers of our work.
> 
> I'm seeing two things happening at once. In-person meetups are coming back. After years of remote-everything, developers want to gather, share ideas and solve problems face-to-face. There's something about learning alongside others that video calls can't replace. We're building that presence again, creating spaces where people can connect over real challenges.
> 
> At the same time, we're learning how to design for AI agents as consumers of our work. If Claude Code can't integrate your API smoothly, that's a developer experience problem, even if your docs read perfectly to humans. So we're figuring out how to serve both audiences: developers who need narrative and context, and agents that need explicit schemas and unambiguous instructions.
> 
> It's interesting work because my background has always been about translating between different contexts from art, to business, to engineering, and advocacy. Now it's humans and agents. Not replacing what we've learned about developer experience, just expanding who we're designing for.
> 
> The expertise we have in serving developers still applies. We're just adding new dimensions to how we think about what makes something useful.

Thanks for joining us on this month’s journey. Beyond the horizon is all about the stories that shape who we are. We hope you’ll return next month as we continue celebrating the people who inspire our culture and move Upsun forward. 💙

### [ISO 27001 certification achieved | Upsun](https://upsun.com/blog/iso-27001-certification/)

# Upsun is now ISO 27001 certified

We're excited to announce that Upsun has achieved ISO 27001 certification. This globally recognized security milestone validates our commitment to protecting customer data and maintaining the highest levels of security across our cloud platform.

ISO 27001 is the world's leading standard for information security management systems. The certification demonstrates that we have established systematic processes to identify, manage, and mitigate security risks, while protecting the confidentiality, integrity, and availability of customer data.

## **Building on our security commitment**

Security has always been central to how we build and operate Upsun. This certification formalizes what we've practiced from day one: taking a systematic approach to protecting customer data and maintaining service reliability.

The certification process involved a comprehensive review of our:

-   Information security policies and procedures.
-   Data protection and access controls.
-   Infrastructure security measures.
-   Incident response processes.
-   Ongoing security monitoring and improvement.

## **What this means for you**

This certification reinforces the security foundation on which Upsun is built. Whether you're deploying production environments, cloning complete stacks with terabyte databases, or testing with real data, you can trust that your information is protected by industry-leading security practices. 

The certification covers our entire platform infrastructure, development processes, and data handling procedures. 

**How to access the ISO 27001 certification**

To access the ISO 27001 certification for audit or vendor assessment purposes, our certification is available on the Upsun Trust Center. 

## **Looking ahead**

Achieving ISO 27001 certification is a testament to our commitment to ensuring the highest security standards. We'll continue to maintain and improve our security practices through regular audits and continuous monitoring.

Our mission is to give development teams the confidence to build, iterate, and deploy at scale. With security handled, you can focus on building great applications.

 If you require additional information or have questions about our certifications, please contact Support.

### [Why Shopware stores slow down and how to fix it | Upsun](https://upsun.com/blog/optimize-shopware-for-speed/)

# Why your Shopware store feels fast until it doesn’t

_Shopware is a powerful platform, but its performance depends entirely on how it is used. In this article, we explore the most common and avoidable causes of slowdowns in production environments, including plugin overload, cache fragmentation, and misconfigured admin settings. Whether you are preparing for a high-traffic event or simply aiming to keep your storefront fast and responsive, this guide will help you identify the root causes of performance regressions. It also explains why relying on infrastructure alone is not enough to keep things running smoothly._

At first glance, your Shopware storefront seems fast. Pages load, searches work, checkouts complete. But then something shifts. Product listings slow down. Admin updates cause lag. API calls ripple across the system. What once felt performant begins to buckle under load. You're not alone.

In our work supporting high-traffic Shopware storefronts, we’ve seen this pattern repeat often. A store launches smoothly, but as traffic grows and the codebase evolves, performance starts to erode quietly. Eventually, it breaks down in ways that affect revenue.

The problem isn’t Shopware itself. It’s the complexity of how it’s configured, extended, and operated in production.

## **The most common culprits**

Here are the issues we see most frequently, based not on theory but real-world cases.

#### **1. Plugin overload**

Shopware's plugin system is powerful, but also risky. Many third-party or custom plugins hook into every request, perform redundant database queries, or introduce logic that doesn't scale. Developers often leave unused or outdated plugins active in production, unaware that they still consume resources.

#### **2. Cache misuse or fragmentation**

Fastly, Redis, HTTP caches—Shopware supports them all. But caching only works when it is designed properly. A misconfigured cache layer, a missing prewarm step, or too many per-user page variations can lead to cache bypasses. When the cache isn’t doing its job, your backend starts working harder than it should.

#### **3. Admin configuration oversights**

Performance isn’t just a code problem. We've seen category pages misconfigured to list thousands of products, dynamic rule conditions that generate expensive queries, and debug logging left on in production. Each of these introduces friction that slows down the entire store.

#### **4. Cache invalidation storms**

ERP integrations that trigger frequent updates, especially when unbatched, often flush large portions of your cache. This kind of invalidation creates backend load spikes and serves cold content to users. Many teams miss this until it's too late.

## **It’s not about more hardware**

Scaling up infrastructure might help in the short term. But if you're serving uncached dynamic pages, rendering bloated queries, or loading unnecessary plugin logic on every request, you will eventually hit a limit. That limit usually arrives sooner than expected.

## **What you can do**

-   Audit your plugin stack. Disable what you don’t need. Assess the runtime impact of what's left.
-   Validate cache hit ratios by checking Fastly response headers like X-Cache.
-   Set pagination and product listing limits deliberately in the admin interface.
-   Batch ERP updates and schedule them during off-peak hours.
-   Profile your application regularly to catch slowdowns before they reach users.

### [Track your carbon emissions easily | 2025 Dashboard ](https://upsun.com/blog/carbon-emissions-dashboard/)

# Carbon emissions data at your fingertips

Tracking environmental impact can be fragmented, time-consuming, and disconnected from operational data. Beyond simply checking ESG reporting boxes or making sure your company is CSRD compliant, actively monitoring environmental impact is the foundation for building an effective sustainability strategy. 

At Upsun, we know that measuring progress is the first step toward improvement. Starting in 2024, we’ve made your annual carbon emissions data easily accessible in the Billing section of the Console -and the 2025 figures are now available.  
  
Now you can easily track last year’s environmental impact at both the Organization and Project levels, and proactively incorporate this data into your financial and environmental strategies.

Organizations across industries can use this emissions data to:

-   Meet ESG reporting requirements and CSRD compliance standards
-   Build data-driven sustainability strategies
-   Track progress on environmental goals
-   Make informed decisions about resource allocation

Organization owners and users with billing permissions can access this data immediately—no setup required

## **How we calculate your emissions**

We've simplified this process by partnering with Greenly to deliver precise emissions calculations using detailed billing data from our cloud providers. All calculations follow GHG Protocol standards to ensure your data meets compliance requirements.

Going forward, emissions data for the previous year will be automatically available in the Console and via our API, which means you get consistent, reliable data without manual collection or complex integrations.

## **More accurate data with updated methodology**

If you received your 2024 emissions data last year, the 2025 emissions might be significantly different. If you have not done any major hosting changes, the gap between the 2 years might reflect improved calculation accuracy on our side, not actual emission reductions.

**What’s changed from 2024?**

In 2025, the methodology used to calculate project carbon dioxide emissions is still aligned with the GHG Protocol but has been updated based on 3 primary factors:

1.  **Updated electricity emission factors:** Every year, we update emissions factors to reflect any significant changes in energy sources used at region level, reflecting for instance the decarbonization efforts at country level. As usual, we updated the emissions factors and in 2025 chose to blend IEA data (the most recognized actor) with ElectricityMaps (for some regions, like the U.S).
2.  **Granular PUE integration:** Where publicly disclosed by providers, we have factored in regional PUE (Power Usage Effectiveness) data to calculate electricity consumption with higher precision.
3.  **Extrapolation Variability:** For cloud services lacking specific infrastructure data for some services, we employ extrapolation. This process can result in year-over-year reporting variability.

## **What's next**

_Carbon accounting is an ever-evolving process._ We are continually refining these calculations as emissions accounting standards and cloud provider strategies evolve.

For more information or if you wish to discuss your organization's specific needs, take a look at the documentation and feel free top contact our ESG team at esg@platform.sh.

### [How to sanitize environment data | Upsun](https://upsun.com/blog/how-to-sanitize-preview-environment-data/)

# How to sanitize preview environment data

Being GDPR-compliant across all your projects is a daily challenge—especially if you’re managing sensitive user data on your projects. Upsun adopts a _GDPR everywhere_ approach with high levels of built-in security and compliance as standard—but there are ways to secure your data on our PaaS further when it comes to preview environments. 

Each time you create a new Git branch on a project on Upsun, the corresponding environment inherits the data (assets and database) from its parent. This means that potentially sensitive data from your production website could be exposed to the preview environment. 

So, how do you navigate this and ensure your application remains compliant? Two words: data sanitization. The deliberate and permanent erasure of sensitive data from a storage device making the data non-recoverable. In this article, I will share the methods of data sanitization that you can implement for preview environments to ensure that your data remains safe at every stage of development. 

## **Some necessary resources before we start** 

We have some prerequisites to ensure that you can follow the solutions and steps detailed in this article—please make sure you have installed the following: 

-   Git
-   PHP
-   jq library
-   Symfony CLI (**please note**: if you’re not using Symfony stack, you will need to download the Upsun CLI)

## **Methods for application data sanitization**

For the purpose of this article, we are going to focus on preview environment data sanitization on Symfony, however, the methods detailed apply to all frameworks. 

If you want more details on how to set up Symfony Demo applications on Upsun, take a look at our Up(sun) and running with Symfony Demo guide.

Throughout the article, we’re going to walk through the various methods available to sanitize Symfony preview environment data on Upsun—5 methods to be exact—which you can weigh up and choose the best one for you. However, **make sure that you complete the** **create a command step** **before proceeding with any method**. 

If you already know the method you would prefer to use, go ahead and click on the relevant title below and we’ll take you straight there:

-   Manual data sanitization
-   Using environment inheritance
-   Using a hook
-   Using runtime operations and activity scripts
-   Using shell scripts

## First things first, create a command to sanitize your data

**Please note**: if you’re hosting a stack other than Symfony, please adapt the command to sanitize your database in your stack and push it to your production branch. This is the only Symfony-specific step in this article.

To carry out any of the five data sanitization methods listed above, we need a callable to sanitize our environments. There are two possible ways to do so:

1.  Using an SQL script to update or fake all sensitive data
2.  Using a Symfony command to do it, perhaps using the fakerPHP bundle

Since we are using a Symfony Demo application, we will use the second option. Do the following, from the `**main**` Git branch:

```shell-session
symfony composer require --dev fakerphp/faker
git add composer.json composer.lock && git commit -m "composer require --dev fakerphp bundle" 
```

Then open your code in your favorite IDE and create a new Symfony command, in an **SRC/command/SanitizeDataCommand.php** file, with the following:

```php
<?php
/* src/Command/SanitizeDataCommand.php */

namespace App\Command;

use App\Entity\User;
use App\Repository\UserRepository;
use Doctrine\ORM\EntityManagerInterface;
use Faker;
use Symfony\Component\Console\Attribute\AsCommand;
use Symfony\Component\Console\Command\Command;
use Symfony\Component\Console\Input\InputInterface;
use Symfony\Component\Console\Output\OutputInterface;
use Symfony\Component\Console\Style\SymfonyStyle;

#[AsCommand(
   name: 'app:sanitize-data',
   description: 'Sanitize user data (username and email).',
   aliases: ['app:sanitize']
)]
class SanitizeDataCommand extends Command
{
   private SymfonyStyle $io;

   public function __construct(private UserRepository $userRepository, private EntityManagerInterface $entityManager)
   {
       parent::__construct();
   }

   protected function configure()
   {
       $this
           ->setDescription('This command allows you to sanitize user data (username and email).');
   }

   protected function initialize(InputInterface $input, OutputInterface $output): void
   {
       $this->io = new SymfonyStyle($input, $output);
   }

   protected function execute(InputInterface $input, OutputInterface $output): int
   {
       $users = $this->userRepository->findAll();
       $this->io->progressStart(count($users));

       $this->entityManager->getConnection()->beginTransaction(); // suspend auto-commit
       try {
           /** @var User $user */
           foreach ($users as $user) {
               $this->io->progressAdvance();
               // initialize faker
               $faker = Faker\Factory::create();

               $this->io->text('faking user '.$user->getUsername());
               // fake user info
               $user->setUsername(uniqid($faker->userName()));
               $user->setEmail($faker->email());
               // please adapt to your needs
           }   

           $this->entityManager->flush();
           $this->entityManager->getConnection()->commit();
           $this->io->progressFinish();
       } catch (\Exception $e) {
           $this->entityManager->getConnection()->rollBack();
           throw $e;
       }

       return Command::SUCCESS;
   }
}
```

This command `**app:sanitize-data**` uses the UserRepository and fakes username and email from the default User Symfony entity. Please adapt to your needs. Then push your code to the `**main**` branch:

```shell-session
git add src/Command/SanitizeDataCommand.php && git commit -m "sanitize data command" 
symfony deploy
```

## 1) Manually sanitize your data

Now that your source code contains a Symfony command to sanitize your data, we will use it manually in a new **preview** environment. Starting with creating a new staging branch and waiting for the process to finish, like so:

```shell-session
symfony branch staging --type=staging
```

Then, execute your newly-created Symfony command on your Upsun staging environment, as seen below:

```shell-session
symfony ssh php bin/console -e dev app:sanitize-data
```

Et voilà, your preview environment data is sanitized!

## 2) Use environment inheritance

In this section, we will create a preview environment, sanitize its data, and then make all new environments inherit from that preview environment.

As mentioned at the top of this article, each time you create a new Git branch on Upsun, the created environment will inherit data from the parent environment. However, it’s possible to change the default data inheritance and set it later to synchronize data from a new parent—the preview environment we will create. 

The Symfony CLI offers the ability to create a branch without a parent, using option `_--no-clone-parent_`, and then setting the parent to staging (a.k.a preview) which ensures new branches inherit the preview environment’s data. Follow the instructions in step 1 for details on how to sanitize preview environment data manually to ensure any future branches inherit sanitized, GDPR-compliant data.

```shell-session
symfony checkout main
symfony branch dev --no-clone-parent
symfony env:info -e dev parent staging
symfony sync -e dev data
```

And that’s it, your new `dev` environment is now created with sanitized data from your preview environment.

## 3) Use a hook

Rather than relying on inheritance, it may be desirable to sanitize certain data on each deployment. In this case, we can move our script call to the `hooks` section of the configuration. 

The type of hook you choose is up to you—deploy or post\_deploy hooks—but here are a few things to keep in mind:

-   Long-running script within the deploy hook will need to extend the deployment time of an application.
-   Long-running script within the post\_deploy hook could make non-compliant/critical data momentarily public while the sanitization is taking place.
-   Redeploys; if sanitization is something you’d like to be able to manually trigger with a redeploy, sanitizing will take place on each redeploy _only_ if placed in the post\_deploy hook. 

To execute a Symfony command during the `post_deploy` hook, add the following in your `.upsun/config.yaml`:

```yaml
applications:
  app:
    hooks:
      build: ...
      deploy: ...

      post_deploy: |
        if [ "$PLATFORM_ENVIRONMENT_TYPE" != production ]; then
          # The sanitization of the database should happen here (since it's non-production)
          php bin/console -e dev app:sanitize-data
        fi
```

Then push your code to the **main** branch:

```shell-session
git checkout main && git add .upsun/config.yaml && git commit -m "add sanitize data command to post_deploy hook" 
symfony deploy
```

## 4) Use runtime operations and activity scripts

There is another option that allows you to create a custom trigger that is run in response to certain activities that take place on the project. Namely, when synchronizing an environment with its parent, we could sync back non-anonymized data from the parent (e.g., if synchronizing from the production environment).

The two components that will make this work are:

-   A **runtime operation**: will allow you to trigger one-off commands or scripts on your project. Similar to crons, they run in the application container but not on a specific schedule.
-   An **activity script**: a JavaScript piece of code that will be run in response to certain _activities_ taking place at the project, environment, or even organization level. 

So we will add an integration (activity script) that responds to certain events to execute a runtime operation to sanitize data on the fly, see add an integration of an activity script below.

**Please note**: if you set a `post_deploy` hook from the previous step, please comment it out as it would not be needed anymore after using this runtime operation.

### **How to create a runtime operation**

To configure a runtime operation, we need to add a new top-level YAML key in our `.upsun/config.yaml` file with the following:

```yaml
applications:
  app: 
    operations:
      sanitize:
        role: admin
        commands:
          start: |
            if [ "$PLATFORM_ENVIRONMENT_TYPE" != production ]; then
              # The sanitization of the database should happen here (since it's non-production)
              php bin/console -e dev app:sanitize-data
            fi
```

Then push your file to the `**main**` branch and deploy. 

```shell-session
git checkout main 
git add .upsun/config.yaml && git commit -m "add runtime operation to sanitize data"
symfony deploy
```

And if you want to test this runtime operation manually, you can use the following:

```shell-session
symfony operation:run sanitize --app=app
```

### **How to create an activity script**

Upsun supports custom scripts that can fire in response to any activity. This script is executed outside of the environment context and so, we need to re-create this context for the activity script to be executed with the necessary rights. To do so, create a new file `src/runtime/sanitize.js` with the following: 

```Javascript
// src/runtime/sanitize.js
let app_container = "app";
let runtime_operation_name = "sanitize";

if (!variables.api_token) {
    console.log("Variable API Token is not defined!");
    console.log("Please define an environment variable with your API Token using command: ");
    console.log("upsun project:curl /integrations/<INTEGRATION_ID>/variables -X POST -d '{\"name\": \"api_token\", \"value\": \"<API_TOKEN>\", \"is_sensitive\": true, \"is_json\": false}' ");
} else {
    console.log("OAuth2 API Token defined");
    let resp = fetch('https://auth.api.platform.sh/oauth2/token', {
        method: 'POST',
        headers: {
            'Content-Type': 'application/x-www-form-urlencoded'
        },
        body: "client_id=platform-api-user&grant_type=api_token&api_token=" + variables.api_token
    });

    if (!resp.ok) {
        console.log("Failed to get an OAuth2 token, status code was " + resp.status);
    } else {
        console.log("OAuth2 API TOKEN ok");
    }

    let access_token = resp.json().access_token;

    // get current branch from activity object
    let branch;
    switch (activity.type) {
        case 'environment.synchronize':
            branch = activity.parameters.into;
            break;
        case 'environment.branch':
        case 'environment.activate':
            branch = activity.parameters.environment;
            break;
    }

    // run runtime operation runtime_operation_name on current/targeted environment
    resp = fetch("https://api.upsun.com/api/projects/" + activity.project + "/environments/" + branch + "/deployments/current/operations",
        {
            headers: {
                "Authorization": "Bearer " + access_token
            },
            method: "POST",
            body: JSON.stringify({"service": app_container, "operation": runtime_operation_name}),
        });

    if (!resp.ok) {
        console.log("Failed to invoke the runtime operation, status code was " + resp.status);
    } else {
        console.log(runtime_operation_name + " launched");
    }
}
```

This activity script uses an API Token, as an environment variable, to connect to the current environment and execute the previously defined runtime operation using the Upsun API. We need to define this environment variable for the integration of our activity script, and later add an API Token environment variable.

Then push your file to the `**main**` branch and deploy, like so: 

```shell-session
symfony checkout main 
git add src/runtime/sanitize.js
git commit -m "add activity script"
symfony deploy
```

### Add an integration of an activity script

Three Upsun events should trigger this runtime operation: 

-   When creating a new branch (`environment.branch`), 
-   When synchronization of data between environments occurs (`environment.synchronize`), 
-   When activating a preview environment (`environment.activate`). 

To implement these triggers, use this command in your terminal to add an activity script integration.

```shell-session
symfony integration:add --type script --file ./src/runtime/sanitize.js --events environment.branch,environment.synchronize,environment.activate --states complete --environments \*
```

**Please note**: A complete list of possible events is available as the Activity script type definition. Any of those Activity Script types can be added as an event list in the `--events=event1,event2,...` option.

**Add an API Token environment variable**

First, get the previous integration ID using the following command: 

```shell-session
symfony integration:list
```

Then, create a new API Token from the Console, keep the value in your hand, and replace it in this terminal command: 

```shell-session
symfony project:curl /integrations/<INTEGRATION_ID>/variables -X POST -d '{"name": "api_token", "value": "<API_TOKEN>", "is_sensitive": true, "is_json": false}'
```

**Please note**: replace `<INTEGRATION_ID>` and `<API_TOKEN>` with the corresponding values previously created.

You can verify that the variable has been created with this command:

```shell-session
symfony project:curl /integrations/<INTEGRATION_ID>/variables
```

### **Time to test**

To test if everything has worked, in the Console or with the CLI, trigger the creation of a new branch from `**main**`, trigger a sync, deactivate and reactivate your preview environment, and then you should see two activities:

-   Activity triggered
-   A runtime operation activity

### **Run into a problem? Debug it**

If you encounter a problem and want to debug the activity script integration, you need to use the following command:

```shell-session
symfony integration:activity:log <INTEGRATION_ID>
```

When adding the integration of your activity script, the corresponding script is added in memory on the Upsun side. This means that each time you update your script, you need to update the cached version of the file, using the following command:

```shell-session
symfony integration:update <INTEGRATION_ID> --file ./src/runtime/sanitize.js
```

**Please note**: of course, to keep your source code up-to-date, you would need to commit this file:

```shell-session
git add src/runtime/sanitize.js
git commit -m "add activity script"
symfony deploy # optional
```

## 5) How to use shell scripts to sanitize development environments

It’s possible to use a shell script to automate the data sanitization of all of your environments, except production,  for all your projects within an organization–learn more about organizations here. To use this shell script, please ensure that all your environment sources from all your projects inside your organization contain the Symfony command to sanitize data, before working through the following steps.

The first step is to create a file named _**fleet\_sanitizer.sh**_ with the following code:  

```shell-session
if [ -n "$ZSH_VERSION" ]; then emulate -L ksh; fi
######################################################
# fleet sanitization demo script, using the CLI.
# 
# Enables the following workflow on a given project and sanitize preview environments (staging, new-feature and auto-updates environment:
# .
# └── main
#     ├── staging
#     |   └── new-feature
#     └── auto-updates
#
# Usage
# 1. source this script: `. fleet_sanitizer.sh` or `source fleet_sanitizer.sh` depending of your local machine
# 2. define ORGANIZATION var: ORGANIZATION=<organizationIdentifier>
# 3. run `sanitize_organization_data $ORGANIZATION`
######################################################

# Utility functions.

# list_org_projects: Print list of projects operation will be applied to before starting.
#   $1: Organization, as it appears in console.upsun.com.
list_org_projects() {
  symfony project:list -o $1 --columns="ID, Title"
}

# get_org_projects: Retrieve an array of project IDs for a given organization.
#   Note: Makes array variable PROJECTS available to subsequent scripts.
#   $1: Organization, as it appears in console.upsun.com.
get_org_projects() {
  PROJECTS_LIST=$(symfony project:list -o $1 --pipe)
  PROJECTS=($PROJECTS_LIST)
}

# get_project_envs: Retrieve an array of envs IDs for a project.
#   Note: Makes array variable ENVS available to subsequent scripts.
#   $1: ProjectId, as it appears in console.upsun.com.
get_project_envs() {
  ENV_LIST=$(symfony environment:list -p $1 --pipe)
  ENVS=($ENV_LIST)
}

# list_project_envs: Print list of envs operation will be applied to before starting.
#   $1: ProjectId, as it appears in console.upsun.com.
list_project_envs() {
  symfony environment:list -p $1
}

# add_env_var: Add environment level environment variable.
#   $1: Variable name.
#   $2: Variable value.
#   $3: Target project ID.
#   $4: Target environment ID.
add_env_var() {
  VAR_STATUS=$(symfony project:curl -p $3 /environments/$4/variables/env:$1 | jq '.status')
  if [ "$VAR_STATUS" != "null" ]; then
    symfony variable:create --name $1 --value "$2" --prefix env: --project $3 --environment $4 --level environment --json false --sensitive false --visible-build true --visible-runtime true --enabled true --inheritable true -q
  else
    printf "\nVariable $1 already exists. Skipping."
  fi
}

# Main functions.
sanitize_organization_data() {
  list_org_projects $1
  get_org_projects $1
  for PROJECT in "${PROJECTS[@]}"; do
    printf "\n### Project $PROJECT."
    # get environments list
    list_project_envs $PROJECT
    get_project_envs $PROJECT
    for ENVIRONMENT in "${ENVS[@]}"; do
      unset -f ENV_CHECK
      ENV_CHECK=$(symfony project:curl -p $PROJECT /environments/$ENVIRONMENT | jq -r '.status')
      unset -f ENV_TYPE
      ENV_TYPE=$(symfony project:curl -p $PROJECT /environments/$ENVIRONMENT | jq -r '.type')

      if [ "$ENV_CHECK" = active -a "$ENV_TYPE" != production ]; then
        unset -f DATA_SANITIZED
        DATA_SANITIZED=$(symfony variable:get -p $PROJECT -e $ENVIRONMENT env:DATA_SANITIZED --property=value)
        if [ "$DATA_SANITIZED" != true ]; then
          printf "\nEnvironment $ENVIRONMENT exists and is not sanitized yet. Sanitizing data."
          printf "\n"
          # do sanitization here
          symfony ssh -p $PROJECT -e $ENVIRONMENT -- php bin/console app:sanitize-data
          printf "\nSanitizing data is finished, redeploying"
          add_env_var DATA_SANITIZED true $PROJECT $ENVIRONMENT
        else
          printf "\nEnvironment $ENVIRONMENT exists and does not need to be sanitized. skipping."
        fi
      elif [ "$ENVIRONMENT" == main ]; then
        printf "\nEnvironment $ENVIRONMENT is production one, skipping."
      else
        printf "\nEnvironment $ENVIRONMENT is not active $ENV_CHECK, skipping."
      fi
    done
  done
}
```

**Please note**: in this script, each time we sanitize an environment, we set environment variable _**DATA\_SANITIZED**_ to be sure that the next time we run this script, it will not sanitize the environment repeatedly.

Then, depending on the machine you want to run this script on, please adapt the code to your needs but it should look something like this:

```php
. fleet_sanitizer.sh  # or source fleet_sanitizer.sh
ORGANIZATION=<organizationIdentifier>
sanitize_organization_data $ORGANIZATION
```

**Tip**: you will find the organization identifier for a specific project by clicking on your **name**, and then on **settings** in the top right corner of the screen.

And just like that, your data is sanitized and you're well on your way to GDPR compliance! 

If you have any further questions about our security and compliance capabilities or encounter any issues with the methods and/or steps above, reach out to our support team who’ll be happy to help. 

Stay up-to-date on all the latest from us over on our social media and community channels. Catch us over on Dev.to, Reddit, and our Community.

### [Digital agencies must modernize their own processes first | Upsun](https://upsun.com/blog/modernize-agency-processes/)

# The hardest modernization: Your own agency’s processes

As a digital marketing agency, you help clients modernize their applications every day. You design sleek user experiences, migrate legacy systems to the cloud, and build future-proof digital products. But when was the last time you stepped back and modernized your own processes?

It’s the classic case of the plumber’s pipes always leaking at home. Agencies are incredible at building cutting-edge solutions for others but often get stuck using outdated workflows, inefficient infrastructure, and time-consuming deployment processes internally. The irony? While you’re helping clients move faster, your own agency may be slowed down by the very problems you solve for others.

The good news is that modernizing your agency’s internal processes doesn’t require an overhaul—just a shift in how you approach platform management. By eliminating infrastructure headaches and streamlining deployments, you can spend less time maintaining your own systems and more time delivering high-value work to clients.

## The true cost of ignoring your own modernization

The numbers don’t lie:

-   According to a Redhat survey, over 21% of modernization projects take two years or longer—often because of the time spent updating platforms rather than modernizing applications themselves.
-   According to RocketSoftware, modernization challenges led to reduced productivity from 33% of their respondents.
-   Agencies that modernize their platforms in tandem with applications report a 30-50% reduction in maintenance costs (IBM).

Now, think about your agency’s internal workflows. Are your developers spending more time managing infrastructure than creating better solutions for your clients? Every hour spent troubleshooting deployments or configuring cloud resources is an hour not spent designing, optimizing, or innovating.

## The platform bottleneck: why your own agency’s growth is slowing down

You know the modernization roadmap for your clients: better performance, scalable architectures, seamless deployment. But do you follow that same approach for your own agency?

### Your own infrastructure setup is slowing your team down

Before any modernization work begins for a client, you need to set up the right infrastructure. But internally, how much time does your agency waste spinning up cloud instances, managing networking rules, and establishing CI/CD pipelines for your own projects? If you’re doing this manually, it’s draining valuable resources that could be better spent on client work.

### Deployment shouldn’t be a headache for your team

You help clients transition to modern deployment strategies, but is your own agency stuck manually managing Kubernetes clusters, runtime dependencies, and container configurations? If deploying internal tools or demo environments feels like a chore, you’re not running as efficiently as you could be.

### Middleware configuration takes more time than It should

Modern applications rely on databases, caching systems, authentication services, and message queues. But does your agency have a streamlined way of handling middleware internally? If each project requires custom configurations, migrations, and troubleshooting, you’re burning unnecessary hours on non-billable work.

### Observability & monitoring are overlooked—until something breaks

You emphasize the importance of logging, tracing, and monitoring for clients, but how much visibility do you have into your own applications and deployments? Without automated observability, small issues turn into major problems, and debugging can quickly become a time-consuming mess.

### Security & compliance aren’t just for clients

Security is a priority for client projects, but is your own agency following best practices? Managing access controls, encrypting data, and ensuring compliance with industry regulations should be built into your own workflow—not an afterthought.

## **Modernizing your own agency with a cloud application platform**

If your agency is spending too much time maintaining internal systems rather than building for clients, it’s time to modernize your own processes. A Cloud Application Platform (CAP) like Upsun eliminates infrastructure overhead, allowing your team to focus on what truly matters—creating outstanding digital experiences.

### How a cloud application platform transforms your workflow

1.  Automated Infrastructure: No more manual cloud setup—pre-configured environments spin up instantly, so your team can get to work faster.
2.  Simplified Deployments: Forget the complexities of Kubernetes and runtime management—your applications deploy consistently, every time.
3.  Integrated Middleware: Databases, message queues, and authentication services are built-in and ready to use.
4.  Observability Out of the Box: Full monitoring, logging, and performance tracking ensure that your internal applications run smoothly.
5.  Security & Compliance by Default: Built-in best practices keep your agency’s infrastructure secure and compliant.

By modernizing your own processes, you free up time to focus on client work, reduce operational overhead, and make your agency more scalable and efficient.

## Stand out by practicing what you preach

### Offer end-to-end modernization services—including your own

Your agency is already helping clients modernize, so why not extend that expertise internally? If you can show prospects and clients that you run a fully modernized, cloud-powered operation, you’ll be a more attractive partner. According to Salesforce, companies that invest in cloud technologies experience up to **53% faster revenue growth** than their competitors (Salesforce).

### Respond faster to market demands

Your ability to adapt to client needs is critical. If your internal systems are slow, your response times will be too. A cloud application platform ensures that your agency is able to create consistent and repeatable solutions that are agile enough to take on new projects quickly.

### Establish a reputation for technical excellence

Clients aren’t just looking for agencies that build great digital experiences—they want partners who can scale, deliver consistently, and innovate. With **94% of companies worldwide adopting cloud computing** (Forbes), having a modernized internal process gives you credibility and a competitive edge.

### Attract enterprise-level clients

Larger clients expect modern, secure, and scalable solutions, and they expect these solutions to be quick and easy to implement.  If your agency is running on legacy processes, it will be harder to win enterprise contracts.  The market no longer allows enterprise customers to take years or months to implement solutions.  During that time a more agile start-up could easily surpass them in market share.

## The time to modernize is now

Your agency is helping clients modernize every day. But if you’re still spending valuable time configuring infrastructure, managing deployments, and troubleshooting platform issues for your own projects, you’re falling behind.

It’s time to practice what you preach. Upsun helps you modernize your own workflows so you can focus on delivering exceptional client experiences, scale your operations, and future-proof your agency.

Ready to modernize your agency’s internal processes? Start with Upsun today and transform the way you work.

### Useful links

-   We all make mistakes: Avoiding the sunk cost fallacy in digital transformation and app modernization
-   Why "build your own" digital transformation is a flawed strategy

### [Evaluating infrastructure for agent-ready environments | Upsun](https://upsun.com/blog/evaluation-guide-for-agent-ready-infrastructure/)

# The data context gap: an evaluation guide for agent-ready infrastructure

Why do AI agents that look brilliant in a sandbox fail the moment they hit production? 

For platform leaders, the answer is a lack of **environmental parity**: the ability to interact with the exact data state and service topology where the actual bugs live. 

When an agent attempts to modify a schema, optimize a query, or reproduce a bug without access to the real-world data state, it hits the **Data Context Gap**.

In 2026, evaluations of AI infrastructure must move beyond model access and toward the primitives of environmental parity. 

If your platform cannot provide an agent with a production-identical state in seconds, your AI strategy will stall under the weight of manual environment provisioning.

## **1\. Beyond byte-copying: metadata-level cloning**

Traditional data duplication (restoring a database dump or cloning a cloud volume) is too slow for the iterative nature of autonomous agents. If a clone takes 30 minutes to provision, your agents remain idle, and the "cost per outcome" skyrockets.

Modern infrastructure must utilize a **Copy-on-Write (CoW) foundation**. 

Unlike traditional cloning that copies data bit-by-bit, a CoW-based platform snapshots the metadata of your runtimes, services, and files without moving physical bytes.

By only writing new data blocks when a change occurs, the system treats a 500GB database branch as a metadata operation rather than a data movement task. This technical distinction is why cloning a massive production environment takes the same time as cloning a fresh one (usually under 10 seconds).

-   **Evaluation metric**: Does the platform support atomic environment branching where code, services, and data are branched simultaneously?
-   **The SRE impact**: This shifts behavior from "disposable code" to "disposable environments," allowing agents to spin up, execute, and destroy stacks without affecting the production filesystem.

## **2\. Solving for "organic state divergence"**

AI agents cannot solve bugs they cannot see. 

Most production failures are not purely code-based; they are tied to years of **Organic State Divergence** (the accumulation of data quirks, schema migrations, and edge-case user inputs that "clean" test accounts or synthetic seed data simply cannot replicate).

To be effective, an agent needs to operate against the "dirty" state of a production environment at the exact moment of failure. Upsun’s cloning mechanism ensures that the agent inherits the full stack: applications, services, and the exact binary state of persistent data.

-   **Evaluation metric**: Can your agents create a "Production Sandbox" that includes the exact binary state of your managed services (MariaDB, PostgreSQL, OpenSearch) without manual data migration?
-   **The risk mitigation**: Because these clones are fully independent, the agent can mutate data and test "what-if" scenarios with zero interconnection to the source project.

## **3\. Automated sanitization and compliance guardrails**

The tension between **context** and **compliance** is the primary blocker for enterprise AI adoption. 

You cannot allow PII (Personally Identifiable Information) to flow into a third-party LLM, yet scrubbing data too aggressively can destroy the very data relationships required for bug reproduction.

The solution is to move sanitization from a manual script to a **platform-level hook**. 

Upsun allows you to define automated sanitization rules within your configuration.

-   **The requirement**: Sanitization must occur _during_ the atomic cloning operation, ensuring that data is anonymized before the agent gains access to the new environment URL.
-   **The permission model**: Evaluation should check if API tokens can be scoped by environment type. An agent should have `write` access to its clone but remain strictly `read-only` or blocked from the production parent.

## **4\. Validating performance with guaranteed resources**

You cannot profile cache hit rates or query performance against a 50-row test database, and running load tests against a live site is a high-risk operation that can lead to production "brownouts." 

For performance work to be valid, an agent needs production-identical resources in an isolated environment.

By cloning a production environment and upscaling the preview environment to match production resources via Guaranteed Resource Profiles, an agent can run real-world load tests without impacting the live site.

This enables **Surgical Scaling**: the ability to independently upsize the vCPU and RAM of a specific container (such as a database or an AI inference engine) without the cost or complexity of scaling an entire cluster. This ensures that the benchmark is valid and that the agent has the dedicated compute required for high-intensity profiling.

**A predictable world**: Within this isolated clone, the agent can use tools like **Blackfire** to analyze results and present a ranked list of optimizations (e.g., "this query needs an index") based on real traffic patterns and dedicated hardware performance.

### **The verdict: infrastructure as a context provider**

The payoff for metadata-level cloning wasn't predicted a decade ago; it was a practical response to the complexity of CMS and e-commerce deployments. 

Today, that same generality makes it the essential foundation for AI agents.

In 2026, the CTO’s goal is to reduce the "friction of the cloud." By choosing a platform that handles the plumbing of data cloning, permissions, and sanitization at the architectural level, you allow your senior talent to focus on the logic of the agents, rather than the fragility of the staging environments.

### **Next steps:**

-   **The Technical Deep Dive**: For a closer look at the history of Upsun's cloning bet and the "User\_7" anecdote, read the original **Dev Center post** 
-   **Map the Risk**: If PII and compliance are your primary blockers for agent adoption, see our **database sanitization technical guide**
-   **Build with Confidence**: If you are ready to see the reproduction loop in action, **start your free 15-day trial**

### [How to use FrankenPHP on your Upsun projects | Upsun](https://upsun.com/blog/upsun-and-running-with-frankenphp/)

# Up(sun) and running with FrankenPHP 

**Please note**: There is an updated version of how to set up FrankenPHP on Upsun. For the most current walkthrough, see how we scaled live connections for 1,200 developers at SymfonyCon. The guide below is preserved for reference.

We’re here to shed a little light on how you can use and configure FrankenPHP, a modern PHP app server, written in Go and designed to accelerate your PHP applications, on Upsun with our step-by-step guide.

The processes/commands in the Up(sun) and running with FrankenPHP tutorial can be adapted for your Platform.sh project by replacing `upsun` CLI by `platform` CLI, and also change `mounts.source` from `storage` to `local` in your application configuration.

## **How to start using FrankenPHP on Upsun**

To perform the following steps in this guide, you need to host your PHP application on Upsun—for details on how to do so, follow this simple tutorial on how to host a Symfony Demo application on Upsun. 

If you’re using your own PHP codebase, you will need to replace all of the `symfony` CLI calls in this blogpost with `upsun` CLI calls, like:

```shell-session
upsun branch staging --type staging
```

### **Create a staging environment**

As we never (_ever_) test new features directly on production, we will create a new environment to test and configure our Symfony Demo application to use FrankenPHP. 

To create a new environment on our project, use the following command:

```shell-session
symfony branch staging --type=staging
```

This command creates a new active `staging` environment (of type `staging`) and automatically switches your local Git branch to `staging`.

### **How to use FrankenPHP on Upsun** 

Now it’s time to show you how to use FrankenPHP, this rad PHP web server was designed for a similar purpose to Swoole and RoadRunner: to increase the speed of your PHP application loading time. So, how do you configure it in Upsun? 

Kevin Dunglas, from Les Tilleuls, provides a built-in FrankenPHP image that can be used to run a FrankenPHP PHP server if preferred to the PHP-FPM server provided by Upsun.

To do so, open your source code in your favorite IDE, and let’s update your `.upsun/config.yaml` file by completing the following steps:

1\. Find the `applications.app.web` section and change it accordingly: all of the HTTP calls need to pass through the application and the default upstream HTTP protocol needs to use tcp unix sockets. You also need to define a `commands.start` to start the FrankenPHP server. 

```yaml
applications:
  app:
    ...
    web:
      locations:
        "/":
          root: "public"
          expires: 1h
          #passthru: "/index.php"
          passthru: true
          scripts: false
          allow: false
      upstream:
        # important for PHP we default to unix sockets
        socket_family: tcp
        protocol: http
      commands:
        start: ./frankenphp php-server --listen=localhost:$PORT --root=$PLATFORM_DOCUMENT_ROOT
```

This `./frankenPHP` binary will be installed in a later step, by using a remote `install-frankenphp.sh` shell script—see step 3 below.

2\. As FrankenPHP needs to write access to a `.local` folder, you need to add a mount (=writable folder within your app container) for FrankenPHP to do so. Please find the `applications.app.mounts` section in your `.upsun/config.yaml` and add the following `.local` mount configuration:

```yaml
applications:
  app:
    ...  
    mounts:
      ...
      ".local": { source: storage, source_path: frankenphp-local}
```

3\. We design a shell script for you (source) that can be used to install frankenPHP (only once) during the `applications.app.hooks.build` step:

```yaml
applications:
  app:
    ...
    hooks:
      build: |
        set -x -e

        curl -fs https://get.symfony.com/cloud/configurator | bash

        NODE_VERSION=18 symfony-build

        curl -fsS https://raw.githubusercontent.com/upsun/snippets/main/src/install-frankenphp.sh | { bash /dev/fd/3 5.1.1 ; }
```

The first curl call to the Symfony configurator is Symfony-specific and introduces new tools to deploy your Symfony demo application. If you're using your own PHP code base, only add the last curl command in your build hooks:

```shell-session
curl -fsS https://raw.githubusercontent.com/upsun/snippets/main/src/install-frankenphp.sh | bash 
```

4\. Add the FrankenPHP runtime to your Symfony project. According to the FrankenPHP documentation page, you need to add the following bundle to the application: 

```shell-session
composer require runtime/frankenphp-symfony
```

If you're not using a Symfony application but your own PHP codebase, you can skip this step.

5\. Add an `APP_RUNTIME` environment variable—to tell Symfony to use the new FrankenPHP runtime, you need an environment variable, named `APP_RUNTIME`. To do so, in your `.upsun/config.yaml`, find the `applications.app.variables` section and add the following:

```yaml
applications:
  app:
    ...  
    variables:
      php: ... 
      env: 
        APP_RUNTIME: 'Runtime\\FrankenPhpSymfony\\Runtime'
```

If you're not using a Symfony application but your own PHP codebase, you can skip this step.

6\. Deploy your changes to staging.

```shell-session
git add composer.json composer.lock symfony.lock .upsun/config.yaml install_frankenphp.sh
git commit -m "Use FrankenPHP instead of PHP-FPM"
symfony deploy   # or upsun push
```

7\. Open your staging environment URL. To open the corresponding environment URL, use the following command:

```shell-session
symfony environment:url
```

8\. Merge to production. When you’re good to go with your application behavior, you can merge it to the `main` production branch, using the following: 

```shell-session
symfony merge
symfony checkout main
git pull upsun main
symfony environment:delete staging
git fetch --prune
```

If you’re willing to use PHP commands directly on the server, like a Symfony console command, you need to use the FrankenPHP PHP-CLI `./frankenphp php-cli`, like the following:

```shell-session
./frankenphp php-cli bin/console 
```

If you want to dive deeper into how to use FrankenPHP or other PHP servers, such as Swoole or RoadRunner, with your Symfony application on Upsun, take a look at this inspiring article from Sergii Dolgushev that is worth the read.

While focusing on installing FrankenPHP, this guide also serves as an introduction to using alternative PHP servers—often considered for the impressive performance they could bring—on Upsun.

The application only needs to boot once and then it remains in memory and stored in the cache, eliminating the need for instantiation with every incoming request. When using PHP-FPM, each time your application runs a PHP script, this PHP script is loaded in memory and then removed at the end of its execution. Furthermore, some alternative servers have embedded asynchronous capabilities that expand the technical horizon even more.

While the performance improvements from using an alternative PHP server like FrankenPHP are promising, it’s essential to proceed cautiously. Simply switching servers won’t solve deep-seated performance issues or other underlying problems—it’s more like a temporary fix for a more significant issue.

An excellent first step is to delve into the application and architecture observability dashboards to identify critical areas that need improvement. Once you thoroughly understand your application’s performance, you can consider moving to an alternative server to enhance efficiency and handling. Find out more about observability here.

Stay up to date on the latest from us over on our social media and community channels: Dev.to, Reddit, our Community. Happy FrankenPHP’ing!

### [Why infrastructure drives the ai revolution | Upsun](https://upsun.com/blog/why-the-ai-era-belongs-to-infrastructure/)

# Stop watching the looms: why the AI era belongs to infrastructure

I live in Manchester, England now. I moved here from Texas last summer (which is its own story), but the thing I wasn't prepared for is how the Industrial Revolution isn't history here. It's the city itself. And if you're American like me, you might need to hear this: the Industrial Revolution didn't start in the US. It started here. Manchester is where the modern world was born.

You see it everywhere. The old cotton mills converted into apartments. Warehouses that once stored raw materials now house coffee shops and coworking spaces. Canal paths where barges carried thirty tons of goods are running trails. The bones of the revolution are still holding the city up. You can't walk three blocks without stepping on a piece of it.

And the longer I live here, the more I realize we're making the same mistake with AI that people made with cotton.

## Everyone's watching the wrong thing

Here's what most people know about the Industrial Revolution: it started somewhere around 1760, someone invented a machine, it changed everything, boom, modern world. The cotton gin. The spinning jenny. The power loom. Pick your favorite invention, credit it with transforming civilization, move on.

But that's not what happened.

The cotton gin was patented in 1794 by Eli Whitney in the American South. The power loom had been around since the 1780s, invented in England. America grew the raw cotton. But it was Manchester that figured out how to turn it into an industry that changed the world. These were extraordinary inventions. They mechanized work that had taken human hands countless hours. But Manchester didn't become the heart of the Industrial Revolution because someone built a clever machine.

**Manchester became Manchester because of the infrastructure that powered the machines.**

The Bridgewater Canal opened in 1761, before the cotton gin even existed. It connected Manchester to the coal mines at Worsley, and suddenly a single horse towing a canal barge could move ten times the cargo of a horse pulling a cart. Then came the Rochdale and Ashton Canals, linking the textile towns across Lancashire and Yorkshire. Then the Manchester Ship Canal in 1894, the largest river navigation canal in the world, which turned a landlocked city into an inland port.

The Liverpool-Manchester Railway opened in 1830. Not the first railway in England. The first inter-city railway _in the world_ to run exclusively on steam power, the first to be double-tracked throughout, the first with a signaling system, the first with a full timetable. It connected Liverpool's port to Manchester's factories, and within decades, a rail network stitched together every major city in the country. The United States wouldn't complete its transcontinental railroad for another 39 years.

By 1830, Manchester had 99 cotton-spinning mills. It was producing so much that Friedrich Engels came here to study the conditions, and some would say his observations became the foundation for modern labor economics. By 1910, Trafford Park had become the world's first industrial park, and the influence had reversed: now American companies like Ford and Westinghouse were coming to Manchester to set up shop.

The machines were the catalyst. But the canals, the railways, the warehouses, the factories, the logistics networks, the signaling systems... **that infrastructure was the revolution.** The machine told you what was possible. The infrastructure made it real.

Sound familiar?

## We're calling it the wrong name

Right now, the world is fixated on LLMs and AI agents the way the history books are fixated on the cotton gin. Everyone's watching the machine.

And look, the machines are extraordinary. I'm not dismissing that. Large language models can reason, write, code, analyze, and synthesize at a scale that was science fiction five years ago. Agents are starting to act autonomously, chaining together tasks, making decisions, operating in the real world. This is genuinely remarkable technology.

But if you think the AI revolution is about the models, you're making the same mistake as someone in 1790 thinking the Industrial Revolution was about the loom.

**The models are the cotton gin.** They're the catalyst. They show us what's possible, that machines can now do cognitive work the way the loom showed us machines could do physical work. But the real revolution? The thing that will actually reshape industries, economies, and how we live? That's the infrastructure being built around them.

People keep calling this "the AI revolution." I think that's like calling the Industrial Revolution "the cotton gin revolution." **It names the spark and ignores the fire.**

What we're actually living through is an industrial revolution. Not a metaphorical one. A literal one. The pattern is identical: a breakthrough invention mechanizes a category of human labor, and then an explosion of infrastructure, systems, and platforms is required to turn that invention into widespread, sustainable transformation. The first time, it was physical labor. This time, it's cognitive labor. But the shape of the revolution is the same.

I've started calling it the **Cognitive Industrial Revolution**. Not because the phrase is catchy, but because it's accurate. It forces you to see the whole picture, not just the machine. It reminds you that revolutions aren't about the invention. They're about the world you have to build around it.

## The part nobody's talking about

Here's what I keep seeing in the AI conversation right now: everyone's debating which model is best, which agent framework will win, whether GPT or Claude or open-source will dominate. Those are interesting questions. They're also the wrong ones.

**The question that matters, the one that mattered in 1780 and matters right now, is: who's building the canals?**

Because AI can write code. It's getting frighteningly good at it. But code isn't an application. An application is code plus hosting, plus routing, plus databases, plus environment management, plus deployment pipelines, plus scaling, plus security, plus observability, plus a dozen other things that have to work together seamlessly for any of it to matter.

AI is about to dramatically increase the volume of software being created. More people building. More ideas shipped. More code written in a weekend than a team used to produce in a quarter. That's the cotton gin moment: the mechanization of code creation.

But every one of those applications needs somewhere to run. Every one of them needs infrastructure. And that infrastructure can't be the same sprawling, duct-taped, manually-configured mess that most companies are running today. **The volume alone would break it.**

This is the part of the revolution that's barely in the conversation. Everyone's racing to build better models and smarter agents. Almost nobody is asking: **when a million new AI-generated applications need to go live next year, what runs them?**

## Manchester knew this before anyone

Here's where the story gets almost too perfect.

Manchester didn't just birth the Industrial Revolution. It birthed artificial intelligence too. And I didn't know that when I moved here.

In June 1948, a machine called the Manchester Baby ran the world's first stored program. It was seventeen feet long, weighed a ton, and took 52 minutes to complete a calculation. It was built at the University of Manchester by Frederic Williams, Tom Kilburn, and Geoff Tootill. Within a year, it evolved into the Manchester Mark 1, which became the prototype for the Ferranti Mark 1, the first commercially available general-purpose computer.

Then Alan Turing moved to Manchester. In 1950, working at the university, he published "Computing Machinery and Intelligence", the paper that asked "Can machines think?" and introduced what we now call the Turing test. **The foundational question of artificial intelligence was asked here. In Manchester.** In the same city where the cotton mills had reshaped the world a century before.

I walk past the buildings where this happened. The same city that built the canals and railways that made the Industrial Revolution possible also built the machines and asked the questions that made AI possible. The DNA of this place keeps producing revolutions.

And both times, the pattern is the same. The breakthrough gets all the attention. The infrastructure does the actual work.

## This is why I'm excited about where I am

I work at Upsun. And what we do maps so precisely onto this pattern that it almost feels like the metaphor was built for us.

Upsun is an application platform. In plain terms: we're the infrastructure layer that takes your code, whether a human wrote it, an AI wrote it, or both, and turns it into a running, scalable, secure application. Hosting, routing, databases, environment management, deployment, scaling, all of it, handled intelligently by design, without the overhead of cobbling together a dozen different services and hoping they play nice together.

**Apps are more than just code.** AI is extraordinary at generating code. But code sitting in a repository isn't an application any more than raw cotton sitting in a warehouse is a shirt. You need the systems, the canals, the railways, the mills, to turn the raw material into something useful.

That's what Upsun is. We're building the infrastructure that makes the Cognitive Industrial Revolution actually work. Not the cotton gin. The canals. Not the model. **The platform.**

And in a world where AI is about to increase the volume of code and applications by orders of magnitude, the infrastructure question becomes the only question that matters. Raw cotton didn't change the world sitting in a warehouse. It changed the world when the canals, railways, and mills connected it to the people who needed it. **The application is the product. Infrastructure is the canal that gets it to the world.** That was true in 1830. It's true now.

## The same mistake, the same opportunity

I walk past the old mills on my way to get coffee. They're beautiful. Red brick, massive, built to last centuries. And they did last. But here's the thing I keep coming back to: the looms are gone. Every single one of them. The machines that started the revolution, the ones the history books obsess over, were replaced and scrapped and forgotten generations ago.

The warehouses are still here. The canals still run. The railways still carry passengers through Piccadilly and Victoria every morning. **The infrastructure outlived the machines by two hundred years.**

I think about that when I think about what we're building now. The models everyone's racing to build today will be replaced (some in a few weeks at this rate). The AI that feels miraculous in 2026 will feel quaint in 2036. Code changes. Tools evolve. The thing that looked like magic becomes a commodity.

But infrastructure lives on. The platforms, the systems, the invisible architecture that connects code to the world and keeps applications running... that endures. Because it was never about the machine. It was about what the machine needed to be useful.

The Industrial Revolution didn't start with the cotton gin. It started with the canal that connected the mine to the city.

The Cognitive Industrial Revolution isn't starting with the LLM. It's starting with the platforms that connect the code to the world.

I happen to live in the city that figured this out first. And I happen to work at the company that's figuring it out again.

### [Why IT teams lose control as dev velocity grows | Upsun](https://upsun.com/blog/why-mid-market-it-teams-lose-control-as-dev-velocity-increases/)

# Why mid-market IT teams lose control as dev velocity increases

At a certain point, faster delivery stops feeling like progress and starts feeling like risk. When engineering teams scale from 10 to 50+ developers, the volume of infrastructure changes, database schemas, environment variables, and networking rules, no longer grows linearly. It scales exponentially.

This is the scaling inflection point where manual governance breaks. What worked for a small team becomes a bottleneck, and IT managers find themselves losing control exactly when the business expects them to support the most growth.

### The bottleneck: manual reviews vs. continuous delivery

Governance usually starts as a human-centric process. A central IT or platform team approves infrastructure requests, reviews changes, and keeps things consistent through tickets and manual checks.

But as deployment frequency jumps from monthly to daily, the human checkpoint becomes an obstacle. Developers, pressured by deadlines, naturally find workarounds. They write helper scripts to bypass slow provisioning or connect autonomous AI agents to internal APIs outside the security perimeter.

This isn't reckless behavior; it’s a response to a structural mismatch. You cannot govern decentralized, continuous execution with centralized, manual mechanisms.

### Why visibility disappears when speed increases

It seems counterintuitive: faster delivery should produce better automation and data. However, if the platform layer is inconsistent, speed creates blind spots.

When every team manages their own "bespoke" environment setup, you lose a single source of truth. IT ends up with plenty of signals - logs, alerts, and tickets - but no structural visibility. Control becomes performative: you have dashboards and policies, but they are too far removed from the actual flow of delivery to shape it in real time.

### The solution: governance at the speed of delivery

Mid-market teams don't need more approval layers; they need governance that is built into the infrastructure. This requires shifting from "Policy as a PDF" to "Governance as Code."

**1\. Built-in guardrails, not manual gates:** When application settings, services, and routing are defined in code, compliance is a deterministic outcome of the build process. By using version-controlled configuration, teams work from an auditable baseline. Developers get self-service autonomy, but only within the limits the platform enforces.

**2.** **Git-driven visibility****:** Instead of reviewing every action by hand, IT can leverage Git-driven workflows. When every infrastructure change is a commit, you gain a traceable path of how environments evolve. Preview environments, tied to specific pull requests, allow IT to see exactly what is being shipped in a realistic context before it ever touches production.

**3\. Shifting left on compliance:** Governance breaks when it depends on spotting issues after the work is moving. By embedding security and operational standards into the platform, you catch risky changes during the build phase. This reduces friction for developers and eliminates the temptation to seek workarounds.

### Control that scales

The strongest IT teams do not stay in control by slowing developers down. They build systems that allow for high velocity within clear, enforceable boundaries. This treats governance as infrastructure, not paperwork.

If your team feels less in control as engineering gets faster, the answer isn’t to tighten the manual checks—it’s to adopt a model that scales with how software is delivered today.

### Next steps

Closing the governance gap starts with moving from reactive oversight to structural control.

-   **Audit your human checkpoints:** Identify where manual approvals are creating the "Shadow IT" workarounds.
-   **Standardize the delivery path:** Use `.upsun/config.yaml` to bring application and service configuration into code.
-   **Request a technical demo:** Ready to stop the shadow IT cycle? **Request a technical demo** to see how Upsun codifies your governance and reclaims your team's velocity.

### [Scaling innovation: Beyond infrastructure to empower adaptability | Upsun](https://upsun.com/blog/scaling-innovation/)

# Scaling innovation: the next frontier in tech adaptability

In the tech industry, we often emphasize the importance of scaling infrastructure to meet customer demands. Yet, as the past few years have demonstrated, particularly with the explosive adoption of artificial intelligence (AI), it’s clear that scaling technical resources alone isn’t enough. Organizations must also focus on scaling innovation—the ability to adapt quickly, embrace new ideas, and implement cutting-edge solutions at a pace that matches or exceeds market demands.

The question isn’t just whether your app can auto-scale to meet traffic spikes. It’s whether your organization can “auto-scale” its innovation capabilities to seize opportunities and address challenges as they arise. To achieve this, businesses need a proactive strategy that prioritizes developer empowerment, streamlined collaboration, and forward-looking tools.

## **Why scaling innovation is critical**

Scaling innovation means creating an ecosystem where new ideas can flourish and be implemented rapidly without compromising quality or stability. Here’s why this focus is more crucial than ever:

1.  Pace of Technological Advancement: Emerging technologies, especially in AI, are transforming industries at an unprecedented rate. AWC predicts that by 2030, AI could contribute up to $15.7 trillion to the global economy. Organizations that fail to integrate these innovations quickly risk falling behind competitors.
2.  Demand for Customization: Customers now expect hyper-personalized experiences, which require businesses to integrate advanced tools and frameworks seamlessly. This shift places immense pressure on development teams to innovate at speed.
3.  Competitive Landscape: The ability to innovate rapidly has become a key differentiator. Companies that can’t keep up with this pace risk losing market share to more agile competitors.

## **Strategies to scale innovation effectively**

### Build a flexible technology stack:

A flexible and modular tech stack is foundational to scaling innovation. Unlike rigid, monolithic systems, a dynamic stack allows businesses to incorporate emerging technologies without overhauling their entire infrastructure. For instance, containerization tools like Docker and Kubernetes enable seamless deployment of new applications, while APIs ensure interoperability between diverse tools and platforms.

Flexibility ensures that teams can integrate advancements—whether AI models, data pipelines, or microservices—as soon as they become available.

### Empower your developers:

Innovation begins with your development team. Empowering developers involves:

-   Providing access to cutting-edge tools and frameworks.
-   Encouraging experimentation through fail-safe environments.
-   Promoting a culture that values curiosity and risk-taking.

For example, companies that adopt hackathon-style initiatives report a 20% increase in developer engagement and a measurable uptick in successful innovation (source). Creating an environment where developers feel supported and encouraged can unlock their full creative potential.

### Invest in collaboration and communication tools:

Collaboration is the backbone of scalable innovation. With remote and hybrid work models becoming the norm, ensuring seamless communication across teams is vital. Tools like Slack, Microsoft Teams, and GitLab enable synchronized efforts, while advanced project management software helps track progress and align objectives.

A McKinsey study found that organizations with effective collaboration strategies are 1.5 times more likely to achieve digital transformation goals (source). These tools reduce silos and ensure that all team members have the insights they need to contribute effectively.

### Leverage preview environments and observability tools:

Preview environments—isolated replicas of production systems—allow developers to test changes in a risk-free setting. This approach ensures that innovations can be vetted thoroughly before deployment, minimizing disruptions.

Observability tools further enhance this process by providing real-time insights into system performance. Leaders in observability report 2.6x faster resolution times for issues and significantly improved developer productivity (source). Tools like Splunk, New Relic, and Speedscale help teams identify bottlenecks and optimize deployments before they affect users.

## **The concept of ‘autoscaling’ innovation**

Just as applications can autoscale to handle increased traffic, organizations must design systems and processes that can “autoscale” innovation. This means:

-   Automating Repetitive Tasks: Freeing up developers to focus on high-value projects by automating routine operations, such as CI/CD pipelines and performance monitoring.
-   Implementing Scalable Processes: Ensuring that workflows can expand without bottlenecks as teams grow or as new technologies are adopted.
-   Fostering Continuous Learning: Encouraging teams to stay ahead of industry trends through ongoing education and knowledge sharing. Companies that invest in training see a 24% higher profit margins (source).  
     

## **Measuring the impact of scalable innovation**

Organizations that prioritize scaling innovation experience tangible benefits, including:

-   Accelerated Deployment Cycles: Businesses that adopt agile methodologies and scalable tech stacks can reduce time-to-market for new features.
-   Increased Developer Productivity: Empowered and well-supported developers contribute to a rise in project completion rates.
-   Higher Customer Satisfaction: Rapidly deployed innovations, such as personalized AI-driven solutions, enhance customer experiences and build loyalty.

## **Flexibility to explore new languages and frameworks**

One often overlooked aspect of innovation is the need to explore and adopt new programming languages or frameworks as technology evolves. For example, the rise of Python paralleled the surge in AI and machine learning advancements. By enabling developers to experiment with new tools and languages, organizations not only stay on the cutting edge but also attract top talent who bring fresh perspectives and diverse skill sets.

A rigid platform or infrastructure can stifle this flexibility, locking teams into specific technologies that may become outdated or limit innovation. Upsun solves this by supporting multiple programming languages, frameworks, and runtime environments. This flexibility allows organizations to:

-   Rapidly Prototype New Solutions: Experiment with emerging tools without overhauling existing infrastructure.
-   Expand Talent Pools: Hire experts with diverse technical backgrounds and integrate their skills seamlessly.
-   Stay Ahead of Trends: Adopt the latest frameworks and paradigms to meet evolving business and customer needs.

This adaptability ensures that teams are not constrained by legacy decisions, enabling them to pursue the most innovative solutions and stay competitive.

## **Upsun: the foundation for scalable innovation**

Upsun provides the infrastructure and tools to make scalable innovation not just a possibility but a reality. By offering a platform-as-a-service (PaaS) designed for agility, Upsun empowers organizations to:

-   Quickly Integrate Emerging Technologies: With support for multiple programming languages, microservices, and seamless APIs, Upsun enables businesses to adapt their tech stack with ease.
-   Enhance Developer Productivity: Features like automated CI/CD pipelines, instant preview environments, and integrated observability tools give developers the freedom to experiment and innovate without delays or risks.
-   Foster Collaboration Across Teams: Upsun’s unified management interface and robust collaboration features ensure that business and technical teams can work in harmony, aligning innovation efforts with strategic goals.
-   Scale Seamlessly: Built-in auto-scaling capabilities and flexible resource management allow organizations to grow without overhauling their infrastructure, ensuring that innovation keeps pace with demand.

By removing the friction typically associated with digital transformation, Upsun allows organizations to focus on what truly matters: delivering value to their customers and staying ahead of the competition.

## **Conclusion: innovation as a core competency**

In today’s fast-evolving tech landscape, scaling innovation is no longer optional. It’s a core competency that determines whether organizations thrive or struggle to keep up. By focusing on flexible tech stacks, empowering developers, investing in collaboration tools, and leveraging advanced testing environments, businesses can create a culture where innovation isn’t just possible—it’s inevitable.

Ultimately, the question isn’t whether your organization can scale its infrastructure. It’s whether you can scale your innovation to meet the demands of tomorrow. The future belongs to those who can innovate—and Upsun provides the platform to help you do just that.

Ready to scale your innovation? Learn more about how Upsun empowers your teams.

### [Why developer workflow fragmentation slows teams | Upsun](https://upsun.com/blog/developer-workflow-fragmentation-and-whats-really-happening-behind-the-scenes/)

# Developer workflow fragmentation and what’s really happening behind the scenes

In the current landscape of enterprise software delivery, a profound paradox has emerged: as the variety of specialized development tools and cloud services increases, the actual velocity of innovation frequently stagnates.

For IT leaders, this phenomenon is known as **developer workflow fragmentation**. 

It’s a state where parallel, unstandardized processes create a pervasive "operational drag" that consumes the very agility these tools were intended to provide. 

While the adoption of diverse toolsets often begins as an attempt to empower teams, the resulting fragmentation leads to a compounding cost of complexity that compromises reliability and inflates your team's "mean time to recovery" (MTTR).

To solve this, we must first visualize what is actually happening inside engineering teams when every project evolves its own workflow independently.

## The hidden factory of software development

The term **"hidden factory"** describes the portion of your capacity that exists solely to rework defects, manage waste, and "glue" together disparate systems. It often remains unnoticed by traditional management because it is buried in the day-to-day execution of engineering tasks.

When you visualize a fragmented workflow, you aren’t looking at a straight line from code to production. Instead, you see a web of "waiting stations" and "rework loops."

Research indicates that developers lose an average of 12 hours per week (nearly 30% of their total capacity) on these non-value-added activities. This includes waiting for manual environment provisioning, debugging configuration drift, and manually recreating production conditions. 

For an IT manager, this is a "shadow tax" on your roadmap that never appears in a Jira ticket but effectively reduces your team's headcount by a third.

_**For more info:** If your team is stuck in the hidden factory, the culprit is usually the "plumbing" of cloud primitives._ _Learn why cloud primitives quietly drain developer time__._ 

## The agility paradox: why fragmentation feels harmless at first

Fragmentation rarely starts with a bad decision. In fact, it usually starts with an "agile" one.

A small team needs to move fast on a new project, so they bypass the central infrastructure standards to set up their own bespoke CI/CD pipeline or cloud instance. 

At first, this feels like autonomy. They ship the first version quickly, and the lack of standardization feels harmless, perhaps even superior to the "slow" central process.

However, this creates the **Agility Paradox**. 

What worked for one team becomes a "coordination collapse" when scaled to ten teams. As these parallel workflows diverge, the institutional knowledge required to maintain them becomes tribal. When a senior engineer leaves or a cross-team dependency breaks, the "freedom" of the initial setup reveals itself as a maintenance trap. 

Data suggests that up to **40% of an organization's automation budget** is eventually consumed just by maintaining these inconsistent, legacy scripts rather than building new value.

## Why visibility alone isn't a governance strategy

IT leaders often respond to shadow IT and fragmentation by attempting to "gain visibility" through more dashboards and reporting tools. But knowing fragmentation exists doesn’t fix the operational drag.

The problem is structural, not just informational. When every team has its own way of handling authentication, database migrations, and secret management, your MTTR (Mean Time to Recovery) is held hostage by complexity. 

If an environment in your "Shadow AI" project differs even slightly from production, a developer can spend an entire day chasing a bug that only exists because of environment drift.

Standardization isn't about removing autonomy; it's about providing **Golden Paths**. 

A Golden Path is a pre-architected, supported route for developers to get from code to production. It absorbs the "boring" parts of infrastructure, networking, scaling, patching, so that developers can focus on the unique logic of the application.

_**For more info:** The key to a Golden Path is ensuring that environments never drift from the source of truth. See:_ _Git-driven environments: consistent builds without the drift._ 

## The economic case: quantifying the context-switching tax

For the IT Middle Manager, the most brutal cost of fragmentation is the **context-switching tax**. 

Research shows that when technical leaders or senior engineers have to oversee five or more different deployment styles, performance remains impaired for 30 to 60 minutes after every switch. This "attention residue" makes it impossible to focus on high-level strategy or innovation.

For a 50-person engineering team, the combined cost of tool overload and fragmented workflows can reach nearly $1 million annually in wasted productivity.

By implementing a standardized backbone like Upsun, you aren't just "fixing IT." You are reallocating that $1 million back into your roadmap. 

You transition your senior engineers from being "infrastructure mechanics" back into "application architects." When the platform handles the operational layers, your team moves from a "build and maintain" posture to a "deploy and innovate" posture.

## Moving from chaos to clarity

The organizations that will win the race to scale AI and modernize their stacks are those that treat their delivery workflow as a first-class product.

Standardized environments on Upsun allow you to codify your application intent once and let the platform handle the execution across any cloud provider. 

You lose the infrastructure noise, you eliminate the hidden factory, and you finally get a clear map of your organization's technology. By defining everything in `.upsun/config.yaml`, you turn your fragmented Shadow IT into a governed, scalable asset.

## Next steps:

Dismantling the "hidden factory" isn't a one-day task, but it starts with reclaiming your team's focus. If you're ready to move from chaos to clarity, here is how to begin:

-   **Audit your "Sprint 0":** Calculate how much time your team actually spends on manual environment setup and "glue work" before a single line of feature code is written. Learn how to automate these fast delivery loops.
-   **Establish your "Golden Path":** Define a single, version-controlled configuration for your most critical applications using **.upsun/config.yaml**. By codifying your application intent, you ensure that every environment is a production-perfect clone.   
    You can **start a free trial** to test your configuration and deploy your first standardized environment in minutes.
-   **Eliminate the context-switching tax:** Centralize your orchestration so your senior engineers can stop pivoting between 10+ different consoles. You can transition your team from "infrastructure mechanics" back into application architects by adopting a unified cloud application platform.

## Ready to stop the shadow IT cycle?

**Request a technical demo** to see how Upsun codifies your governance and reclaims your team's velocity.

### [Seven warning signs of a governance crisis | Upsun](https://upsun.com/blog/seven-early-warning-signs-youre-heading-toward-a-governance-crisis/)

# Seven early warning signs you're heading toward a governance crisis

Governance failures rarely start with a major outage or a failed audit. 

They start with small, localized signals that teams treat as isolated annoyances. By the time a crisis becomes visible, the structural breakdown is already expensive to fix.

If you are in IT leadership or platform engineering, you have likely seen these signs. The risk is ignoring them until they consolidate into a systemic failure.

### 1\. Your environments don’t match

Environment drift is the most reliable lead indicator of a governance breakdown. 

It happens when production is patched directly to fix an urgent issue, but that change never makes it back to staging. Over time, your pre-production environments stop predicting production behavior. 

Deployments fail not because of the code, but because the infrastructure underneath has quietly diverged.

### 2\. Ownership is an accountability vacuum

When something fails at 2 a.m., how long does it take to identify the owner? 

If the process involves a chain of Slack messages and someone asking, "is this us or them?", your structure hasn't made ownership obvious. 

In well-governed organizations, ownership is embedded in the deployment metadata, not a manual spreadsheet.

### 3\. Critical knowledge is siloed

If your recovery process depends on one specific engineer who remembers a legacy config choice, you aren't running governed infrastructure. 

Undocumented knowledge is invisible risk. It creates "don't touch" zones in your architecture and ensures that as you scale, your risk concentrates rather than distributes.

### 4\. Compliance is a manual reconstruction project

Ask your team a simple question: "Show me the review and approval for this specific commit in production." If answering takes days of digging through tickets and logs, you have an evidence problem. When compliance isn't embedded in daily workflows, every audit becomes a fire drill that halts development velocity.

### 5\. Governance is purely reactive

If new controls only appear after an incident or a regulator's finding, your governance is shaped by yesterday’s failures, not tomorrow’s risks. This matters more as AI tools enter workflows; if governance cannot keep pace with the speed of AI-assisted change, gaps only become visible after the damage is done.

### 6\. Shadow IT is a workaround for slow IT

When developers use unapproved tools or store credentials locally, it is usually because the "approved" path is too slow. Shadow IT is a signal that your governance has become a bottleneck. The fix isn't tighter manual control - it’s embedding guardrails into the workflows developers already use so the safe path is also the fastest one.

### 7\. Dashboards reflect activity, not reality

A "green" dashboard can be misleading. Many teams monitor for visible failure (uptime) but not for verified completeness (compliance/security). If your reporting cannot prove that a task was completed correctly under the right controls, you are operating on assumptions, not evidence.

### What these signs are telling you

Individually, these signs feel manageable. Collectively, they point to governance that has failed to scale with the speed of delivery. The solution is to move from reactive firefighting to structural control.

-   **Standardize to eliminate drift:** Define your critical infrastructure in a version-controlled configuration.
-   **Automate the audit trail:** Capture approvals and access events as work happens, turning compliance into a deterministic outcome of the build.
-   **Enforce parity by design:** Use preview environments to ensure staging is an exact clone of production state, eliminating false signals.

The goal is to give teams clear guardrails that keep pace with delivery. If more than two of these signs feel familiar, it is time to act before the crisis forces the issue.

## **Ready to stop the shadow IT cycle?** 

**Request a technical demo** to see how Upsun codifies your governance and reclaims your team's velocity.

### [The governance playbook for mid-market IT teams | Upsun](https://upsun.com/blog/the-governance-playbook-for-mid-market-it-teams/)

# The governance playbook for mid-market IT teams

The contemporary IT landscape for mid-market organizations is defined by a paradoxical pressure: the mandate to accelerate digital transformation and AI integration while operating under the most stringent cost discipline observed in decades. 

For firms positioned between the nimble agility of startups and the vast resources of global enterprises, the "complexity of data lineage" and "legacy modernization paralysis" have emerged as primary barriers to progress. 

As the era of unchecked digital spending concludes, the strategic priority for IT leadership has shifted from pure growth targets to "Maximizing Tech Value" and quantifiable Return on Investment.

Navigating this transition requires a fundamental restructuring of IT governance, moving away from traditional "gate-based" control models toward a system of automated "guardrails" that unify workflows without impeding the velocity of delivery.

## The taxonomy of control: distinguishing gates from guardrails

At the heart of modern engineering friction lies a misunderstanding of how control should be exerted within a delivery pipeline. 

Historically, IT governance has relied on **"gates"**: binary, blocking mechanisms that function as artificial checkpoints. Gates fundamentally depend on external control and manual intervention.

In contrast, **"guardrails"** mark safe pathways for development, providing continuous guidance within predefined boundaries. 

While a gate stops a developer at the end of a process, a guardrail steers them toward the correct configuration from the beginning. 

For lean mid-market teams, this paradigm shift is essential to reduce the "operational drag" of manual approvals. When developers perceive governance as a hurdle, they inevitably seek workarounds; the very definition of Shadow IT. 

By replacing gates with guardrails, IT leaders transform from "gatekeepers" into "platform enablers," fostering an environment where the right thing to do is also the easiest thing to do.

## Strategic centralization: the high-ROI beachhead for governance

To regain control of a fragmented cloud estate without becoming a bottleneck, IT leaders must identify the highest ROI area for centralization.

Mandating specific IDEs or local tools often leads to resistance; however, centralizing the **Configuration-as-Code (CaC) layer** provides a non-intrusive beachhead for governance.

On Upsun, the entire application stack, runtime, services, and routing, is defined in a single, version-controlled file: **.upsun/config.yaml**. 

By centralizing intent rather than mandating specific tools, IT gains a "System of Record" that enforces security and cost-caps across every project automatically. For a full breakdown of how to define these services, see the **Upsun Service Configuration guide**.

This declarative approach allows you to satisfy a SOC2 auditor with automated audit logs rather than manual evidence gathering. It creates a unified cloud application platform where security policies are part of the code, not a separate, ignored PDF document.

## Principles before policies: how to implement "guardrails"

Mid-market IT teams often fail when they try to mandate a one-size-fits-all toolchain because they lack the massive DevOps headcount of enterprise giants. 

A pragmatic playbook focuses on principles and outcomes rather than rigid tool mandates. Instead of a 50-page security PDF, establish a **Golden Path**: a pre-architected route that encoding organizational best practices into developer-friendly templates.

**The "Trojan Horse" Strategy:** The secret to voluntary adoption is providing a feature developers actually want (like production-perfect preview environments) and embedding governance inside them. 

IT leaders can define standardized templates for their teams using Upsun’s project initialization workflows to ensure every new microservice starts with the correct security headers and resource allocation. 

By providing high value (instant environments), IT secures high compliance (data safety) through the use of build and deploy hooks that automate validation before code ever reaches production.

## Balancing autonomy and consistency

The primary friction point in mid-market IT is the tension between developer autonomy and organizational consistency. 

Developers need the freedom to choose the right language or framework for a specific microservice, but IT needs to ensure those services don't become unmanageable "snowflakes."

The Golden Path solution resolves this by providing "freedom within guardrails." It allows for an "escape hatch" where teams with specialized needs can deviate from the standard path, provided they still adhere to the centralized configuration layer. 

This ensures that even "Shadow AI" projects or experimental departmental apps remain visible and governed within the primary IT control plane. Consistency is maintained at the infrastructure and security level, while autonomy is preserved at the application level.

## Measuring success: beyond the "rejected deploy"

Measuring governance by how many deployments you block is a counter-productive metric that drives Shadow IT into the shadows. 

Success should be measured by the reduction of friction and the speed of recovery. Key metrics include:

-   **Lead Time for Changes:** Does governance slow down delivery? In an automated system, it should remain neutral or even improve.
-   **Mean Time to Recovery (MTTR):** Do standardized environments allow for faster incident response? Unified logging and predictable resource behavior significantly lower MTTR.
-   **Capacity Buy-back:** How many hours of senior engineering time were redirected from infrastructure maintenance to product innovation? This is the ultimate proof of governance ROI.

## Next steps: From blocker to enabler

Governance doesn't have to be a feature freeze. It is a strategic capability that reduces risk while increasing delivery speed. If you're ready to unify your workflows without bureaucracy, start here:

-   **Define your guardrails:** Move your security and resource policies out of static documents and into `.upsun/config.yaml`.
-   **Implement the "Trojan Horse":** Provide your team with automated preview environments that bake in data sanitization and compliance by default.
-   **Test the playbook:** **Start a free trial** to see how automated governance reduces your team's cognitive load while improving your security posture.
-   **Unify your control plane:** Stop managing 10+ disparate consoles and adopt a unified cloud application platform.

## Ready to stop the shadow IT cycle?

**Request a technical demo** to see how Upsun codifies your governance and reclaims your team's velocity.

### [Instant environment cloning ends the triage tax | Upsun](https://upsun.com/blog/how-instant-environment-cloning-reduces-the-triage-tax/)

# How instant environment cloning reduces the "Triage Tax"

The most expensive hour in software engineering is the hour spent trying to figure out why a bug exists in production that doesn’t exist anywhere else.

For many teams, the first 70% of a debugging cycle isn't spent fixing code; it is spent on "plumbing." 

This is the time lost to reproducing the issue, wrestling with environment drift, and sanitizing datasets just to get to a starting line. When your staging environment is a "shared waiting station" that everyone is afraid to break, your developers work with a hand on the brake.

True velocity isn't about how fast you can type: it’s about how fast you can fail without consequences. By moving to instant, production-perfect cloning, teams eliminate the "Triage Tax" and move directly to the fix.

### The branching breakthrough: killing the "waiting station"

In a traditional workflow, the staging environment is a bottleneck. If one developer is using staging to test a new feature, another cannot use it to triage a production fire without risking a collision. 

This creates "waiting stations" where senior talent sits idle while environments are manually wiped, reset, or synced.

This is where the transition to a modern platform becomes a strategic advantage. Instead of a shared, static staging server, high-velocity teams move to a one environment per Git branch model. 

This ensures that the infrastructure scales with the team’s needs rather than limiting them. Many organizations accelerate this further by standardizing their setup with debugging template packs to ensure every clone follows a verified blueprint.

To truly eliminate the "it works on my machine" excuse, teams must move toward a deterministic architecture that makes every bug reproducible by matching services, configuration, and data at the platform level.

_**For more info:**_ _Understand the technical mechanics behind environment isolation._ _Explore Preview Environments on Upsun_.

### The forensic snapshot: removing the mental checklist

When a developer starts triaging a bug on Upsun, they remove the "mental checklist" of variables. 

You aren't guessing if the Node.js version or the database schema in staging matches production because you aren't using a "similar" environment: you are using a forensic snapshot.

By using the `.upsun/config.yaml` to define the entire stack (the runtime, the database version, and the service mesh), Upsun allows you to spin up a dedicated, isolated clone of the production environment in seconds. 

Because Upsun uses copy-on-write technology, even multi-terabyte databases are available almost instantly without the cost or time of a physical data migration.

_**For more info:**_ _Learn how to codify your infrastructure so every clone is a perfect replica._ _Read the YAML configuration overview__._

### The safety paradox: "move fast, break things" (safely)

There is a psychological friction to debugging in a shared environment. Developers work slower when they are afraid that an "experimental" fix might accidentally trigger a production email, corrupt a shared test database, or take down a service others are using.

We call this the Safety Paradox: developers work significantly faster when they have the freedom to be bold with their changes. 

In a 100% isolated Upsun clone, the risk to production resources or availability is zero. 

A developer can try an aggressive refactor or drop a table to test a migration without reservation. This level of isolation is especially critical when debugging non-deterministic AI hallucinations, where production-state data is the only way to find the root cause.

### Sanitization at the speed of Git

One of the biggest blockers to realistic debugging is data compliance. In manual workflows, scrubbing a production database for developer use can take hours, leading teams to use "junk data" that fails to replicate the bug.

Upsun changes this math through automated hooks. 

Organizations define sanitization scripts in their configuration that run automatically during the cloning process. 

As the environment is branched, PII is scrubbed and emails are neutralized before the developer ever gains access. This provides a "production-perfect" dataset that is safe, compliant, and ready for immediate debugging.

### Next steps: reclaim your triage time

If your team is still wrestling with "it works on my machine" bugs, it’s time to modernize your triage path.

1.  **Audit your "Environment Prep" time:** Track how long it takes a developer to go from an "incident alert" to having a fully functional, data-synced environment.
2.  **Establish a cloning workflow:** Use the Upsun CLI to create a new branch from production. Use upsun checkout to see how fast you can reproduce a complex state.
3.  **Eliminate the "Shared Staging" bottleneck:** Transition your team to a model where every ticket starts with a fresh, isolated clone. **Watch how this workflow looks in practice here**.

### Frequently asked questions (FAQ)

**How does cloning an environment differ from just running a local Docker container?**

Docker copies the code and the runtime, but it doesn't easily replicate the data state or the cloud service mesh. Upsun clones the entire stack, including the exact service configurations and scrubbed data, ensuring 100% parity.

**Does cloning a large database take a long time?**

No. Upsun uses copy-on-write technology. The data isn't physically copied until you make a change to it. The environment is available almost instantly, regardless of the database size.

**How do we ensure developers don't accidentally send real emails from a clone?**

By using Upsun's worker and service configurations, you can route outgoing mail to a "null" driver or a testing tool like Mailhog in every non-production environment automatically.

**What happens to the clones once the bug is fixed?**

They are disposable. Once the fix is merged into production, the branch can be automatically deleted, ensuring you only pay for the resources you are actively using.

**Is it safe to have production-like data in these branches?**

Yes. Every Upsun branch is protected by the same enterprise-grade security and access controls as production. Automated hooks ensure sensitive data is scrubbed before the environment is reachable.

### [5 ways platforms reduce shadow IT | Upsun](https://upsun.com/blog/5-ways-for-platforms-to-reduce-shadow-it/)

# 5 ways for platforms to reduce shadow IT

### The reality check: the hidden factory of fragmented IT

Is your team losing 12 hours a week to manual glue work? 

The blunt technical reality is that shadow IT does not usually start with malicious intent: it starts with a developer trying to move faster than the central IT ticketing system allows. When the process for requesting a new PostgreSQL instance takes three weeks and involves four different departments, highly productive contributors bypass friction by spinning up unvetted, off-the-books cloud resources to meet a deadline. 

This decentralized adoption creates an invisible architecture of orphaned S3 buckets, dormant test environments, and legacy database snapshots that operate outside routine patching cycles.

This is **the "Hidden Factory" of IT management**: a massive, unmeasured layer of rework loops, manual adjustments, and off-the-books problem solving that **consumes a significant portion of a company’s total capacity** without adding a single unit of value to the end product. 

In software development, this translates to the "glue work" that keeps everything from falling apart but remains invisible to leadership: coordinating between teams, unblocking stuck tasks, and manually syncing environments.

Modern platform engineering aims to solve this by making the "right way" the "easy way." By utilizing a platform like Upsun, organizations can transform their governance from "Policy as a PDF" into "**Policy as Code,**" ensuring that every resource is versioned, reviewable, and automatically enforced through the .upsun/config.yaml file.

### 1\. Moving from policy as a PDF to policy as code

Traditional IT governance relies on documentation: massive PDF files and static spreadsheets that outline security standards, compliance requirements, and naming conventions. The failure of this model is rooted in its **"manual interpretation" requirement**. 

A security policy sitting in a folder on a SharePoint drive does nothing to prevent a developer from misconfiguring a public-facing bucket at 2:00 AM on a Friday. 

Policy-as-code (PaC) is a massive improvement because it treats policies with the same lifecycle management rigor as application logic.

#### **The enforcement gap and automation**

PaC represents a fundamental shift where rules are written in machine-readable languages and integrated directly into the deployment pipeline. 

On the Upsun platform, this is achieved through the .upsun/config.yaml file. Instead of a developer reading a document on how to configure a PHP runtime or a Redis service, the platform enforces the configuration defined in the repository. 

This approach ensures consistency in security standards across all cloud resources and mitigates protection gaps caused by human error.

When policy is codified, it becomes part of the platform logic. 

If a security team requires that all production databases use a specific version of MariaDB, this can be hardcoded into the platform's templates. Any attempt to deploy a version that violates this policy results in a build failure. 

Timely scans of these code-based configuration files help identify compliance missteps, incorrectly coded credentials, and misconfigurations before they escalate into larger issues.

#### **Reducing the hidden factory of rework loops**

The hidden factory thrives on rework: correcting defective outputs or over-processing work. In a PDF-based governance model, rework occurs when a security audit discovers a misconfiguration three months after deployment. The developer then has to pivot back to old code, reconstruct the context, and fix the issue. This contextual pivot is a major drain on productivity. 

By shifting security "left" into the .upsun/config.yaml, the feedback loop is reduced from months to seconds. The platform acts as a continuous automated auditor, ensuring that only compliant code reaches production.

### 2\. Centralizing the data layer to eliminate shadow databases

Shadow data is the ultimate “known unknown”.

Research indicates that approximately 15% of all enterprise data exists as shadow data: information copied, backed up, or stored outside the formal management framework. 

These repositories often contain personally identifiable information (PII) or intellectual property that attackers actively seek. Shadow data frequently hides in forgotten cloud storage, dormant test environments, or personal folders.

#### **The database provisioning bottleneck**

Developers often create shadow databases because the official provisioning process is too slow. 

In a traditional setup, creating a database involves multiple manual steps: filing a ticket, waiting for a cloud admin, requesting a security review, and manually configuring connection strings. 

On Upsun, this bottleneck is removed through managed service definitions in the .upsun/config.yaml. A developer can add a database by adding a few lines of YAML code.14

```yaml
services:
  db:
    type: postgresql:15
    disk: 1024
```

This simple block replaces a three-week ticketing cycle with a three-second code change. Because the platform handles the provisioning, the database is automatically created within the organization's governed perimeter.

#### **Secure internal networking and the service mesh**

By defining relationships in the YAML configuration, the platform automatically handles the "wiring" between the application and the service. These services are not exposed to the public internet: they communicate over a secure, isolated internal network. 

This prevents developers from accidentally leaving a database open to the world, a common cause of data breaches in unmanaged shadow IT setups.

#### **Data cloning and sanitization for realism**

One of the primary drivers of shadow data is the need for "realistic" testing. 

Developers often clone production data into unmanaged dev environments to debug issues. Upsun solves this through "production-perfect clones”. 

Every Git branch can spin up an isolated environment that inherits a copy of the production data. 

Crucially, this inheritance includes built-in sanitization workflows. Organizations can define hooks that automatically scrub PII from the data as it is cloned, ensuring that developers work with realistic but safe data sets. 

This satisfies regulatory requirements like GDPR and HIPAA without requiring manual data preparation.

### 3\. Inheritance: the secret weapon of platform governance

Governance at scale fails when it requires linear human intervention. If an IT manager must approve every environment change for 500 developers, that manager becomes a massive bottleneck. 

The secret weapon of high-velocity engineering organizations is "inheritance."

#### **Scaling via hierarchical configuration**

In the Upsun ecosystem, inheritance describes how resources and configurations propagate from a parent environment to child environments. 

When a developer creates a new feature branch, that branch automatically inherits the entire stack:

-   **The runtime configuration**: The exact PHP, Node.js, or Python versions defined in the parent.
-   **The service mesh**: The same database, cache, and search index configurations.
-   **Resource allocations**: CPU, memory, and disk settings.

This hierarchical model ensures that the "Golden Path" established by IT is the path of least resistance. 

Developers do not need to "go off-road" to find the resources they need because those resources are automatically provided and inherited from the production baseline.

#### **Governance without "Who owns staging?" pings**

The hidden factory is often fueled by "waiting stations": delays in processes due to various inefficiencies. 

Waiting for a shared staging environment to be free or waiting for a manual data sync is a non-value-adding activity. Inheritance eliminates these waiting stations by providing isolated, production-identical environments on demand for every branch. 

This ensures 100% parity. If a configuration works in the preview environment, it will work in production because the infrastructure is defined by the same code and inherited from the same source of truth.

### 4\. Unified platforms as the single source of truth for security

During an active breach investigation, the greatest enemy of the security team is "**the investigative gap.**"

Analysts often find themselves trapped in a reactive loop, hopping between fragmented tools and disconnected spreadsheets to reconstruct what happened. Traditional tools are often designed to alert you once a threat is already inside, leaving analysts to manually reconstruct infrastructure relationships.

#### **Closing the pivot gap with deterministic data**

A unified platform acts as a "single source of truth" by consolidating all infrastructure metrics, application logs, and access records into one deterministic view. 

Because every resource on Upsun is provisioned via Git-driven YAML, the audit trail is absolute and verifiable.

-   **Version control for infrastructure**: Security teams can see exactly who changed a configuration, when it was changed, and what the state of the infrastructure was at that precise moment.
-   **Immutable logs and triage**: Application and access logs are secured and immutable, preventing attackers from tampering with the evidence after a compromise.
-   **Deterministic context**: The .upsun/config.yaml serves as self-documenting code. There is no need to guess the network layout because it is explicitly defined in the repository.

#### **Accelerated triage and incident response**

In a breach, every second counts. A unified platform reduces the **Mean Time to Triage (MTTT)** by providing the forensic context necessary to understand a threat immediately. 

Instead of querying multiple cloud providers to find an orphaned S3 bucket, analysts can view the entire fleet of applications and services from a single console.

### 5\. Faster onboarding via platform-led governance

The time it takes for a new hire to make their first productive commit is a key indicator of organizational efficiency. 

In organizations plagued by shadow IT and fragmented tools, this process can take three weeks or more. 

Cognitive load increases when developers must frequently interact with operations teams for infrastructure changes or resolve permission issues.

#### **Reducing cognitive load with golden paths**

The "agility paradox" suggests that giving developers too many choices leads to cognitive overload. 

When a new developer has to learn how to provision a local database, configure a CI/CD pipeline, and navigate a complex security policy, they are not writing code. Platform-led governance uses "Golden Paths" to provide a paved road from code to production. 

By using standardized templates and automated scaffolding, new hires can spin up a sandbox environment in less than a day.

#### **The self-service revolution**

When governance is built into the platform, developers can be granted autonomy without increasing risk. A developer can "self-service" a new microservice or an AI-augmented application because the guardrails are already programmed into the system. 

This eliminates the need for constant back-and-forth communication, removing the "manual glue work" that bloats development cycles.

### DIY vs. Upsun: the cost of the hidden factory

Building an internal developer platform (IDP) from scratch is a massive undertaking that often leads to "Day 50" problems: once the initial Golden Paths are built, the platform team becomes a bottleneck for every custom request. 

Maintenance of a DIY platform consumes engineering resources that could be spent on product innovation.

### Next steps: ending the shadow IT cycle

Shadow IT is not a personnel problem: it is a tooling problem. When the official path is slow and bureaucratic, the hidden factory will always emerge to meet the demands of the business. 

To regain control, IT Middle Management must provide a platform that is faster and easier to use than the alternatives.

-   **Audit the Hidden Factory:** Identify where developers are currently losing time to "glue work," such as manual environment setup or debugging environment drift.
-   **Codify the standards:** Move your security and compliance policies into machine-readable YAML files that can be versioned, tested, and enforced automatically.

By centralizing the data layer and utilizing inheritance-based governance, organizations can eliminate Shadow IT while simultaneously accelerating developer velocity. Stop being the bottleneck and start being the enabler.

### **Ready to dismantle the Hidden Factory?** 

**Request a technical demo** to see how Upsun codifies your governance and reclaims your team's velocity.

### [Automating governance with policy enforcement | Upsun](https://upsun.com/blog/automating-governance-a-technical-guide-to-policy-enforcement-on-upsun/)

# Automating governance: a technical guide to policy enforcement on Upsun

In traditional IT organizations, governance is often a procedural burden. 

It lives in spreadsheets, Wiki pages, and ticketing queues. For the IT Middle Manager (ITMM) overseeing a modern engineering team, this "procedural governance" is the primary driver of **Shadow IT**. 

When a developer has to wait three days for a security review to change a database version, the temptation to spin up an unapproved instance becomes overwhelming.

To end Shadow IT, we must move governance from the realm of "procedure" to the realm of "mechanics." 

This deep dive explores how Upsun automates policy enforcement directly within the developer workflow, providing the rails that ensure compliance without the friction of manual gates.

## Where friction usually appears: The cost of the manual gate

In a fragmented workflow, friction is almost always found at the handoff points. 

Manual reviews, change advisory boards (CABs), and inconsistent enforcement across different cloud providers create a "governance tax" that consumes up to 20% of a developer's week.

Procedural governance relies on **human memory and compliance**. 

It assumes that every developer will remember to apply the correct security headers or resource limits. When they don't, the result is a production incident or a budget leak. 

Technical enforcement on Upsun removes the "human error" variable by baking the rules into the infrastructure itself.

## Automation mechanisms: The engine of governed delivery

Upsun replaces the manual gate with three core technical mechanisms that ensure every deployment is policy-aligned by default.

### 1\. Versioned configuration as the "source of truth"

The foundation of technical enforcement is `.upsun/config.yaml`. 

Instead of a static security document, your governance lives in a version-controlled file. If a team needs to add a new service or change a runtime version, they must define it here. This allows IT managers to:

-   **Enforce secure defaults:** Runtimes and services are deployed using hardened, read-only images.
-   **Prevent configuration drift:** Because the infrastructure is immutable and recreated on every push, there is no chance of a developer making an unrecorded manual change in production.

### **2\. Automated Build Hooks as Quality Guardrails**

Build hooks are the primary "hard guardrail" of the Upsun platform. 

These are scripts that run during the build process, before the application is live.

By embedding security scans (SAST), linting, and compliance checks into the build hook, IT teams can ensure that non-compliant code simply never reaches the deployment stage.

The platform acts as an automated auditor that provides immediate feedback to the developer, rather than a ticket that sits in a queue.

### **3\. Environment Rules and Resource Caps**

Financial governance is often ignored until the end of the month when the cloud bill arrives.

Upsun enforces resource allocation guardrails at the platform level. IT managers can define hard-caps on CPU and memory within the configuration. 

This ensures that a development branch can never accidentally spin up an enterprise-grade database instance, preventing budget leakage through architectural design rather than verbal policy.

## Developer acceptance: Fewer interruptions, clearer expectations

One of the biggest myths in IT is that developers hate governance. 

In reality, **developers hate ambiguity and interruptions**.

When governance is procedural, developers are often interrupted days after a merge by a security audit. When governance is technical and automated, the expectations are clear and immediate. 

If the code passes the build hook, the developer knows it is compliant. This provides a "psychological safety net" that allows teams to move faster. 

By providing production-perfect preview environments that already include these guardrails, Upsun makes "the right way" the easiest way for the developer to work.

## IT role evolution: From gatekeeper to platform owner

The move to automated enforcement changes the fundamental role of the IT manager. 

You are no longer the gatekeeper. Instead, you are a **Platform Owner** providing a governed, high-velocity "Paved Road" for your engineering teams.

By centralizing the unified cloud application platform, you gain a clear map of the entire organization's tech stack. 

You can satisfy a SOC2 or HIPAA auditor by showing them your versioned configuration files and build logs (deterministic evidence of a secure state) rather than chasing down individual developers for screenshots of their settings.

### Next steps: Automating your enforcement

Moving governance from procedure to mechanics is the final step in dismantling the "hidden factory" of Shadow IT. Here is how to begin:

-   **Audit your approval gates:** Identify which manual reviews can be replaced by an automated build or deploy hook.
-   **Codify your security baseline:** Start defining your mandatory runtimes and services in a standardized `.upsun/config.yaml`.
-   **Test technical enforcement:** **Start a free trial** to see how Upsun’s environment guardrails eliminate configuration drift and budget leakage.
-   **Centralize your orchestration:** Learn how to manage your entire project fleet via the CLI to gain 100% visibility into your cloud estate without slowing down your devs.

## Ready to stop the shadow IT cycle?

**Request a technical demo** to see how Upsun codifies your governance and reclaims your team's velocity.

### [Migration checklist for a unified platform | Upsun](https://upsun.com/blog/migration-checklist-moving-from-fragmented-workflows-to-a-unified-platform/)

# Migration checklist: moving from fragmented workflows to a unified platform

Fragmented workflows, built on separate tools and manual handoffs,are an operational risk. 

They create hidden dependencies, inconsistent environments, and the constant threat of breaking production during routine changes.

The challenge isn't deciding to consolidate; it’s executing the move without disruption. 

This checklist provides a phase-by-phase path to de-risk the transition from disconnected toolchains to a unified platform.

## Why migrations stall

Ambiguity creates resistance. 

If the process isn't explicit, teams don't know what is moving or how their daily work will change. 

Consolidation without a clear migration path simply replaces one form of fragmentation with another.

## Preparation: know what you're working with

Most teams underestimate the tribal knowledge and "temporary" exceptions holding their current workflows together. 

Before migrating, you must expose the reality of the existing system.

**Your preparation checklist should include:**

-   Catalog all tools, pipelines, and deployment processes (including unsanctioned ones)
-   Map dependencies between services, databases, and integrations
-   Identify environment variables, secrets, and shared configurations
-   Tag each workflow by risk level (low, medium, high) and complexity
-   Document current owners and stakeholders for every workflow

## Sequencing: migrate in the right order

The biggest mistake in platform migration is trying to move everything at once. 

A phased approach contains failures within a single stage rather than jeopardizing the entire organization. 

Start with low-risk, low-complexity projects, those with a limited blast radius and manageable dependencies.

### Checklist: 

-   Select 1–2 low-risk projects for pilot migration
-   Execute pilot migration and document outcomes vs. expectations
-   Identify and resolve gaps in the migration process
-   Migrate medium-complexity workloads using refined process
-   Schedule high-criticality migrations with rollback plans in place
-   Test backup and rollback procedures before each critical migration

## Change management: bring your teams along

Migrations fail when teams experience them as a loss of control. 

People don't resist standardization because they love old tools; they resist when the new model feels opaque or restrictive.

Transition from "governance" to "utility." Instead of abstract policy, focus on tangible benefits: no more waiting for staging environments and the ability to recreate production-like testing conditions without opening a ticket.

**Your change-management checklist should include:**

-   Schedule team-specific onboarding sessions using real project workflows
-   Create per-project documentation for deployment, monitoring, and rollback
-   Designate a migration champion for each team
-   Establish a feedback channel for migration issues and improvement requests
-   Set a clear timeline for decommissioning legacy tools

## Validation: confirm the migration delivered

Migration is complete only when the workflow is consistent, not just when the platform is live. 

Confirm that delivery now happens through the system of record rather than side channels.

### **Validation checklist:**

-   Confirm all teams are using the unified deployment pipeline
-   Verify environment configurations are standardized across projects
-   Implement access controls and audit logging on the new platform
-   Compare post-migration performance metrics against pre-migration baselines
-   Decommission legacy tools and revoke access to retired systems
-   Schedule a 30/60/90-day post-migration review

## The goal: infrastructure as code

The hardest part of moving to a unified platform is building a process teams trust. Upsun reduces this friction by tying application and infrastructure configuration to Git. 

When consistency is built into the platform via `.upsun/config.yaml`, migration becomes a repeatable alignment of teams rather than a constant re-architecture of tools.

## Ready to stop the Shadow IT cycle?

Fragmented workflows are a choice, not a necessity. If you are ready to reduce disruption and stop shadow workflows from creeping back in, an Upsun expert can help you map your migration sequence and define a "Golden Path" for your teams.

**Request a technical demo** to see how Upsun codifies your governance and reclaims your team's velocity.

### Additional resources

If you are planning a move away from fragmented delivery workflows, these guides go deeper on migration planning, cutover execution, and reducing operational drag:

-   Migration blueprint for moving your application without rewriting
-   Migration day: executing your Upsun cutover
-   Cutting tech debt at the source: how cloud application platforms put IT back on offense
-   Heroku vs Upsun: the 2026 PaaS choice

### [Why AI agents will break legacy cloud | Upsun](https://upsun.com/blog/ai-agents-break-legacy-cloud/)

# The silent infrastructure tax: why AI agents will break your legacy cloud

For the first time in a decade, humans are the minority on the open web. 

In 2025, automated traffic officially crossed the Rubicon to account for 51% of all web activity, while generative AI-driven referrals to retail sites surged by a staggering 693% year-over-year.

As we move through 2026, these are no longer just "bot" statistics to be handled by a WAF. They represent a fundamental shift in user behavior. 

The fastest-growing segment of your audience is now agentic. These "users" don't browse your UI; they execute against your infrastructure.

For the Modernization Architect, this isn't a marketing trend. It's an architectural crisis. 

Legacy stacks designed for human "think-time" and predictable CDN caching are being crushed by the high-concurrency, zero-latency demands of AI agents.

### The shift from browsing to execution

The traditional web model relied on human patience and predictable caching. A human clicks a link, the CDN serves a cached asset, and the origin server rests.

AI agents, like OpenAI’s Operator or Anthropic’s "computer use" tools, break this model. 

They don't want a cached HTML page; they want real-time, personalized data. 

They hit search endpoints with complex, natural language queries and attempt to trigger multi-step business intents (e.g., "Find a flight, compare it to my calendar, and book the window seat").

**The result: Cache hit rates plummet, and your database becomes the bottleneck.**

### Why your current stack isn't agent-ready

Most legacy architectures struggle with three specific "agentic" behaviors:

1.  **Burst concurrency:** Unlike humans who trickle in, agents often arrive in swarms. A single popular LLM plugin might trigger thousands of simultaneous API calls to your inventory service in seconds.
2.  **Context bloat:** Agents require dense, machine-readable data (structured data like Schema.org and JSON-LD, or tool-integration protocols like MCP). If your backend isn't decoupled, gathering this context requires expensive "join" operations across fragmented microservices.
3.  **Instructional latency:** An agent has a lower timeout tolerance than a human. If your API response takes more than 200ms, the agent may abandon the task, costing you the transaction.

### Building a flexible foundation

To survive the agentic shift, your infrastructure must move away from rigid, "always-on" sizing and toward granular, on-demand scaling.

While your application topology is defined in .upsun/config.yaml, Upsun decouples your resource allocation from your code.

 This architectural separation is critical: it allows you to right-size Production, Staging, or a temporary Preview environment independently, without a single line of code change or a "feature freeze."

When an agent swarm hits, you have the operational flexibility to scale horizontally by adding instances or vertically by adjusting resource profiles via the Upsun Console or CLI. 

The platform ensures your origin remains responsive and your database stays performant, even when "execution-heavy" AI traffic bypasses your edge cache entirely.

### Validating the agent-flow with preview environments

The biggest risk in optimizing for agents is "hallucination in production", where an agent misinterprets an API error and falls into an eternal loop of errors.

You cannot safely test these autonomous flows in production. You need a production-identical clone of your entire stack (data, state, and services) to run "agent stress tests."

Upsun’s branching model allows you to spin up a preview environment for every architectural change. This lets you:

-   **Test "Agent-Purchase" flows:** Can a bot actually navigate your checkout without a human?
-   **Audit machine-readable context:** Use an LLM to "crawl" your preview environment and flag where it gets stuck.
-   **Profile resource consumption:** See exactly how much RAM your search service consumes when hit by 100 concurrent "natural language" queries.

### The modernization mandate

Optimizing for AI agents is the ultimate "stress test" for your digital transformation. 

The practices that make a site agent-friendly (semantic HTML, structured data, and high-performance APIs) are the same practices that improve accessibility and SEO.

However, without an underlying platform that supports **instant portability and elastic scaling**, these frontend optimizations are just window dressing.

The question for 2026 isn't whether agents are coming. They are already here. But rather: will your infrastructure treat them as a new revenue stream or a system failure?

### [Bank cloud migration without a feature freeze | Upsun](https://upsun.com/blog/bank-cloud-migration-without-a-feature-freeze/)

# Bank cloud migration without a feature freeze

_How financial institutions can escape the "Big Bang" migration trap and keep shipping features the entire time._

Every bank executive knows the math. Legacy core systems cost more each year, slow product launches, and widen the gap between what customers expect and what the institution can deliver. 

Over 50% of banking executives say their current systems can't support long-term digital strategy. The case for modernization is airtight.

So why do most hesitate?

Because of the traditional path, the "Big Bang" migration, which means switching everything over at once and hoping nothing breaks. 

In practice, it compresses all risk into a single window with no fallback. Preparation alone often takes at least two years, during which feature development freezes just to keep the migration on track.

For regulated institutions, that freeze is dangerous. Two years without meaningful product updates means two years of falling behind challengers who ship weekly.

## The real cost of the feature freeze

Traditional cloud migration strategies usually follow a rigid sequence:

1.  Freeze new features
2.  Rebuild the infrastructure stack
3.  Migrate the application
4.  Test everything
5.  Release the new platform

This approach creates several major risks.

### **Innovation stalls**

A feature freeze means product teams cannot release improvements. For banks competing with fintechs and digital-first platforms, this delay can last **18–24 months**.

During that time, competitors ship new customer experiences, payment features, and digital banking services.

### Compliance pressure increases

Financial services operate under strict regulatory oversight. Meanwhile, regulators aren't pausing either.

In the EU, the Digital Operational Resilience Act (DORA) makes operational resilience a board-level obligation for banks. PSD3 is on the horizon. Compliance requirements keep evolving, whether your migration is complete or not. 

A feature freeze means you're not just standing still on product, you're potentially falling behind on compliance, too.

### Migration risk compounds

Large migrations fail when testing environments do not match production. Small configuration differences lead to unexpected failures after release.

Banks often discover problems late in the migration process, when fixes are expensive, and timelines slip. This is why the Big Bang migration is feared across financial services. It forces institutions to choose between modernization and stability.

## A better migration model: test in isolation and keep shipping

Upsun removes the need for a long feature freeze by introducing production-like preview environments. 

Preview environments are full copies of the production application stack created automatically from a Git branch. Each environment includes the same services, configuration, databases, routes, and dependencies used in production. 

Developers can test modernization changes in isolation without affecting the live system. Instead of rebuilding everything first, teams migrate gradually while development continues, providing the documented portability required by DORA.

### Test legacy systems against modern guardrails

Many banking applications include legacy code that must continue operating during modernization. With Upsun preview environments, teams can run that legacy code against the new cloud infrastructure configuration before releasing it.

For example, a team might test:

-   Containerized runtimes
-   Updated service configurations
-   New security policies
-   Modern networking rules

Because the instant data preview environments mirror production, teams can catch configuration and behavior issues early, though production validation and monitoring remain essential for integration risks and performance at scale.

## Continuous compliance during modernization

Here's where financial institutions get an advantage that goes beyond speed.

Traditional migrations treat compliance as a gate at the end: build everything, then prove it meets regulatory requirements before going live. 

Upsun flips this. 

Because every preview environment runs on the same certified infrastructure as production with platform-level controls aligned to PCI DSS Level 1, SOC 2 Type 2, ISO 27001, and IBM Cloud for Financial Services validation, compliance isn't something you bolt on at the end. 

Teams inherit a significant portion of their compliance controls from the infrastructure layer. Customers are still responsible for securing their own applications, configurations, and data handling. Still, they start each migration branch on a validated foundation rather than building compliance from scratch at cutover. All environments generate auditable logs and deployment artifacts, supporting compliance evidence and regulatory reporting throughout the migration.

For institutions navigating DORA, this matters. DORA makes operational resilience a board-level obligation, with emphasis on ICT risk management and third-party oversight. 

Upsun's platform-level controls: project isolation, encryption, read-only file systems, WAF, and DDoS protection, give you a resilience story at every stage of the migration.

## Continuous delivery instead of a feature freeze

With production-like preview environments and realistic data cloning, teams can ship features even while modernization progresses.

A typical workflow looks like this:

1.  The developer creates a branch for a modernization change.
2.  Upsun automatically creates a preview environment.
3.  The environment includes services, routes, and cloned (and sanitized) production datasets.
4.  Teams test legacy code against modern infrastructure.
5.  Compliance and security checks run continuously.
6.  Changes are merged and deployed to production.

Because each change is isolated and validated early, there is no need for a long freeze period. 

## Why this matters for financial services

Upsun isn't a generic hosting provider that happens to serve banks. Financial services are a core focus. 

The platform is validated for IBM Cloud for Financial Services and supports GDPR alignment through built-in data protection capabilities. With deployment options across AWS, Azure, IBM Cloud, GCP and OVHcloud, you can choose regions that meet their data residency requirements.

That combination of compliance coverage and multi-cloud flexibility means institutions can modernize safely while continuing to innovate. Instead of choosing between stability and progress, they gain both.

## The bottom line

Banks don't have to choose between modernization and momentum. The "Big Bang" migration with its two-year freeze, its compressed risk window, and its all-or-nothing cutover is a legacy approach to solving a legacy problem.

With production-perfect preview environments, you can test every migration step in isolation, maintain compliance at every stage, and keep delivering value to customers throughout.

Modernization without the freeze. That's what Upsun is built for.

_Ready to see how preview environments work for regulated workloads?_ _Start a free trial_ _or_ _request a demo_ _to talk with the Upsun team about your migration path._

### **Learn more**

-   DORA compliance: how Upsun supports financial services 
-   Faster, compliant delivery on regulated cloud with Upsun and IBM Cloud for Financial Services
-   How B2B multi-cloud platforms simplify multi-cloud deployment
-   Explore how preview environments work

### [Portable cloud architecture for DORA compliance | Upsun](https://upsun.com/blog/dora-exit-strategy-for-financial-services/)

# DORA exit strategy for financial services: portable cloud architecture with Upsun

Financial institutions are required to prove they can operate safely in the cloud without becoming dependent on a single technology provider. What happens if your cloud provider fails, or you are required to move?

The question used to be theoretical. However, since January 2025, it has become a compliance requirement. 

The EU's Digital Operational Resilience Act (DORA) requires banks, insurers, and investment firms to demonstrate they can withstand disruptions to the cloud platforms they rely on, including maintaining a documented, tested exit strategy for each technology provider.

For many organizations, this exposes a hard truth: most modern cloud deployments are deeply tied to one provider. 

If a regulator asks how you would move off AWS tomorrow, "we would figure it out" is no longer an acceptable answer.

## The vendor lock-in trap

Most cloud architectures are not portable. They are built on provider-specific services: AWS Lambda functions, Azure-native databases, and GCP-only networking configurations, creating deep, invisible dependencies. Over time, these dependencies accumulate.

Moving off a single cloud provider doesn't just mean changing a hosting account. It means re-architecting your application. 

For a regulated bank, this is risky. If a bank cannot move workloads away from a provider, then it cannot prove resilience against outages, regulatory action, or geopolitical disruption.

This is the concentration risk DORA was designed to address. 

In November 2025, EU supervisory authorities designated 19 ICT providers as critical under DORA, including AWS, Microsoft Azure, and Google Cloud. These providers now face direct EU-level oversight. 

For financial entities depending on them, the message is clear: prove you are not trapped.

Under DORA Article 28, financial entities must be able to exit contracts with ICT providers without disrupting services or violating regulatory requirements. That means institutions must:

-   Maintain documented exit strategies
-   Identify alternative providers and develop transition plans
-   Plan data migration and transition processes
-   Regularly test and review exit plans

## Why multi-cloud alone is not a DORA exit strategy

When teams hear the term "exit strategy," the instinct is often to adopt a multi-cloud runtime: run applications simultaneously across multiple providers.

In practice, this approach is expensive and complex. 

Running production workloads across several clouds requires duplicated infrastructure, duplicated monitoring, and duplicated operational teams. Even worse, the application itself may still depend on provider-specific services. True portability remains out of reach.

What financial institutions really need is standardized portability: a deployment model where applications can be recreated on another infrastructure provider without redesigning the entire system.

## Standardized portability: the Upsun approach

Upsun takes a different approach to this problem. 

Rather than building applications around a specific cloud provider, Upsun standardizes how applications are defined and deployed. The foundation of this approach is a single configuration file: `.upsun/config.yaml`.

This configuration defines the entire application environment:

-   Runtime versions
-   Services (databases, caches, search engines)
-   Build and deploy processes
-   Routes and networking
-   Scheduled tasks

Your infrastructure definition isn't locked inside a cloud console or a proprietary orchestration layer. It's versioned, auditable, and portable.

Because the configuration is provider-agnostic, the application environment can be recreated on any supported infrastructure, including AWS, Azure, Google Cloud, IBM, and OVHCloud, without redesigning the deployment model.

If a regulator requires a move or a provider experiences a prolonged outage, the application can be restored or migrated to another supported provider using the same Upsun configuration and Git-based workflow.

## What this means for DORA compliance

DORA Article 28 requires financial entities to maintain actionable exit strategies, while Article 30 sets out specific contractual provisions that must be included in agreements with ICT providers,  covering service continuity, termination rights, and data transition. 

Upsun already offers a DORA Contractual Addendum to help financial services customers meet these requirements.

But the technical side is just as important as the contractual side. DORA expects actionable exit plans, not theoretical. 

**A portable, version-controlled infrastructure definition gives compliance teams something concrete to point to: here is the blueprint.**

Combined with Upsun's existing compliance credentials, ISO 27001, SOC 2 Type 2, PCI DSS Level 1, HIPAA, and validation for IBM Cloud for Financial Services, Upsun is designed to support teams that operate in regulated environments.

## Portability isn't the whole picture: migration requires planning

An honest exit strategy requires more than a portable config file. 

Moving a production application between cloud providers still requires a planned migration process: data transfer, integration retesting, DNS cutover, performance validation, and stakeholder sign-off. 

No platform eliminates that work entirely.

**What Upsun eliminates is the infrastructure re-architecture.** 

Your application code doesn't change. Your build pipeline doesn't change. Your service definitions don't change.

The migration effort focuses on the operational steps: data, testing, and cutover, not on rebuilding everything from scratch. That's a fundamentally different starting position than re-platforming from a provider-specific architecture.

## A practical starting point

If you're a financial institution preparing for DORA's exit strategy requirements, start here:

1.  **Audit your current provider dependencies.** Identify which services are provider-specific and which are portable.
2.  **Evaluate how your infrastructure is defined.** Is it in code, or is it locked in a console?
3.  **Ask your platform provider a direct question:** If we needed to move to a different cloud next quarter, what would that actually involve?

With Upsun, the answer starts with a file that's already in your Git repository. 

### **Learn more**

-   DORA compliance: how Upsun supports financial services
-   Faster, compliant delivery on regulated cloud with Upsun and IBM Cloud for Financial Services
-   How B2B multi-cloud platforms simplify multi-cloud deployment

### [Decoupled web stacks without four dashboards | Upsun](https://upsun.com/blog/decoupled-stack-single-platform/)

# How to run a decoupled web stack without four cloud dashboards

**Decoupling and orchestration: managing multi-app stacks on one platform**

At some point in the life of most growing web projects, the architecture forks. The frontend moves to a dedicated deployment. A background worker splits off to its own process. An API layer gets extracted. The right choice technically, usually, but the operational complexity that follows is rarely accounted for in advance.

Six months later, there are four cloud dashboards, three billing accounts, and a README section titled "Environment Variables" that's three pages long and visibly out of date.

## **How vendor sprawl actually happens**

_Key takeaway: Decoupled architectures don't start with vendor sprawl. They accumulate it incrementally, one "best tool for this specific job" decision at a time, until the operational surface area is too large to manage cleanly._

Nobody sets out to run their frontend on Vercel, their API on Render, their background jobs on Railway, and their database on Supabase. It happens one decision at a time, each individually reasonable.

Vercel is genuinely good at deploying Next.js. Render makes it easy to run a Django or FastAPI backend without configuring a server. Railway has a clean interface for managed Postgres. Each choice optimizes for its specific problem, and at the moment of that choice, the integration cost is deferred.

The integration cost always arrives. It shows up as environment variables that need to stay in sync across four providers. It shows up as debugging a CORS error that only happens in the preview environment because the frontend is on a different subdomain there than it is in production. It shows up as an incident postmortem that traces back to a hardcoded URL that pointed at the staging backend instead of production.

The underlying issue is that the components of the application were designed as a single system but deployed as separate concerns. The operational model doesn't match the architecture.

## **The networking problem nobody plans for**

_Key takeaway: When application components live on different platforms, the network between them is implicit, manual, and untested. Deterministic internal networking, where service addresses are known at build time and don't change between environments, removes an entire category of environment-specific bugs._

When a Next.js frontend calls a Django API, something has to tell it where that API lives. In practice, this is usually an environment variable: `NEXT_PUBLIC_API_URL=https://api.myapp.com`. That variable has a different value in local development, in the preview environment, in staging, and in production. Keeping those values correct and in sync is manual work that happens outside version control, and it fails in ways that are annoying to debug.

The failure mode isn't usually dramatic. It's subtle: a preview environment that silently calls the production API because someone forgot to update the variable. A staging environment that's testing against last week's backend because the deployment didn't propagate. A CORS policy that works in production but blocks requests in the branch environment because the origin domain is different.

Deterministic networking sidesteps the problem by making internal addresses consistent and known. When two applications live in the same Upsun project, they can reach each other by a fixed internal hostname that doesn't change between environments. The frontend always knows where the backend is without an environment variable you have to set or keep in sync. The address is determined by the project config, not by whoever last updated the secrets dashboard.

## **What a single-project multi-app config might look like**

_Key takeaway: Defining a decoupled stack in a single config file means the relationships between applications are explicit, version-controlled, and automatically reproduced in every environment, including preview environments for every branch._

Upsun is a platform-as-a-service that manages the infrastructure layer of your application stack, so your team doesn't have to. For multi-app projects, that means the entire stack, frontend, backend, and services, is defined in a single `.upsun/config.yaml` file. Here's a project with a Next.js frontend and a Python FastAPI backend sharing a Postgres database:

```shell-session
applications:
  frontend:
    type: nodejs:22
    source:
      root: "frontend"          # path to this app within the repo
    relationships:
      api:                      # gives the frontend a fixed internal address for the backend
        service: "backend"
        endpoint: "http"
    web:
      commands:
        start: "npm run start"

  backend:
    type: python:3.12
    source:
      root: "backend"
    relationships:
      database:                 # wires the backend to the Postgres service below
        service: "db"
        endpoint: "postgresql"
    web:
      commands:
        start: "uvicorn main:app --host 0.0.0.0 --port $PORT"

services:
  db:
    type: postgresql:16         # platform manages patching within this version

routes:
  "https://{default}/":
    type: upstream
    upstream: "frontend:http"   # only the frontend is public; the backend stays internal-only
```

The `relationships` block is where the networking is defined. The frontend has a relationship to the backend called `api`, which means it can reach the backend at a predictable internal address. The backend has a relationship to the database. Neither relationship requires a hardcoded URL or a hand-maintained environment variable outside the config file.

When a developer opens a branch, the platform spins up both applications and the database, wires them together with the same relationship structure, and assigns each a consistent internal address. The frontend in the preview environment calls the backend in the preview environment, not the production backend.

That's the thing the multi-provider setup can't easily give you: environment isolation that extends all the way through the network, not just to the application containers.

## **What changes operationally**

_Key takeaway: A single project for the full stack means a single deployment pipeline, a single place to check logs, a single invoice, and environment parity that includes networking. The operational overhead of running a decoupled architecture drops significantly._

The immediate practical differences are the obvious ones. One deployment pipeline covers the full stack. Logs from the frontend and backend are in the same place. The monthly invoice comes from one place.

The less obvious difference is what happens to onboarding and debugging.

With a multi-provider setup, a new developer joining the team needs accounts on four platforms, access to four dashboards, and a working understanding of how the pieces connect. The "Environment Variables" README section exists because there's no other way to document a network topology that lives in four separate providers' settings panels.

With a single-project setup, the topology is in the config file. A new developer clones the repository, and the config tells them exactly what the stack consists of, how the components relate to each other, and what version of everything is running. The README section on environment variables gets much shorter.

The same applies to debugging. When something goes wrong at the boundary between the frontend and the backend, the relevant logs are in the same place. The network between them is defined in the same file as everything else. There's no need to switch dashboards or correlate timestamps across four separate logging interfaces.

## **Already running across multiple providers?**

Migration doesn't require moving everything at once. The config file describes the target state of the stack, so a practical approach is to start with a single component, typically the backend and its database, define it in Upsun, and establish the internal networking from there. The multi-provider README problem starts shrinking from the first service that moves across.

* * *

## **Frequently asked questions (FAQ)**

**Can the applications in a project use completely different languages and runtimes?**

Yes. A project can contain a Node.js frontend, a Python backend, and a Java worker process, each running in its own isolated container. The platform manages the networking between them regardless of what they're built with.

**How does the frontend know the internal address of the backend?**

Upsun injects relationship information as environment variables at runtime. The frontend gets a set of variables describing how to reach the backend: host, port, and scheme. These are consistent across environments, so the same application code works in every branch without modification.

**What happens to the networking in preview environments?**

Each branch environment gets its own isolated instance of every application in the project, wired together with the same relationship structure as production. The frontend in a branch environment calls the backend in that same branch environment. The relationship wiring in a branch environment points at that environment's own services, not production's.

**Does this mean all services have to be defined in one repository?**

Not necessarily. Upsun supports source operations and external integrations that allow components to live in separate repositories while still being orchestrated as a single project. For most teams starting out, a single repository is simpler, but the platform doesn't require it.

**How is this different from Docker Compose?**

Docker Compose solves local development orchestration. It doesn't manage deployments, environment parity, scaling, or networking across multiple live environments. A single Upsun project config file covers all of those, from the developer's branch environment through to production, with the same configuration.

### [Our product origin story: The evolution of a PaaS | Upsun](https://upsun.com/blog/upsun-origin-story/)

# The Upsun origin story: the evolution of a PaaS

Upsun is the newest offering from Platform.sh, based on the existing container-based architecture of the Platform.sh PaaS which has been active for almost a decade, managing several thousands of applications for its customers worldwide. Upsun comes with a completely revamped usage-based pricing model designed to provide the flexibility needed for decoupled- and composable-architecture projects. For our team, Upsun is _the_ most important launch from Platform.sh since the company’s inception and we cannot wait to share it with you. 

## **Platform.sh: remedying the fear of deployment** 

Before we dive into the Upsun PaaS product, let’s first take a step back into the past and take a look at the journey of Platform.sh. In the very early days of Platform.sh, around 10 years ago, the cloud and application infrastructure were always in the way of developers achieving what they wanted to. To keep up with competition and customers’ ever-growing expectations, regardless of your application’s goal, iterating fast is paramount. But if iterating means breaking production a couple of times a week, you quickly become very fearful of doing it at all. So we wanted to solve that: this fear of deployment. We set about making the cloud as simple and robust as possible with a focus on this exact use case with Platform.sh: big ecommerce applications with high-traffic, content-heavy CMS-based websites. 

One of the biggest challenges, somewhat specific to these use cases, is that you need preview environments to have non-synthetic data to do robust testing. Testing a content-rich application or an ecommerce solution with a catalog of a million items and thousands of concurrent shopping carts is not the same as testing it with a couple of test items. Just as testing a huge complicated content website is not the same as testing a few pages worth of Lorem Ipsums. 

**So we created our cluster cloning technology that allowed us to provide preview environments on the fly, that are perfect copies of production, in just a couple of minutes.** We built it so it runs precisely the same way on any underlying cloud infrastructure. Today, Platform.sh runs on top of AWS, Google Cloud, Azure, OVH Cloud, and Orange cloud. We built everything a large content or ecommerce site would need, fully integrated into our offering. An efficient, secure, reliable PaaS that allowed developers to continuously integrate and deploy without fear—even on Fridays. 

## **Developing a series of interesting PaaS technologies**  

As the Platform.sh PaaS evolved, we developed a series of innovative technologies. Including our multi-cloud, hyper-dense regions through our streaming WAF and all of the automation layers that allow organizations to run hundreds of applications simultaneously while keeping them updated and secure. 

We also made our offer simple. With clear t-shirt size plans available: small, medium, large, XLarge, and 2XLarge. And if you ended up getting more traffic: just level up. No need to think about anything else, it all just works. 

When we first started working on Platform.sh, we wanted to ease the life of software developers that were managing infrastructure. And possibly due to our roots, we built it all on high-level abstractions. Containers before Docker was even a thing. Descriptive Infrastructure as Code (IaC) before it was even called that. All of this meant that early on when our customers, particularly agencies that often use different stacks for their different customers, would ask whether they could use Platform.sh for Symfony, Node.js, Rails, Elixir, or Django—we could say yes, of course. 

Headless ecommerce and CMSs were also all the rage at the time and so we had to ensure that running multiple application services in a cluster was something our PaaS was good at. If the initial use cases of Platform.sh were running just a couple of applications—a static head with a backend—abstractions were important. So we weren’t going to hardcode a limit. One app, two, a couple dozen: the primitives are the same.

Thanks to our ecommerce origins, we were great at managing the persistence layer—from a compliance, performance, and consistency standpoint—and ensuring backups enabled users to get back to business quickly. We found that these capabilities were _very_ useful to our users, regardless of their chosen tech stack. It seems people running game backends care about not losing a high score just as much as merchants care about not losing their record of a sale.

## **Simplicity isn’t universal: the start of the Upsun evolution** 

A few years into running hundreds of diverse applications with Platform.sh, we realized that our simple, t-shirt-size approach was perfectly suited for most CMS and ecommerce projects. However we needed to go further and grant users with more flexibility in the resource-allocation process, particularly for applications built on decoupled and composable architectures. Enabling them to have greater control over their resource allocation for each component of their project and to scale those components independently based on their project’s needs.

The plans we sold with Platform.sh were simple: a cap based on the maximum amount of CPU and RAM for the production environment. We would automatically fit the biggest size of each container type (within the plan’s limits) into these plans. Preview development environments had a different behavior. Instead, we simply made every container the smallest we could. It was simple. And it worked. Mostly. But as we figured out with time that for some types of applications this plan started breaking. Sometimes it was just a bit awkward and sometimes it meant that there were workloads that were a technical fit but we couldn’t run in any reasonable way.

We discovered that simple is hard; what might afford simplicity in one use case may make another use case horrendously cumbersome. CMS and ecommerce projects usually have a very stable topology so as a developer of these types of applications, you don’t often end up adding and removing services. And when they do, our Platform.sh system was simple. Just reallocate resources between all of them. But it also means that when you add a service to an existing environment, the other services might automatically get smaller.  And if you add a service and it overflows the maximums, you have to go to the next t-shirt size which is double. While this simple approach suits a large number of topologies—one app, one relational db, one cache, one search engine—it’s suboptimal for many other applications. 

While a lot of customers appreciated our nimble approach trying to fit as much as we could into a plan. Others, depending on their project’s typology, had to fight against these plans’ default behavior. And after seeing more and more workloads that painted outside of the lines of a CMS or ecommerce project, we decided it was time to offer an alternative pricing model. 

## **What makes Upsun so special?**

While CMS-like monoliths are still a large part of our market, static site generators, and decoupled and composable architecture projects are gaining interest and market share every month. We wanted Upsun to be built to satisfy new use cases we see rising in the web development ecosystem and provide the best developer-focused experience in the market. Upsun's new offering is built around seven main features and one central concept: You are in control.

**Explicit resources allocation**

With Upsun, every container in every environment can now be configured with its own computing resource settings (CPU and RAM). 

This opens up many new possibilities for your production environment, including:

Guarantee that all applications and services always have the resources needed to serve incoming requests. 

Spawn as many workers or databases instances as you need, or add a new micro-service in a pinch without impacting the existing containers.

Grow only specific applications or services as your project is scaling instead of the whole project. 

Handle surges of traffic by quickly scaling the specific bottlenecks in your application.

However, the benefits are broader than just the production environment. That flexibility now allows you to size your preview environments how you want and creates a variety of new opportunities for our users who can:

Temporarily scale a preview environment with the same resources as production to run performance & load tests for a fraction of the price.

Profile applications and identify bottlenecks by changing the allocated resources and analyzing the results with Blackfire.

Run tiny preview environments to optimize the cost and carbon consumption of temporary instances.

**A matching usage-based pricing**

With the new ways of defining and allocating resources, we needed to rethink how we were pricing our value. We made countless attempts to create the most effective pricing model with three goals always in mind:

The pricing should be flexible to match the new possibilities offered by our resource allocation.

The pricing should be fair and transparent.

The pricing should be simple to understand for everyone.

### **A new pricing equation: separating resources from our value**

Willing to be fair and transparent, we decided to isolate the resources—CPU, memory, and storage—from the value we provide—development workflow and safe and reliable deployment.

This provides users with a transparent view of how resources will be billed. It guarantees that you can scale your applications to hundreds of CPUs, should you need or choose to, at a cost similar to that of the IaaS providers you already know. Some of our regions cost us more than others but we still apply the same prices. Our goal is to put you in control without the headaches of managing overly complex IaaS billing.

Like AWS EC2 vs RDS, our managed services resources are priced to include the added automation and supervision required for databases, queues, and other backend services. And as we want to promote a more responsible cloud usage, our low-carbon regions will also benefit from an additional discount.

**Valuing your time and fostering collaboration** 

Platform.sh provides a lot of innovative features and best practices. But the main benefit of using Platform.sh is the ability to regain your time which you’d often spend on application infrastructure management. This is just as true for Upsun. 

We have always focused on ensuring our clients don’t spend countless hours setting up and maintaining costly infrastructures every month. And the more people work on your projects, the more the benefit is obvious. That's why we have decided to center our value around user licenses. This dimension is the best expression of the reclaimed time you gain.

We are confident that having all project members working on Upsun alongside developers is how you get the most out of it. That's why we are implementing **free viewer licenses**. Project members only viewing environments and deployed applications can enjoy Upsun for free. Invite as many stakeholders, clients & reviewers as you want without any financial impact on your projects.

And we’ve kept the best part for last. With Upsun, user licenses are now organization-based and not per project. Meaning you don't need to worry about giving access to a new project to an actual user.

**Project automation**

For every new project you create, you get a variety of included resources and you will only be billed overages if you go over these included quotas, which are:

10GB of Egress (outgoing) bandwidth & 500k incoming requests

1GB of storage in all environments

300 build minutes

Up to 100 hostnames & TLS certificates

You can find all the details on the Upsun pricing page.

**Support and SLAs**

As the need for support grows with your Upsun usage, we have decided to move the support to the organization level, your support amount will be directly proportional to your amount of projects and users. 

Unlike Platform.sh, our Uptime SLAs (99.9/99.99%) are per project. This allows within the same organization to run non-critical applications at  an optimized cost alongside critical ones that require these additional guarantees. 

**A revamped user experience focused on the CLI**

The Platform.sh CLI has always been at the core of the user experience and Upsun is no different. The new Upsun CLI comes with a “project:init” command, streamlining the creation of the Upsun YAML configuration files for migrating or creating new projects.

We are also introducing the “scale” command, letting you set the resources on your environment containers through the CLI and then you can scale them up or down. Vertically or horizontally.

Applications can be scaled horizontally out of the box. This means you can ensure stateless application scalability without limitation and increase your application reliability.

**Observability on every level**

Observability is crucial for web applications as it allows developers to understand how their systems function in real-time. Developers and operations can monitor their applications, detect errors and anomalies, and quickly identify and resolve issues before they become major problems with the Upsun observability tool. 

Our observability tools includes:

HTTP level metrics and analytics.

Continuous profiling of Go and Node.js application.

Extended Profiling and Application Performance Monitoring of PHP and Python applications.

Infrastructure and resources metrics.

With observability on every level, developers can make data-driven decisions and gain valuable insights into the behavior of their applications, enabling them to continuously enhance their systems for optimal performance and efficiency.

Upsun is not a replacement of the Platform.sh PaaS. It’s the best of the Platform.sh PaaS packaged up in a completely revamped pricing model designed to meet the needs of decoupled and composable architecture projects which were limited by the “plan-based” pricing model. 

Upsun is now available as a private beta for the next few months. If you have one or more projects that would benefit from these new features, let us know via this form! 

Join the wait list now! First come, first served!

**UPDATE:** 07 December 2023

Bring your application and your team to the Upsun PaaS. You can register for an open beta free trial\*, where you can test and evaluate Upsun in a production-grade environment, with plenty of resources.

Start a free trial

* * *

\*Free 5-day trial includes: 1 organization, with 1 project and 2 running environments; unlimited containers; unlimited users; and up to 4.5 CPUs, 12 GB memory, and 20 GB network storage running concurrently. At the end of the trial, your project will be suspended until you add a valid payment method to your account. See available pricing for details.

### [The missing PaaS to scale Laravel applications | Upsun](https://upsun.com/blog/paas-to-scale-laravel-apps/)

# Upsun: the missing PaaS to scale Laravel applications

Laravel is a simple, scalable, secure PHP framework powered by a vibrant and active community. It’s the starting point for many great web applications and online businesses, designed to allow developers to focus on creating value for their customers and users, not battling with a rigid framework.

Upsun and Laravel both share the same belief that developers should focus more on building features and exploring new technologies and grounds, and less on recreating the tools supporting their ventures again and again. With so much shared DNA and qualities, it’s safe to say that Upsun is the perfect PaaS for hosting and scaling Laravel applications.

## Create without sweating the small stuff

It’s about focusing on what matters most: being free to create great applications without sweating the small stuff. For all the web artisans, Upsun helps you reach the stars with your Laravel apps, one deployment at a time.

Upsun empowers development teams with the flexibility to build—and the firepower to run—diverse applications on a single, self-service PaaS. By automating infrastructure management and security, Upsun frees every developer to easily experiment, quickly iterate, and responsibly deploy applications at scale. But, how?

Whatever the complexity of your applications, Upsun empowers you to fully control your environment through your terminal and YAML files. We’re here to take you through the steps on how to do this by running your Laravel applications on Upsun—see full documentation here.

## Upsun CLI for the web artisans: how to set it up

First, download and install the Upsun CLI, where you can then discover all Upsun commands with `upsun list`—everything you’ll need to boldly code what no developer has coded before is here.

Once you have the Upsun CLI; you will need a project. You can clone your Laravel application from its Git repository or create a new Laravel application from scratch and initialize a Git repository.

We recommend you initialize a Git repository before creating an Upsun project as this one will then be your `main` environment track to your main branch. Otherwise, the main environment might track a main branch while your default branch may be a `master` and therefore handled as a secondary environment.

It’s now time to create an Upsun project with `upsun project:create`. Alternatively, you can create a project with the UI, and fetch it locally with `upsun get PROJECT_ID`.

The Upsun CLI has a convenient `project:init` command designed to bootstrap configurations and help you get started in no time. This command has a cool shortcut: `upsun ify`. It’s as simple as that, but how does it work?

## Upsunify your Laravel app

The `upsun ify` command automatically detects the framework, runtime, and dependency managers being used. It’s then up to you to name your Upsun project and select the different services you intend to use.

The `upsun ify` command provides a list of services the configuration of which will be bootstraped for you. Use arrows to move the selector, space to select a service, and type to filter the list.

You can add as many services to your application as you wish—take a look at the documentation to know everything you need to shape your Upsun project to your liking.

Depending on application complexity, the `upsun ify` command might not generate the whole configuration files for you but will get you started with 80-90% of it ready. Our stack guides, documentation, and our community are also always on hand to help you complete a top-notch configuration in no time.

## Laravel unleashed: crafting a decoupled ecosystem ready to scale

Upsun is the PaaS made to help you scale your Laravel applications in any direction you need to, regardless of how seemingly complex your application may be. You may want to scale your project horizontally by handling more technologies. Your project might not be a single Laravel application. It might be bundled with workers, web services in NodeJS and Go, and a data layer in Python. This is the tech ecosystem, with Laravel at its core, needed to power your company product or service. And Upsun can help you manage it.

Our documentation provides a guide for building multiple applications Uspun projects. The `.upsun/config.yaml` file contains an `application’s` top-level key filed with the configuration of your first applications. You could either choose to add more entries to this file or split the configuration into multiple files, one per application. While provisioning the infrastructure for our project, Upsun also globes all of the YAML files into the `.upsun` folder in one meta-configuration file.

### Configure writable cache directories

Laravel requires specific cache folders to be writable. Upsun requires us to explicitly define which folders are writable after the build—these folders are called mounts. To ensure the `bootstrap/cache` and `storage` directories are writable, check the `mounts` definition of your `.upsun/config.yaml file`, as seen below. A Laravel-specific cache folder should be created while the application is being deployed if one is missing.

```yaml
applications:
      app:
        ...
        mounts:
          ...
      
        "bootstrap/cache":
          source: "storage"
          source_path: "cache"
                     
        "storage":
          source: "storage"
          source_path: "storage"
```

Multiple hooks run as part of the process of building and deploying your application. These are places where you can run custom scripts, such as this `deploy` hook that ensures caches are correctly set up and warmed:

```yaml
applications:
      app:
        ...
        hooks: 
          deploy: |
            set -eux
               
            # ensure the cache directories are available
            mkdir -p storage/framework/cache/data
            mkdir -p storage/framework/views
            mkdir -p storage/framework/sessions
               
            # clear all caches and dumped files
            php artisan optimize:clear
               
            # run all available migrations
            php artisan migrate --force
```

Hooks provide even more automation superpower as you’ll be able to run several commands at a critical moment of the deployment lifecycle including `build`, `deploy`, and `post_deploy`.

## A bridge between Laravel and Upsun

Laravel expects all configurations to come in through environment variables with specific names, in a specific format. Upsun provides configuration information as environment variables in a different specific format.

The `platformsh/laravel-bridge` library maps the Upsun variables to the format Laravel expects for common values and makes our artisans' lives much easier. Let’s add it with:

```shell-session
composer require platformsh/laravel-bridge
```

## Craft for sustainable growth: allocating resources as demand soars

In today's era of digital sustainability, developers must remain firmly in the driver's seat. Being in control ensures optimal resource allocation, directly correlating with an application's success, and carries a larger environmental responsibility.

Excess resource usage isn't just a matter of wasted costs; it directly translates to unnecessary carbon emissions. By meticulously tuning resources to match an application's growth trajectory, developers can create efficient, high-performance applications without the ecological baggage. Upsun aims to empower developers with this dual mission: fostering digital growth while championing environmental stewardship.

The upsunify command and the documentation should have let you describe the infrastructure needed for your application. Then from the first deployment, resource allocation is done by default with default resources which can be customized at any time.

## Full control of resource allocation

Your project definition should then be taken into account. You still have to define what resources should be used to run your application and this will be the final requirement. It’s a two-step process having you describe your infrastructure in a YAML file and defining the resource allocation to control the costs.

Let’s say you defined a `backend` application powered by Laravel, a `frontend` using NodeJS or Bun, and a MySQL `database`. We now have to ensure that each of those containers benefits from the optimal amount of resources.

Let’s have a look at what happens behind the scenes to fully understand the possibility you now have. All the images available to you have a default profile: `BALANCED`, `HIGH_CPU`, `HIGH_MEMORY`, depending if you want to favor CPU or memory, or prefer an equilibrium between both requirements. This translates into a ratio of memory per CPU unit.

Images come with an optimized default profile value that will be the preferred choice in most cases. But, we want you to be in the driver's seat. You can eventually override the default value and define explicitly which profile you want to use by extending the services definition in your `.upsun/config.yaml` file.

```yaml
services:
      database:
        type: mysql:10.6
        container_profile: HIGH_MEMORY
```

Once this is defined, or most probably left as it is, we are going to tell how much CPU, therefore memory as well, we want to allocate each container. This container size can be 0.1, 0.25, 0.5, 1, 2, 4. The quantity of memory associated with each CPU level is available in the documentation.

Our node `frontend` is super lightweight and only requires 0.1 CPU, the minimum. We made a lot of improvements on our `backend` (thanks Blackfire!), and 0.25 is enough to deliver. Our database is massive and needs more resources to stay fast:    

```shell-session
upsun resources:set --size frontend:0.1,backend:.25,database:1
```

Our backend requires redundancy. Let’s give it 3 instances:

```shell-session
upsun resources:set --count backend:3
```

Let’s finish our configuration by giving 512 MB disk to the `backend` application and 2 GB to the `database` service:

```shell-session
upsun resources:set --disk backend:512,database:2048
```

No need to redeploy (`upsun redeploy`). Our changes have already been taken into account. This also means that only a couple of CLI commands are required to increase, or lower, the resources allocated in the future.

Imagine you are about to launch a new exciting product that will drive large crowds to your site. A few commands just before the “One more thing” moment in your keynote will ensure your application stays afloat and continues to deliver even with intense and sustained traffic.

## Observability on every level

Each Upsun project comes with a complete Observability solution empowering developers and operations teams with the capability to oversee their applications, pinpoint errors and anomalies, and proactively address issues before they escalate.

Upsun observability tools include:

-   HTTP level metrics and analytics.
-   Continuous profiling of Go and Node.js applications.
-   Full access to Blackfire bundled with every PHP and Python project;
-   Infrastructure and resources metrics.

With observability on every level, developers can make data-driven decisions and gain valuable insights into the behavior of their applications, enabling them to continuously enhance their systems for optimal performance and efficiency.

## Git-driven infrastructure

Not only will Upsun empower developers by letting them describe the infrastructure they need in simple YAML files. It also has Git be the single source of truth. Especially, each environment created on your project is bound to git branches.

Let’s imagine you want to work on a specific feature for your application. You’ll create an environment based on your production environment, and most likely your `main` branch. Upsun will automatically provision a clone of your application, with all its related services and data based on the last available backup. You will even have a development URL provisioned as well so you can experience your feature and collaborate with your team.

There is an integration with GitHub and the main third-party Git providers you might want to consider. This integration lets you have environments automatically provisioned for you every time you create branches, pull, or merge requests. Merging a branch automatically redeploys the target environment. How cool is that?

You therefore have entire control over your production and non-production environments. This is also true for resource allocation. You can decide to reduce the resources allocated to the different containers or your non-production environment with the same `upsun resources:set` command while keeping your production environment resource requirements high.

## Web artisans, the world is yours. What will you build next with Laravel and Upsun?

In conclusion, Upsun is purpose-built to give developers the best of both worlds: the ability to scale resources in sync with their Laravel application’s growing demands, while also being environmentally conscious. The developer's role has never been more critical; you're not just coding an application, you're architecting the future of digital sustainability and performance.

We understand that no development journey is undertaken alone. It's a collective endeavor that thrives on shared knowledge and collaborative problem-solving. That's why we invite you to continue the conversation and share your experiences, questions, or insights on our dedicated social media channels.

Come join a space where Laravel developers like yourself can collaborate, learn, and grow together in crafting the next generation of scalable, decoupled, and eco-friendly applications. We can’t wait to hear what you're working on and how we can better support you in your development journey.

Let’s build anything together with Laravel and Upsun, leveraging the full power of our Laravel PaaS.

### [Watch fast debugging in action | Upsun](https://upsun.com/blog/what-fast-debugging-actually-looks-like-on-upsun/)

# What fast debugging actually looks like on Upsun

Debugging a broken deployment can take hours, especially when the cause is unclear. Recently, a customer ran into this exact situation: their AI agent produced a Drupal site with broken composer scripts and mismatched database credentials, and nothing they tried got it running. 

This video shows how debugging works in practice on Upsun. Our Developer Advocate, Paul Gilzow, walks through this real example from start to finish, covering each step:

-   Starting with the logs to pinpoint the errors.
-   Inspecting the application container to see what the AI generated.
-   Comparing the broken project against a clean Drupal install.
-   Pushing targeted fixes one at a time until the site was live.

The whole process follows a consistent pattern: investigate, isolate, fix, validate. Each change is small, testable, and safe to try because Upsun gives you isolated environments that are clones of your production setup. 

If you want to see a real support case go from first error to working site, watch the full walkthrough above. 

Also, if you want to try this workflow yourself, you can **start a free Upsun trial** and spin up your own project in minutes.

### [How predictable platforms enable scalable AI governance | Upsun](https://upsun.com/blog/how-predictable-platforms-enable-scalable-ai-governance/)

# How predictable platforms enable scalable AI governance

AI is spreading through your organization faster than governance can follow. Every new integration, tool connection, workflow automation widens the gap between documented policies and daily operational reality.

This gap is not a failure of intent.

 Most organizations have policies covering data handling, access controls, and compliance requirements. The problem is that these policies cannot be enforced consistently when AI systems connect to tools and data through unpredictable, ad-hoc interfaces. You cannot govern what you cannot see.

Predictable platforms change this equation. When AI systems interact with external resources through standardized interfaces, governance stops being an afterthought but something that can be designed into the system from the start.

## The problem with unpredictable integrations

Consider how most AI tools currently connect to your systems. 

-   Employees paste proprietary code or internal documents into public AI tools, often without knowing where that data is sent or stored.
-   AI systems generate incorrect outputs that are reused without proper review.
-   AI tools access customer or production data through APIs, custom connectors, or undocumented methods that sit outside existing governance processes.
-   As more AI assistants, chatbots, and integrations are added, organizations lose visibility into how data flows and who is accountable for its use.

These risks grow when environments, workflows, and deployment paths are inconsistent. When every team runs AI differently, governance becomes manual, reactive, and fragile.

Unpredictable systems force IT teams into a policing role. Predictable systems let governance happen by design.

## What governance by design actually means

Governance by design does not mean more rules. It means fewer surprises.

In practice, it means:

-   AI workloads follow the same deployment patterns as the rest of the platform.
-   Data access is defined in code, reviewed, and versioned.
-   All environments are reproducible, not hand-built.
-   Observability is built in, not added later.

“When platforms behave consistently, IT can reason about risk before issues reach production. This is critical for AI, where mistakes can propagate quickly.”

## Why AI governance breaks at scale

Most organizations already have governance frameworks. The problem is that they were designed for static systems.

AI introduces new failure modes:

-   Models interact with live data.
-   Prompts and inputs change constantly.
-   Outputs are probabilistic, not deterministic.
-   Tooling evolves faster than approval cycles.

One of the biggest gaps is that AI is often excluded from existing data privacy and compliance processes. Customers are not informed when AI systems access their data. Engineering teams optimise for speed, not long-term exposure.

Without a predictable platform layer, governance cannot keep up.

## What predictable platforms make possible

Predictability starts with standardised runtime interfaces.

When applications, services, and AI components are deployed using the same model, IT teams gain leverage:

-   Configuration lives in version-controlled files.
-   Changes are reviewed before they run.
-   Environments behave the same across teams.
-   Rollbacks are routine, not emergencies.

This matters for AI governance because it limits how and where AI can operate. Instead of banning tools outright, platforms define safe paths for usage.

## Git-driven configuration as a governance control

One of the most effective ways to enforce governance without friction is Git-driven configuration.

When AI services, data connections, and runtime settings live in code:

-   Access paths are visible and auditable.
-   Reviews happen before exposure.
-   Secrets and credentials are managed centrally.
-   Shadow AI usage becomes easier to detect.

This aligns with how engineering teams already work. Governance becomes part of delivery, not a separate approval step.

## Instant staging and development environments reduce AI risk before hitting production

Another governance advantage of predictable platforms is the availability to create instant development and staging environments.

These preview environments allow teams to test AI behaviour safely and reliably:

-   New prompts can be validated without touching production data.
-   AI integrations can be reviewed by security and compliance teams.
-   Risky changes are isolated to short-lived environments.

From a governance perspective, this reduces the chance that hallucinated outputs or unintended data access reach customers. It also creates a shared review surface for IT, security, and engineering.

## Data cloning with sanitisation supports compliant testing

AI systems often need realistic data to behave correctly. Using production data directly is rarely acceptable.

Predictable platforms that support data cloning with sanitisation make compliant testing practical:

-   Teams test against real structures without exposing sensitive fields.
-   AI outputs can be evaluated under realistic conditions.
-   Compliance teams gain confidence that safeguards are enforced consistently.

This directly addresses the concern about GDPR exposure and uncontrolled data access.

## Multi-service orchestration keeps AI systems contained

AI rarely runs alone. It depends on APIs, databases, vector stores, and external services. When these components are orchestrated as part of a single platform:

-   Dependencies move together.
-   Access rules stay consistent.
-   AI systems cannot expand their footprint quietly.

This containment is essential for managing intellectual property risk and preventing accidental data leakage.

## Observability turns AI governance into measurable practice

You cannot govern what you cannot see.

Predictable platforms include observability by default:

-   Logs show how AI systems behave over time.
-   Performance metrics reveal abnormal usage.
-   Errors and drift are detected early.

For IT middle management, this shifts governance from assumptions to evidence. Decisions are based on data, not guesswork.

## Where compliance fits, without slowing teams

Compliance should not be bolted onto AI systems after deployment. It should be enabled by the platform.

Predictable platforms make it easier to align with compliance requirements because:

-   Data flows are explicit.
-   Access is controlled centrally.
-   Environments are documented by default.

Upsun’s compliance posture and Trust Center support this approach, but the core principle applies broadly. Governance works best when platforms reduce variability, not when teams are asked to remember rules.

## What IT leaders should prioritise now

To enable scalable AI governance, focus on:

-   Reducing variability in how AI workloads are deployed.
-   Standardising runtime interfaces across teams.
-   Making configuration reviewable and auditable.
-   Enforcing safe testing through preview environments.
-   Investing in observability as a governance tool.

AI adoption will continue. The choice is whether governance remains reactive, or becomes part of how systems are built and run.

Predictable platforms make the second option achievable.

## Sources

1.  NIST AI Risk Management Framework overview. https://www.nist.gov/itl/ai-risk-management-framework ¹
2.  NIST AI RMF 1.0 publication. https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10 ²
3.  EU AI Act, obligations of deployers and timeline. https://artificialintelligenceact.eu/article/26/ ³
4.  Clifford Chance, EU AI Act overview of key rules. https://www.cliffordchance.com/content/dam/cliffordchance/PDFDocuments/the-eu-ai-act-overview.pdf ⁴
5.  ISO/IEC 42001:2023 page. https://www.iso.org/standard/42001 ⁵
6.  BSI executive briefing on ISO/IEC 42001. https://pages.bsigroup.com/42001%3A2023

### [Multicloud governance: policy across providers | Upsun](https://upsun.com/blog/multicloud-governance-decision/)

# Why multicloud has become a governance decision

For most IT leaders, multicloud didn't arrive as a decision. It arrived as a fait accompli. A team chose AWS for one workload. Azure came in through a Microsoft enterprise agreement. A SaaS acquisition brought its own cloud dependencies. A DR requirement pointed to a second region with a different provider. Nobody declared a multicloud strategy; the organization just became one.

Today, 87% of organizations run a multicloud strategy, balancing an average of 2.6 public cloud providers simultaneously. But adoption and centralized governance are entirely different things. The gap between where infrastructure has gone and where governance has followed is where most multicloud risk quietly accumulates.

## **How multicloud became the default**

_Key takeaway: Most organizations didn't choose multicloud. They accumulated it through acquisitions, team-level decisions, SaaS sprawl, and DR requirements. Governance frameworks built for a single-provider world didn't follow._

The single-cloud era had a certain operational simplicity. One vendor meant one contract, one support relationship, one set of compliance controls to maintain, one console to govern from. It also meant one point of failure, one pricing lever, and exit costs that grew more prohibitive with every service adopted.

The market has moved decisively away from that model. Gartner predicts that 90% of organizations will adopt a hybrid cloud approach through 2027, pointing out that the most urgent challenge over the next year is managing data synchronization across fractured hybrid environments. 

The pressure isn't coming from a strategic preference for complexity; it's structural and compounding. Regulatory requirements demand data residency in specific jurisdictions. AI workloads concentrate on different providers than traditional compute. Acquisitions bring their own cloud estates. Teams choose the best tool for the job, and the job determines the provider.

The result is that most enterprise cloud estates are now genuinely multicloud. And most governance frameworks are not.

## **The operational pressures making this urgent**

_Key takeaway: Three converging pressures (resilience risk, regulatory complexity, and vendor dependency) are turning multicloud governance from a best practice into a business continuity requirement._

**Resilience risk is no longer theoretical** 

Single-provider concentration creates exposure that standard vendor contracts simply don't cover. According to IBM's Cost of a Data Breach Report, data breaches involving multiple environments are the most expensive to resolve, costing an average of $5.05 million per incident. Worse, they take an average of 276 days to identify and contain; nearly a month longer than standard single public cloud incidents. The operational and financial exposure lands entirely on the enterprise, not the vendor.

**Regulatory complexity has multiplied** 

Data sovereignty requirements, GDPR, sector-specific compliance frameworks, and emerging AI governance regulations all have geographic and provider-specific dimensions. An organization running workloads across AWS, Azure, and GCP in multiple regions isn't facing one compliance posture; it's managing several simultaneously. Without cross-provider governance, compliance becomes a manual, per-environment exercise that scales with the number of providers and regions rather than being enforced centrally.

**Vendor dependency is a strategic risk, not just a technical one.** 

Lock-in to a single provider's proprietary services, pricing models, and roadmap decisions transfers negotiating leverage from buyer to vendor over time. Egress fees, service deprecations, and pricing changes all carry more weight when migration is expensive. The organization that can move workloads has a fundamentally different negotiating position than one that can't, and that difference shows up in contract renewals, SLA negotiations, and total infrastructure cost. Understanding where your governance gaps are is the first step to closing them.

**Read the guide to standardizing app delivery across AWS, Azure, and GCP**.

## **Why governance is the gap**

_Key takeaway: Multicloud environments don't fail because organizations chose the wrong providers. They fail because governance frameworks weren't designed to span more than one._

The governance gap in multicloud isn't about security tools or monitoring dashboards. It's about whether the policies, controls, and visibility that IT leaders rely on actually extend across the full infrastructure estate, or stop at the boundary of each provider's console.

When they stop at the boundary, the consequences are predictable. Cost visibility fragments across billing systems that don't share a common language. Security policies that are tightly enforced in one environment are inconsistently applied in another. Compliance evidence has to be assembled manually from multiple sources before every audit cycle. Access controls that were carefully scoped in one environment sprawl quietly in another. Configuration drift accumulates across cloud environments rather than just across dev and production.

According to the Thales Global Cloud Security Study, 44% of organizations have suffered a cloud data breach, with human error, misconfiguration, and inadequate change control across disparate environments cited as the leading causes. The organizations managing multicloud well aren't the ones with the most sophisticated cloud architectures. They're the ones that treated governance as a cross-provider design requirement from the start rather than a per-provider afterthought.

## **What cross-provider governance actually requires**

_Key takeaway: Governance that spans providers needs to operate at the delivery layer, the consistent layer above individual cloud infrastructure,  not at the provider layer where every environment is different by definition._

The instinct when facing governance complexity is to go to each provider and configure governance there. That approach scales with the number of providers, which means it gets harder as the estate grows rather than easier. A team managing AWS, Azure, and GCP isn't doing governance once. They're doing it three times, in three different interfaces, with three different policy languages, producing audit evidence that has to be manually reconciled.

Cross-provider governance works differently. It operates at the delivery layer: the consistent abstraction above individual cloud infrastructure where policies, environment definitions, access controls, and deployment processes are defined once and enforced everywhere. This is the same principle that makes platform standardization work for application delivery. Move the governance logic up the stack to a layer that doesn't change between providers.

For IT leaders, this reframing matters because it changes where the investment goes. Governance tooling that lives inside each provider's console will always be provider-specific. Governance that lives in the delivery layer, in version-controlled configuration, automated pipelines, and portable environment definitions, travels with the workload regardless of where it runs.

That's what it means for multicloud to be a governance decision rather than an infrastructure one. The infrastructure question (which providers, which regions, which services) remains important. But the governance question (how you maintain control, visibility, and portability across all of them)  is what determines whether multicloud delivers on its promise or just adds complexity to the cost.

**See the reference architecture for portable environments with policy guardrails.**

* * *

## **Frequently asked questions (FAQ)**

**Is multicloud actually more secure than single-cloud?** 

It can be, but only with governance in place to enforce consistent controls across providers. Without that, multicloud expands the attack surface rather than reducing it. The resilience benefit of distributed infrastructure requires the governance discipline to manage it consistently. Organizations that have experienced cloud data breaches in multicloud environments typically cite misconfiguration and inconsistent policy enforcement as root causes, not the multicloud architecture itself.

**How is multicloud governance different from cloud security?** 

Cloud security focuses on protecting workloads within a given environment. Multicloud governance is about maintaining consistent policy, visibility, and control across all environments simultaneously: how workloads move between providers, how compliance evidence is produced, how access is scoped and audited, and how cost is tracked. Security is one dimension of governance; portability, compliance posture, and financial visibility are the others.

**What does vendor lock-in actually cost?** 

The direct costs (egress fees, migration costs, proprietary service dependencies) are measurable but often underestimated at procurement time and difficult to reverse later. The strategic cost is harder to quantify: reduced negotiating leverage, exposure to unilateral pricing changes, and roadmap dependency on a single provider's decisions. IBM's Cost of a Data Breach Report puts multi-environment incidents at an average of $5.05 million, with a 276-day average to identify and contain; a cost and timeline that lands on the enterprise, not the vendor.

**Where does multicloud governance start?** 

With visibility: knowing what's running where, under what configuration, with what access controls. Most governance gaps in multicloud environments aren't the result of bad policy decisions. They're the result of policies that were never applied consistently because there was no unified layer to apply them from. The starting point is establishing that layer, then building policy enforcement on top of it.

**How does data sovereignty fit into multicloud governance?** 

Data sovereignty requirements, which specify where data must reside and who can access it, are one of the strongest drivers of multicloud adoption and one of the hardest things to manage without cross-provider governance. Different providers, regions, and services all carry different sovereignty implications. Governance that spans providers makes it possible to enforce residency requirements consistently rather than managing them as per-environment exceptions.

### [Continuous compliance for regulated teams | Upsun](https://upsun.com/blog/continuous-compliance-regulated-frameworks/)

# Why compliance audits keep slowing your engineering team down

### **Continuous compliance for regulated frameworks**

If you've shipped software in fintech, healthcare, or government, you probably know the specific dread of an upcoming compliance audit. Not because the software isn't secure, but because proving it is requires reconstructing a paper trail for decisions that were made in Jira tickets, Slack threads, and pull request comments over the last six months.

The software is fine. The documentation of the software is the problem.

## **Why compliance becomes a gate**

_Key takeaway: Treating compliance as an end-of-cycle gate means audits measure what teams can document, not what they actually did. The gap between the two is where most audit pain lives._

The compliance gate pattern looks like this. A team builds and ships throughout a quarter. At the end of the quarter, or before a major release, an audit happens. The audit requires evidence: that access controls were in place, that data was encrypted in transit, that the OS was patched, that certificates were rotated on schedule.

Most of that evidence doesn't exist in a form auditors can use, because it was never collected with auditors in mind. Someone patched the OS, but the record of it is a closed Jira ticket. SSL certificates were rotated, but the only evidence is a deployment log that's already been archived. Access controls were reviewed, but the review happened in a Slack thread.

So the team spends two weeks before the audit reconstructing the record. Screenshots, exports, written explanations of what happened and when. The engineering team pauses feature work. The security team runs interviews. Everyone is validating what was done rather than doing anything new.

This is what makes compliance expensive: not the controls themselves, but the documentation of the controls, done manually, after the fact.

## **What evidence collection actually costs**

_Key takeaway: The hidden cost of manual compliance isn't the audit itself. It's the ongoing maintenance work that makes the audit possible: keeping configurations documented, keeping change records current, and keeping a second set of humans informed about everything the engineering team does._

Security controls for a framework operating under PCI DSS or SOC 2 cover a lot of ground. Encryption at rest and in transit. OS hardening and patch management. Access controls and least-privilege enforcement. Certificate management. Vulnerability scanning. Logging and audit trails.

Each of these has two costs: the cost of implementing it and the cost of proving it's implemented. In a manual setup, those are separate workstreams. The engineering team implements the controls. A separate process, usually involving a security engineer or compliance officer, documents them in a format auditors will accept.

As release cadence increases, the documentation gap widens. A team shipping once a quarter can manage the paper trail. A team shipping weekly has a compliance documentation problem that doesn't scale.

The other cost is less visible: the chilling effect on deployment velocity. When every deployment potentially creates new compliance surface to document, some teams slow down their release cadence to reduce audit scope. The compliance process starts shaping the engineering process in ways that have nothing to do with actual security.

## **Inherited controls: compliance as a starting point**

_Key takeaway: When controls are applied at the platform layer and documented automatically, the audit evidence exists by default. The compliance question shifts from "can we prove we did this?" to "which of our platform's controls apply to our audit scope?"_

The alternative to manually implementing and documenting each control is inheriting controls from the platform that hosts the application.

Upsun is a platform-as-a-service that manages the infrastructure layer of your application stack so your team doesn't have to. For regulated applications, that means hundreds of automated controls applied at the infrastructure layer, below the application, across categories that map directly to common compliance frameworks:

-   **OS hardening:** the underlying operating system is configured to baseline security standards and kept current without manual intervention.
-   **SSL/TLS certificate management:** certificates are provisioned and rotated automatically, which removes the routine cert-expiry incident.
-   **Encryption in transit:** traffic between the outside world and your application is encrypted by default, with HTTP redirected to HTTPS and certificates managed for you. Traffic between services inside a project runs on a private, isolated network that's never exposed to the public internet.
-   **Access controls:** environment access is managed through the platform's permission model, with audit logs of who accessed what and when.
-   **Patch management:** security patches are applied to the platform layer on a documented schedule, with records that satisfy audit requirements.

Those controls don't need to be implemented by the development team, and the evidence for them doesn't need to be collected manually because the platform generates it continuously.

For a framework operating under PCI DSS, a significant portion of the control requirements live at the infrastructure layer. When those controls are certified and pre-documented, the audit scope for the application layer shrinks considerably. The team demonstrates what they built and configured; the platform demonstrates everything below that line.

Accessing the audit log for any environment looks like this:

```shell-session
# Pull the activity log for a specific environment
upsun activity:list --environment main --type environment.push

# Output includes: who deployed, when, what changed, and the resulting environment state
# This log is available for every environment, including preview branches
```

The log exists whether or not anyone asked for it. When the audit comes, that's the difference between a report and a reconstruction.

## **What this changes for developers**

_Key takeaway: Compliance stops being a separate workstream that interrupts development. When platform controls are inherited and continuously documented, developers can ship without accumulating audit debt._

The practical shift is that compliance stops being something that happens to the engineering team periodically and starts being something that's true continuously.

A developer deploying a new branch of a Django application in a regulated environment doesn't need to think about whether SSL is configured, whether the OS is hardened, or whether the access controls are in place for that environment. They're applied automatically, to every environment, every time. The platform's audit log captures what was deployed, when, and by whom.

When the audit comes, the evidence isn't a reconstruction. It's a report.

This matters most for teams in sectors where compliance requirements are ongoing rather than periodic: where every deployment is in scope, not just quarterly releases. Healthcare applications handling patient data. Fintech platforms processing payments. Government services with continuous security obligations.

It also matters for smaller teams who lack a dedicated security function. A five-person development team building a healthcare application can't staff a compliance officer, but they can deploy on a platform that handles the controls that a compliance officer would otherwise be responsible for.

## **Already doing compliance manually?**

The platform controls apply to every environment from the point of deployment. Switching from a manual evidence collection process doesn't require rebuilding the application or changing how the team ships. It requires deploying to a platform that generates the evidence automatically. The two-week pre-audit scramble doesn't get faster; it stops being necessary.

* * *

## **Frequently asked questions (FAQ)**

**What does "reducing audit scope" mean in practice?**

For a PCI DSS audit, controls are divided into those the merchant or developer is responsible for and those that fall to the infrastructure provider. When the provider is certified and can demonstrate compliance for the infrastructure layer, the developer's audit scope covers only the application layer. Fewer controls to evidence means a shorter, cheaper audit.

**Does deploying on a compliant platform mean my application is automatically compliant?**

No. Platform-level controls handle infrastructure concerns: OS hardening, encryption in transit, patch management, certificate rotation. Application-level concerns, such as how your code handles cardholder data or patient records, remain your responsibility. The platform reduces scope; it doesn't eliminate it.

**Which compliance frameworks do the platform controls map to?**

Upsun's controls are documented against PCI DSS, SOC 2, HIPAA, and ISO 27001 requirements. The specific mapping varies by framework, but the platform can provide documentation showing which controls satisfy which requirements for use in audit evidence packages.

**How does the platform document that controls were applied?**

Audit logs, deployment records, and configuration snapshots are generated automatically for every environment. These are available through the platform's API and dashboard and are formatted for use as audit evidence.

**What if a control needs to be customized for our specific requirements?**

Platform-level controls handle the baseline. Application-level configuration, such as custom access policies or specific encryption requirements, can be layered on top through the project config file. The platform's certified controls remain in place; the customization extends them rather than replacing them.

### [Security and reliability review checklist | Upsun](https://upsun.com/blog/security-reliability-delivery-model-weak-points/)

# Security and reliability review: 7 delivery model weak points to check first

## Why your delivery model is a security and reliability question

_Key takeaway: Security audits that focus only on application code often miss the delivery layer entirely. That is where the most common and most avoidable failures live._

Most teams treat security as a layer added on top of a working system. The problem is that the delivery model itself introduces risk before a single line of application code runs.

When deployments are manual, environments are inconsistent, or configuration drifts across stages, the system behaves unpredictably. That unpredictability makes incidents harder to detect and easier to compound.

## The 7 weak points worth checking first

### **1\. Inconsistent environments**

When local, staging, and production are configured differently, you are not testing what you are shipping. Bugs that only appear in production are often environment bugs, not code bugs.

_What to check:_ Can you spin up a new environment using the same data and configuration that runs in production?

### **2\. Manual deployment steps**

Any step that requires a human to run a command is a step that can be skipped, done out of order, or forgotten under pressure. The gap between teams that automate and teams that do not is measurable: according to DORA's 2024 research, elite performers recover from failed deployments 2,293 times faster than low performers and achieve an 8x lower change failure rate.

_What to check:_ How many deployment steps are not in version control? If someone new needed to deploy today, what would they not find in the docs?

### **3\. Unclear ownership**

When no one is clearly responsible for an environment or configuration decision, things accumulate. Access persists after people leave. Debt gets deferred until it becomes an incident.

_What to check:_ For each environment in your delivery pipeline, can you name the person accountable for its current state?

### **4\. Weak rollback paths**

Fast rollback is both a reliability mechanism and a security one. If reverting a bad deployment takes hours or requires reconstructing the state manually, your blast radius on any incident grows.

_What to check:_ How long does a rollback actually take in your current setup? Has it been tested recently, or is it theoretical?

### **5\. Configuration drift**

Configuration drift occurs when environments that should match gradually diverge through ad hoc changes, often in a control panel that no one audits. It is one of the hardest failure modes to detect.

_What to check:_ Is your infrastructure configuration versioned alongside application code?

### **6\. Poor access control patterns**

Broad permissions given for convenience rarely get walked back. Over time, more people have production access than need it. This matters beyond operational risk: the Verizon 2024 Data Breach Investigations Report found that stolen credentials appeared in 31% of all breaches over the past ten years, making excess access one of the most consistently exploited exposure points

_What to check:_ Who has production access right now? Is that list reviewed regularly? Are permissions scoped to what each role requires?

### **7\. Low deployment predictability**

If developers are not confident that a deployment will go cleanly, they delay shipping. Larger changesets are harder to review and harder to roll back. Risk compounds.

_What to check:_ What caused the last unplanned deployment freeze? Has the underlying cause been addressed?

**See what a delivery model without these gaps looks like**

## What good looks like

_Key takeaway: Good delivery hygiene reduces the number of decisions that require a human to get right every time._

A delivery model that handles these well shares a few characteristics:

-   Configuration lives in version control, making infrastructure decisions reviewable and reversible.
-   Environments are created from the same source, so staging behaves like production.
-   Deployments are triggered by Git. The commit history is the deployment record.
-   Access is scoped and auditable, with a clear owner per environment.

Upsun builds around these principles: configuration lives in YAML files committed to your repository, each branch can produce a full isolated environment, and access is managed at the environment level. 

**Quick self-review questions**

_Key takeaway: If any of these takes more than a few minutes to answer, that is itself a finding._

Run through these before your next audit:

1.  If a team member left today, could someone else deploy confidently using only what is in the repository?
2.  When was the last time you tested a rollback end-to-end?
3.  Can you produce a current list of everyone with production access and justify each entry?
4.  Is staging in sync with production configuration right now?
5.  How many deployment steps require direct action from a named individual?

## How to spot which gaps to address first

_Key takeaway: Gaps that fail silently are the ones that compound into serious incidents. Visibility is the first step._

Prioritize based on two factors:

-   **How often does this gap affect you?** Weak rollback paths matter more if you deploy frequently. Configuration drift matters more in long-lived environments.
-   **How hard is it to detect when something goes wrong?** Gaps that fail silently, like access sprawl or environment inconsistency, deserve higher priority than those that produce immediate errors.

Start with the gap that is both common and hard to detect.

**Ready to review your delivery model with the Upsun team? Book a reliability review**

## Learn more

-   https://upsun.com/blog/dora-exit-strategy-for-financial-services/
-   https://upsun.com/blog/git-driven-environments-infrastructure-as-code/
-   https://upsun.com/blog/developer-guide-to-building-apps-without-infrastructure-burden/
-   https://upsun.com/blog/unified-cloud-management-platform/

### Frequently asked questions (FAQ)

**Is this relevant if we already have a security team running audits?** 

Yes, and it's complementary rather than duplicative. Most security audits focus on application code, network configuration, and access policies. The delivery layer (environment consistency, deployment process, configuration management) is frequently out of scope for a standard audit and is where structural gaps accumulate between audit cycles.

**How do we prioritize fixing these if we have limited platform engineering capacity?** 

Start with the gaps that are both common and silent. Configuration drift and unclear ownership are the two that cause the most downstream cost because they're hard to detect until they compound. Both can be partially addressed by moving infrastructure definition into version control, which doesn't require a dedicated platform team, just a change to how configuration is managed.

**What's the relationship between these weak points and compliance frameworks like SOC 2 or ISO 27001?** 

Several of the seven map directly to controls in both frameworks: access control patterns, configuration management, and deployment change records are explicit requirements in most compliance frameworks. Closing these gaps in the delivery layer doesn't just reduce operational risk; it generates the audit evidence those frameworks require as a byproduct of normal operations rather than as a manual collection exercise.

**How often should we run through this review?** 

At minimum, before a major release, before an audit, and after any significant team change (new hires, departures, or restructuring). In practice, teams with healthy delivery hygiene build some of these checks into their regular sprint cycle so that gaps don't accumulate between reviews.

### [When vibe coding blurs the lines between roles | Upsun](https://upsun.com/blog/vibe-coding-blurring-product-roles/)

# I thought I invented this. Then I opened TikTok

The video was a product manager who claimed she worked at Netflix. (Her claim, not mine. I have no way of verifying it, and I can’t find the video now.) She was talking about how Netflix now requires every PM to vibe code a working prototype before presenting an idea to engineering. Show, don't spec. Build the thing first.

I sat there for about ten seconds being mildly annoyed. Because I had been doing exactly that for the past few months and was quietly proud of myself for figuring it out on my own.

I'm not in product, technically. I'm in product marketing at Upsun. But we work closely with the product team and the analysts. I'm in roadmap conversations every week. So a few months ago I started vibe coding prototypes (that's the term we'll use once, for SEO, after this I'm calling it AI-augmented development, which is the same thing but sounds fancier and is harder to dismiss in a board meeting). Mostly I built them so I could stop describing ideas in words and start showing engineers the thing.

It worked so well I built a working clone of the Upsun console. Now whenever I want to show a new feature I've been thinking about, I open the clone, reshape it into the version I want to argue for, and share it. The conversation that follows is twice as good as the one I used to have with a slide deck.

I'm even leading a team in our next internal hackathon with one of these prototypes. The prototype is the pitch.

So when the TikTok told me Netflix was making this required, my first reaction was annoyance. My second was: oh. The walls between these roles are coming down faster than I'd realized.

## **The data caught up before the org chart did**

Stack Overflow's 2024 developer survey found 76% of respondents are using or planning to use AI in their workflow, and daily use jumped from 44% to 62% in a single year. McKinsey's State of AI report shows generative AI adoption nearly doubled in 2024. Gartner expects 80% of the engineering workforce to upskill on AI through 2027, and predicts that by 2030, "AI-native development platforms will result in 80% of organizations evolving large software engineering teams into smaller, more nimble teams."

Smaller teams. That phrase is doing a lot of work.

When a team gets smaller without the work getting smaller, you don't lose responsibilities. You smear them across the people who are left. The PM is doing more positioning. The PMM is doing more prototyping. The engineer is doing more product decisions. Everyone is doing more of everything, because AI-augmented development is eating the rote middle.

## **The people building products are saying the same thing**

Marty Cagan, who basically wrote the modern PM playbook, published a piece in May 2025 called "The Era of the Product Creator." His framing: the old division between PM, design, and engineering is collapsing into "a single individual who creates products," and the piece is written explicitly for "anyone wanting to create a successful product, regardless of professional training or experience."

Lenny Rachitsky has been making a similar argument: "AI product sense" is becoming the core skill of product management, and PMs are now expected to be hands-on with tools like Claude Code, Cursor, and v0. Shreyas Doshi puts it harder: "Product sense is the only PM skill that will matter going forward, because the rest can be approximated by a model with the right context." Aakash Gupta tracked 12,000+ people moving into AI-flavored PM roles between January 2024 and October 2025. He says prototype-first PM interviews are now a thing.

## **The CEOs aren't waiting**

Airbnb killed the standalone PM title in 2023. Brian Chesky's bet was that one person should own research, roadmap, delivery, positioning, messaging, and retention. The role they kept is closer to a PMM than a PM, but the work is all of it. Tobi Lutke at Shopify followed last April with the now-famous memo: AI use is the baseline, and before any team can request new headcount, they have to demonstrate why AI can't get the work done. Sam Altman keeps saying we'll see a one-person, one-billion-dollar company. Aaron Levie at Box describes the new individual contributor as "an agent manager."

These are not careful predictions. These are operating decisions.

## **The honest counter-argument**

Saeed Khan wrote a sharp response to the "AI will fix PM" crowd: producing artifacts is not the same as producing judgment, alignment, and vision. He's right about that. Stanford's recent piece on whether product management is dead lands in the same place. The PM role is evolving, not disappearing. Gartner's 2026 outlook warns that prompt-to-app approaches will increase software defects by 2500% by 2028.

So no, this isn't a clean replacement. The roles are not collapsing into nothing. They're collapsing into each other.

## **What I think is actually happening**

The crafts aren't dying. The walls between them are. Product still needs judgment. Marketing still needs taste. Engineering still needs rigor. But the moment between "I have an idea" and "here's a working version you can poke at" used to be measured in sprints. Now it's measured in afternoons. And the person doing that afternoon's work doesn't really care what's on their LinkedIn profile.

Going back to the Netflix PM on TikTok. Maybe Netflix actually requires this. Maybe she was making it up for the algorithm. The detail doesn't matter much. What matters is that I felt seen, and then I felt late, and then I realized the only thing that would have been embarrassing was thinking my job description was going to hold the line on its own.

I'm in product marketing. I'm also, apparently, in product. And in engineering, for two hours at a time, when the prototype needs to exist.

That's the job now.

### [What is environment drift costing your team | Upsun](https://upsun.com/blog/understanding-preventing-environment-drift/)

# Where to find lost engineering time in your delivery pipeline

## What is environment drift? 

_Key takeaway: If your infrastructure is configured outside version control through dashboards, scripts, or manual steps, environment drift is the expected outcome._

Most teams have lived this scenario. A feature works in staging but breaks in production. Two hours later, someone finds a configuration setting that was changed in staging three weeks ago and never documented.

That is what environment drift looks like in practice: small, undocumented differences between development, staging, and production that compound over time. It happens when infrastructure, data, dependencies, and access controls are managed inconsistently across environments, either through dashboard clicks, ad hoc scripts, or decisions that live in individual memory rather than in code.

No single change causes the problem. The problem is that each change is invisible to the rest of the team, and the differences compound with every deploy, every team member, and every environment.

## How environment drift affects your production speed

### **Engineering time spent on invisible work**

Debugging environment mismatches rarely show up on a sprint board, but it absorbs real capacity. Developers reproduce bugs that do not exist in their local setup or spend time reconstructing what production actually contains before they can act. It adds up; Atlassian's 2024 Developer Experience Report found that 69% of developers lose eight or more hours per week to inefficient work that does not appear on a roadmap but shows up in every sprint.

The calculation is straightforward: take your last three outages and count the hours spent on environment comparison or configuration reconstruction. That number is your drift baseline.

### **Slower releases and lower release confidence**

When environments are not synchronized, teams compensate with process: more manual checks before deployment, longer QA cycles, staged rollouts that are extended out of caution. It means the team does not trust what the environment actually contains.

Releases slow down not because the code is wrong, but because no one can verify that the environment is right.

### **Longer incident recovery windows** 

When something breaks in production and staging does not match, you cannot reproduce the issue in a safe environment. Recovery takes longer. Identifying the root cause takes longer. And the blast radius of any given incident expands.

Incident response time depends directly on how well your non-production environments reflect production. An environment you cannot trust during testing is also an environment that cannot help you during a crisis.

### **Duplicated tooling and accumulated overhead**

Teams that manage drift manually build tooling around it: sync scripts, environment-specific runbooks, pre-deployment checklists, and CI pipelines that differ per environment. Each workaround adds maintenance burden, and much of it has to be rebuilt when team composition changes. 

The pattern extends to incident response, 67% of developers still roll back code manually, a sign that automation gaps in the delivery process remain the norm rather than the exception.

**Book a cost-of-drift review and walk through the four cost areas with your own team data.**

## Quick self-assessment: where does your team stand?

_Key takeaway: The goal is not to measure everything; it is to find where your team loses the most time and start there._

Score each area from 1 to 3 using the descriptions below.

**Score of 10 to 12:** Your baseline is solid. Look for gaps in specific areas rather than a wholesale change.

**Score of 6 to 9:** Drift is present and costing you. The question is where it hurts most.

**Score of 4 to 5:** Environment management is adding cost and risk that is not offset by control or visibility.

## What changes in a more standardized model

_Key takeaway: A git-driven environment model makes operational decisions visible, reversible, and shared across the team rather than scattered across dashboards._

The structural fix for environment drift is to put your infrastructure definition under version control alongside your code. When your full-stack apps, services, routes, and environment variables are declared in a versioned file, every environment is built from the same source of truth, with no manual synchronization or anything to drift from.

On Upsun, that file is `.upsun/config.yaml`, committed to your repository. Here is what changes in practice:

-   **Every branch creates an environment** that inherits configuration, data, and services from its parent.
-   **Infrastructure changes go through pull requests**, just like application code.
-   **Rollback is a Git revert**, not a manual reconfiguration.
-   **Onboarding a new developer** means cloning a repository, rather than receiving a handover document of dashboard settings.

When infrastructure is code, it is reviewable, auditable, and reproducible. The knowledge stops living in individual memories and starts living in an accessible repository.

**Try the pricing calculator and see how Upsun's usage-based pricing compares to what your team currently spends** 

**Next step**

Go back to the self-assessment table and add up your scores. If the total is below 6, environment management is already costing your team more than it should. Pick the area where you scored lowest and work through the corresponding section of the checklist; that is where the most recoverable time is.

If you want to see what a standardized environment model looks like in practice, this walkthrough covers how Upsun clones production with full data, files, and services.

**Read more:**

-   Instant data-complete preview environments 
-   Data cloning for developing cloud-based applications 
-   Why cloud primitives quietly drain developer time
-   Why AI agents fail on fragmented stacks

### FAQ

**What is environmental drift?** 

Environment drift is the gradual accumulation of undocumented differences between development, staging, and production environments. It happens when infrastructure, data, and access controls are managed inconsistently through dashboard changes, manual scripts, or decisions that are never captured in code.

**What causes environment drift in software development?** 

The most common causes are infrastructure configured outside version control, environment variables added manually and never propagated, service versions that fall out of sync between environments, and deployment processes that differ between staging and production.

**How does environment drift affect development teams?** 

It slows release cycles, reduces release confidence, and makes production bugs harder to reproduce. Teams compensate with longer QA cycles and manual pre-deployment checks, which adds overhead without fixing the underlying problem.

**Can environment drift affect AI agents?** 

Yes. An AI agent that reads environment state to take action gets incorrect context from a drifted environment and acts on what it sees, not on what is true in production. Inconsistent environments are one of the main reasons AI agents produce unexpected or incorrect outputs in development workflows.

**How do you prevent environment drift?** 

Keep infrastructure configuration in version control alongside application code, automate environment provisioning from branch pushes, and test against production-cloned data rather than synthetic datasets. The goal is to make every environment a reproducible copy of the same source of truth.

### [How platform standardization helps your KPIs | Upsun](https://upsun.com/blog/how-platform-standardization-improves-engineering-kpis/)

# How platform standardization will help you deliver on your KPIs

IT leaders rarely think they have an infrastructure problem. When a roadmap slips or an audit finding lands, the reflex is to hire more senior engineers, a bigger platform team, another DevOps lead. 

But headcount is rarely the real lever. 

The bottleneck is the "hidden factory": the undocumented, invisible work that sits between a developer writing code and that code reaching customers. It doesn't show up in post-mortems because engineers treat the workarounds as normal. 

Compounded across five or ten teams, it's the single biggest leak in your delivery capacity and the reason your KPIs keep stalling, no matter how many people you add.

## The shift: from team optimization to org-wide delivery

_Key takeaway: For a decade, engineering orgs optimized at the team level. That model is now the ceiling on enterprise delivery and the reason IT middle management (ITMM) KPIs keep slipping despite growing investment._

The old playbook was to give every team autonomy over their stack, their pipeline, and their definition of "done." It worked when teams shipped in isolation. It breaks the moment delivery becomes a cross-functional commitment: a launch date, an audit deadline, a compliance posture, a customer SLA.

The market has already voted on this. DORA's 2025 State of AI-assisted Software Development report, surveying nearly 5,000 technology professionals, found that 90% of organizations now use an internal developer platform, and 76% have a dedicated platform engineering team. Platform engineering has moved from experimental to essential. The question is no longer _whether_ to standardize, but whether your platform is high-quality enough to actually move your KPIs. 

When each team has its own path to production, leadership loses the two things they need most: a predictable delivery cadence and a defensible security posture. You can't forecast what you can't standardize, and you can't govern what every team does differently. 

The shift ITMMs need to make is from optimizing inside teams to standardizing between them. Moving the operational logic into a platform layer so every team inherits the same speed, the same controls, and the same guarantees.

## The drag you're probably ignoring

_Key takeaway: Most engineering friction is invisible to leadership because developers absorb it as "normal." Naming it is the first step to removing it._

In fragmented orgs, engineering looks less like a factory and more like a collection of custom workshops. The drag shows up in four predictable patterns:

-   **The snowflake workflow.** Team A has its own deployment scripts; Team B uses a different CI/CD tool. When a lead engineer leaves, the production path leaves with them. And you're paying a retention premium just to protect institutional knowledge.
-   **The staging traffic jam.** A team of ten ships at the speed of three because everyone is queued behind the same staging environment. Parallel work serializes into a crawl, and your delivery forecast quietly slips by a sprint.
-   **Compliance as a penalty.** Security shows up at the end of the cycle as a manual gate rather than a property of the platform. Every release becomes a negotiation, and every audit becomes a fire drill.
-   **The parity gap.** "Works on my machine" is still the top reason deployments fail. When dev, staging, and production are merely similar rather than identical, you're not testing, you're hoping.

None of these line items appear in a budget. All of them tax your KPIs. The question is how much, and what it would look like to eliminate them.

**See how to standardize app delivery across multiple teams and eliminate the complexity tax.**

## Why hiring doesn't fix it

_Key takeaway: Adding engineers to a fragmented process multiplies the cost of fragmentation. The system has to change before headcount can pay off._

Hiring more DevOps talent into a fragmented org is like adding lanes to a highway that still funnels into a single tollbooth. Every new engineer inherits the same undocumented workflows, the same staging queue, the same manual compliance handoffs. And now there are more people paying that tax, not fewer.

The same logic now applies to AI investment, and the data is unambiguous. DORA's 2025 research found that high-quality internal platforms amplify AI's benefits across the organization, while low-quality platforms make AI's impact negligible. Individual productivity gains from AI tools get absorbed by downstream bottlenecks in deployment and testing — meaning the gains never reach the business. AI doesn't fix a fragmented delivery system; it just makes a faster mess.

This isn't an argument against hiring. It's an argument against hiring _first_. Until the path to production is standardized, every additional engineer increases coordination cost faster than they increase output. The leaders who get the most leverage from their platform teams are the ones who fix the system before they scale the team against it.

## What changes when the platform handles the "how"

_Key takeaway: Moving environment, pipeline, and compliance logic into a platform layer turns delivery speed and audit posture into properties of the system rather than acts of heroism._

The fix is to move operational logic into a Golden Path: a standardized, opinionated route from commit to production that every team uses by default. The boring parts get automated so your most expensive talent works on product, not plumbing.

-   **Speed becomes predictable.** When a developer pushes to Git, the platform handles the rest. The same configuration runs in every environment. Shared staging is replaced by isolated, on-demand clones, so engineering and QA work in parallel instead of in line. Cycle times stop depending on which team is shipping.
-   **Security becomes inherited.** IBM's 2025 Cost of a Data Breach Report puts the global average breach at $4.44 million, with the US average hitting a record $10.22 million. The same report found that organizations using extensive security automation saved nearly $1.9 million per breach and shortened the breach lifecycle by 80 days; a DevSecOps approach alone reduced breach costs by an average of $227,000.   
      
    When the underlying platform is already SOC 2 or HIPAA compliant, every team that ships through it inherits those controls. Vulnerability scanning and data scrubbing happen at the platform layer, not as a sprint task. You stop "preparing" for audits because the evidence is a permanent byproduct of how you ship.
-   **Standardization becomes the speed advantage.** This is the point most leaders miss: standardization isn't the opposite of speed; it's the source of it. The teams shipping fastest aren't the ones with the most freedom; they're the ones who don't have to make infrastructure decisions at all.

## What to standardize first

_Key takeaway: You don't need to rewrite applications to start. You need to standardize the path to production in a deliberate order, so each layer compounds the value of the next._

Most standardization efforts stall because leaders try to fix everything at once. A sequenced rollout works better:

1.  **Environment definitions.** Codify dev, staging, and production as a single declarative configuration. This closes the parity gap and ends "works on my machine", the highest-frequency, lowest-effort win available.
2.  **The deployment pipeline.** Standardize the route from commit to production. One pipeline, one set of gates, one definition of "shipped." This is where speed gains compound across teams.
3.  **Access and secrets.** Centralize how credentials, permissions, and environment variables are managed. This is where most audit findings live and where the largest security risk hides.
4.  **Observability and rollback.** Make logs, metrics, and rollback behavior consistent across services. This is what turns incident response from improvisation into a process.

Done in this order, each layer makes the next one cheaper to implement, and every team that onboards inherits the full stack of guarantees.

If you're losing ground to competitors who ship faster, the question isn't whether you have enough developers. It's how many hours a week your developers are spending on plumbing they shouldn't see, and how many of your KPIs are quietly being set by that number.

## Frequently asked questions (FAQ)

**Doesn't standardization kill developer autonomy?** 

No, it relocates it. Developers stop making decisions about infrastructure plumbing and start making more of them about product. Autonomy over what to build is more valuable than autonomy over how to deploy it.

**How do we start standardizing without halting current delivery?** 

Start with the path to production, not the applications. Codify environment definitions and pipeline gates first, then onboard new projects to the Golden Path from day one. Existing services migrate opportunistically, not in a big-bang rewrite.

**How does this improve security and compliance posture?** 

When the delivery process is standardized, controls live in the platform rather than in each team's process. Vulnerability scanning, secret management, and audit evidence are produced automatically on every deployment, which is what makes compliance defensible at scale. It also closes a measurable gap: according to IBM's 2025 Cost of Data Breach Report, organizations with platform-level automation saved an average of $1.9M per incident.

**What's the impact on the bottom line?** 

Standardization shrinks the hidden factory of manual rework, reduces emergency response cost, and frees senior engineering hours for product work. The compounding effect, fewer incidents, faster cycles, cleaner audits, is what shows up in R&D ROI.

**When is the right time for an ITMM to invest in this?** 

Before the next audit, the next major launch, or the next platform hire, whichever comes first. Each of those events is significantly cheaper on a standardized platform than on a fragmented one.

### [POCs are cheap now - here's what changed | Upsun](https://upsun.com/blog/pocs-are-cheap-ai-augmented-development/)

# Code isn't cheap, but POCs are

I keep hearing the phrase "code is cheap."

I don't know who came up with it. Whoever it was clearly has not seen an Anthropic bill.

I get what they mean. The cost of writing a line of code has cratered, AI does most of the typing, you know the rest. Fine. But the phrase is combative in a way that doesn't help anyone, especially the engineers in the room. "Code is accessible" lands better. Less swagger, more honesty.

Either way, here's the line my friend Guillaume gave me that finally cracked it open. "My young daughter can write code. That doesn't make her an engineer."

Right. Because what got cheap isn't engineering. It isn't even code, really. What got cheap is the proof of concept. The hacky working thing that demonstrates an idea. The artifact a product marketer like me used to need a skilled developer to build.

The better phrase: POCs are cheap now.

I'd know. It's what I do.

## **What "POCs are cheap" actually means**

A few months ago, if I wanted to demonstrate a feature idea, I had three options.

Write a long, careful spec doc and hope it gets read. Build a Figma mockup that looks done but can't be clicked through. Or beg an engineer for an hour of their time to mock something up.

Now I have a fourth. Vibe code a working version myself (using that term exactly once for SEO purposes, after this it's AI-augmented development, which is the same thing but sounds fancier and is harder to dismiss in a board meeting).

The trick isn't that I learned to code. I didn't. The trick is that the model carries the technical load and I carry the product judgment. I describe the idea the way I'd brief a senior engineer. I read what comes back. I push it around until the thing in front of me matches the thing in my head. Two hours, maybe three. Then I share it.

Andrej Karpathy coined the term in February 2025. The internet had opinions about whether you're "really" coding when you do this. The internet had the wrong question. The right question is whether the artifact moves the conversation forward. It does. Reliably. Every time.

Guillaume's daughter isn't an engineer. But she could prototype an idea now. So could her teacher. So could your PMM.

## **The pattern in reverse**

Here's the part I didn't expect.

My engineering friends are doing positioning work that's better than some of what I used to ship.

Not all of it. They're not going to take my job. But specific pieces of the work, the parts where you're hunting for the right angle on a feature, or the right way to describe the thing to a customer, or the competitive line that makes the demo land, my engineering friends are coming back with strong drafts.

The pattern is the same as mine, mirrored.

We give them the foundation. ICP. Personas. Buying habits. Competitors. The way our customers actually talk about the problem. They feed all of that to an AI alongside the feature they just built, and they come back with positioning angles I would have spent a week generating in a marketing-team workshop.

The AI didn't do it alone. It needed the context. That context is the part marketing actually owns. But the synthesis, the moment where you stare at the brief and try to find the line that makes everything click, the AI is good at that when you give it the right inputs.

Same dynamic as my POCs. The AI carries the load. The human carries the judgment about what's actually right. Different role on each side of the team.

## **What this means for how teams work**

This isn't a "marketing should learn to code" article. Or a "engineers should learn marketing" article. Those framings miss it.

What's actually happening: the collective brain of a small team got a lot bigger. AI-augmented development gave the non-engineer access to working prototypes. AI-augmented positioning gave the non-marketer access to sharp angles. The crafts haven't moved. The boundary fence got a lot of new doors.

The teams that figure this out fast end up with shorter feedback loops. The PMM walks into the roadmap meeting with a working prototype. The engineer walks into the launch meeting with three positioning drafts. Nobody is starting from a blank page. The conversation skips the first 60% and goes straight to the part where the team is actually deciding something.

The teams that don't figure it out keep treating these as one-way streets. The PMM writes the brief, the engineer writes the code, neither of them touches the other's work. Same speed as five years ago. Worse, even, because everyone else is moving faster.

## **The tradeoff I owe you**

POCs being cheap doesn't mean they're free of risk.

The biggest risk isn't the code. It's the meeting after. A working POC creates the illusion of completeness, and the natural next question is "let's ship it." That's where teams get into trouble. The code I write in an afternoon is not the code anyone should run in front of customers. Gartner warned that "prompt-to-app approaches adopted by citizen developers will increase software defects by 2500%" by 2028. They're right about what happens when nobody draws the line between POC and production.

Draw the line out loud. The POC is the conversation. The product is what gets built afterward, by engineers, with rigor. The engineer's positioning draft is the spark. The launch copy is what marketing builds afterward, with craft. Don't ship either of them straight from AI to the customer.

## **Back to the Anthropic bill**

I want to be honest about one more thing. Code isn't cheap. Tokens cost real money, and I've watched my team's bill climb every month as we lean harder into this workflow. The cost just moved. It used to be developer hours. Now it's compute. The math still pencils out, by a lot, but pretending the cost vanished is how teams end up with quarterly surprises.

Guillaume's daughter still isn't an engineer. She can prototype an idea now. So can my PMM team. So can my engineer doing positioning. The titles don't change. The toolkit does.

That's what we should be saying out loud, in the meetings where the org chart still pretends those three jobs live in three different rooms.

Code is accessible. POCs are cheap. The team is bigger than the headcount.

In the next post, I'll walk through exactly how I build these prototypes: Claude Code, Upsun, and the specific skills, plugins, and MCPs that let a product marketer ship something a real engineer can react to in an afternoon.

### [Native database autoscaling is here | Upsun](https://upsun.com/blog/postgresql-mariadb-database-read-replica-autoscaling/)

# Native, full-stack autoscaling on Upsun: PostgreSQL and MariaDB read replicas now autoscale

Application autoscaling has existed for years. Database autoscaling has lagged behind. Today, that changes on Upsun.

Managed PostgreSQL and MariaDB read replicas now autoscale, joining worker autoscaling in production since March 2026. Apps, workers, and managed databases all autoscalead replicas saturate first, connection pools max, someone getse on one platform - natively, without a third-party database engine or a Kubernetes layer to operate.

Three operational headaches just disappeared. Here's what changed.

### The 2am page about your database, gone

The application usually survives the traffic spike. The database is where things break. Read replicas saturate first, queries queue, someone gets paged.

Starting today, Upsun automatically adjusts read replica capacity in response to CPU and memory usage. When workload pressure rises on the replicas, more are added; when pressure falls, capacity is released. Scaling is dynamic - no restart, no failover, no plan-upgrade window.

**The outcome:** traffic spikes from launches, campaigns, or seasonal events stop turning into database incidents.

### The pre-scale ritual, retired

The calendar reminder before a high-traffic event to _"manually bump worker capacity"_ - and the follow-up reminder to _"manually scale back down two weeks later"_ that nobody actioned - those go away.

Worker autoscaling has been live since March 2026, scaling on CPU and memory usage. Payment processing, video transcoding, AI inference, scheduled batch - anything async - stopped backing up during traffic spikes. Today's release extends the same primitive to managed databases.

**The outcome:** the DevOps tax of manually configuring scaling tools goes away. Routine capacity events stop being calendar items.

### The peak-capacity bill, normalized

Most teams over-provision the database tier - sizing it for the worst peak hour of the worst peak day, paying for that capacity 24 hours a day. For cyclical workloads, that's a significant share of capacity sitting unused most of the time, showing up on every invoice.

Upsun Autoscaling scales down as well as up. Capacity is removed when traffic falls.

**On the invoice:** spend tracks actual usage.

### How it actually works

Upsun monitors CPU and memory usage across worker pools and managed databases - the signals that directly reflect resource pressure. When workloads push CPU or memory up, Upsun adds capacity; when the load falls, capacity is released. Replicas join and leave the running cluster without restart or failover.

### Native, full-stack autoscaling

Autoscaling shouldn't stop at the application layer. With database read replica autoscaling, Upsun now scales applications, workers, and managed databases together - natively, on one platform. No third-party database engine to integrate. No Kubernetes layer to operate. Infrastructure that scales as a system, not as disconnected parts.

-   **Ready to get started?** **Enable autoscaling on your project**
-   **Have questions?** **Talk to us**

### [Why high-velocity teams standardize first | Upsun](https://upsun.com/blog/why-fastest-teams-standardize-first/)

# Why the fastest teams standardize first

There's a version of this conversation that plays out in engineering organizations everywhere. Leadership pushes for standardization. Developers push back. The argument from developers is reasonable on its face: every codebase has different needs, every team has tools they're good at, and adding process feels like slowing down to go faster. It's a genuine tension, and it's also a false one.

The teams that ship the most aren't the ones with the most infrastructure freedom. They're the ones who've eliminated the infrastructure variables that make shipping unpredictable. Standardization isn't the constraint on velocity. It's the foundation of it.

### **Ad hoc velocity vs. repeatable velocity**

_Key takeaway: Ad hoc speed is a liability. It scales with individuals, not with the organization, and it compounds into a structural drag that no amount of hiring can fix._

There are two distinct types of velocity in software delivery, and most organizations are only measuring one of them.

1.  **Ad hoc velocity** is what you have when speed depends on specific people knowing how a specific environment was built. It feels fast, until a deployment fails and the only person who can fix it is unavailable. Until an engineer leaves and takes the production path with them. Until a new developer joins and spends their first two weeks not building anything because no documented, reproducible setup exists. Ad hoc velocity isn't really velocity at all. It's institutional knowledge running on a countdown timer.
2.  **Repeatable velocity** is what you get when the path to production is codified, automated, and identical for every team. Any developer can spin up a working environment in minutes. Deployments don't depend on who's on call. New team members are productive in days, not weeks. The process is deterministic rather than a tribal ritual performed by whoever's been there longest.

The performance gap between these two states is not theoretical. DORA's 2024 research found that elite-performing engineering organizations deploy 182 times more frequently than low performers, with 127 times faster lead times for changes and 8 times lower change failure rates. The difference between those cohorts isn't headcount, budget, or talent density. It's the degree to which delivery has been systematized rather than left to individual variation. 

### **Reducing variability to optimize output**

_Key takeaway: Engineering throughput is throttled by variability. Before you can optimize output, you have to standardize the conditions under which work happens._

In manufacturing, you can't improve throughput if the parts don't fit together consistently. The same principle applies to software delivery. When every team runs different database versions, uses different deployment scripts, and manages environments through undocumented tribal knowledge, variability is baked into every cycle. You can't measure it, can't predict it, and can't fix it by working harder.

The invisible cost shows up in the budget before it shows up anywhere else. McKinsey's research found that 30% of CIOs report that more than 20% of their technology budget dedicated to new products is diverted to resolving tech debt. 

Infrastructure variability is one of the primary mechanisms by which that diversion happens: undocumented configuration, inconsistent environments, and bespoke pipelines that require constant maintenance rather than building product. 

The fastest teams have solved this by standardizing the parts of delivery that don't require creative judgment. Here's how that works in practice at the org level: 

**See how to standardize app delivery across multiple teams and move from ad hoc speed to repeatable velocity.**

-   **Environment parity.** Dev, staging, and production run identical configurations. The time-wasting gap where a bug only exists in one environment disappears because the environments are clones, not approximations.
-   **Deployment logic.** A single, version-controlled configuration file defines how every application interacts with its dependencies. No undocumented tweaks. No snowflake servers. No institutional knowledge required to ship.
-   **Security guardrails.** Compliance and data scrubbing are properties of the platform, not sprint tasks. Security doesn't arrive at the end of the cycle as a gate; it's inherited by every team that ships through the standard path.

None of this reduces what developers get to decide. It eliminates the decisions that shouldn't require a developer at all.

### **Enabling safe speed at scale**

_Key takeaway: Standardization doesn't slow teams down. It gives them the brakes that make it safe to go faster. And the capacity recovered is significant enough to show up in the budget._

The car analogy holds here: better brakes let you drive faster, not slower, because you have control. A standardized platform is the control layer. Automated deployment removes the risk of manual error at the point where errors are most expensive. Consistent environments remove the variability that makes "this will take about three days" a guess rather than a forecast.

The capacity argument is equally direct. At IDPCON 2025, Hariprasad Babu, Manager of Technology at H&R Block, put the problem plainly: "Developers spend 40 to 60 percent of their time on non-coding, non-strategic work." His team's response was to build a standardized internal developer platform that automated the manual, repetitive tasks draining velocity, and the results were measurable: mean time to resolution dropped from up to 24 hours to under one hour. That's not a marginal efficiency gain. It's the difference between an engineering organization defined by its toil and one defined by its output.

That recovered capacity doesn't come from hiring. It comes from eliminating the work that shouldn't exist in the first place. Senior engineers stop being accidental DevOps leads who spend half their week fixing broken staging environments. Junior developers stop losing their first month to environment setup. The platform handles the how, so every team can focus entirely on the what.

Standardization isn't the thing that slows fast teams down. It's what fast teams did first.

**Read the checklist to reduce environment drift and start standardizing your delivery today.**

### **Frequently asked questions (FAQ)**

**Does standardization mean every team has to use the same language or framework?** No. Standardization operates at the platform layer: how code is deployed, how environments are defined, how security gates are applied. Teams retain full freedom over the technical choices that determine product value: language, framework, architecture. The standard governs the connectors, not the components.

**Won't this reduce developer autonomy?** 

It relocates it. Right now, developers in fragmented organizations spend significant time on infrastructure decisions that aren't product decisions: managing environments, debugging deployment scripts, rebuilding staging servers. Standardizing those removes low-value decisions and returns time for high-value ones. Autonomy over what to build is worth more than autonomy over how to deploy it.

**How do senior engineers benefit from this?** 

Directly. In fragmented organizations, senior engineers become the de facto owners of every bespoke environment they've ever touched. They're pulled into incidents not because the problem requires their expertise, but because they're the only ones who remember how the system was set up. Standardization gives that time back, and redirects it to the work they were actually hired for.

**What if a team genuinely needs to deviate from the standard?** 

Standards should be defaults, not mandates. A mature platform allows for documented deviation. A team can diverge with a clear record of why and what the tradeoff is. In practice, when the standard path is also the fastest path, most teams choose it without being asked. You're not enforcing compliance; you're making compliance the path of least resistance.

**When does ad hoc velocity become a business risk rather than just a technical problem?** 

The moment a key engineer leaves, a critical deployment fails outside business hours, or a new hire can't get a working environment in under a week. Each of those events is a forcing function. The organizations that treat them as isolated incidents keep paying the infrastructure tax indefinitely. The ones that treat them as structural signals are the ones that build repeatable velocity, and eventually, a significant speed advantage over competitors still running on tribal knowledge.

### [How to reduce environment drift without slowing down | Upsun](https://upsun.com/blog/checklist-reduce-environment-drift-developer-velocity/)

# Checklist: how to reduce environment drift without slowing devs or AI agents

## How environment drift slows your team down

_Key takeaway: Environment drift persists when teams standardize code but leave infrastructure, data, and access decisions to individual teams and manual setup._

Most teams know their environments are not identical. What they underestimate is how quietly the gap widens. A database version is out of sync between production and staging; an environment variable is added manually to one server but never tracked; a cron job runs in production but was never captured in the dev config. None of these feels significant at the time, but they compound into bugs that are genuinely hard to reproduce and even harder to explain to a customer.

The cost goes beyond developer frustration.  Environment drift means two environments that are supposed to behave the same no longer do. That gap can come from different config files, services, data, permissions, or deployment paths.

An agent that reads environment state to take action gets incorrect context from a drifted environment and acts on what it sees, not on what is actually true in production. Left unaddressed, drift only gets more expensive to untangle.

The checklist below covers the four areas where drift most commonly enters a workflow.

**Identify where environment drift is slowing your team down**

## Is your configuration actually the same everywhere?

_Key takeaway: If your config is not in code, it will drift. Every manual change is a future debugging session waiting to happen._

Most drift originates in configuration. The diagnostic question is simple: Is your infrastructure defined in one place, or scattered across servers and memory?

Ask your team:

-   Are service versions (databases, caches, search engines) defined in a single, version-controlled file shared across all environments?
-   Are environment variables managed centrally, with per-environment overrides explicitly tracked rather than set ad hoc?
-   Are any infrastructure settings applied manually, outside of code?

If the answer is yes, you have already found drift. Manual settings are the most common source because they are invisible to code review, untracked in Git, and forgotten during onboarding. On Upsun, infrastructure, services, and routing are defined in a single declarative `.upsun/config.yaml` file that applies consistently across every environment. There is no separate staging config to keep in sync. 

## Does your deployment process introduce inconsistency?

_Key takeaway: Manual deployment steps are a drift waiting to happen. Every step that lives in a runbook rather than in code is a reliability risk._

Configuration drift and deployment process drift are closely related. When deployment involves manual steps, environment-specific runbooks, or tooling that differs across environments, inconsistency is built into the process rather than occurring by accident.

Ask your team:

-   Does every environment use the same build pipeline and deployment tooling?
-   Are there manual steps in your deployment runbook that do not exist in an automated pipeline?
-   Can a developer spin up a new environment from scratch without following a wiki page?

If your answer to any of these is no, your deployment process is generating drift on every release. The fix is removing the manual steps entirely.

When deployment is Git-driven and fully automated, environment consistency becomes structural. On Upsun, every branch pushes provisions to an environment automatically using the same declarative config as production, with no runbooks and no manual steps in the critical path. 

## Are your access controls consistent across environments?

_Key takeaway: Access drift is a security issue, not just an operational one. Consistent permission boundaries prevent both human errors and agent failures._

Access parity is frequently overlooked in drift audits, but it matters both operationally and for security. When environments carry different permission structures, teams build workarounds that introduce further inconsistency, and automated agents operate without clear boundaries.

Use this checklist:

-   Are permissions grouped by environment type, such as production, staging, and development?
-   Are preview environments governed by explicit access rules instead of ad hoc sharing?
-   If production data is cloned to child environments, is sanitization built into non-production workflows where needed?

Upsun provides environment-level access scoping for both users and agents, so teams define exactly what each environment permits before anything runs in it.

## Are you actually testing against production conditions?

_Key takeaway: The closer your test conditions are to production, the fewer surprises you get on release day. Synthetic data is not a substitute for a production-like state._

Tests that pass in staging but fail in production usually share a single root cause: the data or service state differs. Synthetic test data hides the schema edge cases, volume thresholds, and relational complexity that only emerge with real data.

Ask your team:

-   Do your test environments use data that reflects production data volume and structure?
-   Are database schema migrations tested against a production-representative dataset before deployment?
-   Are service dependencies consistent in behavior across environments?

If your team is testing against a stripped-down or anonymized dataset that does not reflect production structure, you are testing for a system that does not exist. Upsun supports data cloning from production into preview environments, which are paused when inactive rather than deleted, preserving their state between sessions for debugging and review.

## Where to start

Work through these four actions in order. Each can be completed in under a day:

1.  **Config audit.** Compare service versions across all environments and document every divergence.
2.  **Pipeline review.** List every manual deployment step. Pick one and automate it this sprint.
3.  **Access audit.** Confirm staging and production credentials are separate, and scope any AI agents to specific environments with defined permissions.
4.  **Data clone.** Run a production data clone into your lowest environment and note what breaks.

None of these requires a platform migration. They are diagnostic steps that reveal where drift has already taken hold and give your team a clear, prioritized starting point.

## Frequently asked questions (FAQ)

**How does Upsun help teams fix environment drift without slowing developers down?** 

Every branch push on Upsun provisions an environment automatically using the same declarative config as production. There are no separate runbooks, no manual sync steps, and no environment-specific pipelines to maintain. 

**How do I know if my team has an environment drift problem?**

 If your team regularly sees bugs in production that cannot be reproduced in staging, spends time before releases manually verifying environment settings, or relies on one or two people who "just know" how production is configured, drift is already present. 

**Why does environment drift make incident recovery slower?** 

When production and staging do not match, you cannot reproduce the issue in a safe environment. That means debugging happens in production, root cause analysis takes longer, and the blast radius of any incident expands. The closer your non-production environments reflect production, the faster your team can isolate and resolve problems.

**Can environment drift affect AI agents?**

 Yes. An AI agent that reads the environment state to take action gets incorrect context from a drifted environment and acts on what it sees, not on what is true in production. Inconsistent environments are one of the main reasons AI agents produce unexpected outputs in development workflows, and the risk grows as teams give agents more autonomy.

### [How to standardize app delivery | Upsun](https://upsun.com/blog/standardizing-app-delivery-without-internal-platforms/)

# A practical guide to standardizing app delivery without rebuilding everything internally

## Standardizing app delivery starts with removing avoidable variation

_Key takeaway: Standardize the route from code to production. Everything else is a team decision, not a platform problem._

Most app delivery problems do not start with bad engineering. They start with too much variation.

One team provisions environments manually. Another keeps deployment notes in a wiki. A third has a staging setup that only one engineer understands. Security reviews happen late because the platform does not make the safe path obvious.

The result is predictable:

-   Slower releases
-   More environment drift
-   Harder audits
-   More dependency on senior engineers
-   More production risk from “small” infrastructure differences

Environment drift means development, staging, and production stop behaving the same way. The code may be identical, but the services, data, configuration, permissions, or routes differ enough to make testing unreliable.

Standardization fixes that only when it targets the right layer. The goal is to standardize the route from code to production.

## Why internal platform ownership gets expensive fast

_Key takeaway: The cost of an internal platform is not the build. It is the permanent staffing, maintenance, and opportunity cost of keeping it current._

Building an Internal Developer Platform (IDP), a self-service layer that abstracts infrastructure complexity from application developers, requires more than an initial engineering effort. It requires sustained ownership.

The real cost of building an IDP is everything that comes after: security patches, dependency upgrades, technical debt, and onboarding new engineers to a system that only three people fully understand. That work does not go away; it grows with the platform.

And here is the compounding problem: the reason most teams want a platform in the first place is to stop developers spending time on infrastructure instead of product work. An in-house platform does not eliminate that drain. It relocates it from your application teams to the platform team, which you now have to hire, retain, and keep funded indefinitely.

The risks compound quickly:

-   **Scope creep:** Platforms grow. What starts as a deployment abstraction becomes a portal, a cost dashboard, a secrets manager, and a compliance layer.
-   **Talent dependency:** Maintenance is an infinite loop. Migration is a bounded project. The engineers who build your platform become the engineers who can never leave it.
-   **Adoption failure:** Developers will find workarounds before they file a ticket asking for a better experience. If the platform was not built around how your teams actually work, it will not get used  and you will still be paying to maintain it.

**Not sure where your delivery inconsistency actually lives? Book a platform review**

## A cloud application platform covers the repeatable delivery layer

_Key takeaway: The strongest use case for a cloud application platform is the repeatable work around running applications, not the business logic that makes your organization different._

A cloud application platform is a managed application runtime environment with integrated capabilities to manage the application lifecycle. They typically support cloud-style operations such as self-service without requiring teams to manage infrastructure provisioning or containers directly.

That distinction matters. A cloud application platform is not a replacement for architectural judgment. It does not remove the need for governance. 

It gives teams a standard operating model for the delivery layer.

For Upsun, that model is Git-driven. Git is the primary tool for managing what an app needs to run, with configuration controlled through YAML files that describe your infrastructure, transparent and version-controlled. That gives IT leaders a practical middle ground:

-   Developers still work from code.
-   Infrastructure configuration is visible.
-   Environments follow a consistent pattern.
-   The platform handles much of the repeatable operational work.

Upsun also supports on-demand environments tied to Git branches. New environments can inherit data and services from a parent environment, including databases, network storage, queues, and routing configurations.

That is useful because standardization becomes part of the workflow, not a separate governance meeting.

## The capabilities that actually matter

_Key takeaway: Most teams need the same core set of things. Overbuilding to cover edge cases you do not yet have is a common failure mode._

Not everything needs to be custom. Most teams need:

1.  **Consistent environment configuration**: dev, staging, and production should behave the same way. Configuration should live in version control, not someone's head.
2.  **Repeatable deployments**: Every merge to a branch should produce a predictable, reviewable environment.
3.  **Self-service provisioning**: Developers should be able to spin up environments without opening a ticket or waiting for an ops engineer.
4.  **Observability hooks**: Logs, metrics, and alerts need to exist by default, not as bolt-ons.

These four things cover the vast majority of what platform teams build from scratch. If most of your workflows are standardizable, buying works well. If your workflows are deeply custom, building may be justified. Most teams overestimate how custom their workflows actually are.

**Discover what a standardized delivery architecture looks like in practice**

**Before you build: questions worth answering honestly**

_Takeaway: If you cannot clearly articulate what problem you are solving, who owns the solution, and how you will measure success, do not build yet._

Before committing to a build, answer these questions honestly:

-   Is the inconsistency you're addressing in the deployment layer or in team processes and culture? 
-   Do you have a platform team that will own this as a product, or are you assigning it to engineers between other projects? 
-   What is the actual cost of the status quo?
-   Are you solving a real problem at your current scale, or anticipating a problem you might have in two years? 

## Next step

Standardizing app delivery does not require rebuilding your infrastructure from scratch. It requires being precise about which layer of the problem you are actually solving.

Map your current deployment workflow. Identify where inconsistency lives. Then ask: is this a configuration problem, a process problem, or a tooling gap? The answer will tell you whether you need to build, buy, or do a bit of both.

## Frequently asked questions (FAQ)

**What is an internal developer platform (IDP)?** 

An internal developer platform is a self-service layer that abstracts infrastructure complexity from application developers. It typically gives developers the ability to provision environments, deploy applications, and access infrastructure without filing tickets or waiting on an ops engineer. The platform is built and maintained internally, which means it requires dedicated ownership to stay current.

**Should I build or buy an internal developer platform?** 

Build if your compliance, security, or workflow requirements genuinely cannot be met by an available product, and you have a dedicated team to own it long-term. Buy or use a managed platform if your team's primary job is product delivery and your infrastructure needs are relatively standard. Most teams overestimate how custom their workflows actually are.

**What is environment drift and why does it matter?**

 Environment drift occurs when development, staging, and production stop behaving the same way. The code may be identical, but differences in services, configuration, permissions, or routing make testing unreliable and increase production risk. It is one of the most common sources of "it works on my machine" failures.

**What capabilities do most teams actually need to standardize app delivery?**

Most teams need four things: consistent environment configuration across dev, staging, and production; repeatable deployments tied to Git branches; self-service environment provisioning; and observability hooks for logs, metrics, and alerts by default. These four capabilities cover the majority of what platform teams build from scratch internally.

### [8 Stages of AI Engineering Maturity for Teams | Upsun](https://upsun.com/blog/8-stages-ai-engineering-maturity/)

# The 8 stages of AI engineering maturity: a framework for teams

A few months ago, Steve Yegge published his 8 levels of AI-assisted development, and it clicked the moment I read it, because I had lived that exact progression myself, moving from autocomplete to running agents one step at a time. Framed as an AI trust gradient, it finally gave the industry a vocabulary for something most of us were already going through without a name for it. If you haven’t read it, save it for later.

Yegge's levels focus on the individual developer. And that’s the thing: when you’re leading an engineering team, you’re not managing one trust gradient, you’re managing a whole distribution of them. You’ve got someone running parallel agents all day, sitting next to someone who still thinks of AI as a fancier autocomplete, and both of them are shipping code. This is why the 10x productivity boost everyone keeps talking about almost never shows up at the org level. The hard part is getting the whole organization to move together, without the fast movers creating chaos and the slow adopters quietly falling behind.

So we took the same principles and looked at them from another angle: not the individual developer Yegge describes, but the team and the organization the team lives in. Eight stages of maturity, from “nobody has decided anything” to “the factory runs itself”.

A quick word on vocabulary, because we lean on it throughout. When we say _team_, we mean a group of people working together toward the same outcome: engineers, yes, but also product, design, QA, whoever it takes to ship software. When we say _organization_, we mean the entire collection of those teams, plus the leadership, budgets, and governance that sit above them.

And here’s the part that makes this an SDLC story and not just a developer story: the new software development life cycle isn’t just about developers. It’s about the whole team. The old boundaries between product, design, and engineering are getting blurry. A product manager can now vibe-code a working prototype instead of writing a three-page spec nobody reads. A designer can ship real HTML and CSS, not just a design system and a Figma file to hand off. That shift is the whole point, and it’s why thinking in terms of individual developers stops being enough.

**Let’s lay out the whole map before we walk through it.**

### Stage 1: The vacuum

Leadership hasn’t taken a real position; at most, it bought a batch of licenses and stopped there. Developers form habits without guardrails: pasting code into whatever chat window is open, no shared context files, no agent setup, no managed API keys. This is a learning phase, and I think that’s fine: people are building intuition for what these models can and can't do. That intuition is the real return right now. Don’t mistake silence for inaction. Your developers have already decided for themselves.

### Stage 2: The drift

Stage 1 was about what the organization hadn’t decided; Stage 2 is about what individuals have decided on their own. One engineer quietly has agents handling a big chunk of their output, running off a personal stash of prompts, custom skills, and a carefully tuned AGENTS.md they keep on their own machine. The person beside them hasn’t changed anything in two years, and nobody flags it because individual variation has always looked normal. This is the last stage where inaction is free. Once the drift becomes visible, and it will, it turns into a team-level problem.

### Stage 3: The islands

The gap that used to run between individuals now runs between whole teams, and it shows up on the delivery calendar where everyone can see it. One team has shared AGENTS.md files, wired up MCP servers, and built reusable skills. Its throughput jumps. The team next door still writes code like it's two years ago.. What starts as a tooling gap hardens into resentment, and that's much harder to repair.

### Stage 4: The standardization bet

The first stage that requires real commitment from leadership is that AI becomes a capability you build deliberately. Three things matter here. Context engineering becomes explicit work, with shared AGENTS.md files and a curated skill and prompt library in the repos, so the team encodes its knowledge once instead of every developer teaching the AI the same lessons. Security and governance come before scale: SSO and SCIM, secret scanning, PR gates that run on agent output, audit logs, and an approved list of models and tools behind a gateway, built before people run at full speed. And training is ongoing, not a one-off workshop, usually built around the champions from Stage 2.

### Stage 5: The workflow redesign

Stage 4 upgrades the tools; Stage 5 redesigns the factory floor, changing how the work actually gets done. Spec-first becomes the default: the spec lives in the repo as the agent’s entry point, and an agent can’t work from a vague ticket any better than a junior developer can. Code review shifts from line-by-line to risk-based questions: Does this match the spec? Do the tests prove it? What’s the blast radius if it’s wrong? CI gates treat agent-opened PRs exactly like human ones, and evals start running right next to the unit tests. Expect a productivity dip while the role moves from writing code to reviewing and orchestrating; that’s normal. Watch quality, not just velocity: more code shipped at lower quality isn’t speed, it’s incidents arriving sooner.

### Stage 6: The operating system

Stage 5 changed how a team works; Stage 6 changes what a team is made of and how teams coordinate. A sprint might hold three engineers and five agent slots, and the engineer now looks more like a product manager than a programmer: writing specs, arguing with the AI about them, checking the tests. TDD becomes a dependency, not a nice-to-have: agents optimize for passing tests, so a weak suite gets gamed, and you won’t find out until production does. Parallel agents running in isolated sandboxes can burn more compute in a single sprint than a quarter of the hosting cost, so token budgets and per-run observability stop being optional. And shared context becomes real infrastructure (project memory, skills, prompt libraries, MCP servers), maintained as team assets and coordinated across teams.

### Stage 7: The bright factory

The line from Stage 6 is who holds the pen. The agents now write and ship whole units of work with barely any human authorship, and the human steps back from driver to supervisor. Most teams are still babysitting: agents kicked off from a terminal on someone’s laptop, looping locally and opening PRs from a dev machine, with no shared runtime and no central record of what ran or why. That local-machine detail is the one thing separating this stage from the next.

### Stage 8: The autonomous factory

Agents move off laptops and onto shared infrastructure, with scheduled runs in sandboxed environments and centralized logs and traces, so a migration that used to need babysitting runs overnight and reports its results in the morning. Recurring jobs become first-class (dependency updates, security patches, test expansion) with defined success criteria and automatic escalation when something fails. Eval becomes the product: the knowledge that lived in people's heads now lives in agent configs, skills, and eval suites that gate every merge, encoded once and enforced automatically. Your standards no longer live in someone's head. They live in the system

## A few honest caveats

No organization sits cleanly on a single stage. You’ll spot some teams at Stage 6 and another still firmly in Stage 1. The number is a center of gravity, not a label you pin on everyone.

Also, you shouldn’t skip stages. Go straight for autonomous agents without the governance, testing, and shared context underneath, and you just become another canceled project. But there’s a subtler reason to go one stage at a time: each stage hurts in its own particular way, and that pain is the lesson. The friction between a fast team and a slow one is what pushes a company to standardize. The grind of reviewing agent output line by line is what convinces a team to redesign the workflow. Skip the pain, and you lose the reason to move on: nothing makes the case for the next stage like the current one starting to hurt.

And stay skeptical the whole way. The hype around this is loud; the evidence, much quieter. So treat every promise here, including ours, with care.

## Conclusion

The question isn't whether to adopt AI. Most teams already have. The real question is whether the system underneath is good enough to be worth amplifying.

Because that's what AI is. I'm convinced of it: an amplifier. It accelerates what’s already there, the good practices and the bad ones alike. The organizations we’ve watched gain velocity without losing quality all share the same foundation: clear service ownership, comprehensive testing, documented services, and automated standards. None of this is new. We’ve been preaching these best practices for years. AI just made their absence impossible to ignore.

The autonomous factory is where this is heading. The hardest part won’t be the agents themselves: it’ll be trusting them enough to take them off individual laptops and run them on shared infrastructure. You build it the same way you always have, with evidence. One eval, one recurring task, one verified deployment at a time.

### [Best Heroku Alternatives for PHP Teams in 2026 | Upsun](https://upsun.com/blog/best-heroku-alternatives-php-2026/)

# Best Heroku alternatives for PHP teams in 2026

Heroku is a Platform-as-a-Service (PaaS) that has hosted PHP applications for over a decade. It runs PHP through the official Heroku PHP buildpack, with Composer, Apache or Nginx, and Git-based deploys. Laravel, Symfony, WordPress, and Drupal teams run production workloads on it.

Heroku still does several things well. The buildpack supports recent PHP versions, the deploy model is predictable, and a mature add-on marketplace covers databases, search, monitoring, and scheduling. 

The trade-offs are structural. The 30-second router timeout (H12) terminates long CMS exports, Magento reports, and Composer admin tasks. The ephemeral filesystem loses files written to a dyno, including WordPress media and Drupal uploads. Add-on billing fragments a production PHP setup across several vendors. 

## **Key takeaways**

-   This guide covers Platform-as-a-Service (PaaS) and developer platforms that PHP teams move to when they outgrow Heroku, as of 2026.
-   Upsun is the strongest fit for production PHP teams running CMSes or multi-framework portfolios that need native PHP, persistent storage, an integrated managed services catalog, and preview environments with real production data.
-   Other alternatives suit specific PHP profiles: Laravel-only teams (Laravel Cloud), low-friction buildpack migration (DigitalOcean App Platform), container-native teams (Render), and edge-latency workloads (Fly.io).
-   Every platform is evaluated against six consistent criteria: PHP runtime support, persistent storage, managed services, background workers, preview environments, and multi-cloud or migration path.

##   
**Why PHP teams look beyond Heroku in 2026**

Three Heroku design choices push PHP teams to reassess. 

-   **A 30-second router timeout.** Heroku terminates any web request that takes longer than 30 seconds, returning an H12 error, and its own documentation recommends keeping in-app timeouts to 10 to 15 seconds. That works for APIs but is painful for CMS exports, Magento report generation, and long Composer-driven admin tasks.
-   **An ephemeral filesystem.** Any file written directly to a dyno, including WordPress media, Drupal files, and admin-installed plugins, is lost when the dyno restarts or scales. Production PHP teams work around this by adding S3 and a third-party plugin, which costs add-on dollars and developer time.
-   **An add-on bill for every service.** Heroku charges Postgres, Redis, search, scheduling, and monitoring as separate add-ons, so a production-grade PHP setup means several contracts, several bills, and several vendor relationships to manage.

The platform still works. It just stopped being the lowest-friction PHP host years ago.

## **What to look for in a Heroku alternative for PHP**

The criteria below structure the comparison and map directly to the columns of the comparison table.

-   **PHP runtime and version support.** Whether the platform runs PHP natively or only through a Dockerfile, which PHP versions are supported, and whether PHP-FPM workers, Composer, and PHP extensions are configurable without custom container work.
-   **Persistent storage for CMS workloads.** Whether the platform provides a persistent file mount that survives deploys and restarts. This is what allows WordPress media, Drupal files, and Magento product images to live on the application platform instead of being offloaded to S3 or Spaces.
-   **Managed databases and search.** Whether PostgreSQL, MySQL, or MariaDB, Redis, and a search engine such as OpenSearch are offered as first-class managed services, rather than as separate vendor add-ons.
-   **Background workers and scheduled jobs.** Whether Laravel Horizon, Symfony Messenger consumers, Drush cron, and other long-running PHP processes can run in dedicated worker containers that scale independently of the web tier.
-   **Preview environments and profiling.** Whether the platform creates an isolated environment for every Git branch, whether that environment can include real production data, and whether PHP profiling tools such as Blackfire are available natively.
-   **Multi-cloud support and Heroku migration path.** Whether the platform supports deployment across multiple clouds, and how compatible its build and runtime model is with an existing Heroku PHP application.

## **The best Heroku alternatives for PHP teams in 2026**

#### **1\. Upsun**

A multi-cloud application platform with native PHP, persistent storage, and an integrated managed services catalog built around production PHP workloads.

Upsun runs PHP as a first-class native runtime, supporting the latest PHP versions. Code and infrastructure are described in a single YAML configuration file: PHP-FPM workers, extensions, and Composer dependency management are configured in the same place. Every Git branch produces a preview environment that clones production code, configuration, and live data in under one minute.

**Key capabilities:**

-   Native PHP runtime with configurable PHP-FPM workers and extensions via YAML.
-   Persistent storage mounts for WordPress media, Drupal files, and Magento product images.
-   Managed services catalog: PostgreSQL, MySQL, Redis, Elasticsearch, OpenSearch, RabbitMQ, and Kafka.
-   Dedicated worker containers for Laravel Horizon, Symfony Messenger, and Drush cron.
-   Multi-cloud deployment across AWS, GCP, Azure, OVHcloud, and IBM Cloud.
-   Blackfire available as a PHP extension for application-level profiling.
-   Compliance with ISO 27001, SOC 2 Type 2, PCI DSS Level 1, HIPAA, TX-RAMP, and GDPR.

**Best for:** Production PHP teams running CMSes, multi-framework portfolios, or compliance-sensitive workloads that need native PHP, persistent storage, and preview environments with real production data.

#### **2\. Laravel Cloud**

Laravel Cloud is Laravel's own hosting product, built specifically for Laravel applications. It offers autoscaling queue workers that track CPU, memory, and job backlog, PR preview environments, and a control plane that understands Artisan commands and Horizon. Managed databases include MySQL and serverless Postgres, with the option to connect to external databases.

The trade-off is the obvious one: Laravel Cloud only runs Laravel applications. If your team also maintains a Drupal site, a Symfony API, or a Magento store, you need a second platform. Teams running other PHP frameworks or CMSes should not choose Laravel Cloud as their primary host.

**Key capabilities:**

-   Laravel-specific autoscaling for queue workers and the web tier.
-   PR preview environments aligned with Laravel conventions.
-   Managed MySQL and serverless Postgres, plus external database support.
-   Entry-level tier with spend caps and millisecond scale-to-zero.

**Best for:** Teams whose entire PHP portfolio is Laravel and who want a platform built around Laravel conventions.

#### **3\. DigitalOcean App Platform**

A managed PaaS that uses the Heroku PHP buildpack directly, offering the lowest-friction Heroku migration path.

DigitalOcean App Platform supports Git-based deployment from GitHub, GitLab, and Bitbucket. Per DigitalOcean's documentation, it runs heroku-buildpack-php and supports PHP runtime versions 8.1 through 8.5, so existing composer.json and runtime configuration typically work without modification. Managed Postgres, MySQL, and Redis are available alongside.

**Key capabilities:**

-   Git-based deployment using heroku-buildpack-php.
-   PHP runtime versions 8.1 through 8.5.
-   Managed Postgres, MySQL, and Redis.
-   Integration with DigitalOcean Spaces for object storage.

**Best for:** Teams looking for the fastest, lowest-rewrite Heroku migration path on a single cloud.

#### **4\. Render**

A plan-based PaaS for PHP teams already comfortable maintaining a Dockerfile.

Render does not provide a native PHP runtime. Its documentation lists Node.js, Bun, Python, Ruby, Go, Rust, and Elixir as natively supported languages and directs PHP users to Docker. For teams already standardized on containers, the rest of the developer experience is clean: managed Postgres, Key Value (Redis), background workers, cron jobs, persistent disks, and plan-based pricing.

**Key capabilities:**

-   PHP deploys via Dockerfile, with an official Laravel Docker guide.
-   Managed Postgres and Key Value (Redis).
-   First-class background workers and cron jobs.
-   Persistent disks for stateful workloads.

**Best for:** PHP teams that have already standardized on Docker and want a clean, plan-based PaaS for container-native deployment.

#### **5\. Fly.io**

A container platform for global, edge-deployed PHP applications.

Fly.io runs Docker containers as lightweight VMs across 18 regions, according to Fly.io's regions documentation as of 2026. The platform supports FrankenPHP, the modern PHP application server, on its container model, and Laravel and PHP tooling have visible team support. Usage-based billing meters compute, bandwidth, volumes, dedicated IPv4 addresses, and inter-region networking separately.

**Key capabilities:**

-   Multi-region container deployment across 18 Fly.io regions
-   FrankenPHP runs cleanly on the container model
-   Persistent volumes for stateful workloads
-   Anycast networking with static IP support

**Best for:** PHP teams whose product depends on low-latency, edge-distributed delivery across geographies.

## **Quick look: how the five Heroku alternatives compare**

##  **Choosing the right alternative**

The core trade-off in moving off Heroku for PHP work is how much of Heroku's design you want to keep. The 30-second timeout, ephemeral filesystem, and add-on-style billing are not random choices: they are the cost of an abstraction that entirely hides the infrastructure. Alternatives that keep that abstraction, including DigitalOcean App Platform with the Heroku buildpack, deliver a fast migration but inherit a similar shape. Alternatives that loosen the abstraction, such as Upsun and Render, give you more control over runtime, storage, and services.

For Laravel-only portfolios, Laravel Cloud is the most opinionated and direct fit. For a fast, buildpack-compatible move, DigitalOcean App Platform is the closest match. For container-native PHP teams, Render is a clean choice. For edge-distributed workloads, Fly.io is the natural option. Upsun is the strongest fit for production PHP teams running CMSes or multi-framework portfolios that need native PHP without a Dockerfile, persistent storage for media, an integrated managed services catalog, and preview environments with real production data.

##   
**Frequently Asked Questions (FAQs)**

**Does Heroku still have first-class PHP support in 2026?**

Heroku still maintains an official PHP buildpack supporting recent PHP versions, with Composer-based dependency management and a choice of Apache or Nginx. The PHP runtime itself is current. What has not changed is the platform model: the 30-second router timeout, ephemeral filesystem, and add-on-based services still shape how a PHP application has to be designed for Heroku, regardless of the PHP version on top.

**Why do PHP teams move away from Heroku?**

The three most cited reasons in 2026 are cost compounding across add-ons, the ephemeral filesystem breaking common CMS upload patterns, and the loss of the permanent free tier in 2022, which removed the cheap on-ramp many small PHP projects depended on. Teams looking for production-grade testing and multi-cloud flexibility also tend to outgrow Heroku's single-region, single-cloud model.

**Does Upsun support PHP, and which versions?**

Yes. Upsun runs PHP as a first-class native runtime and currently supports PHP 8.2, 8.3, 8.4, and 8.5. You select the version in a YAML configuration file stored with your code, configure PHP-FPM workers and extensions in the same place, and Upsun uses Composer 2.x by default for dependency management. No Dockerfile is required.

**Which PHP frameworks and CMSes does Upsun support?**

Upsun has documented guides for Laravel and Symfony, plus tutorials for the major PHP-based content management systems: WordPress, Drupal, Magento, Shopware, and Pimcore. Persistent storage mounts handle CMS media and user uploads without offloading to S3, and managed services include PostgreSQL, MariaDB, Redis, and OpenSearch for the typical PHP stack. Laravel Horizon, Symfony Messenger, and Drush cron all run in dedicated worker containers in the same project as the web app.

**Which Heroku alternative supports WordPress, Drupal, or Magento natively?**

Upsun supports WordPress, Drupal, Magento, Shopware, and Pimcore through documented templates and persistent storage mounts that survive deploys, which is the main blocker for CMS workloads on Heroku. Pantheon and Acquia are stronger specialist choices if you only run WordPress or Drupal and want a host built around that one CMS.

**Can I migrate a Laravel app from Heroku without rewriting?**

Yes, on most of the alternatives covered here. DigitalOcean App Platform reuses the Heroku PHP buildpack directly, so a Laravel app often migrates with no code changes. Upsun and Laravel Cloud both have first-class Laravel support and documented migration paths, though Upsun expects you to add a YAML configuration file describing your services. Render requires a Dockerfile.

**Which Heroku alternative has native PHP support without Docker?**Upsun, Laravel Cloud, and DigitalOcean App Platform all run PHP as a native, first-class runtime without requiring you to maintain a Dockerfile. Render and Fly.io expect Docker for PHP workloads. If avoiding container maintenance is a priority, the first three are the shorter list to evaluate.

**Do any of these alternatives let me test against production data?**Upsun is the only platform in this comparison that automatically clones production code, configuration, services, and production data into a preview environment on every Git branch. The others offer staging or PR preview environments, but they do not seed production data by default.

### [Upsun included in the 2026 IDC ProductScape | Upsun](https://upsun.com/blog/upsun-idc-productscape-2026-cloud-deployment-platforms/)

# Upsun included in IDC ProductScape on worldwide cloud deployment-centric platforms, 2026

_Upsun is included in IDC ProductScape guide to worldwide cloud deployment-centric platform capabilities._

Building and scaling applications has never been more complex or more critical. Engineering teams are under constant pressure to ship faster, manage increasingly complex infrastructure, and adapt to the rapid rise of agent and AI-powered development. Choosing the right platform to support these demands is an important decision for technology organizations.

That's the context in which Upsun is proud to announce its inclusion for the first time in the IDC ProductScape: Worldwide Cloud Deployment–Centric Application Platforms, 2026. Published by IDC, a leading provider of global IT research and advice, the IDC ProductScape is a guide that maps the technical capabilities of cloud deployment platforms across the market, helping organizations understand how different solutions support modern application needs.

Since day one, Upsun has been built around a simple idea: we believe developers should spend their time building software, not managing infrastructure.

In practice, that means: Let's help organizations move faster with code-quality confidence.

### New challenge: how do you go faster with code quality confidence?

Advances in AI agents have accelerated software delivery. However, this has necessitated a re-imaging of the Software Development Life Cycle (SDLC). The use of AI offers productivity gains but also introduces trust and risk challenges (including security and compliance), scalability problems, and workflow changes. Upsun helps companies evolve their SDLC in a way that removes bottlenecks, inspires cross-functional collaboration, and balances speed and quality. 

We believe being included in this year's IDC ProductScape marks a milestone in that journey and reflects our commitment to meeting the real, day-to-day needs of modern engineering teams.  
  
**Explore the complimentary excerpt** to see the full functionality assessment.  
  
_IDC ProductScape: Worldwide Cloud Deployment–Centric Application Platforms, 2026, Doc. # US53014025, March 2026._

### [What is a Webhook? | Upsun](https://upsun.com/blog/what-is-a-webhook/)

# What is a Webhook? Learn about its benefits and how it works

Webhooks enable secure, real-time communication between systems through automated HTTP callbacks. This practical guide shows you how to build reliable webhook architectures that grow with your needs. Master proven patterns for mission-critical use cases including payment processing, inventory management, and workflow automation - empowering you to focus on delivering value rather than managing complexity.

## Basic webhook flow: a step-by-step breakdown

Before diving into technical implementations, let's understand how webhooks work in practice:

1.  **Endpoint setup**: The receiving system creates a dedicated URL (endpoint) ready to accept incoming webhook notifications
2.  **Event registration**: The source system is configured to watch for specific events (like new orders or payments)
3.  **Event trigger**: When an event occurs, the source system automatically sends data to the registered endpoint
4.  **Data processing**: The receiving system immediately validates the payload and schedules the workload to be handled out-of-band by a background queue or worker pool
5.  **Confirmation**: The receiving system sends back an immediate acknowledgement (usually an HTTP 200 or 202 Accepted status code) to release the socket, ensuring the source system doesn't trigger an unnecessary timeout retry

## How webhooks enable real-time communication

Traditional polling requires periodic requests to check for updates, consuming unnecessary system resources. Webhooks implement an event-driven approach using HTTP requests to push data immediately when state changes occur, eliminating polling overhead.

## Understanding webhook architecture

**Event-driven pattern:**

Webhooks use a streamlined publish-subscribe model where systems register HTTP endpoints for event notifications, enabling efficient real-time data flow through automated callbacks.

When changes occur, webhooks instantly push data to registered endpoints, creating an efficient foundation for system integration without polling overhead.

```Javascript
// Production-ready webhook endpoint implementation
app.post('/webhook/user-signup', async (req, res) => {
    const { userId, email } = req.body;
    
    try {
        // 1. Validate request first
        await validateSignature(req);
        
        // 2. Send quick acknowledgment
        res.status(200).json({
            success: true,
            message: 'Request accepted for processing'
        });
        
        // 3. Process webhook data asynchronously
        Promise.all([
            initializeUserAccount(userId),
            sendWelcomeEmail(email)
        ]).catch(async (error) => {
            // Log error but don't affect response
            console.error('Background processing failed:', error);
            // Queue for retry
            await queueForRetry({
                type: 'user-signup',
                payload: { userId, email },
                error
            });
        });
    } catch (error) {
        // Determine appropriate status code based on error
        let statusCode = 500;
        if (error.message === 'Invalid signature') {
            statusCode = 401; // Unauthorized
        } else if (error.message.includes('Bad Request')) {
            statusCode = 400; // Bad Request
        }
        
        res.status(statusCode).json({
            error: error.message,
            requestId: req.id,
            retryable: statusCode === 500
        });
    }
});
```

This implementation demonstrates key webhook handling patterns:

-   Asynchronous request processing
-   Request signature validation
-   Parallel task execution
-   Structured error handling
-   Standard HTTP status responses

  
**Handling production systems**

For reliable distributed systems, implement robust error handling with retry logic, idempotency checks, and clear HTTP status codes. This helps systems gracefully manage failed deliveries and prevent duplicate processing. The webhook provider needs these status codes to properly handle retries and errors. See our HTTP Status Codes Guide for implementation details.

## Common challenges and solutions

While webhooks offer powerful capabilities, they come with specific challenges that need to be addressed:

### Network dependency

**Challenge**: Webhooks rely on both source and destination servers being accessible. Network issues can lead to missed events or data loss.

**Solution**: Implement robust retry mechanisms and maintain an event log for reconciliation:

```Javascript
class WebhookRetryHandler {
    async handleDelivery(event) {
        try {
            await this.deliver(event);
        } catch (error) {
            await this.logFailedEvent(event);
            await this.scheduleRetry(event, {
                maxAttempts: 5,
                backoffStrategy: 'exponential'
            });
        }
    }
}
```

### Request frequency control

Challenge: During high-traffic periods, webhook requests can overwhelm receiving systems.

Solution: Implement rate-limiting at your application's edge router and decouple ingestion from execution. Never handle ingestion throttling using local, in-memory application arrays, as horizontal scaling splits this context across multiple containers. Instead, route incoming payloads directly to a distributed message broker capable of decoupling consumption from spikes in request traffic.

### Complementary communication patterns

Modern distributed systems leverage both webhooks and REST APIs as complementary architectural patterns. Each serves distinct use cases in system integration:

### REST APIs

REST APIs implement request-response patterns ideal for:

-   Data retrieval and manipulation on demand
-   Complex queries with specific parameters
-   Operations requiring immediate confirmation
-   Synchronous workflows where order matters

### Webhooks

Webhooks implement event-driven patterns suitable for:

-   Event notifications and state changes
-   Asynchronous processing of business events
-   Distributed system integration
-   Decoupled architecture patterns

### Implementation considerations

```Javascript
// Example combining both patterns effectively
class OrderSystem {
    // REST API endpoint for immediate order lookup
    async getOrder(orderId) {
        return await this.orderRepository.findById(orderId);
    }

    // Webhook handler for order state changes
    async handleOrderStateChange(req, res) {
        const { orderId, newState } = req.body;

        try {
            // Validate webhook request
            await this.validateWebhook(req);

            // Send immediate acknowledgment
            res.status(200).send({ accepted: true });

            // Process state change asynchronously without blocking
            this.processOrderStateChange(orderId, newState).catch(error => {
                console.error('Error processing order state change:', error);
                // Optional: Implement retry logic or error tracking here
            });
        } catch (error) {
            // Handle validation errors
            res.status(401).json({ error: 'Invalid signature' });
        }
    }
}
```

The performance and efficiency of both patterns depend on proper implementation, including:

-   Appropriate caching strategies
-   Efficient database queries
-   Proper connection pooling
-   Optimized network configurations

Both webhooks and REST APIs can achieve high performance when implemented correctly. The choice between them should be based on architectural requirements rather than perceived performance differences.

## Real-world applications: webhooks in action

Webhooks serve as digital bridges enabling real-time system communication. They transform manual processes into automated workflows that respond instantly to business events.

Key applications include:

-   Support platforms: Automate ticket routing and team notifications while maintaining synchronized customer communications
-   E-commerce: Enable real-time inventory updates and automated order status notifications
-   Development: Power automated deployments and continuous integration pipelines
-   CRM systems: Create comprehensive customer profiles with perfect data consistency
-   Payment processing: Orchestrate secure financial workflows and automated fulfillment

## Implementation examples: system integration patterns

This section demonstrates webhook implementation patterns for common integration scenarios:

### E-commerce inventory

```Javascript
app.post('/webhook/inventory-update', async (req, res) => {
    const { productId, quantity } = req.body;
    try {
        await validateWebhookSignature(req);
        await updateInventory(productId, quantity);
        res.status(200).send({ success: true });
    } catch (error) {
        res.status(500).send({ error: error.message });
    }
});
```

This example demonstrates how webhooks maintain real-time inventory accuracy. The core patterns can be implemented using popular frameworks like Express.js (Node.js) or Flask (Python), providing a solid foundation for your own webhook integrations.

### Payment processing

```Javascript
app.post('/webhook/payment-status', async (req, res) => {
    const { paymentId, status, orderId } = req.body;
    try {
        await validatePaymentSignature(req);
        // Quick acknowledgment
        res.status(202).json({ accepted: true });
        
        // Async order processing
        await Promise.all([
            updateOrderStatus(orderId, status),
            status === 'succeeded' && fulfillOrder(orderId)
        ]).catch(async error => {
            await queueForRetry({
                type: 'payment-processing',
                orderId,
                paymentId
            });
        });
    } catch (error) {
        res.status(500).json({ error: error.message });
    }
});
```

## Building production-ready webhooks for your application

Modern webhook implementations must balance simplicity with production-grade resilience. The following example demonstrates progression from basic handling to robust error recovery and workflow automation:

```Javascript
// Foundation: Basic webhook handling with built-in security
const express = require('express');
const app = express();

class WebhookHandler {
    async processWebhook(req, res) {
        // Verify request before processing
        await this.validateRequest(req);

        try {
            await this.processEvent(req.body);
            res.status(200).send('Success');
        } catch (error) {
            await this.handleFailure(error, req);
            res.status(500).json({
                error: error.message,
                requestId: req.id
            });
        }
    }

    async validateRequest(req) {
        // Combine security checks into a single validation flow
        const valid = await Promise.all([
            this.verifySignature(req.body, signature),
            this.checkRateLimits(req.ip),
            this.validateSource(req.ip)
        ]);

        return valid.every(Boolean);
    }
}
```

This implementation combines security and processing concerns, providing a unified approach to webhook handling.

Key Pattern: Every webhook request flows through a single processing pipeline that handles validation, processing, and error recovery in real-time workflows.

**Handling Production Realities**

When APIs and systems scale, failure becomes inevitable. Here's how to handle it gracefully:

```Javascript
class RetryManager {
    async handleFailure(error, event) {
        await this.messageQueue.add({
            event,
            attempt: 1,
            nextRetry: this.calculateBackoff(1)
        });
    }

    calculateBackoff(attempt) {
        return Math.min(
            1000 * Math.pow(2, attempt),
            3600000 // Max 1 hour
        );
    }
}
```

## What is a production-ready webhook system

A webhook system must handle diverse operations from user signups to payment processing while maintaining reliability and scalability.

### Core requirements

-   Resilient processing pipeline
-   Comprehensive error handling
-   Retry mechanisms for failed operations

### Error handling implementation

Production systems require systematic error handling to maintain data consistency and system reliability. The following implementation demonstrates proper error management:

```Javascript
class WebhookError extends Error {
    constructor(message, statusCode, retryable = true) {
        super(message);
        this.name = 'WebhookError';
        this.statusCode = statusCode;
        this.retryable = retryable;
        Error.captureStackTrace(this, WebhookError);
    }
}
```

### Processing pipeline

The WebhookHandler class implements the complete webhook lifecycle, managing signature verification through error recovery:

```Javascript
class WebhookHandler {
    async processWebhook(req, res) {
        const eventType = req.headers['x-webhook-type'];
        const signature = req.headers['x-signature'];

        try {
            this.verifySignature(req.body, signature);
            const processor = this.getEventProcessor(eventType);
            await processor.process(req.body);

            res.status(200).send('Event processed successfully');
        } catch (error) {
            await this.handleProcessingError(error, req, res);
        }
    }

    async handleProcessingError(error, req, res) {
        const webhookError = this.normalizeError(error);
        await this.logError(webhookError);

        if (webhookError.retryable) {
            await this.queueForRetry(req.body, req.headers['x-webhook-type']);
        }

        res.status(webhookError.statusCode).json({
            error: webhookError.message,
            retryable: webhookError.retryable,
            requestId: req.id
        });
    }
}
```

This implementation creates a resilient foundation for processing business-critical events. Error normalization ensures consistent handling across different types of failures, while the retry mechanism prevents data loss during system failures.

## Operating webhooks in production

Security and monitoring are fundamental aspects of production webhook systems. Security mechanisms prevent unauthorized access, while monitoring systems detect and alert on operational issues.

```Javascript
class WebhookOperations {
    constructor() {
        this.security = new SecurityManager({
            rateLimits: this.configureRateLimits(),
            hmacSecret: process.env.WEBHOOK_SECRET
        });

        this.monitoring = new MonitoringStack({
            alertThresholds: {
                latency: 5000,  // Alert on slow responses
                errorRate: 0.01 // 1% error threshold
            }
        });
    }

    async handleRequest(req, res) {
        const timer = this.monitoring.startTimer();

        try {
            await this.security.validateRequest(req);
            await this.processWebhook(req.body);

            this.monitoring.recordSuccess(timer);
        } catch (error) {
            this.monitoring.recordFailure(error, timer);
            throw error;
        }
    }
}
```

Comprehensive monitoring is essential for maintaining webhook system integrity. Monitoring systems should track key metrics including response times, error rates, and system health indicators.

The following example demonstrates these principles implemented at scale:

```Javascript
// Implementation of webhook handling at scale
class GitHubWebhook extends WebhookOperations {
    async processWebhook(payload) {
        // Process multiple downstream actions concurrently
        await Promise.all([
            this.triggerCIPipeline(payload),
            this.updateProjectBoards(payload),
            this.notifyTeam(payload)
        ]);
    }
}
```

## Building resilient systems

A production-ready webhook architecture must address three fundamental challenges to deliver consistent, enterprise-grade performance:

-   Resilient networking with intelligent failure recovery
-   Enterprise-grade security across distributed endpoints
-   Efficient scaling to handle growing event volumes

```Javascript
class WebhookSystem {
    async process(event) {
        // Implement reliability through message queues
        await this.messageQueue.guaranteeDelivery(event);

        // Enforce security protocols
        await this.validateAndProcess(event);

        // Enable horizontal scaling
        await this.loadBalancer.distributeLoad(event);
    }
}
```

This architectural pattern enables processing of high event volumes while maintaining system integrity and performance. Implementation of these patterns creates webhook systems capable of handling enterprise-scale workloads with consistent reliability.

## Key takeaways for implementing webhooks:

-   Build with security and scalability in mind from the start
-   Implement proper error handling and retry mechanisms
-   Monitor system health and performance
-   Follow best practices for validation and processing

By following these implementation guidelines and best practices, you can create webhook systems that grow seamlessly from basic notification services to enterprise solutions handling millions of daily events. The key is building on a solid foundation and thoughtfully scaling your system as your needs evolve.

Upsun provides access to a webhook integration that allows you to tie arbitrary business logic to the project, environment, and infrastructure activities of your applications. Your own applications themselves can also produce the webhook best practices described in this article, without focusing on infrastructure.

### [ Best Azure App Service Alternatives for .NET Teams in 2026](https://upsun.com/blog/best-azure-app-service-alternatives-2026/)

#  Best Azure App Service alternatives for teams leaving the Microsoft Stack in 2026

Azure App Service is Microsoft's Platform-as-a-Service for hosting web applications, APIs, and background processes on Azure. It supports .NET, Java, Node.js, Python, PHP, and Ruby. Despite the broad runtime list, Microsoft-shop .NET teams use App Service as the default home for their applications.

App Service has real strengths: deployment slots for blue-green swaps, tight integration with Entra ID, Cosmos DB, Azure SQL, and Application Insights, and polished Visual Studio tooling. For .NET teams already inside Microsoft's stack, it is the path of least resistance.

Teams are reassessing App Service in 2026 for strategic and operational reasons. The EU Data Act, recurring Microsoft service retirements, and rising vendor lock-in concerns at the board level have shifted the conversation. 

## **Key takeaways**

-   This guide covers Platform-as-a-Service options that .NET teams move to when reassessing Azure App Service, as of 2026.
-   Upsun is the strongest fit for teams whose mandate is genuine vendor diversification, with native .NET, preview environments that clone production data, and deployment across five cloud providers.
-   Other alternatives suit specific strategies: committing to AWS (AWS App Runner), committing to GCP (Google Cloud Run), Docker-native deployment (Render), and global edge .NET workloads (Fly.io).

## **What to look for in an Azure App Service alternative**

The criteria below structure the comparison and map directly to the columns of the comparison table.

-   **Multi-cloud and BYOC support.** Whether the platform can deploy across AWS, GCP, Azure, or other clouds, including EU-headquartered providers for data residency. Switching to a single different hyperscaler trades one concentration risk for another.
-   **Native .NET runtime.** Whether the platform runs .NET as a first-class supported runtime with version selection and managed patches, or only via Docker. Container-only support moves runtime and build maintenance back to the team.
-   **Preview environments and environment parity.** Whether the platform creates an isolated environment for every Git branch, and whether that environment includes real production data, configuration, and code. App Service's deployment slots are not the same as per-branch preview environments with cloned data.
-   **Pricing model and cost predictability.** Plan-based, resource-based, or usage-based billing, plus how forecastable spend is under realistic production traffic.
-   **Managed databases and services.** Which databases, caches, and queues are offered as first-class managed services. Moving off Azure usually means moving off Cosmos DB and Azure SQL, so the destination platform's managed services catalog matters.
-   **Compliance and enterprise readiness.** Certifications such as ISO 27001, SOC 2, PCI DSS, HIPAA, and GDPR, plus government-specific frameworks where relevant. Some Azure workloads are tied to certifications such as FedRAMP High, IL5, or GCC High that other platforms do not match.

## **The best Azure App Service alternatives in 2026**

#### **1\. Upsun**

Upsun is a multi-cloud PaaS that uses a single YAML file for application code and infrastructure. It clones the full production environment, including live data, on every Git branch and supports 10 native runtimes, including PHP, Python, Node.js, Java, Go, Ruby, and .NET.

 It runs across AWS, GCP, Azure, OVHcloud, and IBM Cloud with identical Git-push workflows. Teams choose the cloud and region per application, which means a single Upsun configuration can target AWS for one application, OVHcloud for another, and Azure for a specific compliance workload, without rewriting the configuration model.

For .NET, Upsun supports the runtime natively. Major and minor versions are selected in a YAML configuration file using type: 'dotnet:<version>', and Upsun manages patch updates automatically. 

**Key capabilities:**

-   Native .NET runtime with version selection in YAML
-   Multi-cloud deployment across AWS, GCP, Azure, OVHcloud, and IBM Cloud
-   Preview environments on every Git branch that clones code, configuration, services, and live production data in under one minute
-   Per-environment CPU, RAM, and disk sizing, with autoscaling on CPU, RAM, and request latency \[VERIFY: current autoscaling triggers\]
-   Managed services catalog: PostgreSQL, MySQL, Redis, Elasticsearch, OpenSearch, RabbitMQ, and Kafka
-   Compliance with ISO 27001, SOC 2, PCI DSS, HIPAA, and GDPR \[VERIFY: confirm SOC 2 Type 2 and PCI DSS Level 1 specifics if applicable\]

**Best for:** .NET teams whose mandate is genuine vendor diversification rather than swapping one hyperscaler for another, particularly teams under EU Data Act pressure or with compliance requirements that travel across environments.

#### **2\. AWS App Runner**

The closest experience match to Azure App Service inside AWS, with deep AWS ecosystem integration.

AWS App Runner is a managed PaaS that auto-scales containerized applications, deploys from container images in ECR or source code in GitHub, and bills per-second compute, memory, and request volume. .NET runs via container build. The platform integrates with the AWS ecosystem, including RDS, Aurora, Cognito, CloudWatch, and Secrets Manager, mirroring how Azure App Service integrates with Cosmos DB and Entra ID.

**Key capabilities:**

-   Auto-scaling containerized applications with per-second billing
-   Source-to-deploy from GitHub, or container deploys from ECR
-   Native integration with RDS, Aurora, Cognito, CloudWatch, and Secrets Manager
-   Single-cloud deployment on AWS infrastructure only

**Best for:** Teams whose strategy is committing to AWS, not teams trying to reduce hyperscaler concentration.

#### **3\. Google Cloud Run**

A serverless container platform with scale-to-zero, request-based pricing, and global GCP deployment.

Google Cloud Run runs containerized workloads with scale-to-zero behavior and fast horizontal scaling, billing per request-processing time. It integrates natively with Cloud SQL, Pub/Sub, BigQuery, and Firestore. .NET runs via container build. The platform suits stateless workloads particularly well, where scale-to-zero genuinely cuts cost.

**Key capabilities:**

-   Serverless container execution with scale-to-zero
-   Native integration with Cloud SQL, Pub/Sub, BigQuery, and Firestore
-   Pay-per-request-processing-time billing
-   Single-cloud deployment on Google Cloud

**Best for:** Teams whose strategy is moving to GCP, particularly for stateless workloads with variable traffic.

#### **4\. Render**

A plan-based PaaS for .NET teams already comfortable with Docker.

Render is an independent PaaS with plan-based, predictable pricing, managed PostgreSQL and Key Value (Redis), background workers, cron jobs, and persistent disks. It runs on its own infrastructure with no multi-cloud or BYOC option, so it solves "leave Azure" but does not offer multi-cloud as a feature. Per Render's documentation, .NET is not natively supported; applications run via Docker.

**Key capabilities:**

-   Git-based deployment with built-in preview environments
-   First-class background workers and cron jobs
-   Managed Postgres and Key Value (Redis)
-   Plan-based predictable pricing
-   Compliance covers SOC 2 Type 2, ISO 27001, HIPAA (opt-in workspace), and GDPR

**Best for:** Teams ready to standardize on Docker who want a polished PaaS developer experience and predictable monthly billing.

#### **5\. Fly.io**

A container platform for global edge-deployed .NET workloads with multi-region routing built in.

Fly.io runs Docker containers as lightweight VMs across 18 regions, according to Fly.io's regions documentation as of 2026, with global Anycast routing. For .NET teams whose users are genuinely distributed worldwide, Fly.io offers low-latency multi-region deployment as the default rather than a separate engineering project. .NET runs via Docker.

**Key capabilities:**

-   Multi-region container deployment across 18 Fly.io regions
-   Global Anycast routing
-   Container model supports any Docker-deployable runtime
-   Managed services: Fly Managed Postgres, Tigris object storage, and Upstash for Redis

**Best for:** .NET teams whose product depends on low-latency, edge-distributed delivery across geographies.    
 

## **Quick look: how the five Azure App Service alternatives compare**

## **Choosing the right alternative**

The core question is what your mandate actually requires. Switching from Azure App Service to AWS App Runner or Google Cloud Run solves "leave Azure" but does not solve hyperscaler concentration. Switching to Render or Fly.io solves "leave hyperscalers" but trades multi-cloud for single-vendor PaaS. Only a platform with deployment across multiple clouds, or a bring-your-own-cloud model, addresses the structural concern that drives most diversification mandates in 2026.

For teams committing to AWS, App Runner is the cleanest landing point. For teams committing to GCP, Cloud Run is the equivalent. For Docker-standardized teams that want predictable monthly billing, Render is the closest match. For global edge .NET workloads, Fly.io is the natural fit. Upsun is the strongest fit for .NET teams whose mandate is genuine vendor diversification, particularly teams under EU Data Act pressure, with compliance requirements that travel across environments, or with multi-cloud as a long-term strategy.    
 

## **Frequently Asked Questions (FAQs)**

**Why are .NET teams leaving Azure App Service in 2026?**

The most cited reasons are strategic vendor diversification (89% of enterprises now operate multi-cloud, with 42% citing lock-in prevention as the primary driver), EU Data Act compliance requires cloud providers to guarantee data portability, recurring Microsoft service retirements that consume platform-team capacity, and the technical reality that .NET 8 and 9 run cleanly on Linux without the historical Windows dependency.

**Does the EU Data Act require leaving Azure?**

No. The EU Data Act, in force since January 2024, requires cloud providers to guarantee data portability and interoperability. It does not mandate leaving any specific provider. What it does is give European teams regulatory cover for diversification decisions and create real pressure on architecture committees to demonstrate that workloads can move if needed.

**Does Upsun support .NET natively, and which versions?**

Yes. Upsun supports .NET as a first-class native runtime. You select major and minor versions in .upsun/config.yaml using type: 'dotnet:<version>', and patch updates are applied automatically. Build hooks use dotnet publish, with documented flags for clean integration with the .NET build system. 

**Can Upsun deploy across multiple clouds, including European sovereign options?**

Yes. Upsun deploys across AWS, Azure, GCP, IBM, and OVHcloud. The OVHcloud option is particularly relevant for European teams under EU Data Act pressure, since it provides a European-headquartered sovereign hosting path that pure US-hyperscaler alternatives cannot match. Teams choose the cloud and region per application without changing application code or configuration syntax.

**Does moving from Azure App Service to AWS App Runner or Google Cloud Run solve vendor lock-in?**

No. Switching from one hyperscaler PaaS to another addresses the platform but not the structural concentration risk. If the strategic mandate behind your move is vendor diversification, only a multi-cloud platform, such as Upsun, or a bring-your-own-cloud approach, addresses the underlying concern. AWS App Runner and Google Cloud Run are strong choices if your strategy is committing to that specific cloud.

**What happens to Cosmos DB or Azure SQL when I leave Azure?**

Cosmos DB and Azure SQL are Azure-specific services with no direct equivalents on other platforms. Migrating off them typically involves replatforming to PostgreSQL, MariaDB, or another open-standard database, and that work should be scoped before any platform decision. Some teams move .NET applications to Upsun while keeping Cosmos DB on Azure during a transition, using Upsun's multi-cloud model to bridge the migration over time.

**Which Azure App Service alternative is best for global .NET deployment?**

For applications where low-latency multi-region delivery is a real product requirement, Fly.io offers the strongest edge-distributed model with more than 18 regions. For a multi-cloud global deployment that lets you pick different providers in different regions, Upsun is the better fit. For staying inside a single hyperscaler's global network, AWS App Runner and Google Cloud Run are both reasonable.

### [Best DigitalOcean App Platform Alternatives 2026 | Upsun](https://upsun.com/blog/best-digitalocean-app-platform-alternatives-2026/)

# Best DigitalOcean App Platform alternatives in 2026

DigitalOcean App Platform is a Platform-as-a-Service (PaaS) on DigitalOcean's cloud. It deploys from Git or Docker, with automatic HTTPS, horizontal scaling, and integration with DigitalOcean Managed Databases and Spaces. Small teams and startups use it for a managed deploy experience on a single cloud bill. 

App Platform does several things well. Pricing is plan-based, single-vendor billing covers compute, databases, and object storage, and the free static-site tier is hard to match on price.

Teams outgrow App Platform's design constraints. Each app runs in a single region, with no native multi-region deployment, no built-in dev, staging, and production environment isolation, no hard spending caps, and autoscaling gated behind dedicated instance plans. This guide compares the strongest DigitalOcean App Platform alternatives in 2026 and identifies which team profile each one fits.

## **Key takeaways**

-   This guide covers Platform-as-a-Service (PaaS) and developer platforms that teams adopt when they outgrow DigitalOcean App Platform, as of 2026.
-   Upsun is the strongest fit for production teams that need multi-cloud deployment, preview environments with live production data, and compliance certifications applied across all environments.
-   Other alternatives suit specific needs: the closest App Platform-style experience (Render), small-team prototyping (Railway), global edge deployment (Fly.io), and bring-your-own-cloud into your own account (Northflank).   
     

## **What to look for in a DigitalOcean App Platform alternative**

The criteria below structure the comparison and map directly to the columns of the comparison table.

-   **Multi-region deployment.** Whether the platform can deploy the same application across multiple regions for latency, redundancy, or compliance. App Platform runs each app in a single region, which is its sharpest structural limit.
-   **Multi-cloud and BYOC support.** Whether the platform can deploy across AWS, GCP, Azure, or other cloud providers, and whether it supports bring-your-own-cloud (BYOC) into an account you own. This matters for data residency, exit options, and avoiding single-vendor lock-in.
-   **Preview environments and environment parity.** Whether the platform creates an isolated environment for every Git branch, and whether that environment can include real production data, configuration, and code. Parity with production is what eliminates the staging drift that breaks releases.
-   **Pricing model and spending controls.** Resource-based, plan-based, or usage-based billing, plus whether the platform supports hard spending caps, idle resource handling, and per-environment sizing.
-   **Managed services catalog.** The databases, caches, search engines, and message queues are offered as first-class managed services. A complete catalog reduces third-party vendor count and operational overhead.
-   **Compliance and security.** Certifications such as ISO 27001, SOC 2, PCI DSS, HIPAA, and GDPR, and whether they apply across all environments, not only production.

## **The best DigitalOcean App Platform alternatives in 2026**

#### **1\. Upsun**

A multi-cloud PaaS built for production-grade applications, with environment parity and compliance applied across every branch.

Upsun is a multi-cloud Platform as a Service that runs applications across AWS, GCP, Azure, OVHcloud, and IBM Cloud from a single Git-driven workflow. Teams describe code and infrastructure in one YAML configuration file, and every Git branch produces a preview environment that clones the production environment, including live data, in under one minute. Pricing is resource-based, with teams paying for the CPU, RAM, and storage they provision.

**Key capabilities:**

-   Multi-cloud deployment across AWS, GCP, Azure, OVHcloud, and IBM Cloud
-   Git-push deployment with automatic preview environments per branch
-   Managed services catalog: PostgreSQL, MySQL, Redis, Elasticsearch, OpenSearch, RabbitMQ, and Kafka
-   10 supported runtimes, including PHP, Python, Node.js, Java, Go, Ruby, and .NET
-   Per-environment CPU and RAM sizing for cost control
-   Compliance with ISO 27001, SOC 2 Type 2, PCI DSS Level 1, HIPAA, TX-RAMP, and GDPR.

**Best for:** Production teams managing multi-application portfolios with compliance requirements that need true environment parity and the option to run in their own cloud.

**Pros:**

-   A single YAML file describes the application code and infrastructure together.
-   Preview environments include live production data on every branch.
-   Multi-cloud option supports data residency and an exit strategy.

**Cons:**

-   Resource-based billing requires more upfront planning than plan-based App Platform tiers.
-   Not optimized for hobby static sites or solo developer side projects.

#### **2\. Render**

A plan-based PaaS that delivers the closest experience match to DigitalOcean App Platform.

Render offers Git-based deployment with managed PostgreSQL and Key Value (Redis), background workers, cron jobs, persistent disks, and automatic TLS. Per Render's documentation, it natively supports Node.js, Bun, Python, Ruby, Go, Rust, and Elixir, with PHP and other languages deploying via Docker. Render runs on its own infrastructure with no multi-cloud or BYOC option.

**Key capabilities:**

-   Git-based deployment with built-in preview environments.
-   First-class background workers and cron jobs.
-   Managed Postgres and Key Value (Redis).
-   Persistent disks for stateful workloads.

**Best for:** Teams that want an App Platform-style developer experience with a more polished UI and a similar plan-based pricing model.

**Pros:**

-   Closest direct experience match to App Platform.
-   Plan-based pricing is easy to forecast.
-   Native background workers and cron jobs without workarounds.

**Cons:**

-   No multi-cloud or BYOC option.
-   No native PHP runtime; Docker required for PHP applications.
-   Preview environments do not automatically include production data.

#### **3\. Railway**

A developer platform optimized for fast prototyping and small-team developer experience.

Railway deploys from Git with no configuration for common stacks, uses a visual dashboard for services and environment variables, and supports usage-based per-second billing with scale-to-zero. Managed Postgres, MySQL, Redis, and MongoDB are available as one-click services. Railway is most often chosen for hobby projects, early-stage products, and small-team workloads.

**Key capabilities:**

-   Git-based deployment with no configuration for common stacks.
-   Visual dashboard for services, databases, and environment variables.
-   Managed Postgres, MySQL, Redis, and MongoDB.
-   Usage-based per-second billing with scale-to-zero.

**Best for:** Solo developers and small teams that prioritize developer experience and a low entry cost over multi-cloud or compliance.

**Pros:**

-   Minimal configuration to deploy most stacks.
-   Clean visual interface for service and variable management.
-   Low cost of entry for hobby projects.

**Cons:**

-   No multi-cloud or BYOC option.
-   Usage-based pricing under sustained traffic is less predictable than App Platform's plan-based model.

#### **4\. Fly.io**

A container platform for global, edge-deployed applications with fine-grained regional control.

Fly.io runs Docker containers as lightweight VMs across 18 regions, with global Anycast routing. Billing is usage-based, metering compute, bandwidth, volumes, dedicated IPv4 addresses, and inter-region networking separately. Region placement, replication, and stateful high availability are the team's responsibility.

**Key capabilities:**

-   Multi-region container deployment across 18 Fly.io regions.
-   Global Anycast routing.
-   Persistent volumes for stateful workloads.
-   Container model supporting any Docker-deployable runtime.

**Best for:** Teams whose product genuinely requires low-latency multi-region deployment with fine-grained regional control.

**Pros:**

-   Strong multi-region performance for latency-sensitive applications.
-   Container model supports any runtime that can be packaged in Docker.
-   Static IP and Anycast networking simplify global routing.

**Cons:**

-   Requires a Dockerfile and a fly.toml configuration; no native buildpack abstraction.
-   Usage-based metering across multiple dimensions compounds at scale.

#### **5\. Northflank**

A Kubernetes-native developer platform with bring-your-own-cloud support across major clouds.

Northflank supports BYOC deployment into AWS, GCP, and Azure accounts, with static IPs, persistent storage, secret management, and cron jobs as native capabilities. Pricing is per-resource. Northflank exposes more of the underlying primitives than App Platform does, which makes it more powerful for platform teams and heavier to operate for small ones.

**Key capabilities:**

-   BYOC into AWS, GCP, or Azure accounts.
-   Kubernetes and Helm workflow support.
-   Static IPs, persistent storage, and secret management.
-   Native cron jobs and background workers.

**Best for:** Platform and DevOps teams ready to bring their own cloud, without an enterprise contract requirement.

**Pros:**

-   BYOC available below Enterprise pricing.
-   Per-resource pricing is predictable at scale.
-   Production controls including observability and persistent storage.

**Cons:**

-   Exposes more infrastructure surface than App Platform users typically expect.
-   Steeper onboarding than dashboard-first PaaS platforms.   
     

## **How the five App Platform alternatives compare**

## **Choosing the right alternative**

The core trade-off in moving off the App Platform is between simplicity and capability. App Platform's single-region, single-cloud, plan-based design is intentionally simple: one bill, one cloud, one region per app. The alternatives in this list each shift that trade-off in a specific direction. Render keeps a similar simplicity with a more polished developer experience. Railway optimizes for the small-team prototyping path. Fly.io and Upsun add multi-region and multi-cloud capabilities. Northflank goes further by handing infrastructure ownership back to the team.

For an App Platform-style experience with better tooling, Render is the closest direct match. For solo developers and small teams optimizing for setup speed, Railway is the most direct fit. For genuine multi-region requirements, Fly.io is the natural choice. For BYOC into your own cloud, Northflank is the strongest option. Upsun is the strongest fit for production teams running multi-application portfolios with compliance requirements that need true environment parity across multi-cloud deployments.

## **Frequently Asked Questions (FAQs)**

**Why do teams leave DigitalOcean App Platform in 2026?**

The most cited reasons are the lack of native multi-region deployment, the absence of built-in dev/staging/production environment isolation, no hard spending caps, and autoscaling being available only on the more expensive dedicated instance plans. Teams that need any of these as defaults tend to outgrow App Platform within a year of serious production use.

**Does DigitalOcean App Platform support multi-region deployment?**

No. App Platform runs each app in a single region. There is no native multi-region failover or geographic distribution at the platform level. Teams with global users either accept the latency, layer a CDN on top, or migrate to a platform that supports multi-region natively, such as Upsun, Fly.io, or Northflank.

**Does Upsun offer multi-region and multi-cloud deployment?**

Yes. Upsun deploys across five clouds (AWS, Azure, GCP, IBM, and OVHcloud), and teams choose the cloud and region per application without changing how they build. This is the main structural advantage over App Platform: you are not tied to a single cloud, which matters for data sovereignty in Europe, agency work across multiple client clouds, and disaster-recovery planning.

**How does Upsun's preview environment differ from DigitalOcean App Platform's?**

Upsun creates an isolated preview environment automatically on every Git branch, cloning your application code, configuration, services, and production data so the environment behaves like a real copy of production. DigitalOcean App Platform does not offer this. On the App Platform, you create separate apps for each environment manually and seed data yourself.

**Is Upsun more expensive than DigitalOcean App Platform?**

For a small static site or a single low-traffic service, DigitalOcean App Platform is cheaper because of its free static tier and low entry plans. For production workloads with multiple services, managed databases, search, and preview environments, the comparison is closer than headline prices suggest: App Platform's separately metered databases ($15/month minimum), dedicated instances for autoscaling, and lack of built-in preview environments add real cost. The honest answer is that Upsun is positioned for production teams, not as the cheapest hobby host.

**Can I migrate from DigitalOcean App Platform to another platform without rewriting?**

Usually, yes. App Platform deploys from Git and Docker, and most alternatives covered here accept the same inputs. Render and Railway support Git-based deploys with managed databases similar to App Platform's. Upsun requires you to add a YAML configuration file describing your services, which is a small upfront investment that buys you reproducible environments and IaC review in pull requests. Northflank and Fly.io expect a Dockerfile.

**Which DigitalOcean App Platform alternative is closest to its experience?**

Render is the closest direct match: plan-based, predictable pricing, Git-push deploys, managed Postgres and Redis, background workers and cron jobs, persistent disks. Teams moving from App Platform to Render usually do so with the least change to how they think about deployment.

### [How to standardize app delivery across distributed teams | Upsun](https://upsun.com/blog/standardize-app-delivery-across-multiple-teams/)

# How to standardize app delivery across distributed teams without breaking what works

Every IT leader running distributed engineering teams eventually hits the same wall. Lock things down too tightly and developers route around the standard: shadow tooling, bespoke scripts, workarounds that become permanent. 

Leave things too open and you end up governing a dozen different paths to production, none of them documented, all of them owned by whoever built them. The org slows down, audit findings accumulate, and the platform team spends its time firefighting instead of building.

The organizations that escape this are the ones that figured out where standardization belongs and where it doesn't. Not everything needs to be uniform. The delivery layer does. The application layer doesn't. Getting that boundary right is the difference between a standard developers resent and one they choose.

### **The chassis model: separating what must be standard from what should stay flexible**

_Key takeaway: Effective standardization draws a clear line between the platform layer which governs how code moves to production, and the application layer, where technical decisions belong to the team building the product._

Think of it as a chassis and an engine. The chassis is the frame, the brakes, the safety systems, the parts that need to work the same way every time regardless of what's under the hood. The engine is where differentiation lives. You don't want every team running the same engine. You do want every team running on the same chassis.

The chassis model answers the autonomy objection directly. Developers don't lose the freedom to make consequential decisions. They lose the obligation to make inconsequential ones.

### **What the platform layer should own**

_Key takeaway: The chassis should handle everything that doesn't require product judgment:  environment lifecycle, connection logic, and security gates. Automating these removes toil without touching autonomy._

-   **Environment lifecycle.** Every branch should automatically provision a production-identical environment on creation and decommission it on close. This eliminates the parity gap (where a bug only exists in one environment because dev, staging, and production have quietly diverged) and removes the staging queue entirely. When environments are ephemeral and per-branch, teams work in parallel rather than waiting in line.
-   **Connection and configuration logic.** How an application connects to its database, cache, and other dependencies should be defined in a single version-controlled configuration file; not assembled manually from tribal knowledge and documentation that was last updated eighteen months ago. When the wiring is codified, new developers inherit it, and when something breaks, the configuration is auditable.
-   **Security and compliance gates.** Compliance shouldn't arrive at the end of a sprint as a manual gate. It should be a function of the platform, automated hooks that scrub data, mask PII, and enforce access controls as part of environment creation. When these controls live at the platform layer, every team that ships through the standard path inherits them automatically. Security posture stops depending on which team is deploying and becomes a property of the system.

This is also where the audit argument becomes practical. When infrastructure is defined in code and every environment is provisioned from that definition, your configuration history is versioned, immutable, and auditable by default. You stop assembling evidence before a review because the evidence is a permanent byproduct of how you ship.

### **What teams should own**

_Key takeaway: Because the chassis handles delivery, teams get genuine autonomy over the decisions that actually determine product value: language, framework, architecture, and release cadence._

In practice, teams retain full freedom over language and framework (a Go microservice, a Python data pipeline, a Node API) the delivery chassis treats all of it as code to be moved to production. 

Release cadence stays with the team: some ship ten times a day, others operate on a slower cycle, and a standardized pipeline supports both without forcing faster teams to wait on approval gates designed for slower ones. Architecture decisions (database choice, service dependencies, caching strategy) belong to the team closest to the product problem.

This is the distinction that resolves the developer's objection. Standardization removes infrastructure decisions that shouldn't require engineering judgment. It doesn't touch the ones that do.

### **How this resolve the shadow IT problem**

_Key takeaway: Shadow tooling is a symptom of a sanctioned path that's more painful than the workaround. When the standard is also the fastest option, compliance becomes the path of least resistance._

Shadow IT in engineering teams rarely happens because developers want to undermine governance. It happens because the official path is slower, more bureaucratic, or more painful than building something themselves. According to Gartner, 41% of enterprise employees already use technology outside of IT oversight; a figure projected to reach 75% by 2027. 

In engineering specifically, that typically means bespoke deployment scripts, undocumented environment setups, and pipelines that exist outside any sanctioned platform. 

The chassis model addresses the root cause rather than the symptom. When the standard path is also the fastest path (when spinning up a production-identical environment takes seconds rather than a ticket and a two-day wait) developers choose it without being asked. You're not enforcing compliance; you're making it the default.

### **Getting there without a big-bang rewrite**

_Key takeaway: Adopting a chassis model doesn't require rebuilding your existing applications. It requires codifying the delivery layer and onboarding new projects to the standard path from day one._

The transition that stalls most standardization efforts is the assumption that it requires migrating everything at once. It doesn't. The practical approach is to establish the chassis standard for new projects immediately, so every new service or feature team starts on the Golden Path from its first commit, while existing services migrate opportunistically as they're touched for other work.

The onboarding benefit compounds quickly. Organizations with mature internal developer platforms in 2025 report a 40% reduction in developer onboarding time, with new engineers able to push code to production within their first week. 

When the path to production is a Golden Path, documented, automated, and identical across projects, a new developer's first week looks fundamentally different. They don't spend days configuring a local environment. They don't need to find the one person who knows how the deployment scripts work. 

The chassis is self-documenting by design: the configuration file is both the setup instruction and the running system. The sequencing of how you get there is more straightforward than most teams expect.

**Read the practical guide: How to standardize delivery without rebuilding your entire internal infrastructure.**

### **Frequently asked questions (FAQ)**

**Does this mean we're building an Internal Developer Platform?** 

Not from scratch. Building and maintaining a custom IDP typically takes months of platform engineering time and requires ongoing investment to keep current. A platform-as-a-service chassis gives you the standardization benefits of an IDP (consistent environments, automated pipelines, security at the platform layer) without the build and maintenance burden.

**How do we handle projects that don't fit the standard configuration?** 

The chassis is designed to be configurable, not rigid. Most non-standard requirements (specific database versions, unusual networking rules, custom build dependencies) can be expressed in the application's configuration file. The workflow standard holds even when the technical requirements vary.

**What happens to our existing bespoke pipelines?** 

They don't need to be migrated immediately. New projects start on the standard path from day one. Existing projects migrate as they're actively worked on (during a feature cycle, a dependency upgrade, or a refactor) rather than in a dedicated migration sprint.

**What's the impact on senior engineers?** 

It removes the work they shouldn't be doing. In fragmented organizations, senior engineers become the institutional memory for every bespoke environment they've ever touched; pulled into incidents not because the problem requires their expertise, but because they're the only ones who remember the setup. The chassis model removes that dependency and returns senior engineering time to architecture and product work.

**How does this affect audit and compliance posture?** 

Significantly. When infrastructure is defined in code and every environment is provisioned from that definition, your configuration history is versioned and immutable. Audit evidence is produced automatically as a byproduct of normal delivery rather than assembled manually before a review. Security controls at the platform layer apply consistently across every team rather than depending on individual implementation.

### [Multi-cloud made simple: reduce risk without complexity | Upsun](https://upsun.com/blog/multi-cloud-made-simple/)

# Multi-cloud made simple: a practical guide to reducing risk without adding complexity

On Monday, October 20, 2025, a global hyperscaler experienced a major incident disrupting many internet services for hours, with recovery progressing throughout the day.¹² It was a reminder that even world-class platforms can have bad days and that continuity plans must account for real dependencies across identity, DNS, networking, and third-party APIs.³ This piece is the practical follow-on to our article about _When the cloud goes dark: what every IT leader should have ready before the next outage_. It is written for CIOs and CTOs who now need a concrete plan to reduce risk without inflating operating cost or complexity.

**Expectation setting:** Upsun’s multicloud story is about smart initial region choice, portability, and tested business continuity and disaster recovery. Our value is in making restoration predictable and repeatable.

## **Who this guide is for and what you will deliver**

If you lead platform, infrastructure, or application operations and you must brief your board on a credible multicloud strategy, this guide gives you:

-   A step-by-step plan to achieve portability without tooling sprawl.
-   A clear governance model that travels with your app.
-   An implementation path on a cloud application platform, such as Upsun.
-   Metrics and artefacts you will deliver in 30, 60, and 90 days.

Analyst guidance continues to emphasise distributed cloud, portability, and digital sovereignty for I and O leaders.⁴ Uptime Institute’s research shows overall outage trends improving, yet complex IT and networking issues remain an impactful share of incidents.⁵⁶ You cannot eliminate outages, but you can reduce correlated risk and shorten restoration with disciplined preparation.⁵⁶

## **The multicloud strategy**

Multicloud is a strategy for choice and portability, not a promise of seamless failover. Treat it as an enabler for disaster recovery, sovereignty, and negotiating position.⁴ The operating principle is simple: accept a non-zero RTO for severe region events, then engineer for fast detection, clean restoration, and consistent governance.

## **Step-by-step plan: 30, 60, 90 days**

### **Day 0 to 30: make restoration executable**

**Outcome by Day 30:** a tested restoration path for one Tier 1 service, with artefacts that any on-call leader can run.

1.  **Pick one critical user journey and map dependencies.** Include identity, DNS, CDN, and operationally critical third-party APIs.
2.  **Set RTO and RPO targets** for the journey. Document downgrade modes you will use during restoration.
3.  **Establish a clean restore target.** Choose a secondary region or data centre aligned with sovereignty requirements.⁴
4.  **Export and rehydrate data.** Prove that today’s database can be restored and started in the target. Record time to fetch, rehydrate, and validate.
5.  **Capture everything in Git.** Declare services, routing, policies, and scaling in a single config.
6.  **Run a game day.** Simulate a provider-region incident, update DNS, use break-glass identity, and execute the restoration while operating in read-only. Measure time to detect, decide, and restore. Use NIST SP 800-34 as the structure for roles and decision thresholds.⁷⁸

### **Day 31 to 60: standardise and expand**

**Outcome by Day 60:** repeatable playbooks for two more services, policy-as-code guardrails, and a shared observability vocabulary.

1.  **Add two Tier 2 services.** Achieve cross-region resilience within your primary provider while keeping portability artefacts current.
2.  **Policy as code.** Express network policy, data retention, backup cadence, and sanitisation as reusable modules.
3.  **Shared observability.** Define a common golden signals dashboard for restore drills. This accelerates detection and decision time during incidents.
4.  **Financial operations hygiene.** Forecast the cost of restoration tests and steady-state backups. Tie spend to avoid incident hours, not only raw line items.

### **Day 61 to 90: Industrialise**

**Outcome by Day 90:** one-button restore pipeline from a clean Git checkout, quarterly drill cadence, and a board-ready report.

1.  **Automate environment build from Git**: One pipeline that rebuilds networking, policies, and services in the target.
2.  **Quarterly drills**: Schedule operator-led restoration tests for Tier 1 and Tier 2 services.

**Executive reporting**: Track RTO, RPO, dependency count, change failure rate, and drill results each quarter. IBM’s 2025 data places the average global breach cost at 4.44 million dollars, reinforcing why disciplined resilience work matters when incidents overlap.⁹

## **How to implement this on Upsun**

Upsun is a multicloud application platform that helps you standardise delivery and make restoration predictable. It is not an automated cross-region failover system. Instead, it gives teams the building blocks to execute BCP and DR with confidence.

### **1) Connect Git and declare your app**

Use a single YAML to define services, routes, policies, and scaling. Commit it alongside your code so environments can be rebuilt from a clean checkout. Read the Upsun overview and docs.

**2) Create automatic preview environments per branch**

Spin up production-like environments for each branch to rehearse restoration steps, validate feature flags, and exercise dependency changes safely. Explore developer resources.

### **3) Clone data with sanitisation**

Use instant data cloning to build representative test datasets while protecting sensitive information. This turns drills from theory into practice.

### **4) Orchestrate multi-service apps as a unit**

Define dependencies once and let the platform manage start order, health checks, routing, and scale consistently across supported providers. This reduces snowflake runbooks during stressful moments.

### **5) Observe once, act faster**

Centralise metrics, traces, and logs so the same dashboards apply in primary and restoration targets. This shortens detection and decision time during incidents.

### **6) See cost across providers**

Use one control plane to view utilisation and forecast spend across clouds. This improves governance without forcing you to stitch reports.

**What this means for an IaaS region outage:** if the hosting region for an Upsun cloud region suffers a severe incident, you would initiate a documented restoration into a different data centre, subject to provider conditions. There is downtime during this process. Your Upsun config, preview environments, data cloning, and orchestration make that restoration predictable.

## **Multicloud strategy without overreach**

### **Apply a tiered model**

-   **Tier 1: critical cash-path services**. Engineer for fast detection and operator-led restoration. Keep tested playbooks for DNS and identity changes. Ensure data, images, and config are ready to rehydrate in the secondary target.
-   **Tier 2: important but not cash-path.** Achieve cross-region resilience within one provider. Keep portability artefacts current so you can rebuild elsewhere if needed.
-   **Tier 3: internal and analytics.** Optimise for cost with disciplined backups and a longer RTO.

Automated failover across regions or providers is complex and expensive. Many enterprises adopt a non-zero RTO with tested restores that fit risk tolerance and budget. This aligns with current analyst emphasis on distributed cloud and portability.⁴

## **Governance that travels with your app**

-   **Policy as code:** Declare network rules, retention, cloning, and secrets handling once and reuse them across locations.
-   **Single change process:** One pipeline and quality gates, so deployments look the same everywhere.
-   **Crisis communications muscle memory:** Use NIST SP 800-34 for roles, exercises, and decision thresholds.⁷⁸
-   **Shared observability vocabulary:** Provider-agnostic metrics and traces allow apples-to-apples restoration reporting over time.

**Financial discipline:** Tie restoration work to avoided incident exposure and regulatory outcomes, not vanity metrics.

## **Measurement that proves resilience is improving**

Track and present these five core metrics quarterly:

1.  **RTO achieved vs target** for Tier 1 drills.
2.  **RPO achieved vs target** for restored datasets.
3.  **Change failure rate** and **mean time to restore**, since delivery quality and resilience travel together.
4.  **Hot-path dependency count**, trending down as you remove or decouple third-party risk.
5.  **Drill scorecard**, including steps executed from Git, time for data rehydration, and operator workload.

Uptime Institute’s research notes that while frequency and severity have improved in recent years, impactful incidents still occur and can ripple across providers.⁵⁶ Your metrics show how you shorten restoration and contain impact. NIST’s guidance remains a practical scaffold for exercises and playbooks.⁷⁸

## **Talking to stakeholders when your cloud platform fails**

-   **We align with industry guidance.** NIST SP 800-34 frames our plans and exercises.⁷⁸
-   **We emphasise region choice and portability.** This supports disaster recovery and sovereignty.⁴
-   **We can operate in a degraded state.** We know what goes read-only and what features we can shed during restoration.
-   **We measure what matters.** We report RTO, RPO, dependency count, and change failure rate. IBM’s 2025 research sets average breach cost at 4.44 million dollars, underscoring why disciplined resilience work remains essential when incidents overlap.⁹

**Bottom line:** start narrow, automate relentlessly, and make restoration a routine muscle. Upsun gives you a clear, Git-driven way to define environments, rehearse changes, and restore with confidence when the cloud has a bad day. To learn more: 

-   Explore the Upsun platform
-   Read the Upsun documentation
-   Visit the developer resources.

## **Sources**

1.  The Verge. “Major AWS outage took down Fortnite, Alexa, Snapchat, and more.”
2.  Financial Times. “Amazon says cloud services recovering from widespread outage.”
3.  Le Monde. “AWS, le service cloud d’Amazon, annonce avoir résolu la panne...”
4.  Gartner Newsroom. “Top trends shaping the future of cloud.”
5.  Uptime Institute. “Annual Outage Analysis 2025.”
6.  McMorrow Reports. “Uptime’s data center outage analysis: improvement but new risks.”
7.  NIST SP 800-34 Rev. 1 page. “Contingency Planning Guide for Federal Information Systems.”
8.  NIST SP 800-34 Rev. 1.
9.  Help Net Security summarising IBM’s 2025 study. “Average global data breach cost now $4.44 million.”

### [Best PaaS for Laravel in 2026: A Developer's Guide | Upsun](https://upsun.com/blog/best-paas-for-laravel-2026/)

# Best PaaS for Laravel in 2026

The best PaaS for Laravel in 2026 depends on three things: whether your stack is Laravel-only, how much you value preview environments, and how predictable you need your bill to be. fc

This guide compares the platforms that show up most often in Laravel deployment discussions,  Upsun, Laravel Cloud, Laravel Forge, Heroku, Render, Railway, DigitalOcean App Platform, Fly.io, and Vercel, against the criteria that actually matter for production Laravel workloads.

## **Key takeaways**

-   This guide covers the Platform-as-a-Service options most commonly used for Laravel applications in 2026.
-   Laravel Cloud is the most native experience for Laravel-only teams that want zero infrastructure decisions and direct alignment with framework releases.
-   Upsun is the strongest fit for Laravel teams that also run other stacks, need preview environments with real data, or have compliance and multi-cloud requirements.
-   Laravel Forge is the most cost-predictable option for agencies, solo developers, or projects where root server access matters.
-   Other PaaS providers (Heroku, Render, Railway, DigitalOcean App Platform, Fly.io) are viable for specific use cases. Vercel is not suited to full Laravel applications.

## **What to look for in a Laravel PaaS**

The criteria below apply to every platform in this guide.

-   **PHP runtime and extensions.** Current PHP versions are configurable per project, with PHP-FPM, Composer, and the extensions Laravel needs available without custom container work.
-   **Queue workers and scheduled tasks.** Dedicated worker containers for Horizon, Octane, and Laravel queues, plus native cron or a worker process for Laravel's scheduler.
-   **Managed services.** First-class managed MySQL or PostgreSQL, plus Redis or a Redis-compatible cache, provisioned and networked to the application.
-   **Per-branch preview environments.** Isolated environments for every Git branch, ideally with realistic production data, so changes are validated before they reach production.
-   **Observability and profiling.** Logs, metrics, and a way to profile Eloquent queries, middleware, and queue jobs.
-   **Multi-cloud and region flexibility.** Whether the platform can deploy across multiple clouds or regions for compliance, data residency, or latency reasons.

## **The top PaaS for Laravel in 2026**

#### **1\. Upsun**

A multi-cloud, polyglot PaaS with native Laravel support, preview environments that inherit production data, and integrated profiling.

Upsun runs Laravel alongside 10 supported runtimes, including PHP, Node.js, Python, Go, Ruby, Java, and .NET. The CLI detects Laravel projects and generates a starter .upsun/config.yaml file. Service connection details are exposed through .environment, so database, cache, and queue connections appear where the framework expects them. Horizon runs as a dedicated worker container, and Laravel's scheduler can be configured as cron or as a worker.

**Key capabilities:**

-   Native Laravel support with auto-generated YAML configuration
-   Dedicated worker containers for Horizon, Octane, and the Laravel scheduler
-   Preview environments on every Git branch that inherit code, configuration, services, and live production data
-   Blackfire profiling for Eloquent queries, middleware, queue jobs, and external calls
-   Managed services catalog: PostgreSQL, MySQL, Redis, Elasticsearch, OpenSearch, RabbitMQ, and Kafka
-   Multi-cloud deployment across AWS, GCP, Azure, OVHcloud, and IBM Cloud
-   Compliance with ISO 27001, SOC 2 Type 2, PCI DSS Level 1, HIPAA, and GDPR.

**Best for:** Laravel teams that need realistic preview environments, integrated profiling, multi-language stacks, regulated workloads, or cloud and region flexibility.

**Pros:**

-   Preview environments include live production data on every branch.
-   Polyglot runtime supports Laravel alongside Node.js, Python, Go, and other backends in the same project.
-   Resource-based per-second billing with per-environment sizing.

**Cons:**

-   Resource-based billing requires more upfront planning than fixed-plan Laravel Cloud tiers.
-   Less framework-aware tooling than Laravel Cloud's first-party UI.

#### **2\. Laravel Cloud**

The official infrastructure platform from the Laravel team, built around the framework's conventions and aligned with its release cycle.

Laravel Cloud is the Laravel team's first-party hosting product, launched in 2025. It deploys from GitHub, GitLab, or Bitbucket with no Dockerfile or YAML required, scaling web, queue, and scheduler workloads independently. MySQL and serverless Postgres are first-party, with Laravel Valkey as a Redis-compatible cache and object storage included.

**Key capabilities:**

-   Native PHP 8.2 through 8.5, with PHP 8.5 as the default for new environments
-   Auto-detected Laravel applications with no Dockerfile or configuration file required
-   Native queue, scheduler, and Horizon support with independent scaling
-   First-party MySQL, serverless Postgres, and Laravel Valkey (Redis-compatible)
-   Built-in Laravel Nightwatch integration for application monitoring
-   Auto-hibernation drops idle apps to zero compute, lowering off-hours costs

**Best for:** Laravel-only teams that want the most native experience, no infrastructure decisions, and direct alignment with framework releases.

**Pros:**

-   First-party Laravel tooling with deep framework integration.
-   Built-in preview environments aligned with Laravel conventions.
-   Autoscaling for queue workers, web, and scheduler tied to Laravel-specific metrics.

**Cons:**

-   Laravel-only by design; not a fit for teams that also run other backends.
-   AWS-only, with no BYOC or multi-cloud option.
-   Ephemeral filesystem; requires Laravel Object Storage (S3) for persistent files, the same constraint Heroku has.

#### **3\. Laravel Forge**

A server provisioning tool that configures and manages Laravel-ready VPS servers on AWS, DigitalOcean, Hetzner, Vultr, or Linode.

Laravel Forge is not a hosting platform. It connects to your cloud account and configures Nginx, PHP-FPM, MySQL or PostgreSQL, Redis, Supervisor for queue workers, scheduled tasks, and SSL via Let's Encrypt. You keep root SSH access. Forge has been the default Laravel deployment tool since 2013.

**Key capabilities:**

-   Provisions Nginx, PHP-FPM, MySQL or Postgres, Redis, and Supervisor on your own VPS.
-   Queue workers via Supervisor and Laravel scheduler via cron.
-   Automatic SSL via Let's Encrypt.
-   Root SSH access to every server.

**Best for:** Agencies running many client sites, solo developers who want predictable monthly costs, and projects where root server access matters.

**Pros:**

-   Most cost-predictable Laravel deployment option for small-scale.
-   Cloud-agnostic; works with any major VPS provider.
-   Root server access for teams that need infrastructure control.

**Cons:**

-   Not a PaaS; teams manage their own VPS lifecycle, OS updates, and HA.
-   No native autoscaling or preview environments.

##   
**Other viable platforms**

These PaaS providers can run Laravel competently but lack first-class Laravel awareness.

#### **Heroku**

A general-purpose PaaS that supports Laravel via the official PHP buildpack. Horizon, Octane, and the scheduler run as worker dynos via Procfile and as add-ons rather than native concepts. Heroku Postgres and Heroku Key Value Store are billed separately. Best for teams already invested in the Heroku add-on ecosystem.

#### **Render**

A plan-based PaaS that does not provide a native PHP runtime, per Render's documentation; Laravel deploys via Docker, with Render publishing an official Laravel-on-Docker guide. Compliance covers SOC 2 Type 2, ISO 27001, HIPAA via opt-in workspaces, and GDPR. Render offers 5 regions for per-service placement, but each service runs in one region with no cross-region private networking. Best for teams that have standardized on Docker and want a fixed monthly bill.

#### **Railway**

A usage-based PaaS that auto-detects Laravel applications and builds them with PHP-FPM and Caddy via its Nixpacks builder. Managed Postgres, MySQL, Redis, and MongoDB are available as one-click services. The UI is clean, but usage-based pricing under sustained traffic is harder to forecast than plan-based alternatives. Best for solo developers prioritizing deployment speed.

#### **DigitalOcean App Platform**

Deploys Laravel from a Git repository or container image, with Managed MySQL, PostgreSQL, and Redis as separate, paid DigitalOcean services \[VERIFY: current PHP build mechanism and supported versions\]. Best for teams that want predictable monthly costs and a single-vendor DigitalOcean stack.

#### **Fly.io**

Runs Docker containers as lightweight VMs across 18 regions, according to Fly.io's regions documentation as of 2026. Fly.io maintains an official fly-apps/dockerfile-laravel package supporting FrankenPHP, RoadRunner, and Swoole as Laravel Octane web servers. Managed services include Fly Managed Postgres, Tigris object storage, and Upstash for Redis. Best for teams that need multi-region deployment.

## **Not recommended for Laravel**

#### **Vercel**

Vercel is built for frontend workloads. Laravel can run via the vercel-php runtime and a serverless function wrapper, but this approach is not suited to a full Laravel application with queues, scheduled tasks, or persistent socket workloads. Teams that need a Laravel backend typically pair Vercel's frontend hosting with a separate backend platform.

## **Side-by-side Laravel PaaS comparison**

## **Choosing the right alternative**

-   **If your stack is Laravel-only**, Laravel Cloud is the obvious choice. If you also run a Next.js frontend, Python data services, or a Node API, Upsun keeps everything in one project with one configuration model.
-   **If preview environments matter to your workflow**, Upsun and Laravel Cloud both offer them, with Upsun's data inheritance being the most realistic for teams that need to validate against a representative state. Forge does not.
-   **If cost predictability matters more than scale**, Forge plus a small VPS is the cheapest entry point. For mid-size production apps with workers, schedulers, and managed services, resource-based platforms like Upsun and usage-based platforms like Railway and Laravel Cloud tend to be more economical than per-dyno models. For enterprise workloads with compliance needs, Upsun and Laravel Cloud Enterprise are the two platforms in this list with broad compliance coverage.

## **Frequently asked questions (FAQs)**

**What is the official PaaS for Laravel?**

Laravel Cloud is the official platform built and operated by the Laravel team, launched in 2025. It is designed exclusively for Laravel applications and aligns directly with the framework's release cycle.

**Which PaaS is best for Laravel Horizon?**

Upsun and Laravel Cloud both run Horizon as a dedicated worker process. On Forge, Horizon runs under Supervisor on your VPS. On Heroku, Render, Railway, and DigitalOcean App Platform, Horizon runs as a separately configured worker service or dyno.

**Which PaaS supports preview environments for Laravel?**

Upsun creates preview environments on every Git branch with live production data inherited from the parent environment. Laravel Cloud, Render, and Railway also offer preview environments, but without automatic production data cloning. Heroku offers review apps. Forge does not offer preview environments.

**Is Laravel Forge a PaaS?** 

No. Forge is a server provisioning and management tool that configures VPS servers you rent from another provider.

**How does Upsun compare to Laravel Cloud?**

 Laravel Cloud is Laravel-only and AWS-only, with the most framework-native experience. Upsun is polyglot and multi-cloud, with preview environments that inherit data, built-in Blackfire profiling, and broader compliance coverage. Teams that run Laravel alongside other stacks, need realistic preview data, or have regulatory requirements, tend to choose Upsun. Teams that want the simplest possible Laravel-only experience tend to choose Laravel Cloud.

### [Why I chose Upsun for building our RAG app | Upsun](https://upsun.com/blog/building-rag-application/)

# 5 reasons why I'm building our RAG application on Upsun

Developers are racing to harness the power of Large Language Models (LLMs) and apply advanced natural language processing across a myriad of applications. One technique that has surged in popularity is Retrieval-Augmented Generation (RAG), which involves using LLM-specific search methods to retrieve relevant information from data and feed it into an LLM alongside prompts. As an Entrepreneur in Residence at Open Strategy Partners, I’m developing such tools to amplify the value our B2B tech customers derive from our strategic marketing collaborations.

I chose Upsun to develop our applications for five key reasons that I believe are relevant to anyone working with RAG. Here’s a detailed look at each, roughly in order of importance:

### 1\. Managed vector databases out of the box

RAG relies on search techniques that involve LLMs in preparing the search index. This necessitates a specialized database capable of semantic querying rather than traditional SQL querying. For instance, I can query a vector database with "A rose by any other name would smell as sweet" and receive results that are semantically similar, even if they don't contain the exact words.

**Upsun offers several managed database options** that cater to this need, including:

-   **PostgreSQL with PGVector Extension**
-   **ElasticSearch**
-   **OpenSearch**

These options provide robust backends for modern RAG applications, eliminating the need to procure additional third-party services. Keeping the data and query engine within the same network as the application not only streamlines operations but also enhances performance.

### 2\. Efficient cloning for testing (e.g., chunking)

RAG pre-processes texts by chunking them—breaking them into similarly sized pieces that fit within the LLM's embedding engine limits. The method of chunking significantly impacts the performance of a RAG application, making the choice of a chunking algorithm crucial.

**Upsun simplifies this process** by allowing the creation of a main environment containing all unchunked texts in the database. From there, I can create multiple branches to test different chunking algorithms. Since Upsun clones data from the parent environment when creating a new branch, I end up with identical copies of my application and data, each running independently with its own testable URLs. This setup enables direct comparison of different chunking strategies. Once the optimal chunker is identified, it can be merged into the main environment, and unnecessary branches can be deleted. No other system offers such an efficient workflow for this process.

### 3\. Cost-effective embeddings sharing across environments

After chunking the texts, the next step is to create embeddings by sending these chunks to an LLM, which converts them into vector arrays representing the semantic understanding of the text. Each chunk processed incurs an API call to the LLM, translating to time, computational resources, and costs. These embeddings are valuable assets, and duplicating them would be wasteful.

**With Upsun, embeddings can be generated in a parent environment** and easily shared with all developers by synchronizing this parent environment with their individual development environments. This approach ensures that embeddings are never duplicated, saving costs and maintaining consistency across the team. Additionally, it eliminates the need for complex DevOps setups, as synchronization is achieved with a single command on Upsun.

### 4\. Secure management of API keys and secrets

Interacting with LLMs necessitates careful handling of API keys and other sensitive secrets. Mismanagement can lead to API keys leaking into public repositories like GitHub, accidental invalidation of production keys, or unauthorized usage leading to unpredictable costs.

**Upsun addresses these challenges** with a robust system for storing and managing secret keys. It allows for:

-   **Environment-Specific Keys:** Different keys can be reserved exclusively for production, testing, or specific projects.
-   **Access Control:** Keys can be restricted to certain environments or projects, enhancing security.
-   **Expense Monitoring:** By controlling API key usage, it's easier to monitor and manage associated costs.

For example, I recently used Upsun to provide OpenAI keys to an intern, ensuring they could only perform specific types of operations while keeping a close eye on API call expenses.

### 5\. Modern development tools and secure builds

Upsun isn't just about databases and environment management; it also excels in supporting modern application development practices. In our setup, we utilize:

-   **Django** **(Python):** For building robust web applications.
-   **FastAPI:** As our REST framework for efficient API development.
-   **Celery:** For background workers handling long-running tasks, ensuring the main Django app remains responsive.

**Key Advantages of Upsun:**

-   **Powerful Request Routing****:** Facilitates the design of custom REST APIs tailored to our needs.
-   **Deterministic and Immutable Builds:** Upsun builds the codebase deterministically from `requirements.txt` and packages the code into immutable images. This ensures that our application remains secure from unauthorized changes and is protected against a range of potential cyber threats that exploit writable file systems.

For more information I’ve written a series of articles about developing Django projects on Upsun.

### Conclusion

Choosing the right platform is crucial for the success of RAG applications. Upsun stands out by offering comprehensive managed services, efficient testing workflows, cost-effective embedding management, secure secret handling, and support for modern development practices. These features collectively make Upsun an ideal choice for building scalable, secure, and high-performance RAG applications. If you're venturing into the world of Retrieval-Augmented Generation, Upsun is certainly a platform worth considering.

#### About the author

Robert Douglass, a former member of the Platform.sh team, helps product teams bring their greatest innovations to life. He is currently building applications that amplify the value of strategic marketing assets for B2B tech companies as Entrepreneur in Residence at Open Strategy Partners GmbH.

### [Automate fintech compliance and security | Upsun](https://upsun.com/blog/why-fintechs-are-moving-to-automated-compliance/)

# Why Fintechs are moving to automated compliance

Manual compliance work is a hidden drag on delivery speed for fintechs and regulated institutions. There is a faster path. Companies handling payment data know the cycle: every new feature requires security audits, evidence collection, and control verification before release.

The traditional approach to building a compliant stack means taking on every layer yourself. You rent the server, configure the network, manage the patches, harden the operating system, and then spend weeks documenting each step for an auditor. 

For most financial institutions, the cost is the loss of engineering time spent on infrastructure maintenance and audit preparation rather than on product development. Senior engineers end up managing DevOps toil and writing compliance documentation rather than building fraud detection models or improving customer experiences.

## How inherited controls reduce your compliance scope

The concept is simple: deploy your application on a platform that is already PCI-certified, and a significant portion of infrastructure controls becomes the provider's responsibility under a shared responsibility model. 

This is what Upsun offers fintech teams through its certifications for PCI DSS Level 1, SOC 2 Type 2, ISO 27001, and HIPAA, with validation for IBM Cloud for Financial Services. Rather than rebuilding security controls from the ground up, Upsun manages automated controls at the platform layer. These include:

-   **OS-level security and patching**: Upsun manages hardened Linux kernels and applies security updates without service interruption.
-   **Network isolation and encryption**: Every project runs behind firewalls with services in full network isolation. TLS encrypts data in transit; disks are encrypted at rest.
-   **Project isolation**: Customer environments are isolated using namespaces, seccomp, and cgroups. No cross-contamination between workloads.
-   **Read-only file systems**: Application code deploys to read-only environments, preventing unauthorized runtime modifications.
-   **Access control and audit logging**: Fine-grained, per-environment permissions with MFA enforcement. Every deployment, configuration change, and access event is logged.

When an auditor asks how you handle OS patching or network encryption, the answer is a provider certificate**.** Your QSA spends less time on infrastructure validation. Your developers stay on the product roadmap instead of gathering evidence.

## Compliance defined as code, not maintained by checklist

One of the biggest risks in financial services is **configuration drift**: a developer makes a quick change to a staging environment and accidentally opens a port or modifies a setting that violates a security policy. In a traditional setup, this kind of drift can go undetected until the next audit cycle.

Upsun addresses this through its `.upsun/config.yaml` file. Your entire infrastructure definition: runtimes, services, routes, build and deploy processes, lives in a single, version-controlled configuration. Every branch, every preview environment, and every production deployment follows the same blueprint.

The configuration is committed to Git, your security posture is versioned, timestamped, and auditable. There is no gap between what was documented and what was deployed. For compliance teams, this means infrastructure evidence is always available in the repository history, rather than being assembled after the fact from screenshots and spreadsheets.

_**Related reading:**_ _Bank cloud migration without a feature freeze_

## What this means for compliance and risk teams

Inherited controls don’t just benefit engineering. If you’re a Chief Compliance Officer or GRC lead, they change the economics of your audit cycle in three ways:

-   **Smaller scope of assessment:** When your platform provider holds PCI DSS Level 1, SOC 2 Type 2, and ISO 27001 certifications, entire control families are removed from your assessment checklist. You reference a single provider certificate instead of documenting how your team manages OS patching, network encryption, and access controls at the infrastructure layer.
-   **Simpler third-party risk register**: DORA Article 28 requires documented oversight and exit strategies for every ICT provider. Consolidating infrastructure onto a single certified platform reduces the number of critical vendor relationships your risk team needs to evaluate, monitor, and report on. One provider certificate replaces a patchwork of separate assessments across compute, networking, storage, and security tooling.
-   **Audit evidence built into the workflow**: Upsun’s infrastructure is defined as code, and every change is logged. Your compliance team can point auditors to versioned configuration files and deployment logs rather than manually assembled evidence packages.

_For a deeper look at how Upsun supports DORA exit strategy requirements, see_ _DORA exit strategy for financial services__: portable cloud architecture with Upsun._

### **Learn more**

-   DORA exit strategy for financial services: portable cloud architecture with Upsun
-   Bank cloud migration without a feature freeze
-   Cut PCI DSS audit burden with inherited compliance
-   Technical guide to policy enforcement on Upsun
-   Upsun Trust Center
-   PCI DSS compliance guidance

### [The bottleneck has moved. AI is rewriting the Software Development Lifecycle | Upsun](https://upsun.com/blog/ai-rewriting-software-development-lifecycle/)

# The bottleneck has moved. AI is rewriting the Software Development Lifecycle

If you've read our previous piece on the 8 stages of AI engineering maturity, you know where your team sits. Turns out adopting AI is the easy part; adapting to its consequences is where most organizations struggle.

For more than a decade, software organizations optimized around a single assumption: implementation capacity was scarce. Developer productivity tools, platform engineering, and automation all emerged from the same underlying logic — writing software was the primary constraint on delivery, and everything else was built around solving for that. As AI has begun to reduce that constraint, the bottleneck hasn't disappeared. It has simply moved, and it keeps moving.

Over the past several months, Fabien Potencier, Upsun's CTPO, and I — and a small but curious team — threw ourselves into conversations with Product and Engineering leaders about how AI is reshaping their organizations. We talked to a lot of people, asked a lot of questions, and came away with a lot to think about. This blog is our attempt to share what we learned. 

What came back surprised us — not in a single dramatic revelation, but in the consistency of a few signals that kept appearing across companies of all sizes. 

Greg Gambatto, founder of Ctrl+G,  put it plainly: "Our product and engineering organization now spends more on tokens than on salaries." Not cloud hosting, not payroll taxes. Tokens: an operational cost that nobody anticipated would grow as fast, and no financial system was built to track, let alone govern.

## The engineers got faster. The organization didn't.

Adoption began where most technology shifts begin: with individual contributors. Engineers experimented, productivity improved, and the most advanced users moved from using AI as an assistant to orchestrating multiple agents simultaneously — generating code, writing tests, reviewing architecture risks, and deploying to the cloud. The gains were real and visible. What didn't change was everything around them.

Review processes, approval chains, and deployment controls were still designed for a world in which humans authored every line. As output increased, review queues grew alongside it, and senior engineers found themselves spending less time building and more time validating work they hadn't written. As one CTO put it: "We can generate a week's worth of code in an afternoon. But our review process is the bottleneck. It takes forever and still assumes humans authored everything."   
  
The constraint hadn't disappeared; it had migrated from creation to validation, and that migration exposed a challenge most teams hadn't anticipated, which overwhelmed the most senior members of the team.

## The trust problem nobody planned for

Reviewers are no longer evaluating logic and style. They're hunting for hallucinations, architectural inconsistencies, and security issues buried inside otherwise convincing implementations — output that appears correct on first inspection but requires more scrutiny, not less.   
  
Some teams responded by automating the review layer itself, using layered agents that generate, critique, and score output before anything reaches a human. It works, but it isn't an upgrade to the existing process. It's a new one, built from different assumptions, and rebuilding it takes time and resources most teams hadn't budgeted for.   
  
While engineering worked through that, a different kind of pressure was building on the other side of the process.

## Product became the next constraint

Several organizations started reporting something that would have sounded unusual just a few years ago: engineering was ready to ship features that product hadn't finished defining.   
  
Historically, implementation was always the limiting factor. That relationship has quietly inverted. AI systems don't handle ambiguity the way experienced engineers do; human developers fill gaps through discussion and judgment, while AI systems execute what is written, propagating vagueness directly into the output.   
  
Specification quality has become a first-class engineering concern, and org charts are beginning to reflect it — product managers prototyping directly, designers pushing commits, and engineers spending more time defining systems than writing every line themselves. When implementation becomes easier, clarity becomes the scarce resource.

## The cost caught up

For most teams in the early stages, the economics feel manageable; subscriptions, predictable costs, productivity gains that justify the spend. That picture changes the moment orchestration enters. Token consumption doesn't scale with headcount the way software licenses do. It scales with usage, autonomy, and ambition, growing with every retry, every failed run, and every agent that explored further than it should have.   
  
Some organizations are already reporting AI engineering costs rising from hundreds to thousands of dollars per engineer per month. Uber's CTO told The Information the company burned through its entire 2026 AI budget by mid-April. On the All-In podcast, Salesforce CEO Marc Benioff said the company expects to spend $300M on Anthropic tokens in 2026, almost entirely on coding. Tokens have quietly become strategic enough to compete with payroll, and most finance teams don't see it coming.

## A new SDLC is emerging

What is changing is not the existence of review, governance, or product definition — it's their relative weight. For years, implementation speed was the primary constraint, and the entire industry organized itself around solving for that. AI has dramatically reduced that constraint and, in doing so, has exposed everything quietly sitting behind it.

The organizations adapting fastest are not the ones with the best models. They are the ones willing to rethink the assumptions embedded in how software gets built; their processes, their team structures, their economics,  and to treat that rethinking as seriously as any technical decision.

The bottleneck didn't disappear. It moved into review processes, product specifications, and token budgets that nobody planned for. The teams pulling ahead aren't distinguished by the tools they use. They're distinguished by how quickly they noticed where the constraint had moved.

### [Fix bugs fast with environment cloning | Upsun](https://upsun.com/blog/the-reproduction-problem-why-you-cant-recreate-the-investigative-gap/)

# The reproduction problem: why you can’t recreate the investigative gap

In the modern dev stack, we have mastered the art of the deploy. 

We have CI/CD pipelines that ship code in minutes and observability dashboards that track every millisecond of latency. Yet, when a P0 incident strikes, the most common phrase in Slack isn’t a solution; it’s "I can’t reproduce this locally."

This is the Reproduction Gap.

Most engineering teams are world-class at building and monitoring, but they are remarkably fragile at recreating runtime behaviour.  

Without an identical environment, debugging becomes a manual forensic task where the variables change every time a developer attempts a fix. 

Solving this requires more than just better logs; it requires an architecture where production reproduction is a standard, automated skill rather than a senior-level manual chore.

### The repro gap: more than just "it works on my machine"

When a developer says they can’t reproduce a bug, they aren't complaining about a lack of skill. They are pointing to a structural failure of environment parity. 

According to our engineering teams, the "Repro Gap" is usually caused by the drift of three specific variables:

-   **Stateful Data Entropy:** Bugs often live in the "shape" of production data that isn't present in synthetic sets. For example, a user might put an emoji in their name that breaks a specific UI component, but the developer’s "clean" test data lacks that specific case.
-   **Architecture Topology:** Many developers use a local LAMP stack or a simplified Docker setup that lacks the service mesh, cache layers, or search indexes of production. If production uses a cache but your local environment doesn't, all your cache-fetch code goes largely untested until it hits the live site.
-   **Minor Version Drift:** Differences in application libraries or service versions (like running PHP 8.2 locally while a customer is on 8.1) lead to "Heisenbugs" like deprecation warnings that only appear in the production logs.

The result is an investigative gap where 80% of the triage time is spent attempting to see the bug happen.

To close this gap, teams are moving toward instant environment cloning to automate the plumbing and move directly to the resolution.

### The "Heisenbug" cost and the "User Interview" tax

The inability to reproduce a bug instantly creates an investigative gap that can last days. For subtle or user-specific issues, reproduction becomes nearly impossible without a detailed "interview" with the user to figure out exactly which variables need to be replicated.

Because reproduction is manual and fragile, most teams default to "debugging in production." They push a fix and hope the live environment likes it. T

his leads to a cycle of creating junk data in production that can't be deleted, as developers run several iterations of a "test fix" against live databases.

Every manual database export/import cycle to reset a test environment can eat several minutes per iteration, effectively killing the developer's "flow state." (You can explore how instant environment cloning automates this plumbing to move directly to the fix.)

### The safety paradox: Why we settle for "close enough"

Why don't teams just spin up a fresh environment for every bug? 

If you aren't using a containerized, automated environment, provisioning the required services is non-trivial; you’re manually installing software and duplicating configs. Even in advanced K8s setups, cloning production data quickly is a manual chore that often relies on slow, custom scripts.

But "close enough" is what creates the Incident Hangover.

When you can’t reproduce a bug in isolation, you work slowly because you’re afraid of the "Safety Paradox": the fear that an experimental fix might accidentally trigger a production email or corrupt a shared database. 

True speed comes from the confidence that your environment is a 100% isolated, disposable clone of the production "crime scene."

_**For more info:**_ _Learn how to move from "hope-based" security to automated, versioned truth._ _Read the YAML configuration overview_.

### Next steps: build the reproduction muscle

Reproduction shouldn't be a senior-level "magic trick." It should be a standard, automated part of your workflow.

1.  **Audit your investigative gap:** On your next three bug reports, track how much time was spent "setting up the repro" versus "writing the code."
2.  **Standardize your topology:** Use the `.upsun/config.yaml` to ensure your dev, staging, and production environments are replicas. To move even faster, you can standardize these setups with our debugging template packs.
3.  **Eliminate the "Shared Staging" model:** Move to a workflow where every Git branch automatically inherits the production state. Watch how this workflow looks in practice here.

### Frequently asked questions (FAQ)

**Why is reproduction harder than deployment?**

Deployment is a one-way street: you are pushing code to a known state. Reproduction is "reverse engineering": you are trying to recreate a complex, stateful moment in time. Without automated cloning, you are forced to rebuild that state manually every time.

**Does Upsun help with "Heisenbugs"?**

Yes. Because Upsun clones the entire service mesh and configuration alongside the code, the environmental variables that cause Heisenbugs are captured in the clone. The bug has nowhere to hide.

**How do we handle the security of production data during reproduction?**

Upsun uses automated hooks to scrub sensitive data and neutralize emails during the branching process. You get the realism of production data without the security risk of "debugging in production."

**What happens if a fix works in the clone but fails in production?**

On Upsun, this is mathematically unlikely. Since the clone and the production environment use the same `.upsun/config.yaml` and infrastructure-as-code definitions, the runtime behavior is identical.

**Can junior developers use this workflow?**

Absolutely. By automating the reproduction setup, you lower the barrier to entry for triage. A junior dev can spin up a production clone via a Git branch and start investigating without needing a senior engineer to configure the environment for them.

### [How to patch 40 Drupal sites without 40 deployments | Upsun](https://upsun.com/blog/patch-drupal-fleet-without-manual-deployments/)

# How to patch 40 Drupal sites without 40 manual deployments

**Standardizing the fleet: automated updates for multi-site management**

There's a specific kind of update that Drupal agencies and enterprise teams dread: a security release in something the whole fleet runs on, the PHP runtime, the database engine, or a shared service, with a patched version available now and a deadline attached. For a team managing a single site, moving to the patched version is an afternoon of work. For a team managing 40 Drupal installations across a client portfolio or subsidiary structure, it's a race against a deadline with 40 manual deployments between them and done.

By the end of the day, most sites are patched. A few aren't, because something went wrong partway through and got deprioritized. Those few sites sit in the queue, unpatched, for longer than anyone intended.

This is the fleet management problem. It's not about any single site. It's about what happens when you multiply the overhead of managing one site by the number of sites in the fleet. It isn't specific to Drupal, either: any fleet of sites running the same stack hits the same wall, whether that's Symfony, WordPress, or a Node.js frontend. Drupal is just the running example here.

## **Why manual fleet management doesn't scale**

_Key takeaway: Manual updates are fine for one site. For a fleet, the labor scales linearly with the number of sites, while the risk of inconsistency compounds. Any process that requires a human to repeat the same action 40 times will eventually produce a site that was missed._

The standard approach to managing a fleet of framework installations is essentially the same process as managing a single installation, repeated. Log into each site, apply the update, verify the deployment, and move to the next one. For a fleet of ten, this is tedious. For a fleet of fifty, it occupies someone for days. For a fleet of two hundred, it's a dedicated role.

The repetition isn't just expensive, it's error-prone in a particular way. Manual processes applied at scale produce inconsistent results, not because anyone is careless, but because humans can't apply the exact same procedure identically across dozens of environments. One site gets a slightly different configuration. Another gets skipped during a deployment that failed and wasn't retried. A third gets updated with a different PHP version because the person doing it didn't check the config file.

The fleet starts identically. Over time, it diverges. Sites that were launched from the same template six months ago are running different PHP versions, different service versions, and different infrastructure configurations. The divergence is invisible until something breaks, at which point the debugging process has to account for the fact that the site that's broken may not match the site that's working.

## **Version drift: the compounding problem**

_Key takeaway: Version drift across a fleet isn't just a maintenance problem. It's a security surface and a debugging liability. A fleet where every site is running the same configuration is fundamentally easier to secure and support than one where every site is slightly different._

Version drift tends to be treated as a cosmetic problem, something to clean up eventually, when there's time. It's actually a security and operational liability that gets more expensive the longer it persists.

From a security perspective, a fleet with inconsistent patch levels has an inconsistent attack surface. A vulnerability that's been patched on 38 of your 40 Drupal sites is still an open vulnerability, because the two unpatched sites are real targets. Fleet security is only as strong as the least-patched site.

From a support perspective, a fleet where every site is slightly different means that a solution that works for one site may not work for another. Debugging a reported issue requires first establishing what's actually running on that specific site, which may differ from what you think is running, because the config file was updated six months ago but this particular site wasn't included in that deployment batch.

The only sustainable answer to version drift is making it structurally unnecessary: not by being more disciplined about manual updates, but by making manual updates unnecessary in the first place.

## **What automation actually looks like**

_Key takeaway: Fleet automation isn't a custom tooling project. It's using the platform API and a version-controlled config file together: the config defines what every site should be running, and the API applies that definition across the fleet without site-by-site intervention._

Upsun is a platform-as-a-service that manages the infrastructure layer of your application stack so your team doesn't have to. For fleet management, that means combining a shared config file with the Upsun API to propagate changes across every site in the fleet automatically.

The config file defines the target state for every site. A Drupal fleet config might look like this:

```shell-session
applications:
  drupal:
    type: php:8.3                          # change this once to update the whole fleet
    variables:
      env:
        DRUPAL_HASH_SALT: "change-per-site" # overridden at the project level per site
    relationships:
      database:
        service: db
        endpoint: mysql
      cache:
        service: redis
        endpoint: redis

services:
  db:
    type: mariadb:10.11                    # platform manages patching within this version
  redis:
    type: redis:7.2
```

When PHP 8.3 needs to move to 8.4, or MariaDB needs a version bump, that change happens in the config file. One change, one commit, one code review. Then a script iterates over every project in the fleet and triggers a deployment:

```Python
import requests

API_TOKEN = "your-api-token"
FLEET_PROJECT_IDS = ["project-1", "project-2", "project-3"]  # or fetched dynamically via API

# Exchange the API token for a short-lived access token (valid ~15 minutes)
auth = requests.post(
    "https://auth.upsun.com/oauth2/token",
    auth=("platform-api-user", ""),
    data={"grant_type": "api_token", "api_token": API_TOKEN},
)
access_token = auth.json()["access_token"]

for project_id in FLEET_PROJECT_IDS:
    response = requests.post(
        f"https://api.upsun.com/projects/{project_id}/environments/main/redeploy",
        headers={"Authorization": f"Bearer {access_token}"},
    )
    if response.status_code in (200, 201, 202):
        print(f"{project_id}: redeploy triggered")
    else:
        print(f"{project_id}: redeploy failed - {response.status_code}")
```

The script doesn't configure anything. The config file already defines the target state. The script just tells each project to apply it. Each redeploy is triggered independently, so one project doesn't wait on another, and the output gives you a clear record of which projects succeeded and which need attention.

This is what fleet management looks like when it's not a manual process. The update cycle is: change the config file, commit it, and run the script. The human involvement is in the decision about what to change, not in applying the change 40 times.

## **What a consistent fleet enables**

_Key takeaway: A fleet where every site is known to be running exactly what the config file says removes an entire category of uncertainty from operations, support, and security. You stop asking "what is this site running?" and start knowing._

The operational benefits of a consistent fleet go beyond the time saved on updates.

Support becomes faster because every site in the fleet is a known configuration. When a client reports an issue, you're debugging the application, not the environment. The environment is the same as every other environment in the fleet.

Security becomes auditable. "All sites are running PHP 8.3.x with the MariaDB 10.11 service layer" is a statement you can make and verify, because the config file is version-controlled and the API deployment logs confirm which projects are running which version of it.

Onboarding a new subsidiary or client site into the fleet is straightforward. Fork the config file, customize the per-site variables (database credentials, site-specific configuration), deploy. The new site starts at the same baseline as every other site in the fleet.

And when a critical advisory lands on a Friday afternoon for a runtime or service the fleet depends on, the response is: update the config file, run the script, review the output. Not 40 manual deployments.

## **Already managing a fleet manually?**

The config file approach doesn't require rebuilding existing sites from scratch. The config describes the target state, so migration is a matter of writing down what each site is already running: the PHP version, the services, the relationships between them. Start with one site as the template, verify it matches production, then extend it to the rest of the fleet. The fleet starts converging from the first site that moves across.

* * *

## **Frequently asked questions (FAQ)**

**Does every site in the fleet have to be identical?**

The config file defines the shared baseline: runtime version, service versions, and infrastructure configuration. Per-site variables (database credentials, environment-specific settings, custom domains) are configured separately per project and override or extend the base config. The fleet can share a common infrastructure definition while each site remains independently configurable.

**How do we manage the config file across a large fleet without a monorepo?**

A common pattern is a dedicated "fleet template" repository that contains the shared config file. Individual site repositories pull from or reference that template. When the template is updated, a CI pipeline can iterate over all registered fleet projects and trigger deployments via the API. The platform API supports this pattern directly.

**What happens if a deployment fails on one site mid-fleet update?**

The script approach means each deployment is independent. A failure on one project doesn't block others. The script output tells you which projects succeeded and which failed, so you have a clear list to retry or investigate rather than having to work out which sites were reached and which weren't.

**Can we roll back a fleet update if something goes wrong?**

Yes. Because the config file is version-controlled, rolling back means reverting the commit and redeploying. Upsun also maintains deployment history per environment, so individual environments can be rolled back through the platform if needed.

**How do we handle sites that legitimately need a different configuration from the rest of the fleet?**

Exceptions are handled at the project level. A site that needs PHP 8.2 while the fleet standardizes on 8.3 can have that specified in its own config file, which takes precedence. The pattern is: shared template for the fleet baseline, per-project overrides for justified exceptions. The key difference from a fully manual approach is that exceptions are explicit and documented rather than accidental.

### [Why AI adoption is slowing your team | Upsun](https://upsun.com/blog/why-ai-adoption-is-slowing-your-team/)

# Why individual AI adoption is breaking team-level throughput

There is a question a lot of engineering leaders are quietly sitting with right now: we have rolled out AI tools across the team, the developers seem faster, so why isn't more software actually shipping?

It is a reasonable thing to consider. Pull requests are opening faster. Lines of code per sprint are up. The boilerplate that used to take full afternoons now takes minutes. By every local measure, the investment is paying off.

But look at the macro numbers (e.g., features delivered to production, cycle time, and actual time-to-market), and the picture is different. In a lot of teams, cycle time has gotten longer since AI tools landed.

The reason is straightforward, even if it is uncomfortable: writing code was never the bottleneck. Everything downstream was. 

### **The problem with optimizing the wrong constraint**

_Key takeaway:_ _Generating code faster doesn't accelerate delivery. It just moves the problems downstream._

Software delivery has never been primarily constrained by how fast a developer can write a function. The real constraint, in most mature teams, is the structural process required to verify, govern, and safely release code: review, testing, compliance checks, merge decisions, and deployment gates.

AI coding assistants do not touch any of that. They make one part of the pipeline dramatically faster while leaving everything downstream exactly as it was. This has a significant impact on cross-functional teams, including (but not limited to) reliability, quality assurance, security.

The result is predictable in retrospect. You have increased the rate at which unreviewed code enters the review queue without increasing the team's capacity to process it. The constraint did not disappear; it simply backed up into the queue.

### **What is actually happening in the review queue**

_Key takeaway_: _When a reviewer merges code they didn't write and can't trace, accountability for that decision falls entirely on them._

Senior engineers and tech leads are the ones absorbing the impact. They are being handed pull requests that are larger, more frequent, and harder to reason about than anything they have reviewed before.

The difficulty is not just volume. It is that the code arrives without a clear trail of intent. A reviewer reading a diff written by a human developer can usually reconstruct the thinking: they know the person, the ticket, and the conversation in Slack two days ago.

A multi-file diff generated in a few minutes by an AI assistant carries none of that context. The reviewer did not plan the change, did not write it, and cannot easily trace why certain decisions were made.

That creates pressure toward a pattern nobody wants to admit is common: merge it, trust the compiler, and deal with problems when they surface. This happens not because the reviewers are careless, but because the alternative of properly reverse-engineering every AI-generated patch under a growing backlog simply isn't sustainable.

The individual productivity gains do not disappear; they just get absorbed by the pipeline friction. The developer saved two hours writing code; the tech lead spent four hours reviewing it. Net result: the organization lost time.

### **The structural question worth asking**

_Key takeaway:_ _The fix isn't more tooling. It's changing where and how in the process AI operates._

The reflex response is to treat this as a tooling problem. Find a better AI tool, set tighter rules about what developers can generate, or add more reviewers. None of that fixes the underlying issue.

The underlying issue is that AI-assisted development was dropped into a process built entirely for human-paced, human-planned development. The process assumed a certain relationship between the person writing code and the intent behind it. That assumption no longer holds.

The teams starting to move past this problem are not the ones restricting AI use. They are the ones asking a different question: instead of making individual developers faster in isolation, what would it look like to make the team's workflow faster together?

That means thinking about where AI automation lives, whether in a private local editor or in a shared environment the whole team can see, and what kind of un-bypassable decision trail it leaves behind when it acts.

That is not a tool change. It is a process change. And for most organizations, it is the conversation that should have happened before the licenses were purchased.

**This is the problem Upsun Dispatch™ was built to solve: moving AI automation off the laptop and into a shared layer the whole team can see.**

-   **New here?** **Read the introduction to Upsun Dispatch**
-   **Want to help build it?** **Apply to the founding design partner cohort**

* * *

### **Frequently asked questions (FAQ)**

**Why does AI-generated code create an audit problem?**

Any modification introduced into a codebase that lacks an auditable record of why it was generated. It compiles, it passes syntax checks, but the reasoning behind the architectural decisions is invisible to everyone else on the team. Six months later, when something breaks, nobody can reconstruct what the agent was trying to do.

**Why isn't a well-written Git commit message enough?** 

A commit message captures a human's summary of a change. It doesn't capture the prompts, context, and reasoning chain that led an AI agent to make specific structural decisions. Those two things aren't equivalent, and treating them as equivalent is how intent gets lost.

**Does this create extra work for the developer?** 

It shouldn't. The goal isn't to ask developers to manually document every AI interaction. It's to capture that context at the point where AI automation runs, as a natural part of the workflow rather than an additional step bolted on after the fact.

**How does this connect to compliance requirements?** 

Frameworks like ISO 27001 require teams to demonstrate why a change was made, who authorized it, and how it was verified. Code that was generated by an agent running locally on a developer's laptop, with no shared record of context or approval, makes that very difficult to prove. That's a real audit risk, not just a process concern.

### [Close the AI context gap in your IDE | Upsun](https://upsun.com/blog/mcp-server-ai-ide-context/)

# Bridging the AI context gap: Why your IDE needs a platform contract

_Key takeaway: Hosting an MCP (Model Context Protocol) server on Upsun lets AI IDEs like Cursor, Codex, Claude Code and Windsurf reach real infrastructure context (database schemas, service logs, environment variables), closing the gap between local coding assistants and your cloud environment._

### **The blind spot in AI-assisted development**

The common cause of AI-generated bugs isn't faulty logic. It's missing context. When you ask an AI agent to "optimize this query," it reads the syntax but has no view of the state.

It doesn't know whether your Postgres table holds a hundred rows or a hundred million. It can't see your Redis eviction policy, and it has no idea how your network is routed.

The Model Context Protocol (MCP) is an open standard that connects LLMs to external data sources and tools. By tunneling an MCP server into your Upsun environment through the CLI, you make your live infrastructure a readable dependency for your AI.

### **I. Turning infrastructure into a readable dependency**

_Key takeaway: an_ _MCP server tunneled into Upsun_ _through the CLI reaches the same services and credentials your application already uses, so the AI grounds its suggestions in your real configuration._

The Upsun CLI opens a secure tunnel from your machine to your project's services, the same ones your application connects to through its relationships. Point a database-specific MCP server, such as the official PostgreSQL MCP server, at that tunnel, and it inherits a live connection without you hand-writing credentials.

That has two effects. The AI tool bases its output on your live environment configuration instead of guessing, which cuts down on hallucinated assumptions and failed deployments. And because connection strings are handled through the tunnel rather than typed into a prompt, the AI agent never has to guess how to connect to your data.

### **II. The secure "context tunnel"**

_Key takeaway: the Upsun CLI opens an encrypted connection between your local machine and an isolated cloud environment, so production-grade data isn't exposed to the public internet._

To connect a local instance of Cursor, Codex, Claude Code or Windsurf to your cloud context, you use the Upsun CLI to open a secure tunnel, then point a locally running MCP server at it. This connects your locally run MCP server to a specific preview environment.

-   **Data isolation:** the AI agent only sees the context of the branch you're working on. Upsun provides network isolation and encrypted traffic, so your metadata stays inside the environment.
-   **Auditability:** configuration is version-controlled in your config file, so changes the AI suggests are traceable back to a commit.

### **III. Why this matters for AI-assisted coding**

_Key takeaway: real infrastructure context lets AI agents check their suggestions against the actual state of a cloned environment._

Running an MCP server on Upsun gives high-velocity teams three things.

1.  **Schema literacy:** the AI can query your real database schema to check that a generated migration won't break an existing foreign key relationship.
2.  **Environment awareness:** the AI can read the environment variables and service configuration defined in your `.upsun/config.yaml`,  so the code it writes matches how your project is actually set up.
3.  **Validation against a clone:** because Upsun can clone an environment, the AI works against a replica of your production data rather than guessing at it.

### **Beyond the local environment**

Connecting Cursor to Upsun through MCP closes the context gap for an individual developer. 

As AI-generated code moves toward production, the same configuration the AI read in development is the configuration it meets in production, because both come from your version-controlled config file. 

The harder question is what happens when that code actually tries to deploy.

* * *

### **Frequently asked questions (FAQ)**

**Is it safe to connect my IDE to a database via MCP?**

Yes. The Upsun CLI tunnel opens an encrypted connection to an isolated environment, and only a locally running MCP server talks to it. The AI agent only sees the data inside that environment, and that data doesn't cross the public internet unencrypted.

**Does this work with production data?**

Upsun can clone an environment, so the MCP server you tunnel in interacts with a replica of your production data. The AI works against realistic data without touching your live site.

**How long does it take to set up?**

A few minutes once you know the steps: add the service and its relationship to your .upsun/config.yaml, deploy, open a tunnel with the Upsun CLI, then point your editor's MCP configuration at the tunneled connection. Because a branch environment is a full clone, you're not maintaining a separate seed database on top of that.

### [Upsun vs Dokku 2026: Managed PaaS vs Heroku Clone | Upsun](https://upsun.com/blog/upsun-vs-dokku-2026/)

# Upsun vs Dokku in 2026

In 2013, Jeff Lindsay released Dokku, a  free, open-source PaaS that runs on a single Linux server. Thirteen years later, the project still describes itself as "the smallest PaaS implementation you've ever seen”. Dokku gives developers a Heroku-style workflow on infrastructure they own. It supports Git-based deployment, Docker containers, and Heroku-compatible buildpacks, and you can install it on a $5 VPS in about 10 minutes.

Upsun sits in a different category. It is a managed multi-cloud PaaS that runs application infrastructure across AWS, Google Cloud, Azure, OVHcloud, and IBM Cloud. Teams compare the two because Dokku is often where developers land when leaving Heroku, and Upsun is often where they land when Dokku stops being enough. 

##   
**Key takeaways**

-   Dokku is a free, MIT-licensed PaaS you run on a single Linux server. Upsun is a managed multi-cloud PaaS that runs application infrastructure for you across five cloud providers.
-   Dokku is cheaper by monthly invoice and ships Heroku buildpack compatibility through Herokuish, which makes it the easiest landing pad for teams leaving Heroku without re-architecting. Upsun is cheaper by total cost once compliance, observability, and operational hours are factored in.
-   Compliance is non-negotiable. Dokku holds no certifications. Upsun holds ISO 27001, SOC 2, PCI DSS, HIPAA, and GDPR. For regulated industries, this single difference resolves the comparison.
-   Dokku fits hobby projects, single-server workloads, and teams that want a CLI-first tool they can read line by line. Upsun supports autoscaling, multi-cloud deployments, regulated production environments, and teams that want to ship application code rather than manage infrastructure.

In short: Dokku if you want a Heroku clone you can run on a VPS, Upsun if you want a managed platform that scales beyond it.

## **What do Upsun and Dokku have in common?**

Both platforms run on the same conceptual workflow that Heroku popularised. Each supports Git-push deployment, automatic SSL through Let's Encrypt, and a broad range of languages, including Node.js, PHP, Python, Ruby, and Go.  

They both run applications in isolated Docker containers and let you provision databases through the platform rather than configuring them manually. Most importantly for teams migrating from Heroku, both support standard buildpacks, which means most Heroku applications run on either platform with minor modification.

If your only criterion is "Git push to deploy a containerized app on a buildpack workflow," either platform will do the job.

## **What are the main differences between Upsun and Dokku?**

## **Detailed comparison**

### **How do Upsun and Dokku handle hosting and infrastructure?**

Upsun runs your application on infrastructure managed across five major cloud providers. You choose where to deploy, and the platform handles provisioning, networking, OS-level updates, and security patching. The same YAML configuration deploys identically across AWS, GCP, Azure, OVHcloud, or IBM Cloud.

Dokku runs on a single Linux server you provision yourself. A bootstrap script installs Dokku in about 10 minutes on a clean Ubuntu 22.04 or 24.04 host. Once installed, the kernel, OS updates, security patches, firewall, and backups are yours to manage. Dokku does support multi-server deployments through a K3S scheduler, but that adds operational complexity that runs counter to Dokku's core appeal of staying simple. For most Dokku deployments, "one server" is the right mental model.

The trade-off is direct: Dokku gives you total control of a small footprint. Upsun removes the footprint entirely.

### **How do their deployment workflows compare?**

Both platforms deploy on a Git push, but the configuration models differ. Upsun uses a single .upsun/config.yaml file in your repository that defines services, routes, environment variables, and infrastructure for every branch. The config travels with the code, which makes environments reproducible through pull requests.

Dokku configures applications through CLI commands run over SSH, optionally backed by an app.json manifest. There is no web dashboard in the open-source version. Builds run through Herokuish, an implementation of Heroku's buildpack system, with optional support for Cloud Native Buildpacks (experimental), Dockerfile builds, and Docker Compose. This is the single biggest reason Dokku endures: a working Heroku application typically deploys to Dokku unchanged.

Teams that want infrastructure-as-code in a single config file will prefer Upsun. Teams already using Heroku buildpacks and comfortable on the command line will find Dokku faster to set up.

### **Which platform scales better?**

Upsun supports automatic horizontal and vertical scaling. Application containers scale based on traffic and resource utilization, and database read replicas can scale independently. Production environments can be cloned in under a minute, with live data, for testing or feature work.

Dokku does not autoscale. Its default scheduler runs all applications on one host, and you scale by sizing the VPS up rather than out. Multi-server scaling is possible through the K3S scheduler, which deploys applications to a Kubernetes cluster instead of the local environment.

Dokku host, but that path requires Kubernetes expertise and undoes much of Dokku's simplicity. For steady single-server workloads, Dokku is sufficient. For unpredictable traffic, multi-region deployment, or production scale, the manual model becomes a bottleneck.

### **What managed services and observability does each platform offer?**

Upsun provides a managed services catalog including PostgreSQL, MySQL, MariaDB, Redis, Elasticsearch, OpenSearch, RabbitMQ, and Kafka. Services are provisioned through the YAML config and inherit the platform's backup, scaling, and security policies. Observability comes built in: infrastructure metrics, logs, and continuous profiling are part of the platform.

Dokku offers database support through its plugin system. Official plugins exist for PostgreSQL, MySQL, MongoDB, Redis, Memcached, and a handful of others. Each plugin runs the service as a Docker container on the same host as your applications. Backups, updates, and security patches for each plugin are your responsibility. Observability is not included. Teams typically assemble their own stack using Prometheus, Grafana, and an external uptime monitor.

Dokku wins on flexibility and zero licensing cost. Upsun wins on operational simplicity and integrated observability.

### **How does pricing compare between Upsun and Dokku?**

Dokku itself is free under the MIT license. A capable VPS from Hetzner, DigitalOcean, or Linode costs $5 to $25 per month, and there are no per-user fees or feature paywalls. A separate paid product, Dokku Pro, adds a web UI and team-based access control, but the core platform remains fully free.

Upsun uses a Flex pricing model that bills at the resource level for CPU, RAM, and storage. Costs scale linearly with actual usage. For a single small project, Upsun is meaningfully more expensive than self-hosted Dokku. For a team needing observability tooling, compliance certifications, automated backups, and multi-region failover, the comparison shifts once you account for the engineering hours and third-party tooling required to match those capabilities on Dokku.

The honest version: Dokku is cheaper if your time is free and your workload fits on one machine. Upsun is cheaper once either of those stops being true.

### **Which platform is better for compliance and security?**

This is where the comparison ends decisively. Upsun holds ISO 27001, SOC 2, PCI DSS, HIPAA, and GDPR certifications. These are platform-level guarantees that customers inherit when deploying. Security patches, vulnerability management, and infrastructure-level compliance controls are managed by the platform.

Dokku holds no certifications. When you self-host Dokku, you inherit responsibility for your own compliance posture, including OS patching, vulnerability management, audit logging, and access controls. For regulated industries such as healthcare, financial services, or government, Dokku is not a viable production platform without significant additional engineering work. Dokku was built as a lightweight Heroku clone for solo developers and small teams, not as a compliance-ready enterprise platform, and the project has never claimed otherwise.

## **When to choose Dokku**

Dokku is the right tool when simplicity, cost, and Heroku-style workflows matter more than scale and compliance. Pick Dokku if:

-   You are leaving Heroku and want a buildpack-compatible deployment without rewriting your application.
-   You are a solo developer or small team running fewer than 10 applications, and your operational budget tops out at a $25 VPS.
-   You want a CLI-first, scriptable PaaS that you can read line by line and extend through plugins.
-   You have Linux sysadmin skills on the team and treat infrastructure as part of your craft.
-   Your workload fits on a single server and is unlikely to outgrow it.

Dokku has been a stable, working Heroku alternative for over a decade. For the right team, it is a better fit than any managed PaaS.

## **When to choose Upsun**

Upsun is the right tool when single-server operation stops being viable, or when production demands exceed what a self-hosted tool can deliver. Pick up if:

-   Your application carries compliance obligations, including HIPAA, PCI DSS, or SOC 2.
-   You need automatic scaling for unpredictable traffic, such as e-commerce flash sales or product launches.
-   You operate multi-cloud or need data residency across AWS, GCP, Azure, OVHcloud, or IBM Cloud.
-   Your application catalog includes multiple services, background workers, and managed databases that exceed what a single server can hold.
-   Your team should be writing application code, not patching kernels, managing TLS rotations, or assembling observability stacks.

The line between "Dokku is enough" and "Dokku is holding us back" usually crosses somewhere between hobby project and serious production workload, or the moment compliance enters the picture. That crossover is when Upsun becomes the cheaper option, even when its monthly invoice is larger.

## **How do you migrate from Dokku to Upsun?**

A Dokku-to-Upsun migration moves your configuration, services, and data onto a managed platform. The process involves six main steps:

1.  **Translate configuration.** Move from Dokku's CLI-managed setup to a single .upsun/config.yaml file in your repository. Applications, services, routes, and environment variables are defined in YAML rather than through dokku commands.
2.  **Map runtimes and buildpacks.** Heroku buildpack applications running on Dokku can often run on Upsun with minimal modification, since both platforms support standard buildpack runtimes for major languages.
3.  **Map managed services.** PostgreSQL, MySQL, and Redis are supported by both platforms. Each Dokku plugin maps to an equivalent Upsun managed service defined in the YAML config.
4.  **Migrate data.** Export databases from your Dokku-managed instances and import them into Upsun's managed services using standard dump and restore workflows such as pg\_dump and mysqldump.
5.  **Update connection logic.** Application code typically needs minor updates to reference Upsun's environment variables and service relationships.
6.  **Translate custom configuration.** Dokku setups with custom plugins, cron jobs, or Docker-level customization will need to be rewritten into Upsun's equivalent constructs. This is typically the longest part of the migration.

A production migration typically takes 6 to 9 weeks, with the longest phases being infrastructure documentation, MVP testing, and data validation. For Dokku setups with custom plugins, cron jobs, or extensive Docker-level customization, expect additional time to translate those into Upsun's equivalent constructs.

## **Frequently Asked Questions (FAQ)**

**Is Dokku free?**

Yes. Dokku is free and open source under the MIT license, with no feature gates or per-user fees on the core platform. You only pay for the VPS, typically $5 to $25 per month. Dokku Pro is a separate paid product that adds a web UI and team-based access control, but the open-source Dokku runs indefinitely at no software cost.

**Can Dokku scale to multiple servers?**

Not by default. Dokku's default scheduler runs all applications on a single host. Multi-server deployments are possible through the K3S scheduler, which runs applications on a Kubernetes cluster, but configuring K3S requires Kubernetes expertise and undoes most of Dokku's simplicity. For teams that need autoscaling or multi-region deployment without having to operate Kubernetes, a managed PaaS like Upsun is a better fit.

**Does Dokku support SOC 2 or HIPAA compliance?**

No. Dokku does not hold SOC 2, HIPAA, PCI DSS, or ISO 27001 certifications. When you self-host Dokku, you inherit responsibility for compliance, including OS patching, audit logging, access controls, and vulnerability management. Teams in regulated industries typically need a managed platform with platform-level certifications, such as Upsun.

**Does Upsun support multi-cloud deployment?**

Yes. Upsun deploys across AWS, Google Cloud Platform, Microsoft Azure, OVHcloud, and IBM Cloud through identical workflows defined in a single .upsun/config.yaml file. Teams can meet data residency, compliance, and latency requirements without rewriting deployment pipelines for each provider. Dokku, by contrast, runs on a single server you provision yourself and does not abstract multi-cloud deployment.

**What is Upsun's pricing model?**

Upsun uses a Flex pricing model that bills at the resource level for CPU, RAM, and storage. Costs scale linearly with what you provision, rather than through fixed tiers or surprise bandwidth charges. This is structurally different from Dokku, which is free software billed only through the VPS you run it on. Upsun is more expensive on a monthly invoice but typically cheaper in total cost when engineering hours, observability, and compliance are included.

**Can Dokku deploy Heroku applications without changes?**

Mostly. Dokku uses Herokuish, an implementation of Heroku's buildpack system, so most Heroku-style applications deploy to Dokku with minimal modification. Common languages, including Node.js, Python, Ruby, PHP, and Go, work out of the box. Applications that depend on Heroku-specific add-ons or proprietary features may need additional configuration. This buildpack compatibility is the single largest reason teams choose Dokku as a Heroku replacement.

**Is Dokku cheaper than Upsun?**

On the monthly invoice, yes. A self-hosted Dokku instance on a $10 VPS is significantly cheaper than an equivalent Upsun project. On the total cost of ownership, the comparison narrows once engineering hours, observability tools, backup management, and compliance work enter the calculation. For single-server workloads, Dokku is almost always cheaper. For production workloads with operational and compliance requirements, Upsun is often cheaper overall.

### [Why features pass QA but fail in production | Upsun](https://upsun.com/blog/production-data-testing-vs-mock-data/)

# Why features pass QA and still break in production

Database migrations are where the mock data problem shows up most clearly. A migration that adds an index to a table with 500 rows in the development database runs in milliseconds and passes every test. The same migration against a production table with 8 million rows locks the table for 90 seconds during peak traffic. Nobody saw it coming because nobody tested it against 8 million rows.

This isn't an edge case. It's a routine failure mode, and it happens because the data used for testing doesn't reflect the data the application actually runs against.

**What mock data doesn't tell you**

_Key takeaway: Mock data and fixtures validate that code handles the expected case. Production data validates that code handles the actual case. The gap between those two things is where most production incidents originate._

Fixtures and factories are useful. They give you a controlled, repeatable test environment. They let you write tests that run in seconds, isolate specific scenarios, and produce consistent results. None of that stops being true.

What they can't give you is the complexity that accumulates in a production database over time.

A production Drupal installation with three years of content has orphaned taxonomy terms, nodes with missing field data from a schema migration that didn't fully complete, content types with character encoding anomalies from an import run in 2021, and user accounts with permission combinations that were possible under an older role configuration but shouldn't exist under the current one. None of that is in the fixtures, because the fixtures were written to represent how the data should look, not how it actually looks after years of real-world use.

A production Django application with active users has query patterns that a development database doesn't. Certain filters that are fast against 10,000 records become full table scans against 2 million. Certain joins that work fine in isolation behave differently under the load patterns that real usage creates. An N+1 query that's imperceptible in development becomes a performance incident in production.

The mock data problem isn't that developers are writing bad fixtures. It's that fixtures are a model of reality, and models are always incomplete.

## **What "production complexity" actually means**

_Key takeaway: Production databases are complex in three ways that fixtures can't replicate: volume (the amount of data), entropy (the accumulated inconsistencies of real-world use), and query behavior (how the database engine actually performs under real load patterns). All three matter for testing._

Volume is the most obvious dimension. A feature that handles 100 records handles 10 million records differently, in ways that depend on indexing, query planning, and memory allocation. Testing at development scale doesn't always surface these differences.

Entropy is less visible but equally important. Real production databases contain data that doesn't conform to current schema expectations, because schemas evolve and migrations are rarely perfectly retroactive. A Drupal content migration from five years ago may have left fields in states that the current application code doesn't expect to encounter, because the code was written after the migration and assumes clean data. Testing against fixtures written to match the current schema misses these cases entirely.

Query behavior is the hardest to replicate artificially. Database engines make different decisions about query plans depending on table statistics, index cardinality, and data distribution. A query that runs efficiently against a small, uniform development dataset may trigger a different execution plan against a large, heterogeneous production dataset. The only way to test for this reliably is to test against data that has the same statistical properties as production.

## **How data cloning works in practice**

_Key takeaway: Byte-level data cloning creates a_ _production-equivalent copy_ _of the production database state in a preview environment. Combined with data sanitization, this gives developers a test surface with production complexity and no exposure of real user data._

Upsun is a platform-as-a-service that manages the infrastructure layer of your application stack so your team doesn't have to. When a preview environment is created from a production branch on Upsun, the environment includes a byte-level clone of the production database at that point in time. Not a schema copy. Not a fixture-seeded blank database. A faithful copy of the data as it exists in production at clone time, down to the same orphaned records, the same encoding anomalies, the same query statistics.

The clone happens at the storage layer, which means it's fast regardless of database size. An 80GB database doesn't take 80GB worth of time to clone because the platform handles it as a filesystem operation rather than a data transfer.

For most teams, the process looks like this:

```shell-session
# Create a new environment branched from production
upsun branch feature/new-search-index main

# The environment spins up with a full clone of production data
# Your feature code runs against real data from the first commit
```

The developer's branch environment now has the same 8 million rows the migration will encounter in production. The index addition that locked the production table for 90 seconds shows up in development, before it's deployed, when it can still be fixed.

## **Sanitization: making production data safe to use**

_Key takeaway: Production data cloning is only useful if the cloned data can be safely accessed by developers and shared with QA teams._ _Sanitization_ _strips or masks personally identifiable information before the clone reaches a non-production environment, satisfying both privacy requirements and the practical needs of regulated development workflows._

The obvious concern with bringing production data into development environments is privacy. Production databases contain real user data: email addresses, names, payment references, health records, whatever the application stores. That data shouldn't be accessible to every developer on the team, and it shouldn't appear in preview environment URLs that get shared with clients for review.

Data sanitization runs as part of the branching process, before the cloned data reaches the preview environment. A sanitization hook replaces sensitive fields with realistic but fictional values: real email addresses become generated ones, names are replaced, payment data is masked. The database retains its structural complexity and its volume while the identifying information is gone.

For a Drupal project, a sanitization hook using Drush might look like this:

```shell-session
hooks:
  deploy: |
    if [ "$PLATFORM_ENVIRONMENT_TYPE" != production ]; then
      drush -y sql:sanitize --sanitize-email=user+%uid@example.com
    fi
```

The hook runs automatically on every non-production environment, which means sanitization is structural rather than procedural. It doesn't rely on someone remembering to run it; it runs because the configuration says it does.

The result is a preview environment with production-scale data, production-complexity query patterns, and no real user information. QA can test against it. Developers can debug against it. Auditors can verify that the environment reflects production conditions. None of them are looking at real user data.

## **What this changes for QA and release confidence**

_Key takeaway: When QA signs off on a feature that was tested against real production data, the sign-off means something different than when it was tested against fixtures. The gap between "QA approved" and "behaves in production" closes significantly._

The practical shift is in what test results mean.

When a feature passes QA in a fixture-seeded environment, the result is: this feature works correctly against idealized data in a controlled environment. That's useful, but it leaves open a category of failures that only production data would reveal.

When a feature passes QA in an environment cloned from production, the result is: this feature works correctly against the actual data it will run against in production, including the edge cases, the volume, and the accumulated entropy of real-world use. That's a meaningfully stronger signal.

For regulated applications where QA sign-off is part of a compliance process, this distinction matters to auditors. Evidence of testing against production-equivalent data is stronger evidence than testing against fixtures, because it demonstrates that the test conditions reflected reality.

For teams that have experienced production incidents traced back to data the fixtures didn't cover, it removes a category of uncertainty that currently sits between deployment and confidence.

## **Already using fixtures and mocks?**

Keep them. Fixtures are the right tool for unit tests, isolated scenarios, and fast feedback loops. Production data cloning sits alongside them, not in place of them: fixtures for testing how your code should behave, production data for testing how it actually behaves at scale. The two approaches answer different questions, and a mature testing setup uses both.

* * *

## **Frequently asked questions (FAQs)**

**Is production data cloning safe from a GDPR or HIPAA perspective?**

The clone itself is a copy of production data and carries the same obligations as production until it's sanitized. The sanitization hook runs as part of the environment creation process and should be treated as a required step for any regulated application. Once sanitized, the environment contains no real personal data and can be accessed by developers and QA without additional data handling obligations.

**How current is the cloned data?**

The clone reflects production data at the point the branch was created. It's a snapshot, not a live sync. For most development and QA purposes this is sufficient, since the goal is production-equivalent complexity rather than real-time data. For testing that specifically requires recent data, branches can be re-created from the latest production snapshot.

**Does cloning a large production database slow down environment creation?**

Not significantly. The clone happens at the storage layer as a filesystem operation, which means the time taken is largely independent of database size. An environment branched from a production database with 80GB of data takes roughly the same time to create as one with 1GB.

**What if our production database contains data we can't bring into any non-production environment, even sanitized?**

The sanitization hook can be configured to exclude specific tables entirely rather than masking them. For data that can't leave production under any circumstances, the pattern is to exclude those tables from the clone and seed them with synthetic data instead. The rest of the database retains its production complexity.

**Can we run the sanitization hook against specific data types rather than the whole database?**

Yes. Sanitization hooks have full access to the database and can apply different treatments to different tables: masking email addresses in one table, replacing names in another, and leaving non-sensitive tables untouched. The configuration is as granular as the application requires.

### [Why your staging keeps breaking | Upsun](https://upsun.com/blog/fix-staging-environment-drift/)

# Why your Drupal or Django project keeps breaking in staging (and how to fix it structurally)

**Beyond hosting: moving from framework management to application delivery**

There's a particular kind of afternoon that most backend developers know well. You're mid-feature, something actually interesting, the kind of work you took the job for, and then a Slack message arrives. Staging is broken. The PHP version doesn't match production. Someone's composer install pulled a dependency that conflicts with the shared environment. Can you look at it?

Four hours later, you haven't touched a single thing you planned to work on for that day and all your time has been spent fixing your CI/CD pipeline.

It's a predictable result of treating a platform like a hosting account, not bad luck.

## **What "just hosting" actually costs you**

_Key takeaway: The cost of environment drift shows up less in hours per incident than in broken focus: the deep work that's expensive to restart every time a Slack message pulls someone out of it._

Most developers don't think of themselves as infrastructure managers, but a typical open-source project setup asks them to be one anyway. You're maintaining a shared staging environment, manually specifying runtime versions in deployment configs, wiring up database services, and periodically dealing with the fallout when something drifts between environments.

None of that is the job. It's the scaffolding around the job.

The scaffolding problem gets worse as stacks get more complex. A Drupal site with Redis for caching and MariaDB on the backend isn't complicated to run once it's configured, but getting to a clean, reproducible configuration takes real effort, and keeping it in sync across local, staging, and production takes ongoing vigilance. Throw in a second developer and things compound. A third, and you've probably got environment conflicts as a recurring agenda item.

The hidden cost is the interruption pattern, not the time any single incident takes. Context-switching out of focused work is disproportionately expensive because of what it displaces: the kind of deep work that takes roughly 20 minutes to drop back into. Multiply that across a team over a quarter and the cost stops looking like a stack of support tickets and starts looking like features that ship slower, because the people building them keep getting pulled away.

## **The infrastructure-as-code answer most teams stop short of**

_Key takeaway: Most IaC implementations stop at provisioning. You get a reproducible environment, but OS patching, certificate rotation, and service updates still land on the team. The full version of this idea is a platform that takes over everything below the application layer, not just at setup, but on an ongoing basis._

The standard advice here is "infrastructure as code": define your environment declaratively, check it into version control, and stop letting configuration drift happen. That's correct, as far as it goes. The problem is that most implementations stop at provisioning. You get a reproducible environment, but you're still responsible for the underlying services: patching the OS, rotating certificates, managing database versions.

You've reduced drift. You haven't reduced maintenance.

The more complete version of that idea is a config file that describes what your application needs, and a platform that takes responsibility for everything below that line, not just at provisioning time, but on an ongoing basis.

Upsun's approach to this is a single config file at `.upsun/config.yaml`. For a Drupal project with Redis and MariaDB, it looks roughly like this:

```shell-session
applications:
  drupal:
    type: php:8.3                  # exact runtime version, consistent across every environment
    relationships:
      database: "db:mysql"         # wires the app to the database service below
      cache: "redis:redis"         # wires the app to the Redis service below
    mounts:
      "/web/sites/default/files":
        source: local
        source_path: files

services:
  db:
    type: mariadb:10.11            # platform manages patching within this version
  redis:
    type: redis:7.2                # same: version pinned, maintenance handled
```

That's the whole stack. The runtime version, the services, the relationships between them. The platform handles OS patching, SSL rotation, service updates within the defined versions, and the networking between containers. You don't touch any of that, not at setup, and not later.

The PHP version in the config is the PHP version in production. Not approximately. Not "we think so." Exactly.

The same file shape covers a Django project on Python. Different runtime, different database, identical structure:

```shell-session
applications:
  django:
    type: python:3.12              # exact runtime version, consistent across every environment
    relationships:
      database: "db:postgresql"    # wires the app to the PostgreSQL service below
      cache: "redis:redis"         # wires the app to the Redis service below
    mounts:
      "/app/media":
        source: local
        source_path: media

services:
  db:
    type: postgresql:16            # platform manages patching within this version
  redis:
    type: redis:7.2                # same: version pinned, maintenance handled
```

Same single file, same division of labor. The runtime and services change with the stack; what the platform takes off your plate doesn't.

## **Why this matters more for open-source frameworks**

_Key takeaway: Open-source frameworks are flexible by design, which means deployment decisions fall to the team by default. A version-controlled config file makes those decisions explicit and traceable, so "what's running in production?" has an answer that doesn't require SSHing into anything._

Proprietary SaaS products tend to be opinionated about their own deployment. Open-source frameworks are, by design, flexible, which means the deployment decisions land on you.

That flexibility is mostly a feature. It's why Drupal runs on shared hosting and in hardened government infrastructure. It's why Django powers startups and large financial institutions simultaneously. But it also means there's no default answer to "how should this be deployed," which means every team makes those decisions from scratch and then lives with the consequences.

The common failure mode here is accumulated pragmatism, not incompetence. You make a reasonable decision early: a shared staging server, a manual deployment script, a cron job that works, and then you inherit it forever. The decision made sense when there was one developer and one site. By the time there are five developers and six sites, it's technical debt with no obvious moment to pay it down.

A version-controlled config file doesn't eliminate those decisions, but it surfaces them. What runtime do you actually need? Which services? When those are explicit and checked into version control, the question "what's running in production?" has an answer that doesn't require SSHing into anything.

## **Making the infrastructure layer boring**

_Key takeaway: The aim here is infrastructure that stops asking for attention, not more powerful tooling. When the platform handles the routine work, what's left is the application._

The goal here is infrastructure that stops requiring attention.

A lot of developer tooling tries to make infrastructure more powerful or more configurable. That's sometimes what you need. More often, you need something that handles the routine work without asking you to think about it, and that gets out of the way when you're debugging something in the application layer, not the platform layer.

When the environment is defined in code, reproducible across branches, and maintained by the platform rather than the team, the category of problems that look like "staging is broken" mostly disappears. What's left is the application. Which is, after all, what you're actually there to build.

## **Already have an existing setup?**

The config file describes a target state, not a migration path. If you're running Drupal on a managed server with a deployment script you've maintained for three years, moving to a platform config is a matter of writing down what you're already running: the PHP version, the services, the relationships between them. The config becomes the source of truth for a setup that currently lives in your head and a README that's six months out of date.

* * *

## **Frequently asked questions (FAQs)**

**Do I still control my PHP or Python version?**

Yes. You specify the exact version in `.upsun/config.yaml`. The platform ensures that version is consistent across every branch and environment, and handles security patching within it. You're not handing over control; you're making the decision once and having it enforced everywhere.

**What happens to the underlying OS and certificates?**

The platform manages OS hardening, kernel patching, and SSL certificate rotation automatically. These aren't things you configure; they're handled below the line your config file defines.

**Can this work with decoupled or headless stacks?**

Yes. You can define multiple applications in a single config file (a Next.js frontend and a Drupal backend, for example) and the platform handles the networking and isolation between them. No separate cloud accounts or manual networking config required.

**Why doesn't my existing deployment script cover this?**

Scripts handle what you've already anticipated. The maintenance gap they leave is everything else: runtime version drift, certificate expiry, service compatibility across environments. A platform-managed config file covers the ongoing work, not just the initial setup.

**What does "the platform maintains it" actually mean day to day?**

In practice: you update the config file when you want to change something. The platform applies that change consistently. Between changes, it handles patching and updates without requiring input from the team. The operational surface area shrinks to the application itself.

### [Upsun vs Porter 2026: Managed PaaS vs Kubernetes BYOC | Upsun](https://upsun.com/blog/upsun-vs-porter-2026/)

# Upsun vs Porter in 2026: Kubernetes abstraction layer vs managed PaaS

Upsun and Porter both wrap a developer-friendly deployment workflow around infrastructure that would otherwise require expertise, but they solve the problem from opposite ends. Upsun is a managed multi-cloud PaaS that runs application infrastructure across AWS, Google Cloud, Azure, OVHcloud, and IBM Cloud. Porter is a Kubernetes abstraction layer that provisions a cluster inside your own AWS, GCP, Azure, or DigitalOcean account.

Developers compare them because both promise a similar outcome: Git-push deployment, managed services, autoscaling, and an escape from raw cloud infrastructure. The difference is who owns the cluster underneath. Porter gives you a friendlier face on a Kubernetes cluster you own. Upsun removes the cluster entirely.

## **Key takeaways**

-   Porter is a Kubernetes abstraction layer that deploys into your own cloud account (BYOC). Upsun is a managed multi-cloud PaaS where the application infrastructure is operated by the platform.
-   Porter charges a subscription on top of your cloud bill. Upsun bills resource-based pricing as a single platform fee with no separate cloud account required.
-   Compliance is non-negotiable. Porter inherits its compliance posture from the cloud account it runs in, which means you carry the certification work. Upsun holds ISO 27001, SOC 2, PCI DSS, HIPAA, and GDPR at the platform level.
-   Porter fits teams with existing cloud spend and a preference for retaining cluster ownership. Upsun fits teams that want a single bill, built-in compliance, and infrastructure that someone else operates.

In short: Choose Porter if you want Kubernetes, you don't have to manage in your cloud, Upsun if you want application infrastructure operated by the platform across multiple cloud providers.

## **What do Upsun and Porter have in common?**

Both platforms wrap a Heroku-style developer experience around infrastructure that would otherwise require expertise. Each supports Git-push deployment, a wide range of languages including Node.js, Python, Ruby, Go, PHP, and Java, automatic SSL, and managed databases provisioned through the platform. Both offer web dashboards and CLIs, both support preview environments tied to Git branches, and both let developers deploy applications without writing Kubernetes YAML or cloud provider configuration.

The conceptual workflow is similar. What differs is what sits underneath, and who is responsible for it.

## **Key differences at a glance**

## **Detailed comparison**

### **How do Upsun and Porter handle hosting and infrastructure?**

The category difference is the headline of this comparison. Upsun runs your application on infrastructure that the platform operates across five major cloud providers. You choose where to deploy, and Upsun handles provisioning, networking, OS-level updates, and security patching. The same YAML configuration deploys identically across AWS, GCP, Azure, OVHcloud, or IBM Cloud.

Porter takes a different approach. You connect Porter to your AWS, GCP, Azure, or DigitalOcean account, and Porter provisions a Kubernetes cluster inside it. For AWS specifically, Porter provisions an EKS (Elastic Kubernetes Service) cluster. From that point on, the cluster belongs to you. Porter operates a control plane that monitors and manages your cluster, but the resources, the cloud bill, and ultimately the cluster itself sit in your account. If you stop using Porter, the cluster keeps running. You just lose the abstraction layer Porter provides.

This is genuine BYOC (Bring Your Own Cloud), and it is Porter's strongest differentiator. Teams with existing cloud commitments, credits, or compliance work already done inside their AWS or GCP account can leverage all of it.

### **How do their deployment workflows compare?**

Both platforms deploy on a Git push, but the configuration source of truth differs. Upsun uses a single .upsun/config.yaml file in your repository that defines services, routes, environment variables, and infrastructure for every branch. The config travels with the code, which makes environments reproducible through pull requests.

Porter configures applications through its web dashboard, backed by Helm charts under the hood. Developers can deploy from Git connections, via the Porter CLI, or through the dashboard interface. Add-ons such as managed databases and caches install with a few clicks. One trade-off: after Porter provisions resources in your cloud, infrastructure changes made outside Porter (in the AWS or GCP console, for instance) are not always reflected back in Porter's view, which can fragment the source of truth.

Teams that want everything declared in version-controlled YAML will prefer Upsun. Teams that want a dashboard-driven workflow with Kubernetes underneath will prefer Porter.

### **Which platform scales better?**

Both platforms scale automatically, but the mechanisms differ. Upsun supports automatic horizontal and vertical scaling for application containers, with database read replicas scaling independently. Production environments can be cloned in under a minute, with live data, for testing or feature work.

Porter inherits Kubernetes-native scaling primitives, including Horizontal Pod Autoscaler (HPA) and Vertical Pod Autoscaler (VPA). For teams that already understand Kubernetes scaling patterns, this offers significant flexibility, and Porter's pricing actually rewards scale: the per-resource cost decreases as you grow, with a volume discount available at 40+ vCPU or 80+ GB RAM. The trade-off is that scaling decisions can require Kubernetes context that the abstraction does not fully hide.

Porter wins on scaling flexibility for teams comfortable with Kubernetes concepts. Upsun wins on simplicity for teams that want autoscaling without the underlying mental model.

### **What managed services and observability does each platform offer?**

Upsun provides a managed services catalog including PostgreSQL, MySQL, MariaDB, Redis, Elasticsearch, OpenSearch, RabbitMQ, and Kafka. Services are provisioned through the YAML config and inherit the platform's backup, scaling, and security policies. Observability comes built in: infrastructure metrics, logs, and continuous profiling are part of the platform.

Porter offers add-ons for common databases and caches, deployed as Kubernetes workloads inside your cluster. It also lets you connect to native cloud services such as RDS, Cloud SQL, or Azure Database, which is useful for teams that prefer managed cloud databases over containerized ones. Observability is partially provided through Porter's dashboard, but production teams typically supplement with external tools such as Datadog, New Relic, or a self-hosted Prometheus and Grafana stack.

Porter wins on cloud-native service integration. Upsun wins on integrated observability and zero-configuration managed services.

### **How does pricing compare between Upsun and Porter?**

The pricing models are structurally different and worth understanding before choosing.

Porter charges a subscription for the management layer, ranging from $50 to $1,250 per month, depending on plan, on top of whatever you pay your cloud provider. The Porter bill covers the control plane, monitoring, and developer experience. The cloud bill covers compute, storage, and networking at standard provider rates. Porter's pricing scales sublinearly: per-resource costs decrease as you grow.

Upsun uses resource-based pricing, where you only pay for the resources you provision: CPU, RAM, and storage. There are no fixed tiers or surprise bandwidth charges, and you receive a single bill for both platform and infrastructure. For teams with existing cloud commitments or credits, Porter's BYOC model can be meaningfully cheaper at scale. For teams without that existing investment, Upsun's single-bill model is simpler to budget and operate.

The honest version: Porter is cheaper when you have existing cloud spend you want to leverage. Upsun is cheaper when you do not, and easier to reason about either way.

### **Which platform is better for compliance and security?**

This is where the platforms diverge sharply. Upsun holds ISO 27001, SOC 2, PCI DSS, HIPAA, and GDPR certifications. These are platform-level guarantees that customers inherit when deploying. Security patches, vulnerability management, and infrastructure-level compliance controls are managed by the platform.

Porter's compliance posture is more complicated. Because Porter runs in your cloud account, you inherit whatever compliance posture your cloud provider offers, but the certification work for your application and infrastructure remains with you. AWS, GCP, and Azure are individually certified for SOC 2, HIPAA, and PCI DSS, but having a compliant cloud provider is not the same as having a compliant application stack. You still carry responsibility for audit logging, access controls, configuration management, and Kubernetes-level hardening. Teams in regulated industries who use Porter typically need internal compliance expertise that teams using a fully managed platform do not.

## **When to choose Porter**

Porter is the right tool when retaining cluster ownership matters more than offloading infrastructure entirely. Pick Porter if:

-   You already have significant AWS, GCP, Azure, or DigitalOcean spend you want to leverage, including credits, commits, or enterprise discount programs.
-   You want Kubernetes power available when needed (HPA, custom resources, Helm charts) without writing Kubernetes manifests for every deployment.
-   You need vendor independence: your cluster persists in your cloud account if you stop using Porter.
-   You have at least some Kubernetes context on the team, or are willing to develop it, for day-2 operations.
-   You want pricing that rewards scale, with per-resource costs decreasing as your usage grows.

Porter has built a credible Kubernetes abstraction layer for teams that want infrastructure ownership without operational pain. For the right team, it bridges the gap between simple PaaS and full Kubernetes management.

## **When to Choose Upsun**

Upsun is the right tool when infrastructure ownership stops being worth the operational and compliance cost. Pick Upsun if:

-   Your application carries compliance obligations, including HIPAA, PCI DSS, or SOC 2, and you want platform-level certifications rather than building them yourself.
-   You want a single bill for both platform and infrastructure, with no separate cloud account to manage.
-   You operate multi-cloud across AWS, GCP, Azure, OVHcloud, or IBM Cloud and need a consistent deployment workflow across providers.
-   You want infrastructure-as-code in a single YAML file that travels with your repository.
-   Your team should be writing application code, not managing Kubernetes clusters, even abstracted ones.

The line between "Porter is enough" and "Porter still requires too much infrastructure attention" usually crosses when compliance, multi-cloud, or operational simplicity becomes the priority. That crossover is when Upsun becomes the cheaper option, even when its monthly invoice looks different from a Porter plus cloud combination.

## **How do you migrate from Porter to Upsun?**

A Porter-to-Upsun migration moves your applications, services, and data from a Kubernetes cluster in your cloud account onto a fully managed platform. The process involves six main steps:

1.  **Translate configuration.** Move from Porter's dashboard-managed setup (backed by Helm charts) to a single .upsun/config.yaml file in your repository. Applications, services, routes, and environment variables are defined in YAML and travel with the code.
2.  **Map runtimes and build steps.** Porter applications built from Dockerfiles or buildpacks can typically run on Upsun with minimal modification, since Upsun supports both buildpack and custom container builds for major languages.
3.  **Map managed services.** PostgreSQL, MySQL, and Redis are supported by both platforms. Porter add-ons and connected cloud services (RDS, Cloud SQL) map to Upsun's managed services catalog defined in the YAML config.
4.  **Migrate data.** Export databases from your Porter-managed cluster or attached cloud services and import them into Upsun's managed services using standard dump and restore workflows such as pg\_dump and mysqldump.
5.  **Update connection logic.** Application code typically needs minor updates to reference Upsun's environment variables and service relationships rather than Porter's.
6.  **Decommission the Porter cluster.** Once production traffic has cut over to Upsun, you can stop using Porter and either keep the underlying Kubernetes cluster running in your cloud account or tear it down. The cluster belongs to you, so the choice is yours.

A production migration typically takes 6 to 9 weeks, with the longest phases being infrastructure documentation, MVP testing, and data validation. For Porter setups with custom Helm charts, complex add-on configurations, or significant cloud-native service integration, expect additional time to translate those into Upsun's equivalent constructs.

## **Frequently Asked Questions (FAQs)**

**Is Porter open source?**

Porter's core codebase is open source under the MIT license. The hosted control plane and several enterprise features are commercial. You can self-host the open-source version of Porter, but most production users run Porter's managed control plane with their own cloud account underneath, paying Porter for the management layer and the cloud provider for infrastructure.

**Does Porter work with AWS, GCP, and Azure?**

Yes. Porter provisions Kubernetes clusters in AWS, Google Cloud, Microsoft Azure, and DigitalOcean accounts. On AWS specifically, Porter provisions EKS (Elastic Kubernetes Service) clusters; equivalent managed Kubernetes services are used on the other clouds. Multi-cloud deployment from a single Porter setup is supported, but each cloud requires its own cluster and connection.

**What is Porter's pricing model?**

Porter charges a subscription for its management layer, ranging from $50 to $1,250 per month, depending on plan and usage, on top of your cloud provider bill. Porter's pricing scales sublinearly, meaning per-resource costs decrease as your usage grows, with a volume discount kicking in around 40+ vCPU or 80+ GB RAM. Total cost is the sum of the Porter subscription and your AWS, GCP, Azure, or DigitalOcean bill for the underlying compute, storage, and networking. 

**Can I leave Porter without losing my infrastructure?**

Yes. Because Porter provisions resources in your own cloud account, the Kubernetes cluster, applications, and data remain in your possession if you stop paying for Porter. The cluster keeps running. What you lose is the abstraction layer Porter provides, which means you become responsible for managing the cluster directly through the cloud provider's tools. This BYOC ownership model is one of Porter's defining advantages.

**Does Upsun support multi-cloud deployment?**

Yes. Upsun deploys across AWS, Google Cloud Platform, Microsoft Azure, OVHcloud, and IBM Cloud through identical workflows defined in a single .upsun/config.yaml file. Unlike Porter, which requires a separate cluster per cloud, Upsun abstracts multi-cloud through a unified platform interface. Teams can meet data residency, compliance, and latency requirements without managing per-cloud infrastructure.

**What is Upsun's pricing model?**

Upsun uses resource-based pricing, where you only pay for the resources you provision: CPU, RAM, and storage. There are no fixed tiers or surprise bandwidth charges, and you receive a single bill for both platform and infrastructure. This is structurally different from Porter, which charges a subscription on top of your separate cloud provider bill. Upsun is simpler to budget; Porter can be cheaper when you have existing cloud spend to leverage.

**Is Porter cheaper than Upsun?**

It depends on your existing cloud spend. If you already pay AWS, GCP, or Azure for compute and have credits, commits, or enterprise discounts, Porter can be cheaper at scale because per-resource costs decrease as you grow. If you do not have existing cloud commitments, Upsun's single-bill resource-based pricing is typically more predictable and competitive, especially when factoring in the compliance and observability work that Porter leaves to the customer.

### [Your PaaS choice is a governance commitment | Upsun](https://upsun.com/blog/paas-privacy-governance/)

# Why your PaaS choice is a governance commitment

Choosing a Platform-as-a-Service (PaaS) is not just an infrastructure decision. It is also a decision about how personal data will be handled over the life of the project. It's a governance commitment made early, with consequences that run late. A PaaS does not remove an organization’s accountability for privacy, security, or regulatory compliance. However, a well-architected PaaS can materially strengthen the control environment in which those obligations are managed.

### **The operational impact** 

A privacy-by-design PaaS can make the day-to-day work of privacy, security, and engineering teams much easier. New teams can onboard faster because core controls such as identity, audit logs, and encryption are already in place.

As the project scales, the benefits become more visible. Standardized logging, federated identities, and uniform data-handling rules reduce the need for repeated one-off privacy negotiations with operations and security teams. That not only helps avoid inconsistent practices across services, regions, and integrations, it reduces the risk of ‘privacy debt’ building up over time. Releases are less likely to stall on privacy reviews because the basic controls do not need to be rebuilt each time a new service is launched.

A good PaaS is not just about accelerating development; it also plays a crucial role at the end of the project. Strong governance ensures that the project’s outcomes are properly managed, documented, and transitioned. If retention controls and deletion paths are explicit at the platform level, decommissioning or migration is more orderly. Without that structure, shutdown or transfer work can become a manual compliance exercise that is slow, messy, and difficult to evidence.

### **The DPO perspective**

From a DPO perspective, the main value of a well-designed PaaS is that it makes compliance more sustainable. It supports data minimization through default-off logging, storage limitation through platform-level retention controls, and integrity and confidentiality through access restrictions and encryption. 

The choice of platform also affects vendor risk and data transfer governance. A PaaS with clear residency options, documented sub-processing, and reliable audit trails is easier to assess during procurement and more straightforward to defend later if the organization is challenged on how it manages personal data. In practical terms, that means fewer exceptions, fewer manual workarounds, clearer accountability, and less risk of needing a privacy redesign after the project is already live.

**Design versus retrofit**

The difference between “by design” and “by accident” is often the difference between a manageable project and a fragile one. When privacy controls are built into the platform, common data protection requirements become operational defaults rather than engineering fixes. When they are added late, the organization usually has to revisit roles, logs, retention, export controls, and deletion workflows under pressure.

This kind of retrofit is expensive and difficult to govern. It also creates avoidable risk because the organization is trying to correct privacy weaknesses after data flows and operational practices have already been established.

### **At Upsun**

Upsun is designed to remove the risks associated with "bolting on" compliance, shifting data protection from a development chore to a platform guarantee. By centralizing controls and audit trails, Upsun replaces manual, siloed compliance checks with automated reporting, dramatically reducing the time needed to compile evidence by:

-   Enforcing secure configurations, including native encryption for data at rest and in transit by default. 
-   Allowing administrators to maintain strict data residency by selecting the precise geographic region and infrastructure provider when initializing a project in the Management Console.
-   Guaranteeing tenant isolation and implementing granular Role-Based Access Control across Organization, Project, and Environment levels, thus enforcing the principle of least privilege. Enterprise customers can further secure their environments with optional SSO dashboard access and Multi-Factor Authentication over SSH. 
-   Tracking all changes and integrating application and system logs into immutable audit trails. This auditability supports legal defensibility and accelerates incident response time by making controls traceable, thereby proving accountability.

Providing the tools to build a multi-cloud strategy is one of Upsun’s strongest advantages, particularly as the regulatory landscape evolves and threat actors become increasingly sophisticated. Our multi-cloud offering helps organizations understand where their data resides and how it is protected, while also giving teams the building blocks they need to execute business continuity and disaster recovery plans with confidence. 

Upsun supports deployment across multiple cloud providers where appropriate. If compliance or availability concerns arise, projects can be deployed to a different region and/or provider, helping to reduce service disruption and improve data availability.

  
Finally, you’ve probably heard the phrase “we take security seriously.” But what you really need is proof. That’s why we hold SOC 2 Type 2, ISO 27001, and PCI DSS Level 1 certifications and why they matter for your organization. We've done the work to pass independent scrutiny of our infrastructure controls, which means your teams spend less time proving the platform layer and more time shipping.

Choosing Upsun is not just a technical decision, it is a long term privacy and governance choice.

### [Upsun vs CapRover 2026: Managed vs Self-Hosted PaaS](https://upsun.com/blog/upsun-vs-caprover-2026/)

# Upsun vs CapRover in 2026: what you give up running your own PaaS

CapRover is a self-hosted PaaS that turns any Linux server into a Heroku-style deployment target. Built on Docker, Nginx, and Let's Encrypt, it gives developers a web dashboard for managing applications, a one-click marketplace of pre-built services, and Docker Swarm clustering for multi-node setups. You install it on any Linux VPS with a single shell command and manage everything through a browser.

Upsun is a managed multi-cloud PaaS that runs application infrastructure across AWS, Google Cloud, Azure, OVHcloud, and IBM Cloud. Teams compare the two because both promise an easier path to deployment than configuring cloud infrastructure directly. The difference is what you give up to get there.

## **Key takeaways**

-   CapRover is a self-hosted PaaS that runs on a single Linux server, with optional Docker Swarm clustering for multi-node setups. Upsun is a managed multi-cloud PaaS that runs application infrastructure for you across five cloud providers.
-   CapRover is cheaper by monthly invoice and ships with a one-click marketplace that makes spinning up databases and developer tools nearly effortless. Upsun is cheaper by total cost once compliance, autoscaling, and operational hours enter the picture.
-   Compliance is non-negotiable. CapRover holds no certifications and changed to a modified Apache license in 2023 that restricts modification of paid features and redistribution. Upsun holds ISO 27001, SOC 2, PCI DSS, HIPAA, and GDPR.
-   CapRover fits indie developers, side projects, and teams that want a click-through UI on a small server. Upsun fits autoscaling, multi-cloud deployment, regulated production environments, and teams that want to ship application code instead of managing infrastructure.

In short: CapRover if you want a clickable PaaS on a VPS, Upsun if you want a managed platform that handles scale and compliance for you.

## **What do Upsun and CapRover have in common?**

Both platforms run on the Heroku-style workflow that has shaped modern PaaS. Each supports Git-push deployment, automatic SSL through Let's Encrypt, and a range of languages including Node.js, Python, PHP, Ruby, and Go. Both run applications in isolated Docker containers, and both let you provision databases through the platform rather than configuring them manually.

If your only criterion is "Git push to deploy a containerized app behind a managed reverse proxy," either platform will do the job.

## **What are the differences between Upsun and Caprover?**

## **Detailed comparison**

### **How do Upsun and Caprover handle hosting and infrastructure?**

Upsun runs your application on infrastructure managed across five major cloud providers. You choose where to deploy, and the platform handles provisioning, networking, OS-level updates, and security patching. The same YAML configuration deploys identically across AWS, GCP, Azure, OVHcloud, or IBM Cloud.

CapRover runs on a Linux server you provision yourself. A single shell command installs CapRover, Docker Swarm, Nginx, and Let's Encrypt in roughly 10 minutes on any VPS with a public IP. Once installed, you manage applications through a web dashboard at your captain subdomain. The kernel, OS updates, security patches, firewall, and backups remain yours to manage. CapRover supports multi-node setups by joining additional servers to its Docker Swarm cluster, but Docker has slowed development of Swarm in favor of Kubernetes-based solutions and lists SwarmKit among its retired and deprecated products.

The trade-off is direct: CapRover gives you control of the server and a polished UI on top of it. Upsun removes the server entirely.

### **How do their deployment workflows compare?**

Both platforms deploy from a Git push, but the configuration models differ. Upsun uses a single .upsun/config.yaml file in your repository that defines services, routes, environment variables, and infrastructure for every branch. The config travels with the code, which makes environments reproducible through pull requests.

CapRover applications are configured through the web dashboard, optionally backed by a captain-definition file in your repository that points to a Dockerfile or template. Deployments can come from a Git connection, a CLI command (caprover deploy), a tarball upload, or the one-click app marketplace. The marketplace is one of CapRover's most distinctive features: dozens of common applications, including WordPress, GitLab, Mattermost, MySQL, and MongoDB, deploy with a few clicks and a handful of configuration values.

Teams that want infrastructure-as-code in a single YAML file will prefer Upsun. Teams that want a clickable interface and pre-built one-click installs will prefer CapRover.

### **Which platform scales better?**

Upsun supports automatic horizontal and vertical scaling. Application containers scale based on traffic and resource utilization, and database read replicas can scale independently. Production environments can be cloned in under a minute, with live data, for testing or feature work.

CapRover does not autoscale. You set an instance count manually per application, and Nginx load balances requests across those instances. For multi-node setups, you add servers to CapRover's Docker Swarm cluster and assign workloads to specific nodes through dashboard labels. This works, but Docker Swarm itself has been in maintenance mode at Docker Inc., and most modern container orchestration has moved to Kubernetes. For steady single-server workloads, CapRover scales adequately. For unpredictable traffic, multi-region deployment, or production workloads that need autoscaling, the manual model becomes a bottleneck.

A related limitation worth flagging: CapRover does not deploy Docker Compose stacks natively. If your application uses multiple services (web app, database, cache, background worker), each must deploy as a separate CapRover app, with networking handled through CapRover's internal subdomain routing rather than Compose's shared networks.

### **What managed services and observability does each platform offer?**

Upsun provides a managed services catalog including PostgreSQL, MySQL, MariaDB, Redis, Elasticsearch, OpenSearch, RabbitMQ, and Kafka. Services are provisioned through the YAML config and inherit the platform's backup, scaling, and security policies. Observability comes built in: infrastructure metrics, logs, and continuous profiling are part of the platform.

CapRover's one-click marketplace handles service deployment elegantly. PostgreSQL, MySQL, MongoDB, Redis, and other common services install with a few clicks and run as Docker containers on your CapRover server. The catch is that you operate them. Backups, version upgrades, and security patches for each service are your responsibility. Observability is limited to NetData, which CapRover bundles for system metrics. Application-level metrics, error tracking, and log aggregation require external tools that you assemble yourself.

CapRover wins on installation convenience. Upsun wins on operational simplicity and integrated observability.

### **How does pricing compare between Upsun and Caprover?**

CapRover is free to install and use. A capable VPS from Hetzner, DigitalOcean, or Linode costs $5 to $25 per month, and there are no per-user fees or feature paywalls. In July 2023, CapRover moved from a standard Apache 2.0 license to a modified version that restricts modification of paid features and redistribution of paid versions, though the core platform remains free for self-hosted use.

Upsun uses a Flex pricing model that bills at the resource level for CPU, RAM, and storage. Costs scale linearly with actual usage. For a single small project, Upsun is meaningfully more expensive than self-hosted CapRover. For a team needing observability tooling, compliance certifications, automated backups, and multi-region failover, the comparison shifts once you account for the engineering hours and third-party tooling required to match those capabilities on CapRover.

The honest version: CapRover is cheaper if your time is free and your workload fits on a single server. Upsun is cheaper once either of those stops being true.

### **Which platform is better for compliance and security?**

This is where the comparison ends decisively. Upsun holds ISO 27001, SOC 2, PCI DSS, HIPAA, and GDPR certifications. These are platform-level guarantees that customers inherit when deploying. Security patches, vulnerability management, and infrastructure-level compliance controls are managed by the platform.

CapRover holds no certifications. When you self-host CapRover, you inherit responsibility for your own compliance posture, including OS patching, vulnerability management, audit logging, and access controls. For regulated industries such as healthcare, financial services, or government, CapRover is not a viable production platform without significant additional engineering work. CapRover was built as a developer-friendly self-hosted PaaS for indie developers and small teams, not as a compliance-ready enterprise platform.

## **When to choose CapRover**

CapRover is the right tool when convenience, cost, and a clickable interface matter more than scale and compliance. Pick CapRover if:

-   You want a click-through dashboard with a one-click app marketplace for spinning up WordPress, GitLab, MySQL, and similar services.
-   You are an indie developer or small team running side projects, internal tools, or a handful of production apps on a small VPS.
-   You have basic Linux and Docker familiarity and prefer a no-Kubernetes orchestration model.
-   Your applications can deploy as independent services without requiring native Docker Compose support.
-   Your workload fits on a single server or a small Docker Swarm cluster.

CapRover has been a stable, popular self-hosted PaaS for nearly a decade. For the right team, it is a better fit than any managed PaaS.

## **When to choose Upsun**

Upsun is the right tool when self-hosted convenience stops being worth the operational and compliance trade-offs. Pick Upsun if:

-   Your application carries compliance obligations, including HIPAA, PCI DSS, or SOC 2.
-   You need automatic scaling for unpredictable traffic, such as e-commerce flash sales or product launches.
-   You operate multi-cloud or need data residency across AWS, GCP, Azure, OVHcloud, or IBM Cloud.
-   Your application uses multiple coordinated services that benefit from Docker Compose-style native multi-container support.
-   Your team should be writing application code, not patching kernels, managing TLS rotations, or operating Docker Swarm clusters.

The line between "CapRover is enough" and "CapRover is holding us back" usually crosses somewhere between hobby project and serious production workload, or the moment compliance enters the picture. That crossover is when Upsun becomes the cheaper option, even when its monthly invoice is larger.

## **How do you migrate from CapRover to Upsun?**

A CapRover-to-Upsun migration moves your applications, services, and data onto a managed platform. The process involves six main steps:

1.  **Translate configuration.** Move from CapRover's dashboard and captain-definition files to a single .upsun/config.yaml file in your repository. Applications, services, routes, and environment variables are defined in YAML and travel with the code.
2.  **Map runtimes and build steps.** CapRover applications built from Dockerfiles can often run on Upsun with minimal modification, since Upsun supports both buildpack runtimes and custom container builds for major languages.
3.  **Map managed services.** PostgreSQL, MySQL, Redis, and MongoDB are supported by both platforms. Each one-click app from CapRover's marketplace maps to an equivalent Upsun managed service defined in the YAML config.
4.  **Consolidate multi-service applications.** Applications split across multiple CapRover apps (because CapRover does not support Docker Compose natively) can often be combined into a single Upsun project with multiple services defined in one YAML file.
5.  **Migrate data.** Export databases from your CapRover server and import them into Upsun's managed services using standard dump and restore workflows such as pg\_dump and mysqldump.
6.  **Update connection logic.** Application code typically needs minor updates to reference Upsun's environment variables and service relationships.

A production migration typically takes 6 to 9 weeks, with the longest phases being infrastructure documentation, MVP testing, and data validation. For CapRover setups with extensive marketplace apps, custom Nginx configuration, or complex Swarm clustering, expect additional time to translate those into Upsun's equivalent constructs.

## **Frequently Asked Questions (FAQs)**

**Is CapRover free and open source?**

CapRover is free to install and use for self-hosted deployments. Its license status is more nuanced. In July 2023, CapRover moved from a standard Apache 2.0 license to a modified version that restricts modification of paid features and prohibits redistribution of paid versions without a written agreement. The core platform remains free, but the modified license means CapRover is technically source-available rather than fully open source under the strict Open Source Initiative definition.

**Can CapRover deploy Docker Compose applications?**

Not natively. CapRover deploys each service as a separate application, which means a multi-service stack (app, database, cache, worker) must be split into individual CapRover apps with networking handled through internal subdomain routing. This is one of CapRover's most significant limitations for teams running complex multi-container applications. Platforms like Upsun, Coolify, and Dokploy support multi-service configurations more natively.

**Can CapRover scale to multiple servers?**

Yes. CapRover supports multi-node clusters through Docker Swarm. You add additional servers to the cluster from the dashboard and assign workloads using node labels. The trade-off is that Docker Swarm itself has been in maintenance mode at Docker Inc. for several years. For teams that need autoscaling, advanced orchestration, or multi-region deployment, a managed PaaS like Upsun is a better fit.

**Does CapRover support SOC 2 or HIPAA compliance?**

No. CapRover does not hold SOC 2, HIPAA, PCI DSS, or ISO 27001 certifications. When you self-host CapRover, you inherit responsibility for compliance, including OS patching, audit logging, access controls, and vulnerability management. Teams in regulated industries typically need a managed platform with platform-level certifications, such as Upsun.

**Does Upsun support multi-cloud deployment?**

Yes. Upsun deploys across AWS, Google Cloud Platform, Microsoft Azure, OVHcloud, and IBM Cloud through identical workflows defined in a single .upsun/config.yaml file. Teams can meet data residency, compliance, and latency requirements without rewriting deployment pipelines for each provider. CapRover, by contrast, runs on individual servers you provision yourself and does not abstract multi-cloud deployment.

**What is Upsun pricing model?**

Upsun uses resource-based pricing, where you only pay for the resources you provision: CPU, RAM, and storage. There are no fixed tiers or surprise bandwidth charges. This is structurally different from CapRover, which is free software billed only through the VPS you run it on. Upsun is more expensive on a monthly invoice but typically cheaper in total cost when engineering hours, observability, and compliance are included.

**Is CapRover cheaper than Upsun?**

On monthly invoice, yes. A self-hosted CapRover instance on a $10 VPS is significantly cheaper than an equivalent Upsun project. On the total cost of ownership, the comparison narrows once engineering hours, observability tools, backup management, and compliance work enter the calculation. For single-server workloads and indie projects, CapRover is almost always cheaper. For production workloads with operational and compliance requirements, Upsun is often cheaper overall.

### [From local dev to production in moments | Upsun](https://upsun.com/blog/from-local-dev-to-production-in-moments/)

# From local dev to production in moments: using Upsun CLI and API for fast delivery loops

For most developers, the terminal is where real work happens. While web UIs look polished, most developers prefer the command line for speed and control. However, the path from a local change to a real, production-like environment is full of friction.

Tickets, YAML edits, console clicks, waiting for pipelines, re-running jobs.  
All before you even know if the change works.

Upsun CLI and API to shorten this loop. Push from your terminal, trigger deployments, manage environments, and integrate with any CI/CD pipeline, all without context switching or learning proprietary tools.

## **Deployment workflow problems developers face**

Many platforms promise developer-friendly experiences but deliver the opposite:

-   **Context switching kills momentum.** You're writing code in your editor, checking status in the browser console, reading documentation in another tab, and troubleshooting in yet another tool. Each switch costs time and mental energy.
-   **Custom workflows create vendor lock-in.** Proprietary CLIs, specialized deployment tools, and platform-specific integrations mean your team learns systems that don't transfer to other projects. Change platforms? Start from scratch.
-   **Manual steps introduce errors.** Click through the console to deploy. SSH into servers to run migrations. Check logs in separate dashboards. Miss one step and deployments fail at 3am.
-   **Environments drift by default.** Local development uses Docker. Staging runs on a different infrastructure than production. Each environment has slightly different configurations. Bugs appear in production that never surfaced in testing.

The result? Developers spend more time managing infrastructure than building features. Stack Overflow survey found that developers spend over 30 minutes daily just searching for solutions to deployment and infrastructure issues.

## **Upsun's approach: extend your workflow, don't replace it**

Upsun treats your terminal and existing CI/CD pipelines as the primary interface. Everything available in the web console is accessible via CLI or API.

### **Terminal-first deployment**

The Upsun CLI wraps Git commands you already use. Pushing code automatically triggers builds, activates environments, and syncs data. One command replaces multiple manual steps.

Push a new feature branch, and Upsun instantly creates a live environment with a clone of production data. Share the URL with stakeholders for review. Merge when ready. The environment auto-deletes on merge. No tickets, no waiting, no manual cleanup.

The CLI auto-detects which project and environment you're working in based on Git context. No configuration files to maintain or project IDs to memorize.

### **API access for any integration**

Behind every CLI command is a REST API endpoint. Authenticate once with an API token, and you can:

-   Automate deployments from any CI system
-   Build custom tooling for your team
-   Integrate with internal monitoring systems
-   Script complex workflows across multiple projects
-   Trigger operations from webhooks or scheduled jobs

The API uses standard OAuth2 authentication and returns HAL-formatted JSON. Any HTTP client works, no proprietary SDKs required.

### **Infrastructure as code that actually works**

Configuration lives in your Git repository as YAML files. Define applications, databases, caches, routes, and deployment hooks in one place. Branch your code and the infrastructure branches with it.

This isn't theoretical infrastructure-as-code. It's practical: branch a feature and get a complete clone of the production application, PostgreSQL database, Redis cache, and environment variables. Test against the real stack, not mocked services.

When you merge the branch, the infrastructure is automatically removed. No orphaned resources, no surprise cloud bills.

## **How teams actually use this**

### **Fast feedback loops without CI complexity**

Traditional approach: push code, wait for CI to build, manually deploy to staging, test, repeat. Each cycle takes 10-15 minutes minimum.

With Upsun, push creates a live environment immediately. Run tests against the actual deployed application and services. See failures in context, fix them, push again. Cycle time drops to seconds instead fo minutes.

The CLI can return environment URLs instantly. Share them in pull requests. Designers review actual UI. Product managers test features. Stakeholders approve before merge. Feedback happens on real deployments, not screenshots.

### **CI/CD that works with any platform**

Most platforms lock you into their CI system or require complex integrations. Upsun works with GitHub Actions, GitLab CI, Bitbucket, or any CI/CD system that can run bash commands and install the Upsun CLI.

Install the CLI in your pipeline, authenticate with a token, and run deployment commands. The same script works across platforms. Switch from GitHub to GitLab? Update the token; everything else remains the same.

### **Testing against production-like data safely**

Development environments need realistic data to catch bugs. But production databases contain sensitive customer data that you can't expose across multiple environments and access points.

Upsun clones production data to preview environments automatically, then runs sanitization scripts during deployment. Developers get realistic test data without accessing sensitive information. Environment variables control when sanitization runs, so production stays untouched.

## **Observability without additional tools**

The CLI exposes logs, metrics, and performance data directly in your terminal. Stream application logs while developing. Check CPU and memory usage before scaling decisions. Profile critical endpoints to find bottlenecks.

For PHP and Python applications, Blackfire APM integration is included. Profile any endpoint from the command line, compare performance between branches, and fail CI builds when performance degrades. No additional instrumentation or third-party services required.

## **Getting started takes minutes**

1.  **Install the CLI:** Use the Bash installation script. You can also install using Homebrew (macOS/Linux) or Scoop (Windows). One command gets you running.
2.  **Authenticate:** Run the authentication command. It opens your browser to log in and automatically configures SSH access for your deployments.
3.  **Initialize your project**: Run `upsun init` from your existing code repository. Choose between an AI-assisted setup or a guided configuration. The CLI detects your language, framework, and dependencies, then generates a starter configuration file.
4.  **Deploy:** Commit the configuration, push your code, and watch your application go live. The entire onboarding takes less time than most cloud provider sign-up forms.

For teams with existing infrastructure, migrate incrementally. Run Upsun alongside current systems, move projects one at a time, and validate that workflows improve before committing fully.

## **The core difference**

Most platforms add layers: custom interfaces, proprietary tools, platform-specific workflows. Each layer promises to simplify but actually introduces complexity and vendor lock-in.

Upsun removes layers. It extends Git and your terminal with deployment automation. The CLI speaks the same language as your existing tools. The API integrates with any system that makes HTTP requests.

Your workflow stays familiar. Git commits trigger deployments. Environment variables configure applications. SSH provides direct access when needed. The difference is speed and automation, not wholesale replacement.

## **What this means for your team**

Faster deployment cycles mean faster feedback. Faster feedback means fewer bugs reach production. Fewer production bugs mean fewer emergency fixes and late nights.

Terminal-based workflows keep developers in their tools. Less context switching preserves flow state. Better focus leads to higher-quality code.

Automated environment management reduces DevOps burden. Platform engineers can focus on architecture instead of provisioning infrastructure. Developers can experiment without creating technical debt.

The compounding effect of small efficiency gains—60 seconds instead of 15 minutes, one command instead of six clicks, automatic cleanup instead of manual tickets adds up to significantly more time building features customers care about.

## **Try it yourself**

The fastest way to understand is to experience it. Create an Upsun account, point the CLI at any Git repository, and push. Watch a production-grade environment appear in moments.

## **Explore further**

-   **See the Upsun CLI in action**  
    Complete command reference, installation guides, and authentication setup for terminal-based deployments.
-   **Read the API documentation**  
    REST API endpoints, authentication methods, and integration patterns for automating deployments with any CI/CD tool.

### [Fix the staging bottleneck with preview environments | Upsun](https://upsun.com/blog/staging-bottleneck-preview-environments/)

# Why your team keeps waiting for staging (and what to do about it)

**The staging bottleneck: why your framework needs ephemeral preview environments**

There's a specific kind of Friday afternoon that frontend and backend developers both recognize. A feature is ready to test. Staging is occupied. Someone else pushed a half-finished migration to the shared database last Tuesday and it's been "almost fixed" ever since. You either wait or you merge blind and hope.

Most teams treat this as a scheduling problem. It isn't. It's an architecture problem.

## **Why shared staging breaks under any real workload**

_Key takeaway: A single shared staging environment is a serialization bottleneck. It forces parallel development to become sequential at exactly the point where speed matters most._

A shared staging server makes sense for a solo developer or a very small team with a slow release cadence. The moment you have two developers working on separate features, or a QA process that runs alongside active development, the shared environment starts causing problems that compound in ways that are easy to underestimate.

The obvious problem is queue time. Developer A needs to test a checkout flow. Developer B has a migration running. Developer A waits.

The less obvious problem is contamination. Staging environments accumulate state. A database that's been through six developers' test runs over two weeks is not a reliable test surface. A feature that passes on a contaminated staging environment may behave entirely differently when it hits a clean production database. You've tested something, but you haven't tested what you think you've tested.

The least obvious problem is the slowdown effect on code review. When testing requires access to a shared resource, reviewers start approving things they haven't fully validated because the cost of getting environment access is high enough to skip. The bottleneck doesn't just delay testing; it degrades its quality.

## **The gap between staging and production**

_Key takeaway: Every difference between your staging environment and production is a potential blind spot. Bugs that live in that gap are invisible until they're live._

Environment drift between staging and production is so common it's become background noise. Different OS patch levels, slightly different service versions, and database contents that diverge week by week. Most developers have absorbed "works on staging, breaks in production" as an annoying fact of life rather than a solvable problem.

But it's a solvable problem.

The gap exists because staging environments are maintained manually. Someone updates production but forgets staging. A dependency gets pinned to a different version. The database schema gets a hotfix that never makes it back into the migration scripts. None of these are mistakes exactly, they're just the natural result of treating two environments as separate things to manage.

The fix isn't better discipline around keeping staging current. That's a process cost that grows as the team grows. The fix is making the two environments the same thing by construction.

## **What Git-driven preview environments actually do**

_Key takeaway: When a branch automatically provisions its own production-equivalent environment, the staging queue disappears and the gap closes. Every developer tests against a clean, accurate surface without touching anyone else's work._

The mechanic is straightforward. When you push a branch, the platform spins up a complete environment for that branch: the same runtime version, the same services, the same configuration as production. When the branch is merged or closed, the environment is torn down. No manual provisioning, no shared state, no queue.

Upsun is a Cloud Application Platform that manages the infrastructure layer of your application stack so your team doesn't have to. One of the ways that shows up in practice is how environments work: each one is a clone of its parent, down to the data. A branch off main gets the same stack, the same service versions, and a copy of the production data snapshot. You're not testing against a staging approximation. You're testing against a replica.

Creating a branch environment on Upsun looks like this:

```shell-session
# Branch from main and spin up a full environment automatically
upsun branch feature/new-checkout main

# Your branch environment is live at a unique URL within seconds
# Same runtime, same services, same data as production
```

The practical effect on a team of four or five developers is significant. Feature branches can be tested in parallel. QA can review a branch environment directly, with a real URL, without waiting for a deployment slot. A bug reported against a specific branch can be reproduced in that branch's environment, not in a shared environment that may have been modified by three other people since the bug was filed.

For frameworks like Drupal or Django, where the database schema and the application code are tightly coupled, this matters even more. A migration that works against a real copy of the production database is a migration you can actually trust.

## **The workflow shift**

_Key takeaway: Preview environments change what's possible, not just how fast the existing process runs: code review with live environments, QA in parallel with development, and a staging bottleneck that no longer exists._

The change is less about testing speed than about what becomes possible when environment access stops being a scarce resource.

Code reviewers can open a live environment for any pull request without asking anyone for access. QA can run tests against a branch before it's merged, not after. A product manager can preview a feature in a real environment without waiting for a deployment. A hotfix can be validated against a production replica before it goes live, not in a contaminated shared environment that was last cleaned six weeks ago.

Rather than getting faster or better, the shared staging environment simply becomes unnecessary.

## **Already running a shared staging setup?**

The shift to per-branch environments doesn't require rebuilding your workflow from scratch. If your team currently deploys to a shared staging server for review, the change is additive: branches get their own environments, the shared server stops being the gatekeeper for QA, and the queue dissolves. The main thing to plan for is updating any CI/CD steps that assume a single staging target, since each branch environment gets its own URL.

## **Frequently asked questions (FAQs)**

**Does every branch really get a full environment, including services like Redis and a database?**

Yes. Each preview environment is a clone of its parent environment, services included. If production runs MariaDB and Redis, the branch environment runs the same versions of both, seeded from a snapshot of production data.

**What happens to the data in a preview environment?**

It starts as a copy of the parent environment's data at the point the branch was created. Changes you make in the preview environment stay isolated there. When the branch is deleted, the environment and its data are removed. Production is never touched.

**How is this different from just spinning up a staging server manually?**

The key difference is that it happens automatically, is consistent by construction, and carries no ongoing maintenance cost. A manually provisioned staging server drifts from production over time and requires someone to keep it current. A platform-managed preview environment is created from the same config file and data every time.

**Can non-developers access preview environments?**

Yes. Each environment gets its own URL. You can share that URL with QA, a product manager, or a client without giving anyone access to the underlying infrastructure.

**What happens to preview environments when a branch is merged?**

They are deactivated and removed. You only pay for environments while they're active, which also means you're not running idle servers for branches that shipped three weeks ago.

### [Application monitoring & logging guide | Upsun](https://upsun.com/blog/application-monitoring-and-logging/)

# Application monitoring & logging: A developer's guide to taking control

No developer wants 3 AM urgent server outages and performance alerts, but that's exactly what can happen without solid application monitoring. Poor performance and outages directly impact your revenue.

Akamai and SOASTA’s research reveals the brutal economics of performance problems: even a mere 100ms increase in latency slashes conversion rates by 7%, while extended downtime can hemorrhage thousands of dollars hourly. This direct link between technical performance and business outcomes is precisely why your monitoring stack must evolve beyond basic tracking to become an early warning system, catching and resolving issues before they ever reach your users' screens.

Application performance monitoring means stopping issues before they start. Well-configured service level objectives (SLOs) turn potential disasters into minor fixes.

_"The best time to fix a bug is before it exists."_ \- Andrew Hunt, co-author of The Pragmatic Programmer

In this guide, we'll explore these key areas:

-   Early warning systems that catch issues at the onset
-   Precise alerts that identify root causes
-   Data-driven maintenance planning
-   Battle-tested tools that fit your stack

## **Why monitor? The real cost of downtime**

What hurts more than a 3 AM wake-up call, watching revenue fall after systems go down. Here's how smart monitoring stops fires before they start:

-   **See it break:** Users won't tell you when things slow down - they'll ghost you
-   **Fix faster:** Precise system insights can significantly cut your resolution time
-   **Scale intelligently:** Monitor capacity metrics to scale resources based on actual demand
-   **Data-driven decisions:** Finally, measure the real impact of your technical choices

**Proactive security:** Don't wait for breaches to happen. Detect and block threats in real-time with continuous monitoring

## **The three core elements of application monitoring**

Application monitoring keeps your systems honest. Three pieces work together to tell you what's happening under the hood. 

### **1\. Metrics: Track key health indicators**

-   Watch your system's health in real-time–catch small hiccups before they turn into real headaches
-   Monitor key indicators like CPU usage, response times and error rates
-   Set smart alerts that notify you when metrics drift outside acceptable ranges

### **2\. Logs: Your system's digital paper trail**

-   **Capture detailed records** of every significant event across your application
-   **Log everything that moves** across your system. Every error, warning, and user action. It's your digital paper trail when things go wrong.
-   Debug issues with complete context and timestamp data

### **3\. Traces: Your request's journey map**

-   **Follow requests** as they travel through your distributed services
-   Find performance bottlenecks and improve service connections
-   See how different parts of your app work together, from API calls to database queries and service communication

These three pieces work together as your monitoring foundation, helping you catch problems early and keep everything running smoothly. You know what's great? Modern cloud platforms have made it pretty easy to set up these monitoring tools–no rocket science needed. Lets look at how in the next section.

## **Monitoring in the cloud era**

Cloud monitoring gives you a direct line between system health and business impact. Real-time monitoring lets you catch and fix small hiccups before they snowball into big problems that affect your users. You can optimize your system based on actual performance metrics.

Modern container platforms like Kubernetes have changed how we look at data and offer granular insights into every component of our applications. You get granular insights while maintaining the full context of your system.

## **Multi-runtime architecture: Optimizing monitoring across your stack**

Modern applications are versatile and adaptable in that they use different specialized tools (called runtimes) to get various jobs done efficiently. Rust powers the heavy lifting, Node drives web API,s and Python crunches data. Each runtime needs its monitoring approach to catch problems early— think of it like having specialized doctors for different parts of your system.

**Runtime-specific monitoring strategies:**

This strategy helps maintain optimal performance across your entire application while reducing mean time to resolution when problems pop up.

-   **Node.js monitoring**
    -   Track event loop lag (warning threshold: >100ms)
    -   Monitor heap usage patterns with tools like clinic.js
    -   Example config: `{ "eventLoopLag": { "warning": 100, "critical": 500 }, "heapUsage": { "warning": "70%", "critical": "85%" } }`  
         
-   **Python monitoring**
    -   Watch for GIL contention using py-spy
    -   Track memory leaks with memory\_profiler
    -   Example config: `{ "gilContentionRate": { "warning": "25%", "critical": "40%" }, "memoryGrowth": { "warning": "10MB/min", "critical": "50MB/min" } }`  
         
    -   **Rust monitoring**
        -   Monitor thread pool usage to maintain service responsiveness
        -   Use metrics-rs to track system resources.
        -   Example config: `{ "threadPoolUtilization": { "warning": "85%", "critical": "95%" }, "requestLatency": { "warning": "10ms", "critical": "50ms" } }`

Upsun makes working with multiple runtimes less complex by giving you visibility into your entire stack from a single place.  You can define and manage dependencies between services, helping you identify potential bottlenecks. Our unified monitoring lets you track performance across all technologies.

## **Numbers that drive decisions**

Here are the key metrics to watch, along with their thresholds and what to do when things go wrong:

### **1\. Performance metrics (speed & responsiveness)**

**Response time monitoring:** Track request response speed—it's your user experience pulse.

-   **When the warning threshold hits:** Profile slow queries (using database profiling tools), optimize code paths, and check network latency (with traceroute, mtr).
-   **When the critical threshold hits:** Deploy APM diagnostics. Trace bottlenecks. Check timeouts. Monitor resources. `[2025-02-13 12:15:23] [WARN] Slow query detected - Endpoint: /payment - Duration: 650ms - Query: SELECT * FROM orders WHERE user_id = ?`

**Error rate monitoring:** Track requests that fail to keep your service running smoothly.

-   **When the warning threshold hits:** Analyze error patterns across your stack (using error tracking tools).
-   **When the critical threshold hits:** Check recent deploys and infrastructure changes. `[2025-02-13 12:30:00] [ERROR] POST /api/users - 500 Internal Server Error - Reason: Database connection failed`

### **2\. System vitals**

**CPU monitoring:** find performance bottlenecks early and fix them before your users notice anything's wrong.

-   **When the warning threshold hits:** Profile CPU-heavy processes (using top, htop), optimize algorithms.
-   **When the critical threshold hits:** Scale compute capacity, optimize critical execution paths. `[2025-02-13 14:20:33] [WARN] High CPU Usage - Service: API - Usage: 82%`

**Memory monitoring:** tracking memory usage finds memory leaks before they tank your app. No crashes, no surprises.

-   **When the warning threshold hits:** Run memory profilers to check heap dumps and garbage collection.
-   **When the critical threshold hits:** hunt down memory leaks and restart if needed. `[2025-02-13 14:45:10] [WARN] Memory Pressure - Service: BackgroundJobProcessor - Heap Usage: 90%`

**Disk I/O monitoring:** Monitor both how fast your storage can handle operations (IOPS) and how much data it can move at once (throughput) to keep things running well.

-   Set baselines for your specific workloads (using iostat, iotop)
-   Alert on significant pattern changes
-   Monitor database and file operations closely and tune them when performance starts to lag

### **3\. Service level objectives (SLOs)**

**Availability tracking:** Define measurable SLOs that quantify your service performance. Track latency, error rates, and uptime.

-   **Target:** Target 99.95% uptime. Track error budget (the allowable amount of downtime or errors before breaching service level agreements).
-   **On breach:** Trigger automated scaling when error budget hits 90% to proactively manage capacity. `[2025-02-13 15:00:00] [LOG] SLO breach detected - Error budget: 92% - Region: US-East - Status: Initiating capacity analysis`

**Performance SLOs:** Define response time targets that match what users expect and keep measuring against them.

-   **Target:** Keep p99 latency (99th percentile response time) under 500ms to ensure most users have a fast, smooth experience.
-   **On breach:** Scale up resources and optimize code paths to restore service levels

### **4\. Real user metrics that matter**

-   **Page load time:**
    -   **Normal:** < 2s
    -   **Warning:** > 3s
    -   **Critical:** > 5s (Users leaving)
    -   **Action steps:**  
          
        -   Profile frontend performance (using Lighthouse, WebPageTest)
        -   Optimize assets and API calls
        -   Use network testing tools to identify and resolve performance bottlenecks
        -   `[2025-02-13 16:10:22] [WARN] Slow Page Load - URL: /products - Average Load Time: 4.2s`
-   **User flow completion:** Track successful user journeys.
    -   **Normal:** > 95%
    -   **Warning:** < 90%
    -   **Critical:** < 85%
    -   **Action steps:**  
          
        -   Parse funnel analytics
        -   Scan error logs
        -   Review session data for drop-off points
        -   `[2025-02-13 16:30:45] [WARN] Cart Abandonment Spike - User Journey: Checkout - Completion Rate: 88%`

Track these user-focused metrics consistently and take swift action when warning signs appear; you'll keep solid service delivery and prevent user frustration. When you combine these insights with your system monitoring and logging, you get an observability picture for both technical excellence and business success. With this foundation, let's explore how to protect your systems in real-time with robust security monitoring.

### **5\. Protect your systems in real-time**

Security monitoring works alongside performance tracking to shield your systems from threats. Here's your practical security toolkit:

-   **Smart detection**
    -   Block suspicious IPs after 10 failed login attempts per minute
    -   Alert when traffic spikes 3x above normal within 5 minutes

Scan security events every 30 seconds to spot attack patterns in real-time - your first defense against emerging threats  
 

-   **Active defense**
    -   Rate limiting that adapts to your traffic patterns
    -   Instant blocking of malicious activity
    -   Real-time threat data integration
-   **Quick response playbook**
    -   Standardized threat handling with MITRE ATT&CK
    -   Automated response sequences

Response time targets:

### **6\. Business metrics**

Your application's technical metrics directly impact your bottom line. Here's how to translate performance data into business value:

**Response matrix for transaction issues:**

-   98-99%: Monitor closely
    -   Review system logs
    -   Check recent deployments
-   95-98%: Immediate action
    -   Analyze payment gateway health
    -   Review traffic patterns
-   <95%: Critical response
    -   Activate the incident team
    -   Execute rollback procedures

**Key takeaway:** Track these metrics in real-time and adjust thresholds based on your business patterns. Quick response to degradation prevents a major revenue impact.

## **Logs:** 

Every event, error, and user action gets captured in logs, giving you the complete story when things go wrong. They're your first line of defense for production issues.

**Why structured logs matter**

-   **Security alerts:** Catch suspicious patterns early
-   **System clarity:** See how services interact in real-time
-   **Early detection:** Fix issues before users report them

**What this means for you:**

-   **Fast searches:** Zero in on issues using request\_id, user\_id, error\_type, or timestamp
-   **Spot patterns:** Catch recurring issues before they become problems
-   **Automate responses:** Set up alerts that trigger when things need attention
-   **Clean data:** Parse logs consistently across your entire stack

### **Pro logging practices**

-   **Pick your log levels wisely:**
    -   `DEBUG`: Dev-only details (keep out of prod)
    -   `INFO`: Normal system events
    -   `WARN`: Problems that need attention
    -   `ERROR`: Recoverable failures
    -   `CRITICAL`: Drop everything and fix now
-   **Essential fields in every log:**
    -   `request_id`: Link events across services
    -   `timestamp`: UTC for global tracking
    -   `user_id`: Who triggered this
    -   `service_name`: Where it happened
    -   `log_level`: How urgent is it
-   **Keep it clean:** Use one format everywhere
-   **Store it smart:** Centralize in ELK or cloud logging with retention plans that fit your needs

**Example: structured logging in Python**

```shell-session
`import logging import json
logger = logging.getLogger(name)
def process_order(order_id, user_id, product_name, quantity): logger.info("Processing order", extra={ "order_id": order_id, "user_id": user_id, "product_name": product_name, "quantity": quantity, "event_type": "order_processing" # Adding context for analysis }) try: # ... order processing logic ... logger.info("Order processed successfully", extra={ "order_id": order_id, "status": "success", "event_type": "order_completion" }) except Exception as e: logger.error("Error processing order", extra={ "order_id": order_id, "error_message": str(e), "event_type": "order_error" }, exc_info=True) # Include stack trace for errors raise
```

**Example usage**

```shell-session
process_order("ORD-12345", "user-42", "Awesome Widget", 2)`

```

**Example log output (JSON):**

```shell-session
{"asctime": "2025-02-13 18:00:00", "levelname": "INFO", "name": "__main__", "message": "Processing order", "order_id": "ORD-12345", "user_id": "user-42", "product_name": "Awesome Widget", "quantity": 2, "event_type": "order_processing"} {"asctime": "2025-02-13 18:00:01", "levelname": "INFO", "name": "__main__", "message": "Order processed successfully", "order_id": "ORD-12345", "status": "success", "event_type": "order_completion"}
```

When you need structured logging in other programming languages, here are some solid options:

-   Winston for Node.js formats logs and routes them through multiple destinations
-   Serilog for .NET provides strongly-typed logging with good performance
-   Logrus in Go brings structured logging up a level with rich fields and hooks

Each of these libraries provides a consistent way to capture what your code does as it runs. 

### **Distributed tracing: connect your stack end-to-end**

When requests flow through multiple services, you need clear insights into what happens where. OpenTelemetry makes this simple by linking your components together so you can find and fix issues quickly.

```shell-session
from opentelemetry import trace
from opentelemetry.trace import Status

tracer = trace.get_tracer(__name__)

@tracer.start_as_current_span("process_order") 
def process_order(order_id):
    with tracer.start_span("validate_order") as span:
        # Add business context
        span.set_attribute("order_id", order_id)
        
        if not is_valid(order_id):
            span.set_status(Status.ERROR)
            return False
    
    return True

```

Traces show you exactly what's happening when things go wrong across your system helping you find and fix issues faster.

## **Choose the right monitoring tools**

Your choice of monitoring tools directly determines how well you’re able to detect and resolve issues. Here's a clear and practical guide to picking tools that work for your stack.

### **1\. Tool selection checklist**

-   What's your technical comfort level? Command-line tools vs simpler interface
-   Where's your app running? Cloud or hybrid setup
-   What can you spend? Open source to enterprise
-   What's needed? Basic tracking or deep insights

### **2\. APM tools**

**Quick setup, full visibility**

-   ✓ Zero setup headaches
-   ✓ Ready-to-go monitoring tools
-   ✓ Start tracking in minutes
-   ✓ Built for production loads
-   ✗ Pay more as you grow
-   ✗ Hard to customize for specific needs
-   ✗ You're tied down to one vendor's way of doing things

### **3\. DIY monitoring** 

**For the control enthusiasts**

-   ✓ Build it exactly how you want
-   ✓ Backed by the open source community
-   ✓ Minimize costs by keeping  infrastructure low
-   ✓ Swap and replace tools without friction
-   ✗ Requires deep technical know-how
-   ✗ You own the monitoring stack
-   ✗ Scale it yourself

### **4\. Cloud-native monitoring**

**Ideal when you're all-in on one cloud**

-   ✓ Works with your platform
-   ✓ Quick to set up
-   ✓ Often included in platform costs
-   ✓ One dashboard for everything
-   ✗ Tied to your platform
-   ✗ Limited tweaking options
-   ✗ Features vary by platform

### **Quick comparison**

**Tip:** Mix tools based on what you monitor. Use SaaS APM for core metrics plus specialized tools for specific needs.

**Pick your monitoring stack based on what matters most:**

-   **DIY route**: When you need granular control and custom compliance features
-   **SaaS APM tools**: When you want monitoring that just works and scales with you
-   **Cloud-native tools**: When your apps live in one cloud and you want everything integrated

## **Actionable monitoring: turn data into decisions**

Now that we've covered monitoring tools, let's put that data to work. Here's how to transform metrics into automated actions:

### **1\. Smart alerts that power action**

Configure smart alerts that turn data into action:

-   **Impact-aware:** Focus on user and business-critical metrics
-   **Precision targeting:** Route alerts to service owners instantly
-   **Rich context:** Include actionable troubleshooting data
-   **Dynamic thresholds:** Use dynamic baselines to reduce noise

### Alert and runbook templates:

**Response time > 500ms (5min)**  
actions:

-     check\_cache\_hit\_ratio
-     verify\_db\_connections
-     scale\_service\_pods

**Error rate > 1% (1min)**  
actions:

-     inspect\_error\_logs
-     verify\_dependencies
-     rollback\_if\_needed

**CPU load > 80% (3min)**  
actions:

-     analyze\_resource\_usage
-     optimize\_queries
-     add\_capacity

**Health check failures**  
actions:

-     verify\_endpoints
-     check\_certificates
-     restart\_if\_unresponsive

## **2\. Automation**

Let's implement automated monitoring workflows:

-   **Alert routing:**
    -   Smart routing sends critical issues straight to the right teams through PagerDuty/Slack
    -   Auto-escalate alerts based on severity and response times
    -   Route alert types through custom paths
-   **Issue tracking:**
    -   Auto-create tickets with full context and stacktrace in 2s flat
    -   Monitor metrics and behavioral telemetry to surface emerging patterns (sub-100ms response time)
-   **Resource scaling:**
    -   Auto scale based on real performance data
-   **Release control:**
    -   Roll back deployments and canary releases if the metric starts heading in the wrong direction.

```shell-session
# Alert configuration example
alerts:
  - name: "High API Response Time"
    metric: "http_request_duration_seconds_p95"
    threshold: 500ms
    duration: "5m"
    severity: "warning"
    route_to: "dev-team-channel"
    notification_type: "slack"

  - name: "Critical Service Down"
    metric: "service_health_check_failed"
    service: "payment-service" 
    severity: "critical"
    route_to: "on-call-pager"
    notification_type: "pagerduty"
    actions:
      - "auto_restart_service"
      - "create_jira_ticket"
```

### **3\. Dashboards that cut through noise**

With automation and smart alerts in place, let's create focused dashboards get into critical insights. Here's what we're working with:

-   **Core metrics:** Track real-time system health and performance metrics
-   **Performance data:** pinpoint and resolve performance issues before they affect your users
-   **Debug toolkit:** Drill into metrics when things go wrong
-   **Role-based views:** Role-based views: create tailored dashboards specific to what each team needs to see

Effective monitoring lets you detect and resolve technical issues before they impact your users.

## **Cost control**

-   **Problem:** Monitoring gets more expensive as you grow
-   **Solution:** Track costs and optimize spending by monitoring data storage and usage metrics.

Track key metrics:  
  
Monthly Cost = (Data Points × Storage Time) + (Log Volume × Rate) + (Query Usage × Price)

-   Budget alerts that bite early
-   Ruthless retention policies  
     

## **Evolve your monitoring**

Like the applications they track, monitoring systems need to grow and adapt over time. Static monitoring setups quickly become outdated as your architecture evolves, new services are added, and business priorities shift. Exceptional monitoring isn't a one-time implementation—it's an ongoing practice that continually delivers increasing value.

Set a quarterly cadence to evaluate your entire observability approach, examining which metrics provide actionable insights and which generate noise. This consistent review cycle ensures your monitoring tools detect the issues that matter most to your current architecture and business goals, rather than solving yesterday's problems.

The most mature engineering organizations treat their monitoring configurations with the same care as application code—versioned, tested, and continuously improved. By approaching monitoring as a living system rather than a static setup, you'll build observability that remains relevant and valuable even as your technical setup transforms.

## **Your monitoring checklist: a practical starting point**

Let's build your monitoring strategy based on your application's needs. Start with these foundational steps:

-   **Map key user flows.** Document your critical business transactions and user paths
-   **Monitor core metrics:** Track response times, CPU memory, and errors
-   **Add structured logging:** Use JSON with request IDs for tracing
-   **Set basic monitoring:** Configure uptime checks and user journey tests
-   **Build focused dashboards:** Create views that highlight important metrics
-   **Configure alerts:** Set up notifications that drive action
-   **Review and improve:** Schedule regular checks to refine your setup

## **Observability evolution path**

Let's explore how monitoring evolves to support your needs:

  
**How monitoring flows**

## **Optimize your monitoring pipeline**

Reliable monitoring systems need a few key elements:

-   Use smart sampling to keep data clean without losing important signals
-   Balance traffic loads to capture all critical metrics
-   Index data for quick issue detection
-   Logically structure data to simplify troubleshooting

## **Security**

What you should think about for monitoring data:

-   Filter sensitive data at collection
-   Implement retention policies that match compliance
-   Monitor access patterns throughout the system

## **Key metrics**

Here's what to track to make your systems scale well:

-   **Mean Time to Recovery (MTTR)**: How quickly you bounce back from incidents
-   **Mean Time Between Failures (MTBF)**: Time between system issues - longer is better
-   **Service Level Objectives (SLO)**: Your reliability targets and commitments
-   **Error Budget & Burn Rate**: Acceptable failure threshold and consumption rate

Every small improvement takes you closer to a monitoring system that prevents issues rather than just reacting to them. Build it step by step and watch those late-night alerts become a thing of the past.

### [How Python's updates make it faster and more efficient | Upsun](https://upsun.com/blog/python-performance-improvements/)

# Unlocking Python’s speed: how recent updates are making Python faster

Python, a language loved for its simplicity, has undergone significant performance improvements since version 3.11. It’s impressive to witness how these optimizations are transforming the speed of a 30-year-old language. From specialized, adaptive interpreters to more efficient memory management and the introduction of JIT compilation, Python’s recent versions are evolving rapidly, offering performance gains of ~10%-60% across various workloads.

These changes are making Python not only faster for core functionality but also beneficial for libraries like NumPy and Pandas, making it even more relevant for data-centric applications.

**Read the** **full article here****.**

### [Monetizing FOSS: PaaS solutions for open-source software | Upsun](https://upsun.com/blog/monetizing-foss-paas-solutions-for-open-source-software/)

# Monetizing FOSS: PaaS solutions for open-source software

In today’s software development panorama, there's a philosophy that really stands out and continues to influence the thought processes of numerous creative minds and progressive organizations: Free and Open Source Software (FOSS). FOSS is a champion of collaboration, absolute accessibility, and the freedom to alter, share, and build upon existing software devoid of any licensing impediments. Principles which have been the nurturing grounds for a variety of technological innovations that have now become part and parcel of our lives.

FOSS enables enterprises taking the leap into open source to access a far-reaching community of developers—facilitating the improvement of the software, accelerating innovation, and boosting the credibility of the software. More significantly, organizations can also utilize the open-source approach to establish trust and construct a solid user community. 

However, despite these advantages, one question continually pops up: how do you monetize FOSS offerings effectively? Let’s get into the answer. 

## **Strategies for monetizing open-source solutions**

The good news is there are numerous strategies that can be employed to monetize open-source software, including:

-   Providing paid support, consulting, and training services
-   Rendering additional features, customizations, and integrations as proprietary services
-   Launching premium versions embellished with additional features–commonly referred to as the open-core model
-   Operating a Software-as-a-Service (SaaS) based on the open-source product
-   Offering a Platform-as-a-Service (PaaS) solution premised on the open-source  software

Each of these monetization mechanisms brings to the table its own unique pros and cons—aid support, consultation, and training services arguably being the most straightforward methods for monetizing open-source projects. These services complement the open-source software, offering added value to the users while leaving the software itself freely accessible and open source. Nonetheless, the scalability of this model is inherently restricted as revenue generation is tied to the number of service staff, presenting a potential bottleneck.

On the other hand, the open-core model, proprietary add-ons, and SaaS solutions have evolved as prevalent monetization strategies. They offer users who are willing to pay extra for premium features or convenience, additional value. However, these methods often inadvertently go against the ethos of FOSS. They invariably lead to a divide between free users and paying customers, which might lead to conflicts of interest between maximizing profit and preserving the open-source philosophy. So that leaves us with the PaaS solution.

## **PaaS: maintaining integrity and growth while monetizing**

Platforms-as-a-Service emerge as a strong method to monetize open-source software without infringing on its philosophical principles. This model enables developers to harness the capabilities of open-source software within a hosted environment, avoiding the intricacies of infrastructure management. Here, the core software remains free and accessible to all, while the revenues stem from the platform service and not by curbing access to any specific features or functionalities—it’s a win-win. 

In offering a PaaS, an organization can effectively monetize its software whilst retaining its commitment to the FOSS philosophy. They can do so by providing value-added services such as scalability, availability, security, and the convenience of a modern platform solution that usually offers more than just hosting. Including an array of other services that have become central to the practices of modern development teams, such as CI/CD, container-based systems, orchestration, autoscaling, and more. 

### **Upsun: the ideal PaaS for open-source software**

Among the various PaaS providers, Upsun distinguishes itself as the optimum solution, thanks to its compatibility with various open-source technologies and languages. Along with its unwavering commitment to cultivating an environment conducive to open-source projects.

Upsun provides businesses with a comprehensive feature set meticulously designed to cater to the needs of diverse open-source projects. Providing an end-to-end workflow encompassing development, testing, deployment, and hosting. The robust platform automates infrastructure management, enabling developers to focus solely on coding while ensuring high levels of reliability, security, and scalability for their applications.

Emphasizing the principles of Infrastructure-as-Code, Upsun enables developers to replicate production-like environments, thereby fostering seamless continuity between development, testing, and production phases. In a bid to uphold the highest security standards, Upsun affords strict isolation of applications and data, along with automated patch management, reducing the possibility of security vulnerabilities. While compliance enforcement—including GDPR, SOC 2 Type 2, and PCI DSS Level 1—adds a further layer of reassurance for businesses managing sensitive data.

A unique feature of Upsun, which strikes a chord with the open-source community, is its environment cloning ability. This ingenious feature enables developers to replicate their entire application stack–inclusive of data–facilitating testing of alterations without jeopardizing the production system. This fosters a culture of unhesitant innovation and swift iteration–fundamental aspects of open-source software development.

### **The Upsun OEM programme**

So how can Upsun facilitate monetization for organizations looking to use the PaaS model? Platform.sh has had an impressive OEM program for years now,  and an equivalent program for Upsun is currently in the works. 

The scheme allows businesses to easily and quickly provide their open-source software through a PaaS solution. This ability fosters a closer, service-focused relationship with customers and offers an efficient method for monetizing open-source software.

So, by using Upsun, businesses can maintain their strong dedication to the FOSS philosophy while establishing a sustainable and profitable model for their open-source software. Offering the perfect balance between open-source principles and creative business models–securing its place as the go-to PaaS for open-source software.

Whether you are an open-source project endeavoring to monetize without diluting your commitment to FOSS principles, or an established software company aiming to expedite your time-to-market Upsun is ready to help. Start your free trial.

### Useful links

-   Django Girls: community, python, and open source
-   Exploring DDEV, open source, and DevOps with Randy Fay

## Event Pages

### [Breakfast round-table: The Sustainable Edge: How AI Startups Win VC Funding | Side event of France AI Action Summit 2025 ](https://upsun.com/sustainable-edge-ai-action-summit-2025/)

A special thank you to our esteemed panelists, partners, and attendees for joining us to discuss the competitive advantage of sustainability in the AI industry. 

Watch the full replay to learn from our expert panel.

Thank you for joining us at “The sustainable edge: building VC-ready AI companies”

Breakfast round-table: The Sustainable Edge: How AI Startups Win VC Funding | Side event of France AI Action Summit 2025

Join top VCs and AI founders at France AI Action Summit 2025's exclusive breakfast to learn how sustainability drives competitive advantage and attracts investment in the AI ecosystem. An official side event of the French AI Action Summit 2025.

Join us

Nessrine Berrama

## CEO

dotConferences

A series of global tech events in Paris

Anaïs Blarel

## Sustainability Manager

Revaia

Leading European sustainable growth investor

Réza Malekzadeh

## General Partner

Partech

Global tech investment firm

JB Rudelle

## Co-founder and ex-CEO

Criteo

The advertising platform for the open Internet

Guillaume Moigneu

## VP Product Advocacy

Platform.sh

A multi-cloud Platform-as-a-Service

Robert Vesoul

## CEO and Co-founder

ILLUIN Technology

Cutting-edge AI solutions for business transformation

france-ai-paris-2025

Round table

Thank you

Thank you to our partners

An official side event of France AI Action Summit 2025

## Thank you to our partners

- AI Action Summit
- dotConferences
- Digital Village

## Livestreams

### [Load testing for Black Friday success | Platform.sh](https://upsun.com/live-stream-2)

Load testing for Black Friday success

-   Discover how to stress test your platform effectively 
-   Scale like a pro with real-world strategies and tools for scaling your application

Greg Qualls and Thomas di Luccio

Load testing for Black Friday success | Platform.sh

Uncover essential strategies to ensure your platform can handle peak traffic during Black Friday.

### [Vibe coding: the future of dev—or a fast track to tech debt?](https://upsun.com/vibe-coding-the-future)

Vibe coding: the future of dev—or a fast track to tech debt?

Everyone’s talking about vibe coding—coding by feel, skipping the boilerplate, and trusting your flow. Is it a breakthrough for creative development, or just chaos in disguise? Join us live as we dig into the hype, the backlash, and what it really means for the way we build software now.

Hosted by Greg Qualls and Guillaume Moigneu

### [WordPress showdown livestream | Upsun ](https://upsun.com/upsun-live-wordpress-showdown)

WordPress showdown: vanilla vs. Composer vs. Bedrock

What's the best WordPress method? Traditional (aka “Vanilla”), Composer-based, or the Bedrock framework? We explore them all to help you choose the best fit for your projects.

With Greg Qualls and Paul Gilzow

WordPress showdown livestream | Upsun

Explore the best WordPress method, from traditional (aka “Vanilla”), Composer-based approach, and the Bedrock framework to help you choose the best fit for your projects.

## Landing Pages

### [Deploy Site Updates And Quickly Scale | Upsun](https://upsun.com/manage-traffic-surges/)

Deploy site updates + quickly scale specific bottlenecked containers in your application to manage traffic surges. Shoppers are no match for a multitasker.

Suddenly, Black Friday is like any other day

## Flexible developer experience

-   On-demand preview environments that clone prod byte-for-byte—including data and services
-   Automated infrastructure provisioning via declarative YAML templates
-   Provider- and stack-agnostic

## Team empowerment

-   Built-in observability to monitor every component of your applications, gain insights, and optimize performance
-   Resource and user control at both project and organizational levels, per application, per environment
-   Live preview environments to accelerate stakeholder approvals, speed QA, and launch on schedule.

## Trusted, reliable platform

-   Stable, secure, fully managed infrastructure to increase application reliability, w/24x7 global support
-   Full-control horizontal scaling
-   Container-based vertical scaling
-   Git-driven architecture helps ensure every change to your infrastructure configuration is versioned, auditable, and reversible

"Anyone who has some level of knowledge about DevOps concepts and YAML syntax can get started with Upsun; it’s a fairly easy product for the amount of complexity it can handle. That’s the magic." —Lukas Kahwe Smith, CTO and Co-founder, Witty Works

## Meet Upsun

A PaaS that automates DevOps tasks, so developers can focus on coding and problem-solving.

## Trusted by developers, day in and day out

A bright, new offering powered by Platform.sh—adopted (and ❤️) by 17,000+ developers, 7,000 customers, and proven over the last 8 years—Upsun provides out-of-the-box capabilities that serve as the launchpad for creative development teams’ out-of-the-box thinking. To us, it sounds like a perfect pairing.

Deploy Site Updates And Quickly Scale | Upsun

Deploy site updates and quickly scale specific bottlenecked containers in your application to manage traffic surges.

### [Automate Repetitive DevOps Tasks | Upsun](https://upsun.com/automate-repetitive-devops-tasks/)

Upsun automates repetitive DevOps tasks, so you can focus on coding and problem-solving while your infrastructure counterparts are freed to scale in all dimensions. Friday at 4:00, you’re all out the door.

Leave DevOps tasks in your rearview mirror

## Flexible developer experience

-   On-demand preview environments that clone prod byte-for-byte—including data and services
-   Automated infrastructure provisioning via declarative YAML templates
-   Provider- and stack-agnostic

## Team empowerment

-   Built-in observability to monitor every component of your applications, gain insights, and optimize performance
-   Resource and user control at both project and organizational levels, per application, per environment
-   Live preview environments to accelerate stakeholder approvals, speed QA, and launch on schedule.

## Trusted, reliable platform

-   Stable, secure, fully managed infrastructure to increase application reliability, w/24x7 global support
-   Full-control horizontal scaling
-   Container-based vertical scaling
-   Git-driven architecture helps ensure every change to your infrastructure configuration is versioned, auditable, and reversible

"Anyone who has some level of knowledge about DevOps concepts and YAML syntax can get started with Upsun; it’s a fairly easy product for the amount of complexity it can handle. That’s the magic." —Lukas Kahwe Smith, CTO and Co-founder, Witty Works

## Meet Upsun

A PaaS that automates DevOps tasks, so developers can focus on coding and problem-solving.

## Trusted by developers, day in and day out

A bright, new offering powered by Platform.sh—adopted (and ❤️) by 17,000+ developers, 7,000 customers, and proven over the last 8 years—Upsun provides out-of-the-box capabilities that serve as the launchpad for creative development teams’ out-of-the-box thinking. To us, it sounds like a perfect pairing.

Automate Repetitive DevOps Tasks | Upsun

Upsun automates repetitive DevOps tasks, so you can focus on coding and problem-solving.

### [You deliver the code, we handle the complexities of Platform Engineering | Upsun](https://upsun.com/platform-engineering-solution/)

-   Build, run and scale multiple apps on a single platform
-   Manage your infrastructure seamlessly
-   Host on the tech stacks or cloud providers of your choice
-   Deliver on a secure, enterprise grade platform

You deliver the code, we handle the complexities of platform engineering

You deliver the code, we handle the complexities of Platform Engineering | Upsun

The end-to-end platform as a service (PaaS) for cloud hosting, development, and deployment.

## Trusted by 5000+ organizations

- Adobe
- Pinterest
- J&J
- A+E
- Oris
- The Economist

## Infrastructure taken care of

Platform engineering and Upsun alleviate the pressure of infrastructure management on your team and utilize the power of the cloud to keep your applications running smoothly by taking care of it all for you. Easy.

## Tech updates? We got them

We strive to release the latest versions of all your preferred languages, frameworks, services, and runtimes as soon as possible, so you can easily upgrade and use them from day one with a git push. And with more than 100 frameworks and 14 programming languages available on our platform - the choice is yours.

## Onboard your team faster

With Upsun, application development has never been simpler. It takes just a few minutes to clone your production site and grant access to newly created environments. Our Git-based system makes it quick and simple to learn and adapt - everything is ready with a simple git push.

## Protect your data and be compliant

From GDPR to HIPAA to cybersecurity, it’s challenging to keep up with the latest regulations and security measures—but this doesn’t have to be your job. Leave it to us. You and your team can rest assured knowing that we prioritize privacy and security by ensuring we meet the highest compliance certifications and standards.

Why choose Upsun?

### 25% Reduction in deployment and maintenance time

### 10% Savings on cloud infrastructure costs

### 40% Reduction in app testing time

Get feedback faster. Deliver new features sooner.

### [Power your Magento build with confidence | Upsun](https://upsun.com/magento-platform/)

We guide you end-to-end, from strategy and development through deployment to ongoing support. So, your Magento platform delivers faster launches, rock-solid performance, and seamless scalability, empowering your team to focus on driving revenue and delighting customers.

-   Zero-downtime Magento migrations
-   24/7 comprehensive SLA-backed support
-   Effortless auto-scaling for traffic fluctuations

Power your next Magento build with total confidence

## Complex Magento projects demand specialized expertise

Migrating to Magento, maintaining its performance, or launching new digital campaigns isn't straightforward. It requires a deep understanding of Magento's architecture, seamless integration capabilities, and the ability to scale efficiently, all without disrupting existing operations.​

## Inadequate implementation puts your revenue at risk

When your Magento platform goes down or can't handle peak traffic. Whether it's Black Friday, a major product launch or a flash sale, you lose sales by the minute, frustrate loyal customers and tarnish your brand's reputation. Behind the scenes, your team scrambles to fix urgent outages and performance bottlenecks, burning time and resources that should be driving innovation and growth.

## Your full-service Magento partner

As the team behind Adobe Commerce Cloud, Platform.sh delivers end-to-end Magento mastery, cloud automation and 24/7 SLA-backed support all in one place. From complex migrations and custom feature builds to handling peak traffic, we ensure your site remains fast, secure, and compliant. So you can focus on growth and revenue without worrying about infrastructure.

"Moving to Upsun has transformed our operations. Our team now has the flexibility and autonomy to manage deployments efficiently without worrying about service interruptions. The partnership with Upsun and Dn'D ensured a smooth migration under tight constraints, and we now have the peace of mind knowing our platform is stable and scalable." —Isabelle Sarrazin, General Manager, EasyPara

Power your Magento build with confidence | Upsun

Guided end-to-end Magento strategy, development, deployment and support for faster launches, rock-solid performance and seamless scalability

## Trusted by organizations and development teams worldwide

- Adobe
- Pinterest
- The Economist
- Orange
- Havas
- Randstand
- Suzuki

## Seamless migration to Magento

Accelerate complex re-platforming projects with zero downtime, data integrity you can trust and a roadmap aligned to your business goals.

## Reliable Magento application support

Maintain peak performance and security in high-traffic environments with SLA-backed support and proactive monitoring.

## Campaign-ready Magento deployments

Launch new features and seasonal campaigns on schedule, backed by expert guidance to meet tight deadlines and deliver engaging eCommerce experiences.

Magento experts for every critical project

### [Build an instant clone environment in seconds. | Upsun](https://upsun.com/production-environment-cloning/)

Build an instant clone environment—including databases, files, and all your services. In seconds.

Real applications use real data

## Deploy confidently by cloning real data

-   Quickly shine a light on bugs that might not be visible with simplified or synthetic data.
-   Reduce the chances of post-deployment issues and downtime, ensuring smoother releases.
-   Measure/optimize application performance under conditions that closely mirror real production loads to improve resource management and user experience.

## Clone more than just the frontend

-   Clone an entire production environment, with multiple applications—all code, files, critical data, and services.
-   Easily synchronize your environments to get the latest and freshest data from production.
-   Improve disaster recovery—and eliminate stress—with fully instant, restorable snapshots.

## Rapidly replicate, deploy, and reap value

-   Exact replicas of production environments in seconds.
-   Each contributor can work in their own isolated environment, eliminating conflicts and enabling parallel development.
-   Accelerate the development cycle, expedite approvals, and speed the QA process by sharing preview environments that contain real data with stakeholders.

"[Our digital agency] can easily spin up a new branch of the site in just minutes, while cloning the entire content of the production server, merged with the new code. This is an incredible time-saver, and also means fewer errors." —Verified user in Events Services, G2 Review

## A game-changer for developing cloud-based applications

See our unique approach to cloning from a running production application in action.

## Trusted by developers, day in and day out

A bright, new offering powered by Platform.sh—adopted (and ❤️) by 17,000+ developers, 7,000 customers, and proven over the last 8 years—Upsun provides out-of-the-box capabilities that serve as the launchpad for creative development teams’ out-of-the-box thinking. To us, it sounds like a perfect pairing.

Build an instant clone environment in seconds. | Upsun

Clone an entire production environment, with multiple applications—all code, files, critical data, and services.

### [Deliver Symfony apps at scale | Upsun](https://upsun.com/symfony-apps/)

Automatically deploy to production with your current Git workflows. You’re chill. 🍦

Quickly deliver and scale your Symfony apps

## Flexible developer experience

-   On-demand preview environments that clone prod byte-for-byte—including data and services
-   Automated infrastructure provisioning via declarative YAML templates
-   Provider- and stack-agnostic

## Team empowerment

-   Built-in observability to monitor every component of your applications, gain insights, and optimize performance
-   Resource and user control at both project and organizational levels, per application, per environment
-   Live preview environments to accelerate stakeholder approvals, speed QA, and launch on schedule.

## Trusted, reliable platform

-   Stable, secure, fully managed infrastructure to increase application reliability, w/24x7 global support
-   Full-control horizontal scaling
-   Container-based vertical scaling
-   Git-driven architecture helps ensure every change to your infrastructure configuration is versioned, auditable, and reversible

"Anyone who has some level of knowledge about DevOps concepts and YAML syntax can get started with Upsun; it’s a fairly easy product for the amount of complexity it can handle. That’s the magic." —Lukas Kahwe Smith, CTO and Co-founder, Witty Works

## Meet Upsun

A PaaS that automates DevOps tasks, so developers can focus on coding and problem-solving.

## Trusted by developers, day in and day out

A bright, new offering powered by Platform.sh—adopted (and ❤️) by 17,000+ developers, 7,000 customers, and proven over the last 8 years—Upsun provides out-of-the-box capabilities that serve as the launchpad for creative development teams’ out-of-the-box thinking. To us, it sounds like a perfect pairing.

Deliver Symfony apps at scale | Upsun

Automatically deploy to production with your current Git workflows to deliver updates and new features faster

### [Clone Preview Environments From Prod In Seconds | Upsun](https://upsun.com/clone-preview-environments-from-prod/)

Preview environments that mirror production give you (and stakeholders) visibility to builds, so you can provide feedback, accelerate approvals, and launch projects on schedule. All is right with your world.

Put post-deployment _firedrills_ in the past

## Trusted, reliable platform

Upsun's stable, secure, fully managed infrastructure frees your team to focus on coding applications. Improves application reliability and uptime. And scales in every direction to meet traffic fluctuation. All to keep your applications running smoothly.

## Flexible developer experience

Automated infrastructure provisioning and integration with your current tech stack help your team gain efficiencies and more effectively deliver business results while reducing operating costs.

## Team empowerment

Empower your teams to improve your applications on all levels by enabling them to cost-effectively manage resources. Tighten collaboration. Confidently make decisions. And optimize application performance.

"As the CTO of a still-small startup, my time is limited…With Upsun, we can focus our time and budget on our core technology rather than on DevOps. I’ve always said that Platform.sh was kind of the perfect tool for agencies; I think Upsun is kind of the perfect tool for early-stage startups." —Lukas Kahwe Smith, CTO and Co-founder, Witty Works

## Meet Upsun

A PaaS that automates DevOps tasks, so developers can focus on coding and problem-solving.

## Trusted by developers, day in and day out

A bright, new offering powered by Platform.sh—adopted (and ❤️) by 17,000+ developers, 7,000 customers, and proven over the last 8 years—Upsun provides out-of-the-box capabilities that serve as the launchpad for creative development teams’ out-of-the-box thinking. To us, it sounds like a perfect pairing.

Clone Preview Environments From Prod In Seconds | Upsun

Preview environments that mirror production give you visibility to builds. Launch projects on schedule.

### [Deliver Updates And New Features Faster | Upsun.](https://upsun.com/deliver-faster/)

Devs can automatically deploy to production with familiar Git workflows to get projects out the door faster. Stakeholder scoping miscalculations? No worries.

Deliver updates _+ new features faster_

## Trusted, reliable platform

Upsun's stable, secure, fully managed infrastructure frees your team to focus on coding applications. Improves application reliability and uptime. And scales in every direction to meet traffic fluctuation. All to keep your applications running smoothly.

## Flexible developer experience

Automated infrastructure provisioning and integration with your current tech stack help your team gain efficiencies and more effectively deliver business results while reducing operating costs.

## Team empowerment

Empower your teams to improve your applications on all levels by enabling them to cost-effectively manage resources. Tighten collaboration. Confidently make decisions. And optimize application performance.

"As the CTO of a still-small startup, my time is limited…With Upsun, we can focus our time and budget on our core technology rather than on DevOps. I’ve always said that Platform.sh was kind of the perfect tool for agencies; I think Upsun is kind of the perfect tool for early-stage startups." —Lukas Kahwe Smith, CTO and Co-founder, Witty Works

## Meet Upsun

A PaaS that automates DevOps tasks, so developers can focus on coding and problem-solving.

## Trusted by developers, day in and day out

A bright, new offering powered by Platform.sh—adopted (and ❤️) by 17,000+ developers, 7,000 customers, and proven over the last 8 years—Upsun provides out-of-the-box capabilities that serve as the launchpad for creative development teams’ out-of-the-box thinking. To us, it sounds like a perfect pairing.

Deliver Updates And New Features Faster | Upsun.

Automatically deploy to production with familiar Git workflows. Deliver updates and new features faster.

### [Deliver Node.js apps at scale | Upsun](https://upsun.com/nodejs-apps/)

Automatically deploy to production with your current Git workflows. You’re chill. 🍦

Quickly deliver and scale your Node.js apps

## Flexible developer experience

-   On-demand preview environments that clone prod byte-for-byte—including data and services
-   Automated infrastructure provisioning via declarative YAML templates
-   Provider- and stack-agnostic

## Team empowerment

-   Built-in observability to monitor every component of your applications, gain insights, and optimize performance
-   Resource and user control at both project and organizational levels, per application, per environment
-   Live preview environments to accelerate stakeholder approvals, speed QA, and launch on schedule.

## Trusted, reliable platform

-   Stable, secure, fully managed infrastructure to increase application reliability, w/24x7 global support
-   Full-control horizontal scaling
-   Container-based vertical scaling
-   Git-driven architecture helps ensure every change to your infrastructure configuration is versioned, auditable, and reversible

"Anyone who has some level of knowledge about DevOps concepts and YAML syntax can get started with Upsun; it’s a fairly easy product for the amount of complexity it can handle. That’s the magic." —Lukas Kahwe Smith, CTO and Co-founder, Witty Works

## Meet Upsun

A PaaS that automates DevOps tasks, so developers can focus on coding and problem-solving.

## Trusted by developers, day in and day out

A bright, new offering powered by Platform.sh—adopted (and ❤️) by 17,000+ developers, 7,000 customers, and proven over the last 8 years—Upsun provides out-of-the-box capabilities that serve as the launchpad for creative development teams’ out-of-the-box thinking. To us, it sounds like a perfect pairing.

Deliver Node.js apps at scale | Upsun

Automatically deploy to production with your current Git workflows to deliver updates and new features faster

### [Deliver Django apps at scale | Upsun](https://upsun.com/django-apps/)

Automatically deploy to production with your current Git workflows. You’re chill. 🍦

Quickly deliver and scale your Django apps

## Flexible developer experience

-   On-demand preview environments that clone prod byte-for-byte—including data and services
-   Automated infrastructure provisioning via declarative YAML templates
-   Provider- and stack-agnostic

## Team empowerment

-   Built-in observability to monitor every component of your applications, gain insights, and optimize performance
-   Resource and user control at both project and organizational levels, per application, per environment
-   Live preview environments to accelerate stakeholder approvals, speed QA, and launch on schedule.

## Trusted, reliable platform

-   Stable, secure, fully managed infrastructure to increase application reliability, w/24x7 global support
-   Full-control horizontal scaling
-   Container-based vertical scaling
-   Git-driven architecture helps ensure every change to your infrastructure configuration is versioned, auditable, and reversible

"Anyone who has some level of knowledge about DevOps concepts and YAML syntax can get started with Upsun; it’s a fairly easy product for the amount of complexity it can handle. That’s the magic." —Lukas Kahwe Smith, CTO and Co-founder, Witty Works

## Meet Upsun

A PaaS that automates DevOps tasks, so developers can focus on coding and problem-solving.

## Trusted by developers, day in and day out

A bright, new offering powered by Platform.sh—adopted (and ❤️) by 17,000+ developers, 7,000 customers, and proven over the last 8 years—Upsun provides out-of-the-box capabilities that serve as the launchpad for creative development teams’ out-of-the-box thinking. To us, it sounds like a perfect pairing.

Deliver Django apps at scale | Upsun

Automatically deploy to production with your current Git workflows to deliver updates and new features faster

### [The single, secure, multicloud PaaS | Upsun](https://upsun.com/multicloud-paas/)

Whether you’re on Amazon Web Services, Google Cloud Platform, Microsoft Azure, Orange, or OVHcloud, you can accelerate development and delivery by running the exact same code—without making any changes.

-   High performance container based on multicloud hosting
-   Built for more than 70 languages and frameworks
-   Free development environments for 30 days, then starts at $12 per month

Choose the _best solution_ to deliver your applications at scale

## DevOps steals dev teams’ time.

Provisioning. Packaging. Deploying. Testing. Code monitoring. Scaling. Operations. Security. Compliance. Access control. Managing application infrastructure is complex and time-consuming.

## Tired of endless DevOps issues and tasks?

We’ve all been there. Trying to deliver high-quality customer experiences while reducing tickets—from bug issues to stack and security updates—can often feel like an impossible task. Not to mention keeping costs down, performance strong, and making space for new technologies, innovations, and testing to stay ahead of the curve.

## Fully-managed cloud infrastructure

More Dev. Less Ops. With Upsun, efficiently build, iterate, and deploy applications while we manage cloud infrastructure, data services, and security. Built for developers, by developers, our PaaS gives you control and peace of mind while accelerating the time it takes to build and deploy your applications.

"“Our Upsun environment easily and automatically scales out to meet the demands of the incoming web traffic, and it’s triple-redundant to protect us against hardware failures.”" —Saaed Fattahi, Director of Technology, SportRx

The single, secure, multicloud PaaS | Upsun

Select the IaaS platform—either by geography or cloud provider—that best supports your organization’s needs and deliver your applications faster at scale

## Trusted by 5000+ organizations

- Adobe
- Pinterest
- J&J
- A+E
- Oris
- The Economist

## Automate repetitive DevOps tasks

Focus on high-value contributions (like coding and process optimization) that quickly deliver business results and lower operating costs by automating DevOps tasks with our PaaS.

## Built-in security and compliance

Reduce pressure on IT and security teams and on governance with high-levels of built-in security and compliance (e.g., SOC-2, PCI-DSS)—fully automated and managed by Upsun.

## Optimized code performance

By proactively providing relevant insights to optimize code—and the ability to select your data center region—you can improve performance and reduce your carbon footprint.

Deliver applications faster at scale

### [A Fully Managed Infrastructure To Free Your Team | Upsun](https://upsun.com/free-your-dev-team/)

A fully managed infrastructure, a single set of dev tools, and integration with your current tech stack frees your team to focus on code. Optimal use of resources, faster time to results, more money in the departmental piggy bank. Hero status. 🐷 💰

Free devs to do _what they do best_

## Trusted, reliable platform

Upsun's stable, secure, fully managed infrastructure frees your team to focus on coding applications. Improves application reliability and uptime. And scales in every direction to meet traffic fluctuation. All to keep your applications running smoothly.

## Flexible developer experience

Automated infrastructure provisioning and integration with your current tech stack help your team gain efficiencies and more effectively deliver business results while reducing operating costs.

## Team empowerment

Empower your teams to improve your applications on all levels by enabling them to cost-effectively manage resources. Tighten collaboration. Confidently make decisions. And optimize application performance.

"As the CTO of a still-small startup, my time is limited…With Upsun, we can focus our time and budget on our core technology rather than on DevOps. I’ve always said that Platform.sh was kind of the perfect tool for agencies; I think Upsun is kind of the perfect tool for early-stage startups." —Lukas Kahwe Smith, CTO and Co-founder, Witty Works

## Meet Upsun

A PaaS that automates DevOps tasks, so developers can focus on coding and problem-solving.

## Trusted by developers, day in and day out

A bright, new offering powered by Platform.sh—adopted (and ❤️) by 17,000+ developers, 7,000 customers, and proven over the last 8 years—Upsun provides out-of-the-box capabilities that serve as the launchpad for creative development teams’ out-of-the-box thinking. To us, it sounds like a perfect pairing.

A Fully Managed Infrastructure To Free Your Team | Upsun

A fully managed infrastructure that integrates with your current tech stack frees your team to focus on code.

### [Deliver Flask apps at scale | Upsun](https://upsun.com/flask-apps/)

Automatically deploy to production with your current Git workflows. You’re chill. 🍦

Quickly deliver and scale your Flask apps

## Flexible developer experience

-   On-demand preview environments that clone prod byte-for-byte—including data and services
-   Automated infrastructure provisioning via declarative YAML templates
-   Provider- and stack-agnostic

## Team empowerment

-   Built-in observability to monitor every component of your applications, gain insights, and optimize performance
-   Resource and user control at both project and organizational levels, per application, per environment
-   Live preview environments to accelerate stakeholder approvals, speed QA, and launch on schedule.

## Trusted, reliable platform

-   Stable, secure, fully managed infrastructure to increase application reliability, w/24x7 global support
-   Full-control horizontal scaling
-   Container-based vertical scaling
-   Git-driven architecture helps ensure every change to your infrastructure configuration is versioned, auditable, and reversible

"Anyone who has some level of knowledge about DevOps concepts and YAML syntax can get started with Upsun; it’s a fairly easy product for the amount of complexity it can handle. That’s the magic." —Lukas Kahwe Smith, CTO and Co-founder, Witty Works

## Meet Upsun

A PaaS that automates DevOps tasks, so developers can focus on coding and problem-solving.

## Trusted by developers, day in and day out

A bright, new offering powered by Platform.sh—adopted (and ❤️) by 17,000+ developers, 7,000 customers, and proven over the last 8 years—Upsun provides out-of-the-box capabilities that serve as the launchpad for creative development teams’ out-of-the-box thinking. To us, it sounds like a perfect pairing.

Deliver Flask apps at scale | Upsun

Automatically deploy to production with your current Git workflows to deliver updates and new features faster

### [Iterate, Merge, Sync, And Ship Anytime | Upsun](https://upsun.com/iterate-merge-sync/)

Leave big releases in the past. No more post-release debugging. No sweat.

Iterate, merge, sync, and ship as often as _you_ want to

## Flexible developer experience

-   On-demand preview environments that clone prod byte-for-byte—including data and services
-   Automated infrastructure provisioning via declarative YAML templates
-   Provider- and stack-agnostic

## Team empowerment

-   Built-in observability to monitor every component of your applications, gain insights, and optimize performance
-   Resource and user control at both project and organizational levels, per application, per environment
-   Live preview environments to accelerate stakeholder approvals, speed QA, and launch on schedule.

## Trusted, reliable platform

-   Stable, secure, fully managed infrastructure to increase application reliability, w/24x7 global support
-   Full-control horizontal scaling
-   Container-based vertical scaling
-   Git-driven architecture helps ensure every change to your infrastructure configuration is versioned, auditable, and reversible

"Anyone who has some level of knowledge about DevOps concepts and YAML syntax can get started with Upsun; it’s a fairly easy product for the amount of complexity it can handle. That’s the magic." —Lukas Kahwe Smith, CTO and Co-founder, Witty Works

## Meet Upsun

A PaaS that automates DevOps tasks, so developers can focus on coding and problem-solving.

## Trusted by developers, day in and day out

A bright, new offering powered by Platform.sh—adopted (and ❤️) by 17,000+ developers, 7,000 customers, and proven over the last 8 years—Upsun provides out-of-the-box capabilities that serve as the launchpad for creative development teams’ out-of-the-box thinking. To us, it sounds like a perfect pairing.

Iterate, Merge, Sync, And Ship Anytime | Upsun

Leave big releases in the past: iterate, merge, sync, and ship as often as you want to.

### [Deliver Laravel apps at scale | Upsun](https://upsun.com/laravel-apps/)

Automatically deploy to production with your current Git workflows. You’re chill. 🍦

Quickly deliver and scale your Laravel apps

## Flexible developer experience

-   On-demand preview environments that clone prod byte-for-byte—including data and services
-   Automated infrastructure provisioning via declarative YAML templates
-   Provider- and stack-agnostic

## Team empowerment

-   Built-in observability to monitor every component of your applications, gain insights, and optimize performance
-   Resource and user control at both project and organizational levels, per application, per environment
-   Live preview environments to accelerate stakeholder approvals, speed QA, and launch on schedule.

## Trusted, reliable platform

-   Stable, secure, fully managed infrastructure to increase application reliability, w/24x7 global support
-   Full-control horizontal scaling
-   Container-based vertical scaling
-   Git-driven architecture helps ensure every change to your infrastructure configuration is versioned, auditable, and reversible

"Anyone who has some level of knowledge about DevOps concepts and YAML syntax can get started with Upsun; it’s a fairly easy product for the amount of complexity it can handle. That’s the magic." —Lukas Kahwe Smith, CTO and Co-founder, Witty Works

## Meet Upsun

A PaaS that automates DevOps tasks, so developers can focus on coding and problem-solving.

## Trusted by developers, day in and day out

A bright, new offering powered by Platform.sh—adopted (and ❤️) by 17,000+ developers, 7,000 customers, and proven over the last 8 years—Upsun provides out-of-the-box capabilities that serve as the launchpad for creative development teams’ out-of-the-box thinking. To us, it sounds like a perfect pairing.

Deliver Laravel apps at scale | Upsun

Automatically deploy to production with your current Git workflows to deliver updates and new features faster

### [Observability To Optimize Performance | Upsun](https://upsun.com/make-data-driven-decisions/)

Observability on every level provides insights into your application’s behavior. So developers can continuously enhance your systems to optimize performance/efficiencies—success metrics you can share with management and stakeholders. Good job.

Now devs can make data-driven decisions

## Trusted, reliable platform

Upsun's stable, secure, fully managed infrastructure frees your team to focus on coding applications. Improves application reliability and uptime. And scales in every direction to meet traffic fluctuation. All to keep your applications running smoothly.

## Flexible developer experience

Automated infrastructure provisioning and integration with your current tech stack help your team gain efficiencies and more effectively deliver business results while reducing operating costs.

## Team empowerment

Empower your teams to improve your applications on all levels by enabling them to cost-effectively manage resources. Tighten collaboration. Confidently make decisions. And optimize application performance.

"As the CTO of a still-small startup, my time is limited…With Upsun, we can focus our time and budget on our core technology rather than on DevOps. I’ve always said that Platform.sh was kind of the perfect tool for agencies; I think Upsun is kind of the perfect tool for early-stage startups." —Lukas Kahwe Smith, CTO and Co-founder, Witty Works

## Meet Upsun

A PaaS that automates DevOps tasks, so developers can focus on coding and problem-solving.

## Trusted by developers, day in and day out

A bright, new offering powered by Platform.sh—adopted (and ❤️) by 17,000+ developers, 7,000 customers, and proven over the last 8 years—Upsun provides out-of-the-box capabilities that serve as the launchpad for creative development teams’ out-of-the-box thinking. To us, it sounds like a perfect pairing.

Observability To Optimize Performance | Upsun

Observability on every level provides insights into your application’s behavior. Make data-driven decisions.

## Contact

### [Contact us | Upsun](https://upsun.com/contact-us)

# Talk with our team

You have goals. We're here to help you achieve them.

- Custom solutions. Tailored to fit your requirements
- Startup + volume programs. Exclusive pricing/savings
- Reseller programs. Designed to drive business

"Upsun is a fairly easy product for the amount of complexity it can handle. That’s the magic." —Lukas Kahwe Smith, CTO and Co-founder, Witty Works

Contact us | Upsun

Discover if Upsun is right for your organization. Contact us about product capabilities, demos, pricing, project sizing, and more.

## Locations

Through its wholly owned subsidiaries, Upsun operates in the countries listed below.

### 🇦🇺 Barton, Australia

Platform.sh Pty Ltd trading as Upsun
  
The Realm Level 1, 18 National Circuit,  
Barton, ACT 2600, Australia

### 🇬🇧 Bristol, UK

Platform.sh Limited trading as Upsun  

2 Maules Gardens, Stoke Gifford,  
Bristol BS34 8AN, UK

### 🇺🇸 Brooklyn, USA

Platform.sh, Inc. doing business as Upsun  

106 S Main St Ste 4 Brooklyn,  
MI 49230, USA

### 🇫🇷 Paris, France

Platform.sh SAS
  
22 rue de Palestro  
75002 Paris France  

+33 (0) 1 40 09 30 00

### 🇩🇪 Köln, Germany

Platform.sh GmbH doing business as Upsun  

Koblenzer Str. 11, 50968 Köln, Germany

### 🇪🇸 Madrid, Spain

Platform.sh PAAS SP, SL doing business as Upsun
  
Calle de Serrano 90, 28006 Madrid, Spain

### 🇨🇦 Vancouver, Canada

Platform.sh Canada Sub, Ltd. doing business as Upsun Canada Sub
  
Waterfront Centre, 200 Burrard Street,  
Suite 1200, PO Box 48600
  
BC V7X 1T2, Canada

## Agency — Hosting Partner

### [(untitled)](https://upsun.com/agency-hosting-partner/)

Trade server patches for client demos. Upsun’s ISO-27001 platform deploys in under 60 seconds and pays recurring revenue back to your agency, plus co-marketing, Slack access, and priority support.

## 215+ agency partners

- Atwix
- Forix
- ImageX
- Aten Design Group
- 21Torr
- Digital Garden
- Dn'D

Convert infrastructure into profit

## Gain visibility

Appear in [Partner Locator](/partner-locator), secure co-marketing opportunities, and access Market Development Funds for growth campaigns.

## Tap solution architects

Work alongside technical experts on enterprise requirements. Navigate ISO 27001 and SOC 2 compliance for major client deals. Join a private Slack workspace with our architects and 200+ peer agencies—swap plays, surface issues in real time.

## Secure partner pricing

Build recurring revenue streams through exclusive margins on our agency hosting platform. Benefit from warm referrals and dedicated account management.

## Master migrations

Offer expert-guided transitions from WordPress, Drupal, and Magento platforms with comprehensive training and dedicated tooling.

Agency advantages

## Margin multiplier

Transform infrastructure costs into recurring revenue streams. No new tooling to learn; same Git push, better margins.

## Instant client wow

Deploy complete environments per branch in under 60 seconds. Craft the right solutions and launch them quickly for every client.

## No-drama DevOps

End urgent server alerts and performance firefighting. Auto-scale traffic surges with zero manual tuning required.

"Having sites unified on one platform helps new developers get up and running sooner. Moving to Upsun was one of our best decisions."
– Stella Power,Managing Director, Annertech

"Upsun enables our team to craft the right solutions for clients and launch them quickly."
– Jesse Day,Director of Technical Solutions, Adapt

"I only worry about the code. I commit to Git and it works. I can share the URL while making a cup of tea."
– Gareth Bryan,Lead Developer, Five Mile Media

### 1 Connect
Book a short call with a partner manager. Walk us through your stack and goals, and together we'll sketch the right plan.

### 2 Activate
Day one: live workshops, migration help, and a ready-made marketing kit. Most partners launch their first client site inside two weeks.

### 3 Grow
Once you're humming, we team up on bigger deals, share recurring revenue, and help you keep clients for the long haul. Quarterly strategy reviews make sure the roadmap—and revenue—scale on both sides.

How it works

Your partnership growth path

## Registered - Getting Started

Open the door to our partner ecosystem. Get baseline perks and platform access to see how we take the grind out of your agency's workflow.

## Bronze - Early Engagement

Launch your first production sites and certify your first developer. This is where you get hands-on, turning DevOps overhead into real client wins.

## Silver - Active Contributor

Your client portfolio is growing, and so is your team's expertise. This tier rewards that momentum with higher margins and faster support.

## Gold - Growth Partner

You're leading more complex builds, so we'll back you with a dedicated partner manager and training budgets to scale your team's skills.

## Platinum - Strategic Collaborator

For partners driving significant new business. We'll help you master enterprise security (ISO 27001, SOC 2) so you can confidently win the most valuable deals.

## Diamond - Premier Partner

For our most committed partners. You get top margins, co-selling on major accounts, and a direct line to leadership to help shape our roadmap.

¹ Based on feedback from more than 25 Upsun agency partners in 2023.

## Agency — Strategic

### [(untitled)](https://upsun.com/strategic-implementation-experts/)

Launching from scratch, migrating, or modernizing? Tap upsun’s implementation architects for the clarity and technical pathways that turn complex projects into confident launches.

## Building from scratch?

We design for success from day one with strategic implementation planning. Our experts design your infrastructure, streamline your approach, and deliver enterprise-ready performance.

## Ready to migrate?

We implement near-zero downtime migrations with total confidence. With 500+ successful transitions, our implementation experts engineer a seamless move.

## Transforming your infrastructure?

Our implementation experts streamline complex modernization projects. We blend technical mastery with business acumen to transform your systems without disruption.

Implementation expertise for every stage

## Extended implementation capacity

Need extra development capacity? We integrate certified experts on our platform. They work **under the direction of** your Upsun consultants to deliver quality work faster, as part of your **Upsun-led strategy**. All external experts operate under Upsun's statement of work and project management.

## Featured certified experts

- basecom
- unleashed
- digital convergence
- vanksen

## Global network

- cti digital
- sqli

## Chromatic

### Trade invisible DevOps for work clients can see

Chromatic's CEO, Chris Free, on why even his DevOps-expert agency offloads infrastructure. Learn how they focus on shipping the features that impress clients, leaving the invisible server updates to us.

## Annertech

### How Annertech managers 100+ clients sites

Stella Power, Managing Director, explains how they tackle complexity at scale. Learn how Annertech uses the Upsun API and CLI to build theT custom tools and dashboards they need to innovate and deliver consistent service.

## Why trust Upsun with your implementation?

Under it all sits the Upsun platform: the foundation everything else rests on. Think of us as the friend who sketches the blueprint on a napkin, then sticks around to pour the concrete. First sketch the cloud diagram. Next pick the people. Last, tackle the 3 a.m. go-live checklist. We're there for all of it.

## A plan you can pin to the wall

We start by asking what matters to you: speed, revenue, a calmer dev team? Then we map the tech to those goals, draft a straightforward timeline, and agree on what "done" looks like.

## Talk strategic implementation with real engineers

You'll be on a first-name basis with the engineers sketching your roadmap. They listen, tweak, and build alongside you, making sure the thing actually fits, and grows.

## You build, we keep the lights on

Put your energy into the big ideas. We'll wrestle with the servers and configs so you can ship money-making features sooner.

## When you need help right now

Get rapid issue resolution with direct access to our engineering team, ensuring continuous optimization of your deployment.

## Enterprise reliability

Deploy with confidence on our enterprise-grade architecture, with production-grade preview environments that eliminate surprises and ensure stability at scale.

Implementation outcomes you can count on

🚀 Accelerated time to value

Ship features in hours, not weeks. Our proven deployment patterns and platform mastery translate directly to faster revenue realization.

⚡️ Strategic resource optimization

Our team aligns the right experts with your needs. We tap into our in-house expertise or bring in certified Upsun experts to help you hit your goals.

😎 No-surprise environments

See exactly how changes perform before production. Our preview technology eliminates deployment surprises.

🛡️ Rock-solid reliability

Based on average client results across 2,700+ live projects (2023-24), our expert-guided deployments achieve 99.99% uptime. We architect for stability from day one.

How our platform expertise powers your success

🕹️ Unified control, simplified operations

Our consultants turn complex infrastructure into your competitive edge. They give you streamlined control that just works.

☁️ Multi-cloud flexibility, zero drama

Pick your cloud—AWS, Azure, GCP, or OVHcloud—we stay chill. Our consultants deliver consistent architecture while keeping you strategically independent.

🔎 Performance insights that drive decisions

Our experts transform platform metrics into proactive optimization strategies, often enhancing performance before issues can impact your business.

## Are you a dev agency looking to take on more implementation work?

Are you a dev agency looking to take on more implementation work? Partner with us to expand your deployment expertise and power your clients' success.

## Events

### [Shopware Shoptoberfest | North America](https://www.shopware.com/en/events-calendar/shoptoberfest-north-america/)

Shopware Shoptoberfest | North America

Nashville, U.S.A

### [DotAI 2026](https://www.dotai.io/)

DotAI 2026

Paris, France

### [DotJS 2026](https://www.dotjs.io/)

DotJS 2026

Paris, France

### [DrupalCon EU | Rotterdam](https://events.drupal.org/rotterdam2026)

DrupalCon EU | Rotterdam

Rotterdam, Netherlands

### [EVOLVE | Partner Summit 2026](https://www.evolvepartnersummit.com/)

EVOLVE | Partner Summit 2026

Paris, France

### [QCon San Francisco 2026](https://qconsf.com/)

QCon San Francisco 2026

San Francisco, U.S.A

### [SymfonyCon Warsaw 2026](https://live.symfony.com/2026-warsaw-con/)

SymfonyCon Warsaw 2026

Warsaw, Poland

## Pages

### [Upsun: a highly flexible PaaS to develop applications](https://upsun.com/)

# Cloud infrastructure_with guardrails_

Give development teams the flexibility they need. Maintain centralized control over security, compliance, and spend.

## Trusted since 2015 by companies like

- Adobe
- UNICEF
- GAP
- Assa Abloy
- Colby College
- Columbia University
- ebsco
- first Foundation
- freitag
- hachette Livre
- havas Dublin
- invesco
- md Systems
- mentos
- mizzou
- nrdc
- orange
- oxford
- pacific Bank
- paul Scherrer institute
- randstad institute
- rhodes college
- sorbonne university
- university of surrey
- suzuki
- taboola
- unity
- university Of British Columbia
- u.s. chamber of commerce
- wittyWorks
- YMCA

Upsun: a highly flexible PaaS to develop applications

Upsun provides ultimate developer flexibility with self-service, predictable pricing. Customize your resources, runtimes, environments, and more. Start your free trial today!

"Costs have decreased by more than 60%, _everything has become easier_ and, above all, faster." —Manfred Ruf, IT Manager, UNICEF

## Total stack flexibility. Zero infrastructure friction

Upsun supports over 10 runtime languages and nearly any framework, with one standardized workflow across your entire stack.

### Java

### .net

### Python

### Node.js

### Next.js

### Magento

### Drupal

### Php

### Ruby

### Go

### Symfony

### Laravel

## Upsun has expertise serving

### Financial services

### Government and public sector

### Retail

### SaaS and startups

### Travel and hospitality

### Higher education

## Industry validation from leading analysts

### Certified B Corporation

We are a Certified B Corporation, verified by B Lab. This holds us to high standards of accountability and transparency.

### "One of our best decisions in a decade" — Markus H.

Don't just take our word for it. Explore our journey to the top of the G2 Leaderboard.

### 2025 Gartner® Magic Quadrant™ for Cloud-Native Application Platforms

Platform.sh (Upsun) recognized for second consecutive year.

## Blog articles

## Security and compliance

Inherit a hardened security posture with compliance-ready controls by default.

## 24x7 support

Get round-the-clock engineering support and proactive architecture guidance.

60%

Reduction in costs

UNICEF cut costs by 60% and scaled globally with Upsun.

UNICEF

https://www.unicef.org/

## Operational control at scale

Enforce centralized control with standardized environments across every team.

## Cloud portability

Deploy to AWS, Azure, Google Cloud, IBM, or OVHcloud with one unified toolchain.

## Secure AI deployment

Run AI workloads in isolated environments that keep proprietary data secure.

## Speed, flexibility, and control

Move fast with standardized workflows that maintain enterprise control.

Introducing Upsun Dispatch™

AI has made writing code fast, and you can feel it. Commits are up, pull requests are up, new repos spin up over a weekend, and your engineers swear they are faster. But where are all the new products? If every team really got faster, the software you use every day should be getting visibly better. AI helped your engineers ship more code. It didn't help your team ship more products.

For the past several months, we asked engineering and product leaders why, and we wrote down what we found: the 8 stages of AI engineering maturity, and how the bottleneck moved. The short version: the constraint was never typing.

It's tempting to blame the volume, but it isn't really the problem. Writing code was never the whole job; architecting and shipping it safely is. Is it tested? Is it secure? Will it scale? Will it hold up in production? A mature team answers those questions the same way every time, with the process, the tooling, and the test suite it has already built. Where it breaks is the individual who got fast on their own machine, on a framework that's theirs alone and may no longer be good enough. Remembering everything it takes to ship is overwhelming on its own, and hopeless once you have several agents running in parallel.

You've probably seen small "AI-native" teams shipping at a pace that makes no sense for their headcount. Same models as everyone else; the difference is that they embraced the shift and built the harness, the context and the process that turn a capable model into an effective one. We are building that platform as a product.

That is why today we are introducing Upsun Dispatch™.

## **What is Upsun Dispatch™**

Upsun Dispatch is a platform for the agentic software development lifecycle. The founding idea is that the workflow is the primitive, not the agent. Most tools in this space make one engineer faster in their IDE or terminal. The gains are real, but they stay on that one laptop. Upsun Dispatch puts the workflow where the whole team can see and run it, so the speed belongs to the team, not to whoever has the best setup.

Upsun Dispatch is built for the team and fits their rituals. You bring the tools your team already lives in (GitHub, GitLab, Linear, Jira, ...), the workflows that mirror how you actually ship, and the docs and processes that capture how your team works. Upsun Dispatch runs the rest: it picks up work, runs the agents, moves the work through your workflow one step at a time, stops where a human needs to decide, and keeps a logged cost record of every run.

> Writing the code stopped being the hard part, join us in rewriting the SDLC for the agentic AI era. **Register now for our Upsun Dispatch webinar on June 30,2026** and find out how you can help us build Upsun Dispatch.

## **Why we’re building Upsun Dispatch**

A handful of convictions shaped the product. Here they are.

-   **Agents belong in the cloud, not on your laptop**: Running agents on individual machines doesn't scale, and it's a security problem: production secrets and tool access spread across personal laptops, with no isolation and no record of what each agent touched. Upsun Dispatch runs them in an isolated environment, on the context and the process that the whole team relies on.
-   **Agents follow your process, not their own**: A workflow is a sequence of steps that runs the same way every time, with agents and humans both taking part. At the start, while you're still tuning the process and learning what the agents get right, the human gates are everywhere. As trust builds, you take gates out one at a time.
-   **Every change gets a real environment**: Upsun Dispatch works on its own, but pair it with Upsun Cloud, and every change gets more: a preview environment that's a byte-for-byte copy of production, the same infrastructure, the same code, the same data. The agent can test changes for real. And for web applications, anyone in the team can open that environment to judge the change for themselves.
-   **No model lock-in**: A smart router picks the right model for each task automatically. Models and providers will keep changing, and Upsun Dispatch absorbs that rather than bet your workflow on one vendor.
-   **Compliance is built in**: Every run is logged as immutable data: the issue, the agent's context, the plan, who approved it, and what it cost.
-   **You can see what it costs**: Agents spend tokens, and on individual laptops nobody can tell where the money is being spent. Upsun Dispatch shows cost per feature, per workflow, per team.
-   **The whole team ships, not just engineers**: Product, design, security, and managers take part in a workflow directly, approving gates and following runs without touching code.
-   **Built to be driven, not clicked**: Automation matters more to us than the UI. Everything Upsun Dispatch does is available through an API, and a run can start from a person, a GitHub event, a schedule, or an API call.

## **What this means for Upsun**

Upsun Dispatch sits under the Upsun brand because it runs on a decade of production infrastructure built for thousands of customers across every major cloud. The reliability, the security, the multi-cloud flexibility, the 24/7 support: that foundation carries forward into everything Dispatch does.

Upsun Dispatch is not a pivot away from what Upsun does. Upsun has always been about shipping software without infrastructure getting in the way; Upsun Dispatch extends that to the way software is built. It runs on its own and can be used as a standalone product with whatever infrastructure you already have. But it is compatible with Upsun Cloud.

## **How to be part of building Upsun Dispatch**

The conversations we have had with engineering leaders over the past several months shaped every decision in Dispatch. That process is not over: it is the point. We are not building this in a closed room.

The full public launch will happen in September 2026. But as soon as July 1st, our product will be available on an “invite-only” basis to continue gathering early feedback from a select group of users. Throughout the summer, we will continue working closely with a founding cohort of design partners who are already running AI workflows and hitting the orchestration wall. 

Design partners get direct access to our team, real influence on the product roadmap, and charter terms that reflect a genuine partnership rather than a vendor relationship. The product will reflect the people who help build it. 

The SDLC is being rewritten, and we are building the infrastructure to do so safely and at scale, with teams ready to move first. 

**Register now for our Upsun Dispatch webinar on June 30,2026** and find out how you can help us build Upsun Dispatch.

Fabien Potencier

Chief Product and Technology Officer

https://www.github.com/u/fabpot

https://www.drupal.org/u/fabpot

Agentic SDLC

AI Engineering

AI

Introducing Upsun Dispatch: a platform for the agentic SDLC

Upsun Dispatch is a platform for the agentic software development lifecycle, where humans and agents ship together.

News

Find out the latest Upsun news | Upsun

Read the latest Upsun news, product announcements, partnerships, certifications, and press releases - updates on the cloud application platform for developers

Company news, partnerships, and press releases.

## **Bridging the gap between technology and human care**

While Goodflair offers a fully digital experience, the back office is run by qualified Veterinary Technicians who review every claim. For Christophe Mas, the infrastructure must support these human experts without becoming a distraction.

> "The CRM is the operational heart of Goodflair," Christophe explains. "It handles all business workflows, manages connections with our third-party partners, and operates with a high level of security. Ultimately, it is what makes our promise of ultra-fast reimbursement a reality."

### **Why Upsun was the right fit**

The move to Upsun was about getting three things right: scaling, security, and expertise. Generalist cloud providers often lack the deep platform knowledge required to move as fast as a growing startup.

> "We needed finer scalability, a robust and secure infrastructure we handle health data, that is non-negotiable and above all, genuinely expert support," says Christophe. 

Upsun’s "NoOps" model allowed them to scale their Symfony CRM alongside WordPress in a centralized, predictable environment without managing the underlying plumbing.

### **Removing the fear of production risk**

The biggest barrier to rapid delivery is the fear of breaking the site. Before Upsun, Goodflair found testing to be a tedious manual process where results rarely matched what would actually happen in production.

Goodflair fixed this by making preview environments a natural reflex. 

> "Today, in a few clicks, we create a preview environment that is a faithful replica of production same configuration, same services, same data," says Christophe. "Each environment is fully isolated tests cannot impact production, and data remains protected. For a company that handles health data, that is far from a minor detail."

### **Scaling without the operational overhead**

By moving to a dedicated application platform, Goodflair has created shorter delivery cycles and a calmer work environment. Stability is a trust issue; a single outage could delay a reimbursement and break a customer promise.

> "PaaS, by nature, frees engineering teams from low-value infrastructure tasks," Christophe notes. "We ship faster and with greater confidence because environments are reproducible and consistent. Automatic scaling means we no longer have to question capacity at every release."

### **Advice for technical leaders**

The Goodflair team encourages other CTOs to focus on the product rather than the infrastructure. By offloading the "Ops" to a partner that understands high-stakes platforms, teams can maintain their velocity as they grow.

> "Moving to PaaS is a structural choice that frees up engineering bandwidth for what truly matters: the product," Christophe concludes. "With Upsun in particular, you also get genuinely expert and responsive support. I recommend it to any CTO who wants to build fast and build well, without drowning in ops."

### **About Goodflair**

Goodflair is a French insurtech providing transparent and ultra-fast pet insurance. Based in France, they combine a digital-first experience with human veterinary expertise. They are currently ranked #1 on Trustpilot among French pet insurance providers.

Insurance at speed: How Goodflair hits 8-hour reimbursement targets with Upsun

WordPress

Symfony

Goodflair co-founders Christophe Mas and Jérôme Brisseau launched the company in 2022 to fix a major problem: nearly half of pet owners avoid the vet because it costs too much. They built their reputation on a single, difficult promise: paying back claims in an average of 8 hours.


To hit that goal, they rely on two critical engines: a WordPress storefront and a custom Symfony CRM that handles the business operations. But as the company scaled, their original cloud provider, a massive generalist, became a bottleneck. At a giant host, the platform is just one of a hundred products; it lacked the specialized support and sharp expertise needed to handle sensitive pet health data and complex technical requirements.

Goodflair moved 100% of its applications to Upsun to gain finer scalability, tighter security, and expert support. By adopting Upsun’s Git-driven workflow, every code change automatically creates an isolated preview environment.


These environments act as production-perfect clones where the team can test new features, member journeys, or pricing updates against real data without risking the live site. By defining their entire infrastructure as code, Goodflair offloaded server complexity to the platform, freeing their internal team to focus entirely on insurance innovation.

Radical velocity: Shorter delivery cycles and faster shipping of new insurance features.
Production-perfect testing: Eliminated "unpleasant surprises" by using isolated preview environments for every branch.
Operational peace of mind: Achieved stable response times and high security for sensitive health data.
0% infrastructure toil: Freed up engineering bandwidth to maintain a #1 Trustpilot ranking and focus on member care.

How Goodflair hits 8-hour reimbursement | Upsun

See how French insurtech Goodflair pays pet claims in 8 hours by running WordPress and Symfony on Upsun, with isolated preview environments and expert support

The 8 stages of AI engineering maturity: a framework for teams

A few months ago, Steve Yegge published his 8 levels of AI-assisted development, and it clicked the moment I read it, because I had lived that exact progression myself, moving from autocomplete to running agents one step at a time. Framed as an AI trust gradient, it finally gave the industry a vocabulary for something most of us were already going through without a name for it. If you haven’t read it, save it for later.

Yegge's levels focus on the individual developer. And that’s the thing: when you’re leading an engineering team, you’re not managing one trust gradient, you’re managing a whole distribution of them. You’ve got someone running parallel agents all day, sitting next to someone who still thinks of AI as a fancier autocomplete, and both of them are shipping code. This is why the 10x productivity boost everyone keeps talking about almost never shows up at the org level. The hard part is getting the whole organization to move together, without the fast movers creating chaos and the slow adopters quietly falling behind.

So we took the same principles and looked at them from another angle: not the individual developer Yegge describes, but the team and the organization the team lives in. Eight stages of maturity, from “nobody has decided anything” to “the factory runs itself”.

A quick word on vocabulary, because we lean on it throughout. When we say _team_, we mean a group of people working together toward the same outcome: engineers, yes, but also product, design, QA, whoever it takes to ship software. When we say _organization_, we mean the entire collection of those teams, plus the leadership, budgets, and governance that sit above them.

And here’s the part that makes this an SDLC story and not just a developer story: the new software development life cycle isn’t just about developers. It’s about the whole team. The old boundaries between product, design, and engineering are getting blurry. A product manager can now vibe-code a working prototype instead of writing a three-page spec nobody reads. A designer can ship real HTML and CSS, not just a design system and a Figma file to hand off. That shift is the whole point, and it’s why thinking in terms of individual developers stops being enough.

**Let’s lay out the whole map before we walk through it.**

### Stage 1: The vacuum

Leadership hasn’t taken a real position; at most, it bought a batch of licenses and stopped there. Developers form habits without guardrails: pasting code into whatever chat window is open, no shared context files, no agent setup, no managed API keys. This is a learning phase, and I think that’s fine: people are building intuition for what these models can and can't do. That intuition is the real return right now. Don’t mistake silence for inaction. Your developers have already decided for themselves.

### Stage 2: The drift

Stage 1 was about what the organization hadn’t decided; Stage 2 is about what individuals have decided on their own. One engineer quietly has agents handling a big chunk of their output, running off a personal stash of prompts, custom skills, and a carefully tuned AGENTS.md they keep on their own machine. The person beside them hasn’t changed anything in two years, and nobody flags it because individual variation has always looked normal. This is the last stage where inaction is free. Once the drift becomes visible, and it will, it turns into a team-level problem.

### Stage 3: The islands

The gap that used to run between individuals now runs between whole teams, and it shows up on the delivery calendar where everyone can see it. One team has shared AGENTS.md files, wired up MCP servers, and built reusable skills. Its throughput jumps. The team next door still writes code like it's two years ago.. What starts as a tooling gap hardens into resentment, and that's much harder to repair.

### Stage 4: The standardization bet

The first stage that requires real commitment from leadership is that AI becomes a capability you build deliberately. Three things matter here. Context engineering becomes explicit work, with shared AGENTS.md files and a curated skill and prompt library in the repos, so the team encodes its knowledge once instead of every developer teaching the AI the same lessons. Security and governance come before scale: SSO and SCIM, secret scanning, PR gates that run on agent output, audit logs, and an approved list of models and tools behind a gateway, built before people run at full speed. And training is ongoing, not a one-off workshop, usually built around the champions from Stage 2.

### Stage 5: The workflow redesign

Stage 4 upgrades the tools; Stage 5 redesigns the factory floor, changing how the work actually gets done. Spec-first becomes the default: the spec lives in the repo as the agent’s entry point, and an agent can’t work from a vague ticket any better than a junior developer can. Code review shifts from line-by-line to risk-based questions: Does this match the spec? Do the tests prove it? What’s the blast radius if it’s wrong? CI gates treat agent-opened PRs exactly like human ones, and evals start running right next to the unit tests. Expect a productivity dip while the role moves from writing code to reviewing and orchestrating; that’s normal. Watch quality, not just velocity: more code shipped at lower quality isn’t speed, it’s incidents arriving sooner.

### Stage 6: The operating system

Stage 5 changed how a team works; Stage 6 changes what a team is made of and how teams coordinate. A sprint might hold three engineers and five agent slots, and the engineer now looks more like a product manager than a programmer: writing specs, arguing with the AI about them, checking the tests. TDD becomes a dependency, not a nice-to-have: agents optimize for passing tests, so a weak suite gets gamed, and you won’t find out until production does. Parallel agents running in isolated sandboxes can burn more compute in a single sprint than a quarter of the hosting cost, so token budgets and per-run observability stop being optional. And shared context becomes real infrastructure (project memory, skills, prompt libraries, MCP servers), maintained as team assets and coordinated across teams.

### Stage 7: The bright factory

The line from Stage 6 is who holds the pen. The agents now write and ship whole units of work with barely any human authorship, and the human steps back from driver to supervisor. Most teams are still babysitting: agents kicked off from a terminal on someone’s laptop, looping locally and opening PRs from a dev machine, with no shared runtime and no central record of what ran or why. That local-machine detail is the one thing separating this stage from the next.

### Stage 8: The autonomous factory

Agents move off laptops and onto shared infrastructure, with scheduled runs in sandboxed environments and centralized logs and traces, so a migration that used to need babysitting runs overnight and reports its results in the morning. Recurring jobs become first-class (dependency updates, security patches, test expansion) with defined success criteria and automatic escalation when something fails. Eval becomes the product: the knowledge that lived in people's heads now lives in agent configs, skills, and eval suites that gate every merge, encoded once and enforced automatically. Your standards no longer live in someone's head. They live in the system

## A few honest caveats

No organization sits cleanly on a single stage. You’ll spot some teams at Stage 6 and another still firmly in Stage 1. The number is a center of gravity, not a label you pin on everyone.

Also, you shouldn’t skip stages. Go straight for autonomous agents without the governance, testing, and shared context underneath, and you just become another canceled project. But there’s a subtler reason to go one stage at a time: each stage hurts in its own particular way, and that pain is the lesson. The friction between a fast team and a slow one is what pushes a company to standardize. The grind of reviewing agent output line by line is what convinces a team to redesign the workflow. Skip the pain, and you lose the reason to move on: nothing makes the case for the next stage like the current one starting to hurt.

And stay skeptical the whole way. The hype around this is loud; the evidence, much quieter. So treat every promise here, including ours, with care.

## Conclusion

The question isn't whether to adopt AI. Most teams already have. The real question is whether the system underneath is good enough to be worth amplifying.

Because that's what AI is. I'm convinced of it: an amplifier. It accelerates what’s already there, the good practices and the bad ones alike. The organizations we’ve watched gain velocity without losing quality all share the same foundation: clear service ownership, comprehensive testing, documented services, and automated standards. None of this is new. We’ve been preaching these best practices for years. AI just made their absence impossible to ignore.

The autonomous factory is where this is heading. The hardest part won’t be the agents themselves: it’ll be trusting them enough to take them off individual laptops and run them on shared infrastructure. You build it the same way you always have, with evidence. One eval, one recurring task, one verified deployment at a time.

8 Stages of AI Engineering Maturity for Teams | Upsun

Most teams already use AI. The question is whether your org is moving together. A framework for taking your whole team from chaos to autonomous agents.

Insights

Strategic cloud & platform insights for leaders | Upsun

Actionable insights for engineering and platform leaders on cost control, governance, modernization, and multi-cloud strategy - built for enterprise decision-makers.

Technical guides, explainers, and industry perspective.

ITMM Homepage

### [DevOps automation for cloud application delivery | Upsun](https://upsun.com/devops-automations/)

# DevOps automation from _code to production_

Upsun gives platform and DevOps teams a faster way to ship: automated deployments, production-like environments on every branch, and managed application services that reduce manual cloud operations.

DevOps automation for cloud application delivery | Upsun

Automate the path from code to production with Upsun. Standardize deployments, create production-like environments, manage services, and reduce manual cloud operations

- Adobe
- The Economist
- Oris
- Freitag
- A+E
- The British Museum

## Manual work is the bottleneck, not your code

### Engineering time disappears into setup work

Developers wait for environments, services, and infrastructure that should be automated. Velocity drops not because of the code, but because of the wait.

### Staging that doesn't match production

Environment drift turns every release into a debugging session. Bugs surface in production that staging could not catch.

### Slow project onboarding

Every new app needs its own CI setup and infrastructure configuration. The same setup process starts from scratch on every project.

### From Git push to production in three steps

### Define once

Declare your application, services, and environment rules in a single config file. Databases, caches, and queues, all in one place, version-controlled alongside your code.

### Push to any branch

Every Git push triggers an isolated, production-like environment automatically, with real services attached and real data cloned in. No tickets, no waiting, no manual setup.

### Ship with confidence

Merge when it's ready. Upsun handles the deployment. The environment tears itself down. Your platform team never touched a ticket.

## Every step from commit to production

### DevOps automation

Cloud DevOps automation should remove the repetitive work between code and production. Upsun reduces manual provisioning, scaling, patching, and environment cleanup so your team can focus on shipping.

### Pipeline and deployment automation

Connect Git workflows to reproducible builds and isolated environments with services attached: less custom scripting and fewer deployment handoffs.

### Platform engineering without the ticket queue

Platform engineering tools should give developers self-service without turning the platform team into a ticket queue. Upsun standardizes environments, branches, and services at the platform level.

### Multi-cloud deployment

Deploy the same application configuration across multiple cloud providers. Choose where workloads run based on compliance, cost, or latency, without rewriting infrastructure for each provider.

### Developer productivity

Branch environments are provisioned in minutes with production-like data. Reviewers can test real changes. No staging drift, or it "works on my machine.”

### Governance and control

Define environment policies, service configuration, and access controls once. Apply them consistently across teams, projects, and applications.

## Why teams choose Upsun over building it themselves

"This morning, we launched a new development environment to test a disruptive feature. That would've been a huge ordeal in our old setup. Now it's just part of the workflow." —Geoff Douglas, VP of Engineering, MarketNation

### [Get in touch with Upsun experts](https://upsun.com/contact-paas/)

# Find _the right platform_ for your team

Tell us about your stack and scale. We'll help you decide.

**What happens after you submit:**

1.  We review your request and your context
2.  A technical expert gets back to you within 1 business day
3.  You get a 30-minute discussion focused on your stack, goals, and questions 

_Costs have decreased by more than **60%**_  
– Manfred Ruf, IT Manager, UNICEF

Get in touch with Upsun experts

- University of Oxford
- UNICEF
- Adobe
- Mentos
- Unity
- GAP

### [Talk to a compliance expert](https://upsun.com/contact-enterprise/)

# Book a _platform assessment_

Tell us how your teams deploy today. We'll show you where to standardize.

**What happens after you submit:**

1.  We review your request and your context
2.  A technical expert gets back to you within 1 business day
3.  You get a 30-minute discussion focused on your stack, goals, and questions 

_Costs have decreased by more than **60%**_ _everything has become easier and, above all, faster._  
– Manfred Ruf, IT Manager, UNICEF

Talk to a compliance expert

Get in touch with Upsun experts

- University of Oxford
- UNICEF
- Adobe
- Mentos
- Unity
- GAP

### [Get in touch with Upsun experts](https://upsun.com/contact-heroku/)

# Talk through your _Heroku migration_

Tell us what you're migrating. We'll connect you with the right expert.

**What happens after you submit:**

1.  We review your request and your context
2.  A technical expert gets back to you within 1 business day
3.  You get a 30-minute discussion focused on your stack, goals, and questions 

_Costs have decreased by more than **60%**_ _everything has become easier and, above all, faster._  
– Manfred Ruf, IT Manager, UNICEF

Get in touch with Upsun experts

- University of Oxford
- UNICEF
- Adobe
- Mentos
- Unity
- GAP

### [Platform engineering without building an internal platform | Upsun](https://upsun.com/platform-engineering/)

# _Platform engineering_ without building an internal platform stack

Give developers self-service environments, standardized deployment workflows, and built-in governance without maintaining a complex internal platform architecture.

Platform engineering without building an internal platform | Upsun

Get the self-service, standardization, and governance of an internal developer platform, without the operational burden of building one. Git-native, multi-framework, managed.

- Adobe
- The Economist
- Oris
- Freitag
- A+E
- The British Museum

## Reduce internal platform complexity

Support developer self-service and standardized delivery workflows without operating multiple platform engineering tools and integrations internally. Upsun acts as a PaaS-based platform layer, so your team gets the outcomes of an internal developer platform without building one from scratch.

### Tool sprawl

Platform engineering stacks often require stitching together separate deployment, infrastructure, and governance tools that all need to be maintained independently.

### Custom integrations

Internal platforms require ongoing engineering effort to build and maintain workflows, integrations, and the glue connecting them.

### Operational maintenance

Platform teams spend time operating the platform itself, patching clusters and fixing pipelines, instead of improving developer workflows.

### Inconsistent adoption

Without a unified golden path, different teams continue using different deployment workflows and infrastructure patterns.

## A managed platform layer for application delivery

Upsun centralizes environments, deployments, infrastructure workflows, and governance into a single platform designed for modern application teams. Developers get a Git-native self-service workflow. Platform teams get the standardization and governance without owning the infrastructure underneath it.

### Platform teams set the standard

Define services, environments, and policies once. The configuration becomes the golden path every team inherits automatically.

### Developers self-serve

Developers provision environments and deploy applications through Git, without filing tickets or waiting on infrastructure provisioning.

### Governance applies automatically

Access controls, compliance policies, and operational standards are enforced at the platform level, consistently, across every team and project.

## What you'd otherwise have to build yourself

A typical internal developer platform combines Kubernetes, a service catalog, CI/CD orchestration, and a governance layer, each requiring dedicated engineering time to build and maintain. Upsun provides the same outcomes as a managed platform.

### Self-service environments

Developers can create and manage environments without relying on manual infrastructure provisioning or platform team tickets.

### Standardized deployment workflows

Teams deploy applications through consistent, Git-based operational workflows. No custom pipelines per team.

### Built-in governance

Apply operational standards and infrastructure policies consistently across applications, without building a separate policy engine.

### Integrated infrastructure management

Provision services and infrastructure through declarative, version-controlled configuration. No cluster management required.

### Preview environments

Generate isolated, full-stack review environments automatically for every branch and pull request.

### Multi-framework support

Run PHP, Python, Node.js, Java, Go, and other application stacks side by side on the same operational platform.

## Support platform engineering goals without operating platform infrastructure

Upsun helps engineering organizations improve standardization, developer experience, and operational consistency while reducing the amount of internal platform tooling teams maintain manually. Platform engineers shift from running infrastructure to defining standards.

### Reducing internal platform maintenance

Avoid maintaining custom deployment tooling, Kubernetes clusters, and infrastructure automation internally.

### Standardizing developer workflows

Give application teams consistent deployment and environment workflows, regardless of the framework they use.

### Improving developer self-service

Allow developers to provision environments and deploy applications independently, without platform team intervention.

### Supporting multi-team governance

Apply operational standards consistently across engineering teams and environments, with centralized visibility.

"Upsun has been a transformation accelerator. It allowed us to do DevOps without the extremely expensive and laborious part of setting up these platforms." —Thomas Barriere, DSI, Ineris

### [GitOps platform: deploy from Git without the overhead | Upsun](https://upsun.com/gitops-platform/)

# _Git push_ to deploy. Everything else is automatic.

Define your infrastructure as code, push to Git, and Upsun handles the rest. Builds, environments, deployments, and rollbacks, all driven by your Git workflow without custom scripts or glue.

## Powered by Platform.sh. 6,000+ customers. 8 years in production.

- Adobe
- UNICEF
- GAP
- Assa Abloy
- Colby College
- Columbia University
- ebsco
- first Foundation
- freitag
- hachette Livre
- havas Dublin
- invesco
- md Systems
- mentos
- mizzou
- nrdc
- orange
- oxford
- pacific Bank
- paul Scherrer institute
- randstad institute
- rhodes college
- sorbonne university
- university of surrey
- suzuki
- taboola
- unity
- university Of British Columbia
- u.s. chamber of commerce
- wittyWorks
- YMCA

GitOps platform: deploy from Git without the overhead | Upsun

Push to Git and Upsun handles the rest. Infrastructure as code, automatic deployments, consistent environments across dev, staging, and production.

## Your Git workflow is already the deployment workflow

Upsun treats your Git repository as the single source of truth for both application code and infrastructure. Push a branch and an environment appears. Merge it and it deploys. No pipelines to stitch together. No infrastructure to maintain separately.

### DIY pipelines break at scale

Custom deployment scripts work until they don't. Every change to your stack requires updating the pipeline too.

### Environments drift from production

Dev, staging, and production diverge over time when infrastructure isn't defined as code and versioned with the application.

### Slow feedback loops

Traditional pipelines take 10 to 15 minutes minimum to get a change into a testable environment. Every cycle compounds.

### Rollbacks are manual and risky

Without traceable, Git-tied deployments, rolling back means guesswork and coordination across tools.

### Push code. Get a running environment.

### Define your stack in one config file

Your application, services, routes, and environment variables live in a single YAML file committed to your repository. Infrastructure is versioned alongside code.

### Push to Git

Every push triggers an automatic build and deployment. Upsun reads the configuration, provisions the services, and wires everything together. No manual steps.

### Branch, test, merge, deploy

Create a branch and get a full environment. Merge it and it deploys to production. Every step is traceable back to a Git commit.

## Built-in delivery without the overhead

Upsun gives you the outcomes of a mature GitOps platform without the internal tooling to build or maintain. Infrastructure branches with your code. Environments are consistent by default.

### Git-driven deployments

Every push, branch, and merge triggers the appropriate deployment action automatically. Your Git workflow is the deployment workflow.

### Infrastructure as code

Your entire stack is declared in a single configuration file versioned in Git. Every branch carries identical infrastructure, eliminating environment inconsistencies.

### Consistent environments

Dev, staging, and production are all built from the same configuration. What you test is what you ship.

### Commit-level rollback and traceability

Every deployment is tied to a Git commit. Rolling back means reverting the commit and redeploying. No guesswork, no coordination across tools.

### No pipeline maintenance

Upsun replaces the scripts and glue holding your deployment workflow together. Build and deploy logic is handled by the platform, not your team.

### Works with your existing Git host

Connect your repository and keep your existing workflow. Upsun integrates with your Git host and mirrors your branch structure into running environments.

## What teams use Git-driven deployments for

### Shipping features faster

Push a branch, review in a live environment, merge to deploy. No waiting for platform teams or manual environment setup.

### Platform engineering at scale

Give every team a consistent deployment workflow without maintaining the tooling behind it. One configuration standard across all projects.

### Eliminating staging drift

Infrastructure defined as code means every environment is built the same way. No more "it works on staging but breaks in production."

### Faster, safer rollbacks

Every deployment maps to a Git commit. Reverting is as simple as reverting the code.

"This morning, we launched a new development environment to test a disruptive feature. That would've been a huge ordeal in our old setup. Now it's just part of the workflow." —Geoff Douglas, VP of Engineering, MarketNation

### [Request a platform standardization review | Upsun](https://upsun.com/request-a-platform-standardization-review/)

# Standardize how you ship _without rebuilding_

Transition from building custom infrastructure to configuring a standardized delivery foundation. Speak with a technical expert to see how Upsun can automate your delivery overhead and recover engineering time lost to infrastructure.

-   Find where environment variation is slowing your teams down
-   Give teams self-service access without adding security or maintenance risk
-   Replace custom platform scripts with versioned, enforceable config

Request a platform standardization review | Upsun

30-min deep dive into automating delivery standards and reducing overhead

### [DevOps automation for cloud application delivery | Upsun](https://upsun.com/devops-automation/)

# DevOps automation from _code to production_

Upsun gives platform and DevOps teams a faster way to ship: automated deployments, production-like environments on every branch, and managed application services that reduce manual cloud operations.

DevOps automation for cloud application delivery | Upsun

Automate the path from code to production with Upsun. Standardize deployments, create production-like environments, manage services, and reduce manual cloud operations

- Adobe
- The Economist
- Oris
- Freitag
- A+E
- The British Museum

## Manual work is the bottleneck, not your code

### Engineering time disappears into setup work

Developers wait for environments, services, and infrastructure that should be automated. Velocity drops not because of the code, but because of the wait.

### Staging that doesn't match production

Environment drift turns every release into a debugging session. Bugs surface in production that staging could not catch.

### Slow project onboarding

Every new app needs its own CI setup and infrastructure configuration. The same setup process starts from scratch on every project.

### From Git push to production in three steps

### Define once

Declare your application, services, and environment rules in a single config file. Databases, caches, and queues, all in one place, version-controlled alongside your code.

### Push to any branch

Every Git push triggers an isolated, production-like environment automatically, with real services attached and real data cloned in. No tickets, no waiting, no manual setup.

### Ship with confidence

Merge when it's ready. Upsun handles the deployment. The environment tears itself down. Your platform team never touched a ticket.

## Every step from commit to production

### DevOps automation

Cloud DevOps automation should remove the repetitive work between code and production. Upsun reduces manual provisioning, scaling, patching, and environment cleanup so your team can focus on shipping.

### Pipeline and deployment automation

Connect Git workflows to reproducible builds and isolated environments with services attached: less custom scripting and fewer deployment handoffs.

### Platform engineering without the ticket queue

Platform engineering tools should give developers self-service without turning the platform team into a ticket queue. Upsun standardizes environments, branches, and services at the platform level.

### Multi-cloud deployment

Deploy the same application configuration across multiple cloud providers. Choose where workloads run based on compliance, cost, or latency, without rewriting infrastructure for each provider.

### Developer productivity

Branch environments are provisioned in minutes with production-like data. Reviewers can test real changes. No staging drift, or it "works on my machine.”

### Governance and control

Define environment policies, service configuration, and access controls once. Apply them consistently across teams, projects, and applications.

## Why teams choose Upsun over building it themselves

"With Upsun, we now have more fluidity in our deployment process and something we can standardize all our projects on... We can now spend our time more effectively consulting with our clients to solve their business problems." —Barry Fisher, Director, Pivale

### [Flexible cloud commitments for stable budgets | Upsun](https://upsun.com/understanding-commitments/)

# Understanding _commitments_

A practical guide to predictable, flexible cloud provisioning.

Flexible cloud commitments for stable budgets | Upsun

Learn how Upsun commitments balance predictable cloud spend with flexible provisioning, from stability and lean models to FAQs and pricing guidance

### Why commitments?

Digital projects evolve continuously. Provisions shift, environments grow, and spend can be hard to predict. A commitment contract solves this: define a monthly spending baseline, receive a fixed discount, and retain full control over what you provision.

Commitment contracts are available to customers who spend at least $1,000/month.

## Key principles

### You are always in control

Your spend is determined by what you intentionally set up. Nothing scales automatically unless you configure it to do so. Only a small amount of traffic-based costs can vary, typically less than 5% of your total spend.

### Commitments are not blank cheques

You choose a commitment amount that matches your reality. The goal is to eliminate anxiety, not create it.

### Predictability meets flexibility

Commitments let you stabilise your budget while still allowing you to adjust environments, components, and resources as your projects evolve.

## Example 1: _The stability model_

Some organizations prioritize budget stability above all else: consistent invoices, minimal variation, even when provisions occasionally spike.

### How it works

1.  You estimate your expected monthly provisions (e.g., around $10,000).
2.  You intentionally commit to a higher amount (e.g., $12,000).
3.  You receive a discount on the committed amount.
4.  As long as your actual provisioned resources remain below or equal to the committed amount, your invoice remains stable.
5.  Only if your provisioned resources (including bandwidth) exceed the committed amount will your bill increase.

Because the buffer is deliberate, increased billing happens rarely.

## Example 2: _The lean commit model_

Other organizations prefer spend that tracks closely with what they actually provision. The Lean Commit Model keeps the committed baseline low, preserving flexibility while still delivering a fixed discount.

1.  You estimate your expected provisions (e.g., around $18,000).
2.  You commit to a lower, conservative baseline (e.g., $15,000).
3.  You receive a discount on the committed amount.
4.  When provisions exceed the commitment, the excess is billed on top of the commitment at list price.
5.  When provisions fall below the committed amount, the commitment still applies and the unutilized portion is handled as a true-up.

## Frequently asked questions (FAQ)

### What commitment terms are available?

You commit to a fixed monthly spend for a term of 12, 24, or 36 months. Monthly commitments are billed on a monthly cycle. Annual commitments are also available and are prepaid upfront, though discounts are typically lower than monthly commitment equivalents. The higher your commitment and the longer your term, the greater the discount available. Speak to your Upsun account manager to find the right structure for your organization.

### Can I change my commitment amount during the contract?

Commitments can be adjusted upward during the contract period via a change order. When you increase your commitment, your discount amount increases accordingly while your existing contract terms remain in place. Commitments cannot be reduced during an active contract term.

### What happens if my usage falls below my commitment?

You still pay the committed floor. A true-up line item appears on your invoice to cover the difference between your actual usage and your committed amount. Your fixed discount applies regardles.

### How do I determine a good monthly provisioning baseline?

There are several ways to approach this:

1.  **Use our sizing guides.** For common CMS and eCommerce workloads, reference architectures and cost estimates are available at https://sizing.pltfrm.sh/upsun/
2.  **Start without a commitment.** Run your project in pay-as-you-go mode and observe real provisioning patterns. Once it stabilizes, your usage data will give you a clear baseline to commit against.
3.  **Use the pricing calculator.** If you know your approximate resource footprint, get an immediate projection at https://upsun.com/pricing/calculator
4.  **Talk with the Upsun team.** We're happy to walk through your scenario and provide recommendations based on real deployments.

Most customers combine one or more of these approaches. The goal is confidence, not speed.

### I'm just starting development and don't know my commitment level yet. What should I do?

You have two practical options. Start without a commitment and move to pay-as-you-go until your resource profile becomes clear. Or begin with a lower, conservative commitment that covers your minimum expected spend. You can always increase it as your needs grow.

### What happens if my costs go out of control?

Unlike some platforms, Upsun never adjusts your resources without your direct input. Resources are flexible but not elastic. Even with auto-scaling, you control how much, how fast, and for how long.

The small variable portion of your bill (bandwidth and request volume, typically less than 5% of total spend) is manageable through real-time visibility, traffic alerts, CDN capabilities, and optional DDoS surge protection. If unexpected activity occurs, our support team can help you understand and stabilize the situation.

### [Scaling and performance without re-architecting | Upsun](https://upsun.com/features/scaling-and-performance/)

# Scale _without rebuilding_ your infrastructure

Add instances, tune resources, or let autoscaling do the work, all from the same Git, CLI, Console, or API workflow you already use.

Scaling and performance without re-architecting | Upsun

Scale horizontally or vertically without redesigning infrastructure. Add instances, tune CPU and memory, and use autoscaling based on real usage across environments.

## The problem

Static infrastructure can't keep up. Most teams hit the same three walls:

### Fixed sizing fails under load

Spikes overwhelm what's deployed, and the rest of the time it sits idle.

### Overprovisioning is expensive

Sizing for the worst case all year round costs more than it should.

### Autoscaling stopped at the app tier

Most platforms autoscale apps but route database scaling to a third-party engine, a Kubernetes operator, or a manual upgrade workflow. Capacity at the database tier never caught up.

## Scaling for every workload

Scaling and performance on Upsun allow teams to adjust application capacity through the console, CLI, or API.

- Horizontal and vertical scaling for apps, workers, and managed PostgreSQL and MariaDB
- Native autoscaling across applications, background workers, and managed database read replicas
- No third-party database engine or Kubernetes operator to manage
- CPU and memory-based autoscaling
- Configurable thresholds and instance limits per environment
- Container profiles for any workload type
- Guaranteed CPU for resource-intensive workloads
- Manage from Git, CLI, Console, or API

## How scaling works on Upsun

### Add or remove instances on demand

Run more copies of your app or worker in seconds. New instances are added without downtime and start serving traffic immediately. Trigger it from the CLI, Console, or API.

### Tune resources vertically

Increase CPU, memory, or storage for your app, databases, background jobs, and other services. Choose from four built-in sizes that cover most types of work.

### Set CPU or memory thresholds

Upsun adds and removes capacity automatically across apps, workers, and managed PostgreSQL or MariaDB read replicas, with no restart or downtime.

### Scale workers independently

Worker processes scale separately from your application. Add worker instances to handle background jobs and queues without touching your app's capacity.

## Scaling built around your business growth

### Reliability and availability

Every app and service runs in its own container with allocated CPU, memory, and storage. Guaranteed CPU reserves dedicated compute for resource-intensive workloads.

### Cost control

Resource allocation can be tuned per environment to balance performance and cost, especially for non-production workloads.

### Operational simplicity

Apps, workers, and managed databases share one autoscaling primitive, one platform, and one bill. The same controls apply across the stack, with the integration managed by the platform.

### Capacity matched to demand

Set autoscaling rules before peak periods. Capacity grows when load rises and shrinks when it falls, across apps, workers, and managed database read replicas.

### Per-environment resource control

Run preview and staging at smaller profiles, reserve larger ones for production. Non-production work never carries production costs.

### Growth without migration

As your application grows, add more CPU, memory, and instances on the same platform. No infrastructure migration or application rewrites needed.

### [Upsun included for platform maturity and AI-ready vision - 2026 IDC ProductScape | Upsun](https://upsun.com/2026-idc-productscape-upsun/)

# Upsun included in the 2026 IDC Product Scape for Worldwide Cloud Deployment-Centric Application Platforms

Unlock insights to future-proof your cloud and AI strategy

-   **Get a verified analysis** of the technical capabilities you need to choose the right cloud platform for your business and AI development goals.
-   **Stay competitive** by exploring how  platforms are evaluated across key functionality areas: from DevOps tooling and application security to AI and agentic application support.

2026 IDC ProductScape™

_Source: IDC ProductScape: Worldwide Cloud Deployment–Centric Application Platforms, 2026, Doc. #_ _US53014025, March 2026._

Upsun included for platform maturity and AI-ready vision - 2026 IDC ProductScape | Upsun

Access your free excerpt of the 2026 IDC ProductScape: Worldwide Cloud Deployment-Centric Application Platforms and see how Upsun's AI-ready capabilities compare to top providers.

## Platform maturity and an AI-ready vision, see why _Upsun is a match_

For the first time, Upsun is included in the IDC ProductScape: Worldwide Cloud Deployment–Centric Application Platforms, 2026,  an independent guide that maps the technical capabilities of cloud deployment platforms across the market.

The IDC ProductScape notes that "Upsun is leveraging AI to simplify infrastructure-as-code provisioning for developers, enabling automated resource creation via YAML files." adding that these capabilities “reflect Upsun's evolution from a traditional PaaS toward a more automated, lifecycle-oriented application platform.”

_Source: IDC ProductScape: Worldwide Cloud Deployment–Centric Application Platforms, 2026, Doc. # US53014025, March 2026._

### [Deploy applications faster on any cloud | Upsun](https://upsun.com/deploy-applications-faster/)

# _Deploy applications_ faster on any cloud

Push to Git and Upsun builds, deploys, and manages your environments, services, and infrastructure automatically. One workflow, any major cloud provider.

Deploy applications faster on any cloud | Upsun

Push to Git and deploy. Upsun manages environments, services, scaling, and rollbacks across AWS, Azure, Google Cloud, and more, all from one workflow.

- Adobe
- The Economist
- Oris
- Freitag
- A+E
- The British Museum

### Built for teams shipping production applications

Deploy and manage modern applications without maintaining complex deployment pipelines or infrastructure tooling. Upsun runs on AWS, Google Cloud, Microsoft Azure, IBM, and OVHcloud, all through the same Git-based workflow.

## Shipping shouldn't mean managing infrastructure

As applications grow, deployment workflows get harder to maintain. CI/CD pipelines multiply. Environments drift from production. Upsun keeps delivery consistent without rebuilding your workflow for every project.

### Complex deployment pipelines

CI/CD workflows become difficult to maintain across projects, especially once each team customizes its own.

### Environment inconsistencies

Applications behave differently between development, staging, and production when infrastructure isn't defined consistently.

### Manual infrastructure work

Teams spend time maintaining deployment tooling and provisioning servers instead of shipping features.

### Slow review workflows

Testing changes across environments creates delays when every test requires manual environment setup.

## From Git push to production in three steps

### Push code

Connect your Git repository and define your application, services, and infrastructure in a single configuration file.

### Deploy automatically

Upsun builds and deploys your application, provisioning services and infrastructure based on your configuration. No manual setup.

### Test and scale

Preview environments, rollbacks, and resource scaling are all managed directly through the platform, via Git, CLI, console, or API.

## Built for teams shipping production applications

Upsun supports modern application workflows across multiple frameworks and cloud providers while reducing the amount of infrastructure work teams manage manually.

### Preview environments

Generate isolated, full-stack environments automatically for feature branches and pull requests.

### Integrated services

Provision databases, caches, and application services directly through your configuration file. No separate setup.

### Git-based workflows

Manage deployments directly from your existing development workflow. Push, branch, and merge as usual.

### Rollback support

Every deployment maps to a Git commit. Revert the commit and redeploy to recover quickly from a bad release.

### Multi-cloud deployment

Deploy applications across AWS, Google Cloud, Azure, IBM, and OVHcloud without changing your workflow.

### Framework flexibility

Run PHP, Python, Node.js, Java, Go, and other modern application stacks on one platform.

## Common use cases

### Replacing custom deployment scripts

Reduce operational overhead caused by fragmented, hand-built CI/CD workflows.

### Accelerating developer onboarding

Give developers a consistent deployment workflow across every project, regardless of framework.

### Improving release workflows

Validate changes faster with preview environments before they ever reach production.

### Reducing DevOps maintenance work

Spend less time maintaining infrastructure automation and deployment tooling, and more time shipping.

"The time we save on the maintenance and upgrading of the infrastructure is now spent on development." —Renaud Grand, CTO, Califrais

### [Pantheon alternative with multicloud support | Upsun](https://upsun.com/alternative-pantheon/)

# Your innovation shouldn't be _limited by infrastructure_.

Looking for a Pantheon alternative? Upsun is a powerhouse cloud application platform with flexible Git workflows, your preferred cloud providers, all at transparent pricing.

Pantheon alternative with multicloud support | Upsun

Upsun is a Pantheon alternative with unlimited environment cloning, multicloud support, transparent pricing, and PCI DSS, GDPR, and HIPAA compliance.

| Feature | Upsun | Competitor | Details |
| --- | --- | --- | --- |
| Environment cloning | Unlimited byte-for-byte clones with data | Manual content cloning; limited to 10 environments | Upsun creates complete environment clones in under 2 minutes, including all data and configurations, with no environment limits. Pantheon limits cloning to content only, done manually, with just 10 environments per site. |
| Cloud provider | AWS, Azure, OVH, IBM, GCP | Google Cloud Platform | Upsun offers flexibility with multiple IaaS providers and regions, enabling geographic, regulatory, and environmental advantages. Pantheon runs exclusively on Google Cloud Platform (GCP) with no multicloud options. |
| Language support | Native support for 10 programming languages | WordPress, Drupal + Next.js, Gatsby | Upsun supports the latest versions of 10 programming languages and an array of frameworks. Pantheon is limited to PHP-based CMS (WordPress/Drupal) for the backend, with Next.js, Gatsby only. |
| WordPress | Composer-based, Bedrock, Vanilla | Composer-managed upstream | Upsun fully supports WordPress, including Vanilla, Bedrock, and Composer-based setups, powered by PHP 8.3 and WP-CLI. In addition to traditional WordPress plugins, Pantheon supports Composer-managed WordPress only. |
| Traffic limits | Unlimited page views | Capped by plan tier | Upsun uses usage-based pricing for resources with no restrictions on page views or data transfer. Pantheon charges based on traffic volume and automatically increases your bill when you exceed monthly limits. |
| Pricing model | Predictable & transparent pricing models | Tier-based pricing + website visit upgrades | Upsun offers flexibility with two pricing options: pay only for the resources you provision, or choose a fixed monthly tier plan. Pantheon offers tiered plans (monthly/annual) with traffic-based automatic upgrades. |
| Compliance | SOC 2 Type 2, PCI DSS Level 1, ISO 27001, GDPR, HIPAA | SOC2 Type 2, GDPR, and FERPA | Upsun is PCI DSS Level 1, GDPR, HIPAA, IS0 27001, and SOC 2 Type 2 compliant, with automated compliance monitoring and DDoS protection. Pantheon provides compliance with SOC 2 Type 2, GDPR, and FERPA support. |
| Managed data services | Fully supported | Limited | Upsun solves the database complexity with fully managed data services. Pantheon offers limited data services support for MariaDB/MySQL, Redis, and Apache Solr only, without modern databases. |
| Sustainability | Carbon tracking + green hosting | x | Upsun tracks carbon intensity 12x across all regions and offers a 3% discount when you choose greener, more sustainable data centers. Pantheon does not have any published independent green hosting incentives. |
| Application Performance Monitoring | Built-in observability suite | Limited | Upsun delivers function-level insights, combining observability and telemetry to enable data-driven decision-making. Pantheon uses New Relic APM for users on the higher tier, and this requires an external service and management. |
| Preview Environments | Automatic Git branch | Manual setup required | On Upsun, every git branch has its own environment. Every pull request auto-creates an environment with inherited data and services. Pantheon multidev environments requires manual creation through the dashboard or CLI, with a limit of 10 environments per site. |
| Speed to market | Instant | Relatively fast; manual setup required | Upsun users can ship features in minutes through Git push workflows once source integration is configured. Pantheon is relatively fast with managed containers but requires environment setup before preview launch. |

Want to learn more? [Upsun documentation](https://docs.upsun.com/) has everything you need to get started.

## Why developers choose Upsun

### Multicloud

Upsun places infrastructure choice in your hands. Select your cloud provider and region with lower carbon intensity to earn discounts and support your sustainability goals.

### Instant environment in minutes

Clone your production environment in minutes real data, configs, and code included. Each environment has built-in CI to auto-build your site on the fly.

### No page limit, no surprise charge

Upsun offers pricing that fits your precise business needs. Whether you serve 250K or 500K pageviews, your bill stays the same. No surprise charges, no overages, and no throttling, just clarity and control.

### Multi-language support

Whatever languages, runtimes, stacks, or CMS you use, Upsun has you covered. With support for 10 languages, frameworks, and fully managed services like databases, search, and caching.

## Ready to experience the difference?

We understand that switching platforms is a big step, start with our 15-day free trial and explore Upsun at no cost. You can also schedule a demo to speak with an expert.

Zero effort, 0 commitment required upfront. Get started with our $0 free tier and experience the difference for yourself

One centralized PaaS handles ops, storage, security, previews, and more. Sign one contract, pay one bill, and let your developers focus on one thing: coding

Create byte-for-byte clones of your production environment in under 2 minutes, making updates simple, safe, and straightforward

Get a 3% discount when you deploy and manage applications at data centers in our incentive-eligible greener regions.

"Costs have decreased by more than 60% everything has become easier and, above all, faster." —Manfred Ruf, IT Manager, UNICEF

### [Heroku Enterprise Alternatives: Graduate to Upsun for the Next Decade](https://upsun.com/alternative-heroku/)

# Has your team _outgrown Heroku_?

Migrate from Heroku to Upsun without changing your stack. Upsun keeps the simplicity you already know, but with developer velocity, with the security, observability, innovation, and pricing transparency that modern enterprises actually need.

Heroku Enterprise Alternatives: Graduate to Upsun for the Next Decade

Strategic roadmaps require certainty. Discover why enterprises are migrating from Heroku to Upsun for 99.99% uptime, multi-cloud sovereignty, and AI-native infrastructure.

## The trade-offs you no longer have to make

Every platform forces a decision. On legacy PaaS providers, you typically accept these constraints in exchange for simplicity. On Upsun, you get the simplicity without the trade-off.

- Preview environments vs production parity: Upsun clones code, data, and services byte-for-byte in under a minute.
- Cloud choice vs unified workflow: Upsun runs on AWS, Azure, GCP, OVHcloud, or IBM Cloud with a single, consistent workflow.
- Developer simplicity vs enterprise governance: Skip the pricey shield tiers. Upsun provides SOC 2 and HIPAA readiness natively without complex manual configuration.
- Continuous profiling vs tool sprawl: Deep performance insights usually require an expensive, separate observability stack.
- OpenTelemetry support and Blackfire profiling natively: Get real-time anomaly detection and function-level insights without managing external integrations.

| Feature | Upsun | Competitor | Details |
| --- | --- | --- | --- |
| Multi-cloud | AWS, Azure, OVH, IBM Cloud, GCP | AWS only | **Upsun** offers options on AWS, Azure, Google Cloud, IBM Cloud, and OVH. Seamlessly switch cloud providers to meet your application and business needs. **Heroku** runs exclusively on AWS. An outage affects all hosted applications, and migration requires rebuilding infrastructure from scratch. |
| Preview environments | Byte-for-byte production clone | Manual setup; no automated environment parity | **Upsun** creates exact replicas of code, data, and config in under a minute. **Heroku** requires manual configuration and separate data uploads for staging. |
| Request timeout | Unlimited | Fixed 30-second limit | **Upsun** handles large file transfers and long-running processes without interruption. **Heroku’s** router terminates any connection exceeding 30 seconds. |
| Compute architecture | Architecture flexible (x86 or ARM) | Mandatory ARM (Graviton) | **Upsun** lets you run on x86 or ARM per project. No forced architecture changes, or separate builds for ARM-incompatible dependencies. **Heroku's** Fir generation runs on ARM only. Applications with x86-specific dependencies may require code changes to remain compatible. |
| Resource scaling | Granular vCPU + RAM | Fixed dyno tiers | **Upsun** resources scale linearly, allocate the exact vCPU and RAM your workload needs, and you pay only for what you provision. **Heroku** dynos come in fixed sizes. Scaling means jumping to the next tier, which often means paying for more than you need. |
| Persistent storage | Internal storage included | 3rd-party add-on required | On **Upsun**, persistent storage is included by default. Mount writable directories directly in your app configuration. **Heroku's** filesystem resets on every dyno restart. Persistent storage requires a paid third-party add-on. |
| Security | Built-in WAF | Third-party add-on required | **Upsun** includes built-in WAF and rate limiting, active by default across all environments. **Heroku** has no built-in WAF or DDoS mitigation. Both require third-party add-ons, configured and billed separately. |
| Data protection | Internal data protection | Premium add-on | **Upsun** includes encryption at rest and in transit, automated backups, and point-in-time recovery across all plans. HIPAA-eligible data protection on **Heroku** requires a Shield Private Space, available on enterprise plans only. |
| Compliance | Natively integrated Blackfire profiling | OTel log drains only; no profiling | **Upsun** is certified ISO/IEC 27001, SOC 2 Type 2, PCI DSS Level 1, and HIPAA-eligible. Compliance monitoring is automated across all environments. **Heroku** holds SOC 2 Type 2 certification and supports PCI compliance within Shield Private Spaces. |
| Cron jobs | Internal (no usage fee) | Add-on with usage fees | **Upsun** includes cron jobs within each application at no extra cost. **Heroku's** scheduler add-on is often unreliable and counts toward billable usage. |
| AI infrastructure | Native MCP server | Standard API access | **Upsun** provides AI agents (Cursor, Claude) with real-time infrastructure context via MCP. **Heroku** lacks native agentic integration. |
| Service restarts | On-demand control | Disruptive daily cycles | **Upsun** restarts are developer-controlled and on-demand; no forced cycling of running processes. **Heroku** dynos restart automatically at least once every 24 hours. Cedar-generation apps cannot disable this behavior. |

Need more details? Check [this post](/blog/heroku-vs-upsun/) with a more technical overview.

## Built for how modern teams work

### Define your stack in code

Your entire infrastructure (services, runtimes, and relationships) is defined in a single configuration file within your Git repository. No dashboard-driven manual configuration or add-on sprawl.

### Git branch to clone

Upsun triggers an instant, data-complete preview environment for every pull request. Test migrations and new features against byte-for-byte copies of production data in under a minute.

### One platform, everything included

DDoS protection, persistent storage, cron jobs, observability, and automated backups are built in. One contract, one bill, no third-party add-ons to provision, configure, or maintain.

### Transparent and predictable pricing

Pay only for the resources you provision. No dyno tier jumps, step-increase, surcharges, or surprise invoices when your app performs well. Spending alerts keep your budget exactly where you set it.

## How migrating to Upsun works

### Assessment

Book a demo call with Upsun's migration team. We map your current Heroku stack: dynos, add-ons, config vars, and dependencies, and identify blockers before you commit to anything.

### Mapping

Your entire infrastructure is defined in a single YAML configuration file and deployed to a Upsun sandbox. Services, runtimes, and relationships verified against your production setup.

### Migration

Same buildpacks, same git push workflow, minimal changes to your application code. Upsun's team works alongside yours throughout the transition. Most teams are live in 30 days or less.

### Go live

Production cutover with zero service interruption. DNS cutover, Fastly CDN activated, and Blackfire profiling confirming performance against your production baseline.

"Costs have decreased by more than 60% everything has become easier and, above all, faster." —Manfred Ruf, IT Manager, UNICEF

## FAQs

### Do I need to rewrite my application to migrate from Heroku to Upsun?

No. Upsun supports the same Cloud Native Buildpacks Heroku uses, so most applications run with minimal or no changes. Your git push workflow stays intact. Config vars map directly. The main change is a single YAML file that defines your infrastructure: services, runtimes, and relationships, replacing dashboard-driven manual configuration.

### How long does migration take?

Most teams are live in 30 days or less. Easypara, a large-scale Magento 2 ecommerce platform with a multi-million-row database, completed its full migration in 30 days with zero service interruption.

### What happens to my Heroku add-ons?

Most of Heroku's add-ons are built into Upsun at no extra cost: DDoS protection, persistent storage, cron jobs, observability via OpenTelemetry and Blackfire, and automated backups. Third-party add-ons that connect via API keys and environment variables, such as New Relic, continue to work after migration by copying over the relevant config vars.

### What migration support does Upsun provide?

Upsun offers a 20-minute architecture audit to assess your stack before you commit to anything, followed by hands-on white-glove migration support throughout the transition. The audit is a factual go/no-go assessment.

### How does Upsun pricing compare to Heroku?

Upsun bills linearly; you provision the exact vCPU and RAM your workload needs and pay only for what you provision. No dyno tier jumps, step-increases, and surcharges when your application performs well. Spending alerts notify you when your monthly estimate crosses a threshold you set.

### [Where humans and agents ship code together | Upsun](https://upsun.com/dispatch/)

# Help us _build a new SDLC_

Agents do the volume. Your team holds the line.

AI helped your engineers ship more code. It didn't help your team ship more product. Upsun Dispatch™ is built to fix that. And we need you to help us build it.

Join us in rewriting the SDLC to put an end to: unaudited agent output, overloaded reviews, lost audit trails, and runaway costs.

See it in action, watch the demo

Where humans and agents ship code together | Upsun

Upsun Dispatch is a new SDLC where AI agents do the volume and your team holds the line. Sandboxed runs, audited workflows, tracked costs. Join the waitlist

## Writing the code is no longer the challenge. _It's everything around it._

-   The review queue absorbed every productivity gain. Senior engineers spend half their week clearing PRs they didn't write, didn't plan, and can't fully reason about.
-   Code reaches production with no traceable author, intent, or approval. Something breaks and the engineer reading the diff can't reconstruct who decided this should exist.
-   A workflow that cost cents yesterday costs dollars today. There’s no visibility into why, no way to predict what comes next, and by the time anyone notices the cost, the run is already done.

## Where humans and agents _ship together_

You bring the repo, the API keys, the team. Upsun Dispatch™ runs the rest.

-   Agents run inside isolated sandboxes, completely detached from your live infrastructure. Nothing reaches production unless a human approved it.
-   Every workflow is a structured sequence of agent and human steps. Every gate requires a real decision, not a notification.
-   Every run is logged, every cost is tracked, every decision has a timestamp. The record is there before anyone asks for it.

### Agents

Bring any model. Switch when you need to. The platform governs the run, not the model.

### Sandboxes

When an agent writes code, it runs in an isolated sandbox, completely detached from your live infrastructure. Nothing reaches production unless a human approved it.

### Workflows

Each workflow is a structured sequence of agent and human steps. Every decision is recorded. Every gate requires real action.

### Observability

Every run is logged. Every cost is tracked. Every decision has a timestamp. The record is there before anyone asks for it.

## See it _in action_

Watch Upsun Dispatch™ run real workflows end to end, from an incoming issue to a merged change, with a human approving every decision that matters.

## The SDLC wasn't built for agents. _We're fixing that._

### The workflow is the unit, not the agent

Most platforms make the agent the main thing. We make the workflow the main thing: a structured process where humans and agents are peers and the whole chain is recorded. Better models don't change that. The workflow is still the unit.

### Humans decide how much autonomy agents get

Autonomy is earned, not assumed. A person grants it, based on the agent's track record: the agent that has never been wrong earns more room, the one that shipped a regression gets the gate tightened.

### Teams want a working pattern, not a framework to build themselves

The market is full of primitives that ask you to compose your own. Most teams don't want to. They want something that works out of the box, that they can customize when they outgrow it, and never have to rebuild from scratch.

## What it means to _join early_

### Direct access

You work directly with the engineering team building Upsun Dispatch. Not a support queue.

### Real input on the roadmap

You help decide which workflows ship first and how they work. Your feedback changes the product.

### Charter terms

Founding partners get charter commercial terms that reflect the partnership.

### [Preview environments for every pull request | Upsun](https://upsun.com/preview-envs/)

# _Preview environments_ for every pull request

Every branch gets its own isolated environment, with your full stack, services, and data, automatically. No setup. No shared staging conflicts.

Preview environments for every pull request | Upsun

Automatically generate isolated, full-stack preview environments from branches and pull requests. Test code, services, and data safely before merge.

- Adobe
- The Economist
- Oris
- Freitag
- A+E
- The British Museum

## Built for teams who ship continuously

Upsun connects to your Git workflow and provisions a full-stack environment for every branch or pull request automatically. Code, databases, and services included. Test in production-like conditions before anything ships.

### Staging conflicts

Multiple features competing for the same environment delay reviews and create coordination overhead.

### Environment drift

Shared staging diverges from production over time, so issues caught there may not reflect what actually happens in production.

### Manual setup overhead

Spinning up a test environment means writing scripts, coordinating with platform teams, or waiting. Upsun removes that work entirely.

### Uncertain deployments

When you cannot test against a real stack before releasing, you ship with less confidence.

### From pull request to environment in seconds

### Open a branch or pull request

Upsun detects the new branch from your connected Git repository. Each update triggers a rebuild so previews stay aligned with code changes.

### Your full stack is provisioned automatically

The platform clones your application, services, databases, and infrastructure configuration into a dedicated environment. No scripts. No manual steps.

### Review, test, and share

Developers, QA, and stakeholders get a live URL. Test independently. Share with anyone. When a branch is no longer active, Upsun pauses the environment automatically.

## Everything your team needs to review with confidence

Upsun provisions complete environments, not just app containers. Your databases, caches, queues, and background workers are all there. What your team tests is what your users will see.

### Automatic environment creation

Every branch and pull request gets its own environment, provisioned the moment a branch is pushed.

### Full-stack cloning

Code, configuration, databases, caches, queues, and services are cloned together. No partial environments.

### Git-native workflow

Upsun works directly with your existing Git workflow. No new tools. No new processes.

### Complete environment isolation

Each branch runs independently. Changes in one environment cannot impact production or any other preview.

### Production-like infrastructure

Environments are configured from the same infrastructure-as-code file as production. What you test is what you ship.

### Safe data handling

Tunnel into preview databases to test migrations. Configure sanitization scripts in your deploy hook to automatically scrub PII from every cloned environment. No manual data copying.

## What teams use preview environments for

### Pull request validation

Every PR gets a live environment. Reviewers can test the change directly, not just read the diff.

### Database migrations

Validate schema changes against a production-grade dataset before they go anywhere near production.

### QA and stakeholder sign-off

Share a branch URL with QA teams or non-technical stakeholders. No staging access required.

### Parallel feature development

Multiple teams ship simultaneously without fighting over a shared environment.

"This morning, we launched a new development environment to test a disruptive feature. That would've been a huge ordeal in our old setup. Now it's just part of the workflow." —Geoff Douglas, VP of Engineering, MarketNation

### [Get in touch with Upsun experts](https://upsun.com/contact-flyio/)

# _Outgrown Fly.io_? Let's talk.

Tell us what you need. We'll show you how Upsun compares.

**What happens after you submit:**

1.  We review your request and your context
2.  A technical expert gets back to you within 1 business day
3.  You get a 30-minute discussion focused on your stack, goals, and questions 

_Costs have decreased by more than **60%**_ _everything has become easier and, above all, faster._  
– Manfred Ruf, IT Manager, UNICEF

Get in touch with Upsun experts

- University of Oxford
- UNICEF
- Adobe
- Mentos
- Unity
- GAP

### [Acquia alternative with predictable pricing | Upsun](https://upsun.com/alternative-acquia/)

# Great ideas should not be _limited by infrastructure_

Get your team the right deployment platform without the restrictions. No matter what you run on, Upsun provides you with the infrastructure and integrated tooling to deploy anything, anywhere, without vendor lock-in.

Acquia alternative with predictable pricing | Upsun

Acquia alternative with multi-cloud control, unlimited clones, built-in security and APM, and predictable pricing. Start free for 15 days

| Feature | Upsun | Competitor | Details |
| --- | --- | --- | --- |
| Cloud provider | AWS, Azure, Google Cloud, OVHcloud, IBM | AWS only | Upsun offers flexibility with multiple IaaS providers and regions, enabling users to switch cloud providers as needed to meet their application and business requirements. Acquia relies exclusively on Amazon Web Services (AWS) infrastructure and hosts only in AWS regions. |
| Language support | Native support for 10 programming languages | Drupal-based | Upsun supports the latest versions of 10 programming languages and a wide array of frameworks. Acquia specifically supports Drupal modules and JavaScript, but not as a server-side application. |
| Environment cloning | Unlimited production clones | Limited staging environments | Upsun instantly replicates your production clones, which means you can test every change with real data before going live in minutes. Acquia provides staging environments with manual data copying operations and lacks true production-like cloning with real data and infrastructure replication. |
| Transparent pricing | Transparent & predictable pricing models | Enterprise pricing + hidden charges | Upsun offers flexibility with two pricing options: pay only for the resources you provision, or choose a fixed monthly tier plan. Acquia offers enterprise pricing with annual contracts starting at $141/month. However, most features require custom quotes, often reaching $100K+ annually. |
| Security & Compliance | Built-in Security | Built-in Security | Upsun offers a built-in Web Application Firewall (WAF), DDoS protection, and automated security patches across all plans without enterprise upgrade requirements. Acquia provides standard security features, but advanced security and compliance certifications are limited to enterprise plans. |
| Application Performance Monitoring | Built in APM | New Relic external; limited tiers | Upsun delivers function-level insights, combining observability and telemetry with built-in APM to enable data-driven decision-making. Acquia offers New Relic APM integration for users on the higher tier, and this requires external service configurations. |
| Managed Data Services | Fully supported | Limited | Upsun offers fully managed database caching and search services provisioned automatically per environment. Acquia database management is limited, often requiring external tooling or manual setup. |
| Container management | Git-based workflow | Traditional virtual machine | Upsun eliminates infrastructure complexity through native Git integration and automatic branch-to-environment mapping. Although Acquia uses containers internally, it follows traditional virtual machine management with manual deployments. |
| Team collaboration | Available | Available with limited collaboration features | With the Upsun team, members can collaborate seamlessly on a unified platform with granular access controls and instant onboarding. Acquia collaboration features require manual onboarding processes, which creates friction for efficient team workflow. |
| Traffic limits | Unlimited page views | Capped by plan tier | Upsun offers unlimited page views and traffic by default with need-based pricing for resources. Acquia caps service by monthly views and visits, based on your plan. Consistent traffic can trigger overage fees or force a plan upgrade. |

All the enterprise PaaS features you need— without complexity. [Contact sales](https://upsun.com/contact-us/) to schedule a demo.

## Why developers choose Upsun

### Predictable pricing

Upsun offers predictable pricing that fits every business needs. Choose between fixed tiered pricing or provision-based pricing, where you pay only for the resources you actually provision. Both models provide transparent and predictable billing with no traffic charges.

### Multi-cloud flexibility

Choose the cloud provider and region that fits your needs. Whether you're optimizing for performance or regulatory requirements, Upsun gives you control over where and how your applications run.

### 99.99% uptime available

Keep your applications online even through traffic spikes with 99.99% contractable uptime available, automated disaster recovery, and a dedicated 24/7 support team.

### Team collaboration and control

Manage projects, team members, and environments from a single dashboard with granular permissions. Share live preview environments with stakeholders without complex setup.

## Ready to leave the limitations behind?

We understand that choosing a cloud provider is a big decision. Start with our free tier, spend 15 days. You'll see why over 16,000 developers choose the transparency, flexibility, and autonomy we provide.

Zero effort, 0 commitment required upfront. Get started with our $0 free tier and experience the difference for yourself

One centralized PaaS handles ops, storage, security, previews, and more. Sign one contract, pay one bill, and let your developers focus on one thing: coding

Create byte-for-byte clones of your production environment in under 2 minutes, making updates simple, safe, and straightforward

Get a 3% discount when you deploy and manage applications at data centers in our incentive-eligible greener regions.

"Costs have decreased by more than 60% everything has become easier and, above all, faster." —Manfred Ruf, IT Manager, UNICEF

### [Platform.sh is now Upsun — Same platform, new name](https://upsun.com/platform-sh-is-now-upsun/)

# The evolution of _your trusted platform_

You’ll still work with the team and tech you know; we’ve simply adopted a name that points to what’s next for you. Your apps keep running smoothly. The platform you rely on isn’t going anywhere.

Industry leaders in finance, retail, education, and the public sector rely on Upsun to power their most critical applications.

[Platform.sh is now Upsun](/blog/platformsh-evolves-into-upsun/)

Platform.sh is now Upsun — Same platform, new name

Platform.sh became Upsun — same reliable cloud app platform, team, and 24/7 support. Zero disruption, transparent updates, and a unified console.

## The name for our next chapter

We expanded above and beyond our original scope as developers rapidly adopted our platform for AI applications and enterprise modernization. The name Platform.sh no longer captured the full value and scope of what we created. We needed a name that embodies our vision and accelerates the future you're building.

Up: Outstanding reliability and a continuous improvement path that removes obstacles to innovation

Sun: Global 24/7 support and a continued focus on making development work both productive and enjoyable

## What stays the same

Trust our seamless continuity and the experience you expect, delivered by the same experienced team you rely on; Now called Upsun Fixed.

-   **Core tech:** Access the same powerful cloud application platform
-   **Workflows:** Continue your Git-based processes and preview environments
-   **Support:** Rely on our 24/7 support
-   **Multi-cloud:** Deploy across AWS, Azure, Google Cloud, IBM and OVHcloud
-   **Uptime:** Trust in enterprise-grade reliability with continuous monitoring

## What's new: a renewed commitment to your future

Upsun Flex helps you manage projects & gives you control to configure the exact resources you need at the container level.

-   **Support AI-powered development** and **AI-augmented applications**: Keep humans sane and productive and AI agents fed with the structured data they crave.
-   **Container-level resource management:** Manage resources at the container level, so you can direct capacity where it matters most and pay only for what you actually use.
-   **Unified console experience:** Handle every app from one dashboard, so you're not jumping between tools or tabs.

## Uninterrupted, as always.

Your projects keep moving while we shift to Upsun.com. You’ll get real updates at every step, so nothing catches you off guard. It’s one brand, and the same reliable infrastructure you've come to trust.

- Zero disruption
- Transparent communication
- Brand convergence

### [Shopware PaaS hosting for high-growth stores | Upsun](https://upsun.com/shopware/)

# Shopware PaaS: _the best of both worlds_

Get the customizability of self-hosted with the simplicity of SaaS. Test with your production data in isolated preview environments. Deploy on every commit. Scale from launch to enterprise. 

Spin up production-perfect previews with full Shopware data in minutes, proven at 7,000+ orders/day with sub-600ms p95 on core pages; documented on Shopware.

Trusted by 45+ Shopware stores across EMEA and North America

Shopware PaaS hosting for high-growth stores | Upsun

Run Shopware as PaaS: production-perfect previews, proven performance, and partner support for agencies and brands on Upsun

## Upsun powers Shopware PaaS.

Your clients get proven dev-to-prod patterns from 45+ Shopware stores. You get instant credibility. Join our partner program for co-marketing support, MDF, and access to partnership resources.

### Instant, production-perfect previews

Copy-on-write [data cloning](https://developer.shopware.com/docs/v6.4/guides/plugins/apps/hosting-guide/platform-sh-deployment.html)

### Automatic TLS + containerized services

Production-identical resource allocation [Complete isolation](https://developer.shopware.com/docs/v6.4/guides/plugins/apps/hosting-guide/platform-sh-deployment.html)

### Git-based previews on every branch

Production-identical [configuration](https://developer.shopware.com/docs/v6.4/guides/plugins/apps/hosting-guide/platform-sh-deployment.html)

### What Shopware says

“_The best of both worlds—total customizability and flexibility you get from self-hosted but you get like a really sophisticated and professional way of running shopware.”_

**Jörn Paulsen**, Strategic Business Development Manager, Shopware

### What Shopware agencies say

_"Shopware and Upsun eliminate the classic hosting-agency blame game by delivering the platform from a single source."_

**Yann Karl**, CTO, Strix

## What we're doing together

### Deploy Shopware on Upsun

Step-by-step deployment guide with integration patterns field-tested in production. [View deployment guide](https://developer.shopware.com/docs/products/paas/shopware-paas/)

### Shopware performance under load

Real-world load testing across 7 infrastructure tiers. See how Shopware handles 7,000+ orders/day with sub-600ms response times.
[Get the performance guide](https://upsun.com/blog/shopware-performance-load-testing-guide/)

### Shopware community events

Connect with Shopware developers and agency partners at events across North America and EMEA. [View events calendar](https://www.shopware.com/en/events/)

### Shopware white paper

Technical deep-dive featuring Eagle Crusher and other customer deployments. Performance tuning, scaling strategies, and real-world results. [Get the white paper](/shopware-paas-upsun-definitive-performance-guide.pdf)

### Why Shopware stores slow down

Debug logging, plugin bloat, cache issues: the most common Shopware performance issues—and how to fix them.
[Learn how to fix them](https://upsun.com/blog/optimize-shopware-for-speed/)

## Building Shopware stores for clients?

Join the Upsun Partner Program. Get infrastructure you can trust, plus co-marketing support, revenue share, and solution architects.⁠   
During your first 30 days, you’ll get access to essential resources and support designed to help you ramp up quickly

- Partner program onboarding and orientation
- Access to co-marketing resources⁠
- Technical docs and support materials⁠
- Tier-match evaluation (if migrating existing portfolios)
- Initial partnership planning and goal-setting

## Frequently asked questions

### How do I deploy Shopware on Upsun?

It's simpler than traditional hosting. Define your infrastructure in **.upsun/config.yaml**, push to Git, and your environment spins up with TLS, database, and services already configured. No manual server work needed. View the official deployment guide

### How does Shopware perform on Upsun?

We tested Shopware across seven tiers using K6 load tests that mirror real traffic patterns. Results: 7,000+ orders/day sustained with p95 TTFB under 600ms on core pages, even mid-tier plans. Platform includes instant previews, copy-on-write cloning, expert plugin support, and Shopware-tuned infrastructure. Get the performance guide

### What are production-perfect preview environments?

Previews use copy-on-write technology to clone your Shopware store's data, code, and configuration. Each branch gets its own safe, realistic environment with automatic TLS and unique URLs, all without touching production.

### What benefits does the Upsun partner program offer?

Partners get co-marketing support, MDF, access to solution architects, lead-sharing, and developer certification (1-8 developers based on tier). Revenue tiers progress from Bronze through Diamond, with increasing benefits at each level. We also offer tier-match for eligible portfolio migrations. Join to grow your business

### How is Upsun different from generic cloud hosting?

Generic cloud hosts provide raw compute without Shopware-specific optimization or expert support. Upsun is built for Shopware specifically. You get a tuned stack, instant previews with production data, and expert help when misconfigured plugins or seasonal traffic spikes hit. Analysis shows we're 12x more CPU-efficient than AWS EC2.

### How does the partner program tier-match work?

If you're migrating an existing Shopware portfolio to Upsun, we'll evaluate your situation and potentially match you to a higher tier (Silver, Gold, Platinum, or Diamond) to accelerate your partnership benefits. Reach out to discuss eligibility.

### Can I test Upsun with a client project before committing?

Yes. Start with a trial Shopware project. You get full access to production-perfect preview environments, copy-on-write data cloning, and the complete platform.

### [We support open source | Upsun](https://upsun.com/community/open-source/)

# We support Open Source

Upsun is built on Open Source software and without the contributions of our fellow software lovers, our platform wouldn’t be what it is today. That’s why we want to be champions of Open Source by sponsoring incredible projects around the world that can benefit us all as a global development community.

We support open source | Upsun

Upsun champions incredible open source projects that benefit our global development community through our Community Sites Program. Find out more here.

## Our sponsored projects

### Drupal Association

[The Drupal Association](https://www.drupal.org/association) is dedicated to making Drupal as great as possible. This Open Source non-profit focuses on improving Drupal and growing the Drupal community worldwide to support the project’s objective to create a secure, open web for everyone.

### DDEV

[DDEV](https://ddev.com/) is a widely-used, flexible Docker-based PHP local development tool with a huge community of supporters, contributors, and users from all around the world. We wanted to support DDEV in its continued growth and success and so in May of 2022 we became the Lead Sponsor of the project.

### Symfony

[Symfony](https://symfony.com/) is a powerful set of reusable PHP components and PHP framework for web projects and we are proud to host them on Upsun. Symfony is certainly making PHP development more flexible, efficient, and creative for developers everywhere and that’s why they’re a key member in our program.

### Sylius

[Sylius](https://sylius.com/) is a modern platform for tailored eCommerce solutions fully based on Symfony.
It is constructed from fully decoupled and flexible e-commerce components for PHP. It is also a set of Symfony bundles, which integrate the components into the full-stack framework. On top of that, Sylius is also a complete e-commerce platform crafted from all these building blocks.
Blackfire, a part of Upsun, supports Sylius with a monthly donation, and a free Production subscription.

### Doctrine

[The Doctrine Project](https://www.doctrine-project.org/) is the home to several PHP libraries primarily focused on database storage and object mapping. The core projects are the Object Relational Mapper (ORM) and the Database Abstraction Layer (DBAL) it is built upon.

### PHPStan

[PHPStan](https://github.com/phpstan/phpstan) is a static code analyzer that focuses on finding errors in your code without actually running it. It catches whole classes of bugs even before you write tests for the code. It moves PHP closer to compiled languages in the sense that the correctness of each line of the code can be checked before you run the actual line. Blackfire supports PHPStan with a monthly donation.

### Twig

[Twig](https://twig.symfony.com/) is a template language for PHP, released under the new BSD license (code and documentation). Twig uses a syntax similar to the Django and Jinja template languages which inspired the Twig runtime environment. Blackfire, a part of Upsun, supports Twig with a monthly donation.

### Whoops

[Whoops](https://github.com/filp/whoops) is an error handler framework for PHP. Out-of-the-box, it provides a pretty error interface that helps you debug your web projects, but at heart it’s a simple yet powerful stacked error handling system. Blackfire, a part of Upsun, supports whoops with a monthly donation.

### [See it in action](https://upsun.com/see-it-in-action/)

# Stop the Shadow IT cycle

Transition from manual gates to automated guardrails. Speak with a technical expert to see how Upsun can codify your governance and reclaim your team's velocity.

-   **Dismantle the "Hidden Factory":** Identify where your team is losing 12+ hours a week to manual "glue work."
-   **Deploy "Golden Paths":** Learn to provide self-service autonomy without increasing security or budget risk.
-   **Standardize via Git:** See how `.upsun/config.yaml` replaces static PDF policies with enforceable, versioned code

See it in action

Speak with a technical expert to see how Upsun can codify your governance and reclaim your team's velocity

### [What does Upsun really do? Request a Demo | Upsun](https://upsun.com/demo/)

# Automate. Collaborate. _Accelerate._

An Upsun in-depth demo.

If you’re a developer currently using Upsun and need support, connect with us on our community forum.

What does Upsun really do? Request a Demo | Upsun

Schedule a personalized demo to see how Upsun’s flexible platform gives you full control to build and manage cutting-edge websites and applications.

"Upsun is a fairly easy product for the amount of complexity it can handle. That’s the magic." —Lukas Kahwe Smith, CTO and Co-founder, WittyWorks

### [Get in touch with Upsun experts](https://upsun.com/contact-aws/)

# Simplify your _AWS complexity_

Tell us what you need. We'll show you how Upsun compares.

**What happens after you submit:**

1.  We review your request and your context
2.  A technical expert gets back to you within 1 business day
3.  You get a 30-minute discussion focused on your stack, goals, and questions 

_Costs have decreased by more than **60%**_ _everything has become easier and, above all, faster._  
– Manfred Ruf, IT Manager, UNICEF

Get in touch with Upsun experts

- University of Oxford
- UNICEF
- Adobe
- Mentos
- Unity
- GAP

### [Get in touch with Upsun experts](https://upsun.com/contact-acquia/)

# Moving off _Acquia_? We can help.

Tell us about your environment. We'll walk you through the switch.

**What happens after you submit:**

1.  We review your request and your context
2.  A technical expert gets back to you within 1 business day
3.  You get a 30-minute discussion focused on your stack, goals, and questions 

_Costs have decreased by more than **60%**_ _everything has become easier and, above all, faster._  
– Manfred Ruf, IT Manager, UNICEF

Get in touch with Upsun experts

- University of Oxford
- UNICEF
- Adobe
- Mentos
- Unity
- GAP

### [Get in touch with Upsun experts](https://upsun.com/contact-render/)

# Switching from _Render_? Let's talk.

Tell us what you need. We'll show you how Upsun compares.

**What happens after you submit:**

1.  We review your request and your context
2.  A technical expert gets back to you within 1 business day
3.  You get a 30-minute discussion focused on your stack, goals, and questions 

_Costs have decreased by more than **60%**_ _everything has become easier and, above all, faster._  
– Manfred Ruf, IT Manager, UNICEF

Get in touch with Upsun experts

- University of Oxford
- UNICEF
- Adobe
- Mentos
- Unity
- GAP

### [Professional services for platform engineering | Upsun](https://upsun.com/services/)

# Accelerate your success with _Upsun services_

Onboarding, application services, and an ongoing expert partnership for customers with commitment plans. From first deployment to production scale, our teams help you get the most out of Upsun.

Professional services for platform engineering | Upsun

Ship with confidence using Upsun professional services. We offer structured onboarding, ongoing application support, and expert architecture guidance

## Services for every stages of your journey

Our services are designed for customers with commitment plans. All leads go through the sales team for qualification, commitment plan development, and management.

### Onboarding services

A structured journey from contract to go-live, including configuration, staging setup, and training, so your team feels confident from day one.

### Application services

Hands-on engineering help inside your own application stack: migrations, performance testing, framework upgrades, modernization, and ongoing application support.

### Expert services

An ongoing advisory partnership covering architecture, security and compliance, incident response, and business alignment, scaled to your engagement.

## Onboarding services

Structured onboarding helps your team get up and running on Upsun with confidence, from contract to go-live.

- Guided environment setup and configuration.
- Staging deployment and testing support.
- Migration assistance.
- Technical training sessions.
- Slack-based collaboration during fine‑tuning.
- Hands‑on guidance through production launch.

Onboarding services are available for new customers, with scope defined in your contract.

## Need help with a larger migration or modernization?

For complex or multi-site projects, our implementation experts can support full end-to-end delivery.

## Expert services

Ongoing, expert-led guidance with a dedicated team to help you optimize architecture, strengthen security, manage incidents proactively, and align platform performance with your business objectives.

- Architecture and cost optimization reviews.
- Security and compliance assistance.
- Incident response and root cause analysis.
- Performance reporting and business alignment.

### How expert services works

-   Scoped as a project through Sales and Customer Success.
-   Delivered by senior technical success managers.
-   Defined outcomes, timelines, and responsibilities.

Talk to an implementation architect

## Application services

Ongoing technical services for your applications on Upsun. Our application services team provides hands-on operational support for the applications you run on Upsun, going beyond platform support to help you manage and optimize your application lifecycle.

- DevOps pipeline configuration.
- Preview environment management.
- Application observability and monitoring.
- Release automation and deployment workflows.
- Application lifecycle assistance.

_**Note:** Application services are scoped based on your architecture and requirements. Your Upsun representative can help determine availability and fit._

## FAQs

### Does Upsun perform migrations?

Yes, through Application Services.

### How long does onboarding take?

Most onboarding follows a 45–90 day plan depending on scope.

## Need help _right now?_

### Open a support ticket.

### Check our documentation.

### [Team and access management with centralized control | Upsun](https://upsun.com/features/team-and-access-management/)

# Control access _across projects_ without slowing teams down

Centralized control for organization owners to grant, scope, and revoke access across every project and environment.

Team and access management with centralized control | Upsun

Manage users and permissions centrally across projects and environments. Enforce least-privilege roles, speed up onboarding, and keep access changes auditable.

## Define who can do what at every level

### Define at the right level

Define roles at the organization, project, or environment-type level. Apply them to one project or many.

### Scoped by environment type

Production, Staging, and Development can each have their own rules inside the same project. No juggling per-environment permissions by hand.

### Managed in one place

Console, CLI, and API. No third-party identity stack to plug in and maintain.

## Access controls that match how teams work

Manage access across organizations, projects, and environments. Permissions stay close to how your teams already work.

- Organization-level user management.
- Project admin and project viewer roles.
- Grant environment type roles for production, staging, and development.
- Team-based access across selected projects.
- User invitations and permission updates.
- Access removal at project, team, and organization level.
- Manage everything through the Console, CLI, or API. No shared credentials needed.

## How team and access management works on Upsun

### Set project-level roles

Control whether a user can administer a project or only view it. Project admins can manage access, change settings, push code, and execute actions across environments.

### Apply environment type roles

Set different permissions for production, staging, and development environments. A developer can contribute in development while having view-only access to production.

### Use teams for shared access

Create teams for groups such as developers, QA, agencies, or platform engineers. Add users and projects to a team, then manage shared permissions from one place.

### Administer access from the Console or CLI

Use the Console for guided access management or the CLI for repeatable workflows. Update, remove, or review access as teams and projects change.

### Compliance by design

A consistent permission model across every project supports SOC 2, ISO 27001, HIPAA, and PCI workflows. Access controls are repeatable and documented.

### Onboarding and offboarding in one workflow

Upsun simplifies onboarding and offboarding through a single control plane. No need to manually configure access across systems.

### [Built-in observability, APM, and profiling | Upsun](https://upsun.com/features/observability-apm-and-profiling/)

# See exactly how your _application behaves in production_

Built-in observability across your entire stack, including infrastructure metrics, application performance monitoring, and profiling, without deploying or maintaining separate monitoring infrastructure.

Built-in observability, APM, and profiling | Upsun

Built-in metrics, APM, and profiling to diagnose issues and optimize performance. Get traces and profiles for supported languages without extra tooling.

## Full-stack visibility, no extra tooling required

### Infrastructure and service metrics

Track resource usage, identify saturation points, and correlate infrastructure behavior with application changes across every environment.

### Application performance monitoring

Built-in APM for PHP and Python via Blackfire captures runtime behavior at the code level. Slow requests, expensive queries, inefficient execution paths, all against the real running environment, not synthetic tests.

### Profiling in real conditions

Continuous profiling across NodeJS, Go, Ruby, and Rust from the console, with Blackfire-powered profiling for PHP and Python. See how functions consume CPU and memory over time, without reproducing issues locally.

## From the HTTP layer down to the database query

Trace the exact path of a request through your entire stack and pinpoint where performance breaks down.

- Infrastructure and service-level metrics per environment
- Built-in APM for PHP and Python via Blackfire
- Continuous profiling across NodeJS, Go, Ruby, and Rust
- Visibility across preview, staging, and production environments
- Define performance budgets and block inefficient code on every deploy
- Centralized access through console, CLI, and API

## Built for teams that can't afford surprises in production

### Production debugging

An operations team investigates increased latency by reviewing APM traces and profiling results directly from the production environment. No reproduction steps, no guesswork.

### Pre-release validation

A team compares performance metrics between a preview environment and production before deploying. Issues caught before they reach users.

### Capacity planning

Engineers analyze long-term resource usage trends to make informed decisions about scaling and cost, based on real data rather than estimates.

### Security and isolation

Observability data scoped to your project and environments. Access governed by platform roles. Nothing leaks across projects.

### No operational overhead

Monitoring and profiling managed by the platform. No separate observability stack to deploy, upgrade, or maintain.

### Minimal performance impact

Profiling enabled selectively by environment or use case. See the impact of changes before they go into production, without adding runtime overhead.

### [Integrations and webhooks for automated workflows | Upsun](https://upsun.com/features/integrations-and-webhooks/)

# Connect the _tools and workflows_ you already use

Integrations and webhooks connect every push, deploy, and backup to your existing workflows, without custom polling or manual updates.

Integrations and webhooks for automated workflows | Upsun

Connect Upsun events to external systems with integrations, webhooks, and activity scripts. Automate responses to deployments and environment changes.

## Connected to your delivery workflow

### Connect your source repository

Use GitHub, GitLab, or Bitbucket as the source of truth for your code. Upsun mirrors the repository and manages environments from branch and pull request activity.

### Trigger environment actions from Git

Create branches, open pull requests, push code, and merge changes in your source repository. Upsun can create, rebuild, and remove matching environments based on that activity.

### Activity scripts

Activity scripts run custom logic on platform events, with built-in utilities for HTTP requests, Slack, and Jira.

## Built for production-grade integrations

Upsun helps teams connect deployment activity to the tools that already support their release process.

- Native source integrations for GitHub, GitLab, and Bitbucket.
- Environments created automatically from branches and pull or merge requests.
- Rebuild environments when code changes.
- Activity scripts run on Upsun's infrastructure, with built-in utilities for HTTP requests, Slack, and Jira.
- Filter webhook events by activity type or branch.
- Sign webhook payloads with a shared key for verification.
- Manage every integration through the Console, the upsun CLI, or the REST API.

## Designed for how developer teams ship

### Automatic handoffs

Webhooks and source integrations move deployment status between tools automatically. No manual copying or missed updates.

### Preview for every branch

When a pull or merge request is opened, Upsun creates a preview environment and reports the URL back to the request. Reviewers click straight into the running change.

### Disconnected release workflows

Code, environments, CI, and internal systems often live in separate places. Integrations keep them in sync without forcing teams into a new workflow.

### Custom automation overhead

Upsun runs activity scripts on its own infrastructure. No custom integration layer to monitor, debug, or maintain.

### Production gets through first

Activities run in parallel queues, and production activities are prioritized across all of them. A noisy preview environment can't hold up an urgent production event.

### Audit trails by default

Every integration logs its activities to the project. Inspect run history, view full logs, and replay failed events from the CLI or Console.

### [Upsun: Cloud application platform humans and robots love](https://upsun.com/about-us/)

# Upsun, the cloud application platform humans and AI agents love

Since 2009, we've evolved from Commerce Guys to Platform.sh to Upsun, consistently removing backend complexity so you can focus on building. Today, we expand this mission: giving both your team and AI tools the precise real-world context they need for predictable, reliable deployments that accelerate your work.

Upsun: Cloud application platform humans and robots love

Accelerate application modernization with AI-ready infrastructure. Trusted by 16,000+ developers across enterprise and growth companies. Start your free trial.

## Adobe, UNICEF, and more than 16,000 developers trust us

- Adobe
- UNICEF
- GAP
- Assa Abloy
- Colby College
- Columbia University
- ebsco
- first Foundation
- freitag
- hachette Livre
- havas Dublin
- invesco
- md Systems
- mentos
- mizzou
- nrdc
- orange
- oxford
- pacific Bank
- paul Scherrer institute
- randstad institute
- rhodes college
- sorbonne university
- university of surrey
- suzuki
- taboola
- unity
- university Of British Columbia
- u.s. chamber of commerce
- wittyWorks
- YMCA

## Meet the leaders driving Upsun forward

We're the team that supports AI-powered development and AI-augmented applications with infrastructure that provides the context needed for successful deployments.

### Frédéric Plais

Chief Executive Officer

### Caroline Bec Cox

Chief Financial Officer

### Caroline Leroy

Chief People Officer

### Doug Goldberg

Chief Customer Officer

### Fabien Potencier

Chief Product and Technology Officer

### Josh Bradbury

Chief Revenue Officer

### Tara Condon

Chief Marketing Officer

## Our board

### Eric Buatois

General Partner, Benhamou Global Ventures

### Eric Wittman

Independent Board Member

### Julian Mattes

Partner, Yttrium

### Matthieu Baret

Managing Partner, Eurazeo Venture

### Morgan Kessous

Partner, Revaia

### Pete Chung

Managing Principal, Morgan Stanley 
Expansion Capital

### Reza Malekzadeh

General Partner, Partech

### Stephane Kasriel

### Valérie Gombart

Co-founder, Hi Inov

## Our investors

Upsun is the new name for Platform.sh. All funding references below reflect our history as Platform.sh. We've raised over $180 million in equity funding from a global roster of current investors, including:

- Morgan Stanley
- Partech
- Eurazeo
- BGV
- Hi Inov
- Revaia
- Yttrium

## Our journey

We began as The Commerce Guys (2009), spun out as Platform.sh (2015), and grew to 250+ Upsunners in 43 countries. Today 16k+ devs, including Adobe, UNICEF, and more, run mission-critical apps on our cloud application platform.

### 2009

Founded as Commerce Guys, focusing on eCommerce and content-heavy solutions.

### 2015

Introduced fast cloning of full, production‑grade environments.

### 2020

Expanded multi‑cloud support across major providers.

### 2021

Acquired Blackfire.io to enhance application performance monitoring.

### 2023

Launched Upsun product to give customers more flexibility.

### 2024

Acquired B Corporation™ Certification. • Named in the 2024 Gartner® Magic Quadrant™ for Cloud Application Platforms.

### 2025

Recognized in French Tech 120 for the 6th consecutive year.[Platform.sh rebranded as Upsun.](/blog/platformsh-evolves-into-upsun/)

## Industry validation from leading analysts

Upsun, formerly Platform.sh. The recognitions below were awarded to Platform.sh and continue under the Upsun brand.

### Certified B Corporation

We are a Certified B Corporation, [verified by B Lab](https://www.bcorporation.net/en-us/find-a-b-corp/company/platformsh/). This holds us to high standards of accountability and transparency.

### 2025 Gartner® Magic Quadrant™ for Cloud-Native Application Platforms

Platform.sh (Upsun) recognized for second consecutive year. [Explore the full report](/gartner-2025/)

### G2 Grid Leader, Fall 2025

Top-rated by developers on G2. This recognition comes directly from verified [customer reviews.](https://www.g2.com/products/platform-sh/reviews)

## Who we serve

We work with teams across regulated industries and fast-growing companies.

### Financial services

### Higher education

### Retail

### SaaS and startups

### Travel and hospitality

### Government and public sector

### [Expert support plans and platform reliability | Upsun](https://upsun.com/priority-support/)

# 24/7 platform support _for every Upsun customer_

Keep your applications running smoothly with ticket-based support, fast SLAs, and direct access to platform engineers. Available to all Upsun customers, whether you're on self-service or a commitment plan.

Expert support plans and platform reliability | Upsun

Keep your projects running smoothly with our 24/7 expert support. Get direct access to platform engineers, fast SLAs, and continuous environment monitoring

## Support services

Our 24/7 emergency support team ensures your applications keep running round the clock.

- 24/7 coverage for urgent incidents.
- Ticket-based support available for eligible plans.
- Help with platform issues, configuration questions, and performance bottleneck analysis.
- Access to troubleshooting resources.
- Fast triage and access to Upsun engineers.

## Support tiers for Upsun Flex

All Upsun Flex customers have access to 24/7 help for production-impacting issues. Support tier upgrades provide faster response times and expanded coverage.

### **What this means for Flex customers**

-   All users can open support tickets for production outages or account/billing issues.
-   Default Flex support provides best-effort coverage for urgent issues.
-   Advanced and Premium add-ons unlock SLA-backed response times for P1, P2, and P3 tickets.
-   Support add-ons apply at the organization level.
-   Uptime SLA add-ons (99.9% / 99.99%) require Advanced or Premium Support.  
     

Talk to us about support details

## FAQs

### Do self-service users get support?

Yes. All organizations will receive ticket support for production outages and account/billing issues. Self-service users can also access Upsun’s community support and forums for general questions.

### How do I upgrade my support tier?

Your organization admin can upgrade your support tier directly  in the Upsun console, or you can contact your Account Manager.

### How do I contact the support team?

Open a ticket directly through the Upsun console.

## Need help _right now?_

### Open a support ticket.

### Check our documentation.

### [Get in touch with Upsun experts](https://upsun.com/contact-digitalocean/)

# Outgrowing _DigitalOcean_? Let's talk.

Tell us what you're building. We'll bring the right expert.

**What happens after you submit:**

1.  We review your request and your context
2.  A technical expert gets back to you within 1 business day
3.  You get a 30-minute discussion focused on your stack, goals, and questions 

_Costs have decreased by more than **60%**_ _everything has become easier and, above all, faster._  
– Manfred Ruf, IT Manager, UNICEF

Get in touch with Upsun experts

- University of Oxford
- UNICEF
- Adobe
- Mentos
- Unity
- GAP

### [Git-driven automation for repeatable workflows | Upsun](https://upsun.com/features/git-driven-automation/)

# Define your platform in Git. _Let Upsun do the rest._

Infrastructure, environments, and workflows are defined, versioned, and automated alongside your application code. GitOps out of the box, with no separate pipelines, no manual steps, and no undocumented decisions.

Git-driven automation for repeatable workflows | Upsun

Use Git as the control plane to automate environments, infrastructure, and workflows. Versioned config, event-driven actions, and full auditability.

## One source of truth. Every environment under control.

### Git as the source of truth

Application configuration, services, and environment behavior are all defined in Git. Every change goes through the same review and approval process as application code.

### Event-driven workflows

Upsun reacts to Git events: branch creation, commits, merges. Environments are created, rebuilt, and cleaned up automatically, without separate pipelines or tools.

### Integrated platform actions

Git-driven changes trigger native platform actions including builds, deployments, resource changes, and backups. Notify or orchestrate external systems via activity scripts and webhooks.

## Automation that works the way your team already does

Every action is versioned, reviewable, and repeatable. No ad hoc scripts, no manual steps.

- Every environment change goes through Git review
- Environments created and removed automatically on branch events
- Backups scheduled or triggered via API or CLI
- Notify external systems with activity scripts and webhooks
- API tokens replace shared credentials for automation
- Compatible with GitHub, GitLab, and Bitbucket

## Built for teams that need control without complexity

### Preview environment automation

A pull request automatically creates a full-stack preview environment. When it's merged, the environment is removed. No manual cleanup, no forgotten instances.

### Standardized platform operations

A platform team defines a shared configuration for services and resources. All teams inherit the same defaults through Git, ensuring consistency without enforcing uniformity.

### Controlled production changes

Infrastructure changes are proposed, reviewed, and merged through Git. GitOps for your platform layer, with a clear audit trail for compliance and internal reviews.

### Governance and control

Approval gates, code reviews, and policy enforcement built into the same workflow your team already uses. Guardrails that don't slow delivery.

### Security

Every configuration change committed, reviewed, and logged. Role-based access and API tokens instead of shared credentials. No side doors.

### Reliability

Every platform action executed consistently, every time. No ad hoc scripts, no manual steps, no drift.

### [Get in touch with Upsun experts](https://upsun.com/contact-vercel/)

# Ready to move beyond _Vercel_?

Tell us what you're evaluating. We'll connect you with the right expert.

**What happens after you submit:**

1.  We review your request and your context
2.  A technical expert gets back to you within 1 business day
3.  You get a 30-minute discussion focused on your stack, goals, and questions 

_Costs have decreased by more than **60%**_ _everything has become easier and, above all, faster._  
– Manfred Ruf, IT Manager, UNICEF

Get in touch with Upsun experts

- University of Oxford
- UNICEF
- Adobe
- Mentos
- Unity
- GAP

### [Get in touch with Upsun experts](https://upsun.com/contact-pantheon/)

# Moving off _Pantheon_? We can help.

Tell us about your sites and stack. We'll bring the right expert.

**What happens after you submit:**

1.  We review your request and your context
2.  A technical expert gets back to you within 1 business day
3.  You get a 30-minute discussion focused on your stack, goals, and questions 

_Costs have decreased by more than **60%**_ _everything has become easier and, above all, faster._  
– Manfred Ruf, IT Manager, UNICEF

Get in touch with Upsun experts

- University of Oxford
- UNICEF
- Adobe
- Mentos
- Unity
- GAP

### [Better Render alternative for multi‑cloud scaling | Upsun](https://upsun.com/alternative-render/)

# Everything you need to deploy your application, _anywhere, anytime_

While you’re dealing with infrastructure limitations, successful teams ship faster with enterprise-grade infrastructure. Struggle or scale; the choice is yours.

Better Render alternative for multi‑cloud scaling | Upsun

Scale across AWS, Azure, GCP and more. Unlimited timeouts, built‑in APM, transparent pricing and green hosting make Upsun the clear Render alternative

| Feature | Upsun | Competitor | Details |
| --- | --- | --- | --- |
| Preview environments | Byte-for-byte clones with real data | Manual setup required | Upsun spins up a production-like environment in minutes from a Git pull, with complete byte-for-byte replicas and databases. Render supports previews, but setup requires YAML config, and manual seeding with no data included. |
| Request Timeouts | Unlimited | Up to 100 minutes (requires configuration) | Upsun has no request timeout, even for large files. Render supports 100-minute timeouts, requiring manual configuration. |
| Multi-cloud deployment | AWS, Azure, OVH, IBM, GCP in 15+ regions | AWS, GCP | Upsun offers multiple IaaS providers, enabling you to meet geographical and environmental requirements. Render is limited to AWS (EU) or GCP (US), each app permanently locked to a single region with no migration path. |
| Managed data services | Fully supported | Limited | Upsun solves the database complexity with fully managed data services. Render supports two managed services and Key Value instances; Docker container setup is required for other databases. |
| Pricing transparency | Predictable & transparent pricing models | Complex multi-component pricing | Upsun offers flexibility with two pricing options: pay only for the resources you provision, or choose a fixed monthly tier plan. Render uses a complex, multi-component pricing model with no spending limits for users. |
| Performance monitoring | Built-in observability suite | Basic infrastructure metrics | Upsun provides real-time Application Performance Monitoring (APM) that identifies issues and recommends code optimizations to improve performance. Render requires third-party integration for advanced monitoring. |
| Security and Compliance | SOC 2 Type 2, GDPR, IS0 27001, HIPAA certified | SOC 2 Type 2 + ISO 27001 certified | Enterprise-grade compliance with Upsun's PCI DSS Level 1, GDPR, HIPAA, IS0 27001, and SOC 2 Type 2 - plus automated compliance monitoring. Render holds SOC 2 Type 2 and ISO 27001 certification, with HIPAA available as an additional paid service. |
| Container management | Git workflow | Git workflow | Upsun eliminates infrastructure complexity through native Git integration and automatic branch-to-environment mapping. Render offers a hybrid Git and container approach, but it requires additional configuration and manual CI/CD integration. |
| Auto-scaling | Built-in horizontal + vertical scaling | CPU/memory-based scaling (professional plan only) | Upsun includes enterprise-grade autoscaling on all plans, supporting custom metrics and both vertical and horizontal scaling. Render requires a higher tier to access basic autoscaling, which is limited to CPU and memory metrics only. |
| DDoS protection | Internal DDoS protection | DDoS protection available | Upsun includes DDoS with an integrated Web Application Firewall. Render offers Cloudflare-powered DDoS protection. |
| Persistent storage | Internal storage included | Paid feature, no horizontal scaling | Upsun includes persistent storage for all customers; select and configure storage directly on our platform. Render persistent storage is a paid feature. Applications with persistent disks cannot scale horizontally |
| Green Incentives | Discount for green regions hosting | Not available | Upsun tracks carbon intensity 12x across all regions and offers a 3% discount when you choose greener, more sustainable data centers. Render does not offer sustainability initiatives or green energy options |
| Reverse proxy cache | Built-in | Limited caching | Upsun gives users full restart control, eliminating unexpected interruptions. With rare exceptions, only for critical security updates. Render only caches static sites, not web services. Applications can't control caching, forcing all requests to hit the server. |
| Cron Jobs | Built-in | Separate service with usage-based fees | Upsun includes cron jobs within each application with no additional fees—no separate services or per-job fees. Render charges per cron job as separate services with no access to application files. |
| Language support | Native support for major programming languages | Limited to 6 programming languages | Upsun supports the latest versions of 10 programming languages and an array of frameworks. Render supports 6 languages. Other languages (including PHP and Java) require Docker deployment. |

All the enterprise PaaS features you need—all without complexity. Contact [sales](https://upsun.com/contact-us/) to schedule a demo.

## Discover why Upsun is a better Render alternative

### 99.99% Uptime Available

Keep your applications online even through traffic spikes with 99.99% uptime available, automated disaster recovery, and a dedicated 24/7 support team.

### Your data, your rules

Why settle for one cloud infrastructure? Deploy on your preferred cloud provider: AWS, Azure, Google Cloud, IBM, or OVHcloud – without juggling multiple subscriptions.

### Teamwork makes the dream work

Onboard team members, freelancers, and contractors in minutes with minimal learning curve and role-based access controls.

### Built for enterprise

Cloud choice, scalability, service, and sustainability features make it the right choice for enterprise deployments

## Looking to Migrate to Upsun?

Start with our free tier—spend 15 days exploring Upsun for free. You'll see why over 16,000 developers choose the transparency, flexibility, and autonomy we provide.

Zero effort, 0 commitment required upfront. Get started with our $0 free tier and experience the difference for yourself

One centralized PaaS handles ops, storage, security, previews, and more. Sign 1 contract, pay 1 bill, and let your developers focus on 1 thing: coding

Create byte-for-byte clones of your production environment in under 2 minutes, making updates simple, safe, and straightforward

Get a 3% discount when you deploy and manage applications at data centers in our incentive-eligible greener regions

"Costs have decreased by more than 60% everything has become easier and, above all, faster." —Manfred Ruf, IT Manager, UNICEF

### [Fly.io alternative with multicloud support | Upsun](https://upsun.com/alternative-flyio/)

# _Fly.io_ vs Upsun

Looking for a Platform-as-a-Service that goes beyond limits in deployment, performance, and observability? That’s Upsun.

Fly.io alternative with multicloud support | Upsun

Upsun is a Fly.io alternative with unlimited environment cloning, multicloud support, transparent pricing, and PCI DSS, GDPR, and HIPAA compliance.

| Feature | Upsun | Competitor | Details |
| --- | --- | --- | --- |
| Multicloud | AWS, Azure, OVH, IBM, GCP | Proprietary infrastructure | Upsun offers flexibility with multiple IaaS providers with 15+ regions to meet geographical, regulatory, and environmental requirements. Fly.io operates its own global infrastructure. However, this does not offer users the flexibility to choose their preferred cloud provider. |
| Sustainability | Carbon tracking + green hosting | x | Upsun tracks carbon intensity 12x across all regions and offers 3% discount when you choose greener and sustainable data centers. Fly.io does not have published sustainability policies or environmental commitments. |
| Preview environments | Byte-for-byte clones with real data | Manual GitHub Actions setup | Upsun instantly replicates your production environment in under 2 minutes with byte-for-byte data. Fly.io requires manual environment setup with multi-step processes and no data included. |
| Observability | Built-in observability features | 3rd-party add-on | Upsun offers comprehensive observability with APM, error tracking, metrics, profiling, and dashboards, all in one platform. Fly.io offers basic infrastructure metrics with limited platform support that requires external services. |
| Managed data services | Full support | Postgres and Redis only | Upsun solves the database complexity with fully managed data services. Fly.io requires database operations with limited managed options and self-management responsibilities. |
| Pricing model | Predictable & transparent pricing model | Region-based pricing | Upsun offers flexibility with two pricing options: pay only for the resources you provision, or choose a fixed monthly tier plan. Fly.io utilizes regional pricing, resulting in significant cost variations across different regions. |
| Performance monitoring | Real-time APM | Basic infrastructure metrics | Upsun provides real-time Application Performance Monitoring to detect issues and recommend code optimization. Fly.io offers basic metrics features, like tracing and error tracking, that require an external provider. |
| Regulatory compliance | Comprehensive compliance framework | Limited | Upsun is PCI DSS Level 1, GDPR, HIPAA, and SOC 2 Type 2 compliant, with automated compliance monitoring and DDoS protection. Fly.io supports SOC 2, HIPAA, and GDPR, but lacks PCI DSS certification and does not offer automated compliance features. |
| Background jobs | Built-in cron scheduling | Manual configuration | Upsun includes cron jobs within each application, separate from billable usage and with no additional fees. Fly.io requires manual setup and management. |
| Container management | Git workflow | Docker setup required | Upsun eliminates Docker complexity through a git-only workflow. Fly.io requires Docker expertise and manual container management. |

All the enterprise PaaS features you need—all without complexity. Contact [sales](https://upsun.com/contact-us/) to schedule a demo.

## Why Upsun is the best Fly.io alternative

### Zero DevOps complexity

Git push is all you need to deploy your applications. Focus on development while Upsun manages Docker, containers, and infrastructure behind the scenes.

### Built-in compliance certification

Meet enterprise compliance requirements with Upsun's built-in certifications (SOC2, PCI DSS, HIPAA, ISO 27001) and security controls. Say goodbye to compliance gaps and deploy with confidence.

### Predictable total cost

One platform, one contract, one bill. No surprise charges or hidden infrastructure costs.

### Faster time to market

Go from local repo to production in minutes. Spend time building features without disruption in your application pipeline.

## Ready to migrate to Upsun?

Start with our free trial, and spend 15 days exploring Upsun for free. You'll see why over 16,000 developers choose the transparency, flexibility, and autonomy we provide.

Zero effort, 0 commitment required upfront. Get started with our $0 free tier and experience the difference for yourself

One centralized PaaS handles ops, storage, security, previews, and more. Sign one contract, pay one bill, and let your developers focus on one thing: coding

Create byte-for-byte clones of your production environment in under 2 minutes, making updates simple, safe, and straightforward

Get a 3% discount when you deploy and manage applications at data centers in our incentive-eligible greener regions.

"Costs have decreased by more than 60% everything has become easier and, above all, faster." —Manfred Ruf, IT Manager, UNICEF

### [AWS alternative: deploy without limits | Upsun](https://upsun.com/alternative-aws/)

# Deploy _without limits_ with Upsun

Looking for an AWS alternative? Need to scale but also want developer-friendly features and cloud portability? Our AWS vs. Upsun comparison will help you find the ideal PaaS with pricing perfectly crafted to suit your business needs.

AWS alternative: deploy without limits | Upsun

Upsun is the AWS alternative delivering instant environments, multi‑cloud freedom and built‑in APM, slashing complexity and cloud costs

| Feature | Upsun | Competitor | Details |
| --- | --- | --- | --- |
| Multi cloud | AWS, Azure, OVH, GCP, IBM | AWS only | Upsun runs on AWS, Azure, Google Cloud, IBM, and OVH. Seamlessly switch cloud providers to meet your application and business needs. AWS is a single-cloud vendor. Moving to other cloud providers requires rebuilding applications and infrastructure from scratch |
| New project creation | Minutes and fully automated | Hours/days | Upsun eliminates setup complexity. Simply connect your Git repository, push your code, and your application is live in minutes. Creating a new project on AWS can require hours to days of manual configuration of multiple services, networking, security, DevOps pipelines, and time context switching for developers |
| Environment cloning | Instant byte-for-byte clones with data | Manual setup without data | Upsun instantly replicates your production environment in under 2 minutes with complete data and configurations. AWS cloning is limited to Elastic Beanstalk infrastructure only (no data included) and requires manual CloudFormation templates for complete environments |
| Sustainability | Carbon tracking + green hosting incentives | Carbon tracking; no green hosting incentives | Upsun tracks carbon intensity across all regions and offers 3% discount when you choose greener and sustainable data centers. AWS offers carbon tracking tools; however, there are no pricing benefits or incentives for choosing lower-carbon regions |
| Application Performance Monitoring | Real-time APM | CloudWatch monitoring (extra cost) | Upsun provides real-time APM built-in, which identifies issues and recommends code optimizations to improve performance. AWS APM requires multiple services (CloudWatch Application Signals + X-Ray + CloudWatch) with a complex setup at an extra cost |
| CI/CD Pipeline | Integrated | Silo AWS services | Upsun integrates with your Internal Development Platform (IDP) and CI/CD tools. Simply push to Git and your app deploys automatically. No additional service integration required. AWS requires separate services (CodeCommit, CodeBuild, CodeDeploy, CodePipeline) with complex IAM roles and configuration files |
| Security updates | Automatic | Manual patching required | Upsun automatically handles security updates, patches, and platform modernization so your applications stay secure without manual intervention. With AWS, you're responsible for patching operating systems, runtimes, and maintaining security updates |
| Regulatory compliance | SOC 2 Type 2, PCI DSS Level 1, GDPR, HIPAA, ISO 27001 certified | Manual configuration required | Upsun is PCI DSS Level 1, GDPR, HIPAA, ISO 27001, and SOC 2 Type 2 compliant, with automated compliance monitoring and DDoS protection. AWS provides compliant infrastructure but requires manual configuration of IAM, encryption, logging, and monitoring |
| Developer experience | NoOps, Git workflow | DevOps expertise required | Upsun provides developer autonomy through a Git workflow. No DevOps skills required. AWS requires DevOps knowledge to manage its complex infrastructure |

Built with the flexibility you need to build and scale. Contact sales to schedule a demo

## Why choose Upsun over AWS?

### Eliminate complexity

Upsun provides all your infrastructure needs and easily works with all major cloud providers, including AWS. Your team can focus entirely on innovation and feature delivery while Upsun handles all underlying infrastructure complexity.

### Instant environments

Provision new projects and as many new environments as you need in minutes. Every Git branch creates a complete, production-like environment with all your data included, perfect for testing, previews, and collaboration.

### Green Hosting Incentive

Upsun makes sustainability profitable, not just trackable. When you choose a lower-carbon data center, you receive a 3% Greener Region Discount on your resource usage.

### Multi-cloud freedom

Enjoy multi-cloud freedom without vendor lock-in. For every project, you can choose your preferred cloud provider (AWS, Azure, Google Cloud, IBM, or OVH) with no extra configuration needed.

## Start today

We understand that choosing a cloud provider is a big decision. Start with our free tier - spend 15 days exploring Upsun for free. You'll see why over 16,000 developers choose the transparency,

Zero effort, 0 commitment required upfront. Get started with our $0 free tier and experience the difference for yourself

One centralized PaaS handles ops, storage, security, previews, and more. Sign 1 contract, pay 1 bill, and let your developers focus on 1 thing: coding

Create byte-for-byte clones of your production environment in under 2 minutes, making updates simple, safe, and straightforward

Get a 3% discount when you deploy and manage applications at data centers in our incentive-eligible greener regions

"Costs have decreased by more than 60% everything has become easier and, above all, faster." —Manfred Ruf, IT Manager, UNICEF

### [DigitalOcean alternative for multicloud apps | Upsun](https://upsun.com/alternative-digitalocean/)

# Looking for a _DigitalOcean_ alternative?

Take your apps beyond basic VMs or single-cloud PaaS. Upsun provides a cloud application platform with the flexibility and features to build, ship, and scale without limits.

DigitalOcean alternative for multicloud apps | Upsun

Looking for a DigitalOcean alternative? Run on any cloud, clone prod in minutes, get built-in CI/CD, and 99.99% uptime available - with transparent pricing

| Feature | Upsun | Competitor | Details |
| --- | --- | --- | --- |
| Environment cloning | Full-stack production clones | Manual setup required without data clones | Upsun provides byte-for-byte production clones with real data and services on every Git branch. DigitalOcean supports preview environments through manual setup, but does not offer automatic data cloning. |
| Multicloud deployment | AWS, Azure, GCP, IBM, and OVHCloud | DigitalOcean infrastructure only | Upsun offers flexibility in deploying multiple cloud providers and regions from a single console. DigitalOcean runs exclusively on DigitalOcean's proprietary infrastructure. |
| CI/CD | Automatic on every Git push | Third-party tools required | Upsun provides a complete CI/CD pipeline built in with automatic build, test, and deployment on every Git push. DigitalOcean offers auto-deploy for continuous deployment; however, full CI/CD requires third-party integration. |
| Language support | Native support for 10 programming languages | Limited to 6 languages | Upsun supports the latest versions of 10 programming languages and an array of frameworks. DigitalOcean supports six major languages; other languages require a custom Dockerfile configuration. |
| Pricing model | Predictable & transparent pricing models | Predictable per-component pricing | Upsun offers flexibility with two pricing options: pay only for the resources you provision, or choose a fixed monthly tier plan. DigitalOcean offers per-container pricing with fixed monthly costs. |
| Managed services | Databases, caching, and services integrated | Extra cost for managed services | Upsun simplifies service complexity by integrating fully managed databases, cache, and search indexes into the project. Managed services are separate products you connect to on DigitalOcean, requiring manual database provisioning and migration. |
| Infrastructure management | Fully managed PaaS | Fully managed PaaS | Upsun's managed PaaS uses infrastructure-as-code, where resources are defined in YAML, and the platform handles all infrastructure. DigitalOcean offers a fully managed PaaS designed for maximum simplicity, handling all infrastructure management. |
| Compliance | SOC 2 Type 2, PCI DSS Level 1, GDPR, HIPAA, ISO 27001 certified | SOC 2 Type 2, ISO 27001 only | Upsun is PCI DSS Level 1, GDPR, HIPAA, ISO 27001, and SOC 2 Type 2 compliant, with automated compliance monitoring. DigitalOcean compliance is limited to SOC 2 Type 2 and ISO 27001 certification only. |
| Web Application Firewall (WAF) | Available; built-in | Available (third-party only) | Upsun has a comprehensive, built-in WAF that provides application-layer (Layer 7) protection against web attacks. DigitalOcean provides network-layer DDoS protection but does not include WAF for application-layer threats. Third-party WAF are available through third-party installation. |
| Sustainability incentives | 3% discount for low-carbon regions | Not available | Upsun tracks carbon intensity 12x across all regions and offers a 3% discount when you choose greener, more sustainable data centers. DigitalOcean partners with data centers; however, no financial incentives or carbon tracking tools are available. |
| Custom runtimes | Highly customizable via YAML configuration | Supported via a user-provided Dockerfile. | Upsun is highly customizable via YAML, supporting 10+ native runtimes and composable images for custom packages in a single project. DigitalOcean offers custom runtimes supported via a user-provided Dockerfile. |
| Application Performance Monitoring | Built-in observability suite | Limited | Upsun real-time Application Performance Monitoring (APM) identifies issues and recommends code optimizations to improve performance. DigitalOcean monitors system metrics and basic app insights, but doesn't track application-level performance or errors. |
| Backup services | Automatic backups by default | Varies by product | Backups are built in on Upsun by default, stored redundantly, and can be restored into any environment or branch. Backups vary by product on DigitalOcean: VM backups are paid add-ons, and app/database backups lack complete native protection. |

## Experience the Upsun advantage

### Instant production cloning

Spin up instant copies of your production environment with complete data, configurations, and code for every development branch. Team members can access and test these live preview environments with confidence.

### Multicloud deployment

Upsun places infrastructure choice in your hands. Select your cloud provider and region with lower carbon intensity to earn discounts and support your sustainability goals.

### Multi-language support

Whatever languages, runtimes, stacks, or CMS you use, Upsun has you covered. With support for 10 languages, virtually any frameworks, and fully managed services like databases, search, and caching.

### 99.99% uptime available

Keep your applications online, even during traffic spikes, with 99.99% uptime availability, automated disaster recovery, and a dedicated 24/7 support team.

## Ready to experience the difference?

We understand that switching platforms is a big step. Start with our 15-day free trial and explore Upsun at no cost. You can also schedule a demo to speak with an expert.

Zero effort, 0 commitment required upfront. Get started with our $0 free tier and experience the difference for yourself

One centralized PaaS handles ops, storage, security, previews, and more. Sign one contract, pay one bill, and let your developers focus on one thing: coding

Create byte-for-byte clones of your production environment in under 2 minutes, making updates simple, safe, and straightforward

Get a 3% discount when you deploy and manage applications at data centers in our incentive-eligible greener regions.

"Costs have decreased by more than 60% everything has become easier and, above all, faster." —Manfred Ruf, IT Manager, UNICEF

### [Vercel alternative for multi-cloud apps | Upsun](https://upsun.com/alternative-vercel/)

# Looking for a _Vercel alternative_?

Your great ideas shouldn't be limited by infrastructure or lack of it. Upsun delivers the infrastructure and integrated tools you need to ship full-stack applications without restrictions.

Vercel alternative for multi-cloud apps | Upsun

Discover a Vercel alternative with true multi-cloud, full-stack hosting, preview clones with data, built-in APM, and transparent pricing—no vendor lock-in.

| Feature | Upsun | Competitor | Details |
| --- | --- | --- | --- |
| Preview environments | Complete byte‑for‑byte clones with data | Code only; databases and services not included | Upsun auto-creates environment clones for every branch including code, data, config, and connected services. Vercel creates preview URLs for each branch, but databases and services must be configured separately via external providers |
| Multi-cloud deployment | AWS, Azure, Google Cloud, IBM, OVHcloud | AWS infrastructure only | Upsun lets you deploy on multiple cloud providers and across 15+ regions from a single console, with no vendor lock-in. Vercel runs exclusively on AWS infrastructure, meaning you cannot choose alternative cloud providers or regions. |
| Language support | Native support for 10 programming languages | Focused on JavaScript/TypeScript frameworks | Upsun natively supports the latest versions of 10 major programming languages and an array of frameworks. Vercel offers runtimes for Node.js, Python, Go, and Ruby, but limited to serverless functions, with full support centered on JavaScript and TypeScript frameworks. |
| Managed services | Fully managed databases and services | Limited; requires external services | All managed services: databases, caching, search are fully integrated into Upsun environments, with no external providers. Vercel provides Postgres and Redis via third-party providers, while other databases and services depend on external integrations. |
| Pricing model | Transparent and predictable pricing models | Hybrid pricing model | Upsun offers flexibility with two pricing options: pay only for the resources you provision, or choose a fixed monthly tier plan. DigitalOcean offers per-container pricing with fixed monthly costs. |
| Backend hosting | Full backend support with persistent services | Serverless functions only with time limits | Upsun supports persistent workers, background jobs, and cron tasks with full backend capabilities; no time limits or serverless constraints. Vercel backend support is limited to serverless functions with execution time limits, no background workers, and stateless architecture. |
| Request timeouts | Configurable with unlimited worker processes | 5-15 minutes maximum (plan-dependent) | On Upsun, web requests can run for extended periods with a default 5-minute limit (configurable), and background workers execute without time limits. Vercel functions have maximum execution durations of between 5-15 minutes depending on plan; proxied requests to external services timeout at 2 minutes. |
| Regulatory compliance | SOC 2 Type 2, PCI DSS Level 1,ISO27001 GDPR, HIPAA | SOC 2 Type 2, ISO 27001, GDPR, PCI DSS, HIPAA | Upsun is PCI DSS Level 1, GDPR, HIPAA, ISO 27001, and SOC 2 Type 2 compliant, with automated compliance monitoring. Vercel is SOC 2 Type 2, ISO 27001, GDPR, PCI DSS compliant; HIPAA available on Enterprise with BAA. |
| Application Performance Monitoring | Built-in observability suite | Available with additional configuration | Upsun real-time Application Performance Monitoring (APM) identifies issues and recommends code optimizations to improve performance. Vercel provides basic observability built-in; advanced APM requires third-party integrations via OpenTelemetry. |
| Sustainability | Carbon tracking + green hosting discounts | Not available | Upsun tracks carbon intensity 12x across all regions and offers a 3% discount when you choose greener, more sustainable data centers. Vercel uses serverless architecture for energy efficiency but does not provide carbon tracking, green hosting options, or sustainability incentives. |

Want to learn more? [Upsun documentation](https://docs.upsun.com/) has everything you need to get started.

## Built with everything you need to deploy and scale

### True multi-cloud freedom

Upsun places infrastructure choice in your hands. Deploy on AWS, Azure, Google Cloud, IBM, or OVHcloud in any region. With this, you can choose your provider and region based on performance, or to support your sustainability goals.

### Production-perfect preview environments

Spin up instant copies of your production environment with complete data, configurations, and code for every development branch. Team members can access and test these live preview environments with confidence.

### Full-stack deployment

Deploy complete applications with backend services, databases, caching, and search engines; all from one centralized platform. Sign one contract, pay one bill, and let your developers focus on coding instead of infrastructure management.

### Build without constraints

Build in the language, framework, or database your project needs. Deploy microservices, monoliths, or anything in between. Upsun supports your architecture, not the other way around.

## Looking to Migrate to Upsun?

Start with our free tier—spend 15 days exploring Upsun for free. You'll see why over 16,000 developers choose the transparency, flexibility, and autonomy we provide.

Zero effort, zero commitment required upfront. Get started with our $0 free tier and experience the difference for yourself.

One centralized PaaS handles ops, storage, security, previews, and more. Sign one contract, pay one bill, and let your developers focus on one thing: coding.

Create byte-for-byte clones of your production environment in under 2 minutes, making updates simple, safe, and straightforward.

Get a 3% discount when you deploy and manage applications at data centers in our incentive-eligible greener regions.

"Costs have decreased by more than 60% everything has become easier and, above all, faster." —Manfred Ruf, IT Manager, UNICEF

### [Managed Application Platform| Upsun (formerly Platform.sh)](https://upsun.com/managed-application-platform/)

# Ship confidently _without the DevOps tax_

Upsun is a managed application platform driven entirely by your repository. Bring your stack, any language, any framework, any AI tool. The result: predictable costs, consistent environments, and a reliable path to production.

Managed Application Platform| Upsun (formerly Platform.sh)

A managed application platform for multi-stack teams. Bring any language, framework, or AI tool. Deploy from Git to any cloud.

## Less drift, faster onboarding, readable audits

### Your environments stay in sync

Every branch deploys with the same configuration as production, including services, route and data. No separate staging mode that quietly drifts.

### Fast onboarding

Your stack lives in YAML in your repo. New developers, contractors, and AI coding tools all read the same source of truth, no tribal knowledge, buried admin UI, or waiting on console permissions.

### Audits become readable

Every infrastructure change is a Git commit. Audits go from days of digging through logs to a git log your auditors can actually follow.

## Evaluate with the right framework

Most platform comparisons stop at price and uptime. But the real cost of a platform is measured in deploy confidence, incident recovery time, and cloud portability. Use these criteria when comparing your options:

- Team velocity : How much faster can you ship when infrastructure is automated.
- Environmental parity: Does dev match production exactly, or are you guessing.
- Service density: How many services, languages, or runtimes can fit in one project.
- Build reproducibility: Can you rebuild the same artifact six months from now.
- Downtime tolerance: What is the real cost of maintenance windows versus zero-downtime deploys.
- Compliance posture: How much audit preparation time do built-in certifications save.

## How Upsun delivers against those criteria

## One project. Any stack

### Production-parity preview environments

Every branch becomes a full-stack environment with cloned data, services, and routing. Reviewers test real behavior, not screenshots. QA catches real issues before merge.

### Multi-cloud, no lock-in

Upsun runs on AWS, Google Cloud, Azure, IBM Cloud, and OVHcloud with portable YAML configuration. Pick a region by compliance, cost, or latency. No provider-specific tooling, no rewrites between clouds.

### 25+ managed services

Upsun ships PostgreSQL, MySQL, MongoDB, Redis, OpenSearch, Solr, RabbitMQ, and more patched, scaled, and backed up automatically. Add them to your stack with a few lines of YAML.

### Governance and control

Set environment policies, service configuration, and access controls once at the team level. Apply them across every project, environment, and application; no re-implementing per app.

### Observability and APM

Upsun ships with continuous profiling, APM traces, and infrastructure metrics out of the box. Find bottlenecks before customers do without separate vendor, extra agent, or second bill.

### Git-driven workflow

Every branch is an environment. Every merge is a promotion. Activity hooks let you script the rest. Your delivery pipeline follows your code

## Pay only for what you provision

CPU and RAM determine your bill. No per-seat fees, traffic-spike penalties, or surprise overages. Size your project before you commit.

## Get started in three steps

### Connect

Link any Git repository. Define your stack in a YAML file inside the repo.

### Push

Every push triggers a build. Every branch becomes an isolated environment with its own URL, services, and data.

### Deploy

Merge to main, and Upsun deploys to production with zero downtime. Same configuration, no hand-offs.

## Frequently Asked Questions (FAQ)

### Can I migrate my existing application to Upsun?

Yes. Add a YAML file to your repository describing your stack, point Upsun at the repository, and deploy. Upsun supports PHP, Python, Node.js, Ruby, Java, Go, and .NET. Your existing application deploys without re-architecting.

### Do I need DevOps experience to use Upsun?

No, but YAML helps. Most teams are productive within a day.

### Are the resources I configure guaranteed?

Yes. CPU and RAM are defined per service in YAML and dedicated to your service. You pay for the horsepower you provision, and you get it.

### Will Upsun scale as my traffic grows?

Yes. Scale vertically for more CPU and RAM per instance, scale horizontally for more instances, and add managed services as you grow.

### Can I bring my own cloud region?

Yes. Upsun runs on AWS, Google Cloud, Azure,  IBM Cloud, and OVHcloud across multiple regions with a portable YAML configuration that works across every cloud.

### What happens to data in a preview environment?

Cloned from production, isolated, and sanitizable. Destroyed when the branch is deleted.

### [Multi-Cloud and Edge | Upsun](https://upsun.com/features/multi-cloud-and-edge/)

# The best cloud for each app. _One platform for all of them._

Deploy each application to the cloud and region that fits it best, without changing how you build or operate it.

Multi-Cloud and Edge | Upsun

Choose the best cloud and region for every application from a single platform

## One platform. Every major cloud. Regions worldwide.

### A wide selection of infrastructure providers

AWS, Azure, GCP, IBM, OVHCloud and more. Deploy each application to whichever provider fits, using identical workflows across all of them.

### Region-level control

Place each application in a specific region to meet performance, regulatory, or data residency requirements. Managed as part of your platform configuration through Git, not through manual infrastructure setup.

### Built-in edge layer

A regional edge proxy and HTTP cache at the entry point to every region. For global delivery, the managed CDN option provides 60+ points of presence with centralized cache and routing management.

## Multi-cloud without the operational overhead

One deployment pipeline across every provider. No custom tooling, no fragmented workflows.

- Deploy to AWS, Azure, GCP, IBM, and OVHCloud
- Identical workflows regardless of underlying provider
- Pin workloads to specific regions for data residency compliance
- Managed CDN with 60+ points of presence for global delivery
- Git-driven infrastructure choices, versioned alongside your code
- Centralized visibility and control via CLI, API, or console

## Built for teams with real infrastructure demands

### Regulatory deployments

Deploy workloads to specific regions to meet data residency requirements. Pin European data to OVHCloud Germany, US data to AWS Virginia, all from the same deployment pipeline.

### Performance optimization

Run applications in the regions closest to your users. Add edge caching for global delivery with 60+ points of presence, without managing separate infrastructure stacks.

### Risk mitigation

Distribute your application portfolio across Azure, AWS, and more. Reduce provider dependency without fragmenting the workflows that keep everything running.

### Security and compliance

Security controls applied consistently across every cloud and region. TLS by default, network isolation, encrypted traffic, and auditable configuration changes. SOC2, ISO, GDPR and more.

### Governance and visibility

One platform means one place to see where applications are running and what they cost. Centralized oversight via CLI, API, or console.

### Resilience and continuity

Portable configurations and repeatable workflows make disaster recovery possible across providers and regions. Build automated cross-cloud failover without rebuilding your platform model.

### [CLI, console, and API for platform control | Upsun](https://upsun.com/features/cli-console-and-api/)

# Run your application _your way_

Deploy code, manage environments, and automate workflows using your preferred interface: CLI, Console, or API. Whichever interface you choose, projects, permissions, and outcomes stay the same.

CLI, console, and API for platform control | Upsun

Control projects and environments through the CLI, web console, or REST API. Automate deployments, logs, users, and workflows with consistent behavior.

## The interface that fits your workflow

### Upsun CLI

The Upsun CLI puts every platform action in your terminal. Push code, branch environments, tail logs, and SSH into running containers without leaving your workflow.

### Upsun Console

A web view of every project, environment, user, and activity. See platform state at a glance, manage access, and run day-to-day work from your browser.

### Upsun API

Every CLI and Console action is also available through a REST API. Trigger deployments, manage environments, or pull project state from your CI, dashboards, or internal tools.

## Platform control that fits every workflow

Any action available in one interface is available in the others. Your team can move a workflow from Console to a CLI script to an API call without rewriting the logic.

- Cover any task from the terminal with more than 130 CLI commands across 30 namespaces.
- Skip SSH key management, browser login generates your SSH certificates automatically.
- Call Upsun from your own code through a REST API and a full OpenAPI reference.
- Run the same commands locally and in CI with project auto-detection and a non-interactive mode for pipelines.
- The Console offers Light, Dark, and High-Contrast modes, all meeting WCAG 2.0 level AA accessibility standards.

## What this means for your team

### Automate without rewriting

Anything you can click, you can script. Move a manual flow into an API call or CLI command and keep the same behavior, the same permissions, the same outcome.

### Use what fits your workflow

Terminal, browser, or CI pipeline, each fits a different kind of work. Pick the interface that fits your workflow.

### One permission model everywhere

Roles, teams, and access rules apply across the CLI, Console, and API. A user gets the same access through every interface, easier to audit, harder to misconfigure.

### Ready for AI coding agents

Agents can deploy, branch, and restore environments using the same CLI permissions as the user who authenticated them.

### No third-party maintenance

Upsun builds and maintains all three interfaces. No third-party wrappers to install, no community SDKs to keep up to date, no API drift to track.

### Match the tool to the team member

Different roles need different tools. Product teams can use the Console, while developers and platform teams work through the CLI or API.

### [Get in touch with Upsun experts](https://upsun.com/contact-devops/)

# Talk through your _DevOps challenges_

Tell us what you're automating. We'll bring the right expert.

**What happens after you submit:**

1.  We review your request and your context
2.  A technical expert gets back to you within 1 business day
3.  You get a 30-minute discussion focused on your stack, goals, and questions 

_Costs have decreased by more than **60%**_  
– Manfred Ruf, IT Manager, UNICEF

Get in touch with Upsun experts

- University of Oxford
- UNICEF
- Adobe
- Mentos
- Unity
- GAP

### [Backups and data recovery built in | Upsun](https://upsun.com/features/backups-and-data-recovery/)

# Restore your environment _in one command_

Automated and on-demand backups of your code, files, and managed services, restorable to any environment.

Backups and data recovery built in | Upsun

Platform-managed backups for managed services with scheduled and on-demand options. Restore to production or non-production to recover fast after incidents.

## Code, data, and services backed up together

### Captured together

Every backup includes your code, your files on mounts, and the data inside every managed service.

### Restored as one

Roll the whole stack back to a consistent state, not just one layer of it.

### Managed in one place

One place to manage schedules, snapshots, and restores, regardless of where your data is stored.

## Backup to restore in one command

Every backup captures your entire stack and is stored separately from your environments and replicated across data centers in your region.

- Run backups without taking your site down.
- Backups are ready before you need them.
- Set your own recovery point with a configurable schedule.
- Restore safely to production or any preview environment.
- Trigger an on-demand backup before any risky change.
- Restore data only, keep your current code.

## Built for how teams actually operate

### Recovery built in

Backups, schedules, and restores ship with every project. No third-party tools to procure, integrate, or keep running.

### Fast incident response

Recovery is self-serve and permission-controlled. Teams act on incidents without waiting for support tickets or third-party vendors.

### Compliance by design

Automated backups with configurable retention support audit requirements under SOC 2, HIPAA, and GDPR. Coverage is consistent and repeatable across every project.

### Governed access, by default

The same role-based permissions that govern your environments govern your backups. Only authorized users can create, view, or restore them.

### Real data in non-production environment

Restore production data into preview or staging to test migrations, reproduce bugs, or rehearse incidents without touching live.

### Less for platform teams to maintain

No custom backup scripts, no separate storage tooling, no on-call rotation for backup failures. The platform owns the operational layer.

### [Talk to a compliance expert](https://upsun.com/contact-compliant/)

# Talk through your _compliance and security requirements_

Tell us what you're required to meet. We'll bring the right expert.

**What happens after you submit:**

1.  We review your request and your context
2.  A technical expert gets back to you within 1 business day
3.  You get a 30-minute discussion focused on your stack, goals, and questions 

_Costs have decreased by more than **60%**_ _everything has become easier and, above all, faster._  
– Manfred Ruf, IT Manager, UNICEF

Talk to a compliance expert

Get in touch with Upsun experts

- University of Oxford
- UNICEF
- Adobe
- Mentos
- Unity
- GAP

### [Compliant cloud platform for regulated industries | Upsun](https://upsun.com/compliant-cloud-platform/)

# _Built-in compliance_ and operational controls for modern applications

Deploy and manage applications on a platform designed to support standardized environments, controlled deployment workflows, and security-focused operations across teams.

Compliant cloud platform for regulated industries | Upsun

Deploy on ISO 27001, SOC 2, PCI DSS Level 1, and HIPAA certified infrastructure. Built-in audit logging, immutable environments, and access controls for regulated teams.

- Adobe
- The Economist
- Oris
- Freitag
- A+E
- The British Museum

### Support security and compliance requirements without rebuilding operational workflows

## Compliance breaks when teams operate differently

As organizations grow, environments and workflows diverge. Audit complexity increases. Security controls become impossible to apply consistently. Upsun standardizes delivery workflows and keeps governance visible across every team.

### Environment inconsistency

Different infrastructure configurations across environments increase operational and compliance risk. Drift between staging and production is one of the primary reasons audits fail.

### Manual deployment controls

Custom deployment workflows are difficult to standardize and audit consistently across teams and projects.

### Fragmented governance

Security and operational policies vary across teams. Permissions, access controls, and configurations are managed separately with no central visibility.

### Audit preparation overhead

Every deployment, configuration change, and access event is tracked manually. Evidence gathering takes weeks instead of minutes.

## Operational consistency designed into the platform

Upsun centralizes environments, deployment workflows, infrastructure configuration, and operational controls into a single managed platform layer.

### Infrastructure defined as code

Your entire stack, services, routes, and environment variables are declared in a single versioned configuration file. Every branch carries identical infrastructure. No drift between environments.

### Controlled, auditable deployments

Changes are introduced exclusively through the Git-based build and deploy workflow. Every deployment, configuration change, and access event is automatically logged and retained for audit.

### Compliance inherited from the platform

Build on ISO 27001, SOC 2, PCI DSS Level 1, and HIPAA certified infrastructure. Offload the majority of infrastructure-level controls to Upsun and focus your team on application-level security.

## Security and compliance controls built into every environment

Core security controls are enforced automatically at the platform level, without requiring application-level customization or additional tooling from your team.

### Standardized environments

Every environment, from development to production, is built from the same infrastructure-as-code configuration. No configuration drift. No inconsistencies between stages.

### Immutable environments

Environments run with a read-only file system and a controlled execution model. Changes are introduced only through Git-based workflows, preventing unauthorized configuration changes.

### Granular access management

Role-based permissions, integrated MFA, and per-environment access controls managed centrally. SSH access restricted to public key authentication only.

### Automatic audit logging

Every deployment, configuration change, and access event is automatically logged. Complete audit trails built into every environment, retained for 6 months or more.

### Compliance inheritance

Build on certified infrastructure: ISO 27001, SOC 2 Type 2, PCI DSS Level 1, HIPAA, and TX-RAMP. Access attestation documents and compliance reports directly from the Upsun Trust Center.

### Data residency and encryption

Deploy in specific geographic regions to meet data sovereignty requirements. Encryption in transit and at rest across all environments by default.

## What compliance-focused teams use Upsun for

### Reducing PCI DSS audit burden

Build on PCI DSS Level 1 certified infrastructure and inherit the majority of infrastructure-level controls. Your team focuses on application code, not firewall rules and network isolation.

### Eliminating environment drift

Infrastructure defined as code means every environment is built identically. The primary reason audits fail, configuration drift between staging and production, is removed by design.

### Streamlining audit preparation

Every deployment and access event is logged automatically. Generate compliance evidence in minutes instead of gathering screenshots and logs across multiple systems for weeks.

### Enforcing access governance

Manage role-based permissions across teams and environments centrally. Developers work freely in isolated preview environments without access to production.

"We really appreciate the peace of mind that Upsun provides. Our team now has the flexibility and autonomy to manage deployments efficiently without worrying about service interruptions." —Isabelle Sarrazin, General Manager, Easypara

### [Enterprise application platform for standardized delivery | Upsun](https://upsun.com/enterprise-application-platform/)

# _Standardize application delivery_ across teams and environments

Upsun gives engineering organizations a single platform to standardize deployments, environments, infrastructure workflows, and governance across applications and teams.

Enterprise application platform for standardized delivery | Upsun

Standardize deployments, environments, and governance across teams on one platform. Multi-framework, multi-cloud, Git-driven, with enterprise-grade compliance built in.

- Adobe
- The Economist
- Oris
- Freitag
- A+E
- The British Museum

## Inconsistent delivery creates operational overhead

Every team deploys differently. Environments drift. Security controls vary. As teams grow, the inconsistency compounds. Upsun brings deployments, environments, and governance into one operational model.

### Environment drift

Staging and production environments diverge over time, creating deployment risk and debugging overhead.

### Custom deployment tooling

Internal scripts and CI/CD pipelines become difficult to maintain consistently as more teams and projects depend on them.

### Operational silos

Every application team develops different workflows, configurations, and infrastructure patterns, with no shared standard.

### Governance gaps

Security and compliance controls are difficult to apply consistently when each team manages its own infrastructure independently.

## One platform for applications, environments, and operations

Upsun centralizes the operational layer behind modern application delivery so teams can deploy consistently without rebuilding workflows for every project. Infrastructure, services, and code are defined together and version-controlled in Git.

### Define the standard once

Platform teams define a single configuration standard for services, environments, and access controls. Every team inherits the same defaults.

### Teams deploy through Git

Application teams push code through their existing Git workflow. Builds, environments, and deployments happen automatically against the shared standard.

### Operations maintain visibility

Platform and operations teams retain centralized visibility into deployments, access, and configuration across every project, without slowing down individual teams.

## Built for organizations running many applications and teams

Upsun replaces fragmented, team-by-team deployment tooling with a consistent operational model that scales across the organization.

### Standardized environments

Deploy consistent environments across development, staging, and production with infrastructure defined as code.

### Automated deployments

Build, deploy, and manage applications through Git-based workflows integrated with your existing CI/CD automation.

### Preview environments

Automatically generate isolated, full-stack environments for feature branches and pull requests across every team.

### Centralized governance

Apply operational standards, access controls, and compliance policies consistently across teams and projects.

### Multi-framework support

Run PHP, Python, Node.js, Java, Go, and other modern application stacks side by side on a single platform.

### Multi-cloud flexibility

Deploy applications across AWS, Google Cloud, Microsoft Azure, and other major providers without redesigning operational workflows.

## Standardized governance without slowing delivery

Engineering teams need operational consistency without introducing friction into development workflows. Upsun gives developers self-service deployment workflows while allowing platform and operations teams to maintain visibility, consistency, and governance across environments.

### Standardizing deployments across teams

Replace fragmented deployment workflows with a consistent operational model across applications and teams.

### Reducing internal platform maintenance

Avoid the ongoing cost of maintaining custom deployment tooling and internal developer platforms built on Kubernetes or similar infrastructure.

### Improving environment consistency

Reduce deployment issues caused by infrastructure drift between staging and production.

### Supporting regulated environments

Apply security and compliance controls consistently across projects, backed by ISO 27001, SOC 2, and PCI DSS certified infrastructure.

"Upsun has been a transformation accelerator. It allowed us to do DevOps without the extremely expensive and laborious part of setting up these platforms." —Thomas Barriere, DSI, Ineris

### [Instant development environments | Upsun](https://upsun.com/features/instant-development-environments/)

# Stop managing staging. _Start shipping._

Every branch gets its own isolated, production-accurate environment, automatically. Shared staging is a headache you don't need.

Instant development environments | Upsun

Spin up isolated, production-grade preview environments from branches and pull requests. Test code, services, and data safely before merge

## One platform. Every branch a real environment.

### Push a branch. Get an environment.

No configuration, no waiting. A full production-accurate environment spins up the moment you push, and rebuilds automatically with every code update.

### Everything production has. Nothing it doesn't.

Code, services, and configuration are replicated exactly. Identical CPU, RAM, databases, caches, queues, and background workers. What you test is what ships.

### Fully isolated, by default.

Nothing bleeds across environments. Your work can't affect production, and nobody else's branch can affect yours.

## Built to replace staging entirely

Every environment is a complete clone of production, ready the moment you need it and gone the moment you don't.

- Every branch gets a live, shareable URL
- Code, services, and data cloned from production
- Environments appear on branch creation, disappear on merge
- Tunnel into preview databases to test migrations or sanitize data before cloning
- Trigger an on-demand environment before any risky change
- Full support for databases, caches, queues, and background workers

## Built for how teams actually ship

### Pull request validation

A developer opens a pull request. Upsun creates a live environment automatically. Reviewers test the real change before approving the merge.

### Database migrations

Validate schema changes against a production-accurate dataset before they touch live data. Issues caught early, not at 2am.

### Stakeholder review

Product and QA review new features in a live environment with real data. Less back-and-forth, faster sign-off.

### Security by default

Every environment inherits Upsun's full security model. Network isolation, runtime protections, fully contained.

### Access that scales with your team

The same role-based permissions that govern your platform govern your previews. No separate access layer to manage.

### No runaway costs

Environments are ephemeral. They appear when a branch is created and disappear when it's merged or closed.

### [Heroku Enterprise Alternatives: Graduate to Upsun for the Next Decade](https://upsun.com/heroku-alternative/)

# Has your team _outgrown Heroku_?

Migrate from Heroku to Upsun without changing your stack. Upsun keeps the simplicity you already know, but with developer velocity, with the security, observability, innovation, and pricing transparency that modern enterprises actually need.

Heroku Enterprise Alternatives: Graduate to Upsun for the Next Decade

Strategic roadmaps require certainty. Discover why enterprises are migrating from Heroku to Upsun for 99.99% uptime, multi-cloud sovereignty, and AI-native infrastructure.

## The trade-offs you no longer have to make

Every platform forces a decision. On legacy PaaS providers, you typically accept these constraints in exchange for simplicity. On Upsun, you get the simplicity without the trade-off.

- Preview environments vs production parity: Upsun clones code, data, and services byte-for-byte in under a minute.
- Cloud choice vs unified workflow: Upsun runs on AWS, Azure, GCP, OVHcloud, or IBM Cloud with a single, consistent workflow.
- Developer simplicity vs enterprise governance: Skip the pricey shield tiers. Upsun provides SOC 2 and HIPAA readiness natively without complex manual configuration.
- Continuous profiling vs tool sprawl: Deep performance insights usually require an expensive, separate observability stack.
- OpenTelemetry support and Blackfire profiling natively: Get real-time anomaly detection and function-level insights without managing external integrations.

| Feature | Upsun | Competitor | Details |
| --- | --- | --- | --- |
| Multi-cloud | AWS, Azure, OVH, IBM Cloud, GCP | AWS only | **Upsun** offers options on AWS, Azure, Google Cloud, IBM Cloud, and OVH. Seamlessly switch cloud providers to meet your application and business needs. **Heroku** runs exclusively on AWS. An outage affects all hosted applications, and migration requires rebuilding infrastructure from scratch. |
| Preview environments | Byte-for-byte production clone | Manual setup; no automated environment parity | **Upsun** creates exact replicas of code, data, and config in under a minute. **Heroku** requires manual configuration and separate data uploads for staging. |
| Request timeout | Unlimited | Fixed 30-second limit | **Upsun** handles large file transfers and long-running processes without interruption. **Heroku’s** router terminates any connection exceeding 30 seconds. |
| Compute architecture | Architecture flexible (x86 or ARM) | Mandatory ARM (Graviton) | **Upsun** lets you run on x86 or ARM per project. No forced architecture changes, or separate builds for ARM-incompatible dependencies. **Heroku's** Fir generation runs on ARM only. Applications with x86-specific dependencies may require code changes to remain compatible. |
| Resource scaling | Granular vCPU + RAM | Fixed dyno tiers | **Upsun** resources scale linearly, allocate the exact vCPU and RAM your workload needs, and you pay only for what you provision. **Heroku** dynos come in fixed sizes. Scaling means jumping to the next tier, which often means paying for more than you need. |
| Persistent storage | Internal storage included | 3rd-party add-on required | On **Upsun**, persistent storage is included by default. Mount writable directories directly in your app configuration. **Heroku's** filesystem resets on every dyno restart. Persistent storage requires a paid third-party add-on. |
| Security | Built-in WAF | Third-party add-on required | **Upsun** includes built-in WAF and rate limiting, active by default across all environments. **Heroku** has no built-in WAF or DDoS mitigation. Both require third-party add-ons, configured and billed separately. |
| Data protection | Internal data protection | Premium add-on | **Upsun** includes encryption at rest and in transit, automated backups, and point-in-time recovery across all plans. HIPAA-eligible data protection on **Heroku** requires a Shield Private Space, available on enterprise plans only. |
| Compliance | Natively integrated Blackfire profiling | OTel log drains only; no profiling | **Upsun** is certified ISO/IEC 27001, SOC 2 Type 2, PCI DSS Level 1, and HIPAA-eligible. Compliance monitoring is automated across all environments. **Heroku** holds SOC 2 Type 2 certification and supports PCI compliance within Shield Private Spaces. |
| Cron jobs | Internal (no usage fee) | Add-on with usage fees | **Upsun** includes cron jobs within each application at no extra cost. **Heroku's** scheduler add-on is often unreliable and counts toward billable usage. |
| AI infrastructure | Native MCP server | Standard API access | **Upsun** provides AI agents (Cursor, Claude) with real-time infrastructure context via MCP. **Heroku** lacks native agentic integration. |
| Service restarts | On-demand control | Disruptive daily cycles | **Upsun** restarts are developer-controlled and on-demand; no forced cycling of running processes. **Heroku** dynos restart automatically at least once every 24 hours. Cedar-generation apps cannot disable this behavior. |

Need more details? Check [this post](/blog/heroku-vs-upsun/) with a more technical overview.

## Built for how modern teams work

### Define your stack in code

Your entire infrastructure (services, runtimes, and relationships) is defined in a single configuration file within your Git repository. No dashboard-driven manual configuration or add-on sprawl.

### Git branch to clone

Upsun triggers an instant, data-complete preview environment for every pull request. Test migrations and new features against byte-for-byte copies of production data in under a minute.

### One platform, everything included

DDoS protection, persistent storage, cron jobs, observability, and automated backups are built in. One contract, one bill, no third-party add-ons to provision, configure, or maintain.

### Transparent and predictable pricing

Pay only for the resources you provision. No dyno tier jumps, step-increase, surcharges, or surprise invoices when your app performs well. Spending alerts keep your budget exactly where you set it.

## How migrating to Upsun works

### Assessment

Book a demo call with Upsun's migration team. We map your current Heroku stack: dynos, add-ons, config vars, and dependencies, and identify blockers before you commit to anything.

### Mapping

Your entire infrastructure is defined in a single YAML configuration file and deployed to a Upsun sandbox. Services, runtimes, and relationships verified against your production setup.

### Migration

Same buildpacks, same git push workflow, minimal changes to your application code. Upsun's team works alongside yours throughout the transition. Most teams are live in 30 days or less.

### Go live

Production cutover with zero service interruption. DNS cutover, Fastly CDN activated, and Blackfire profiling confirming performance against your production baseline.

"Anyone who has some level of knowledge about DevOps concepts and YAML syntax can get started with Upsun; it’s a fairly easy product for the amount of complexity it can handle. That’s the magic." —Lukas Kahwe Smith, CTO and Co-founder, Witty Works

## FAQs

### Do I need to rewrite my application to migrate from Heroku to Upsun?

No. Upsun supports the same Cloud Native Buildpacks Heroku uses, so most applications run with minimal or no changes. Your git push workflow stays intact. Config vars map directly. The main change is a single YAML file that defines your infrastructure: services, runtimes, and relationships, replacing dashboard-driven manual configuration.

### How long does migration take?

Most teams are live in 30 days or less. Easypara, a large-scale Magento 2 ecommerce platform with a multi-million-row database, completed its full migration in 30 days with zero service interruption.

### What happens to my Heroku add-ons?

Most of Heroku's add-ons are built into Upsun at no extra cost: DDoS protection, persistent storage, cron jobs, observability via OpenTelemetry and Blackfire, and automated backups. Third-party add-ons that connect via API keys and environment variables, such as New Relic, continue to work after migration by copying over the relevant config vars.

### What migration support does Upsun provide?

Upsun offers a 20-minute architecture audit to assess your stack before you commit to anything, followed by hands-on white-glove migration support throughout the transition. The audit is a factual go/no-go assessment.

### How does Upsun pricing compare to Heroku?

Upsun bills linearly; you provision the exact vCPU and RAM your workload needs and pay only for what you provision. No dyno tier jumps, step-increases, and surcharges when your application performs well. Spending alerts notify you when your monthly estimate crosses a threshold you set.

### [Secure, compliant app environments by default | Upsun](https://upsun.com/features/security-and-compliance/)

# Every environment ships with _security and compliance built in_

Environments inherit a hardened security posture and compliance-ready controls by default, across every environment from preview to production.

Secure, compliant app environments by default | Upsun

Secure, compliant environments from preview to production. Hardened runtime, TLS and encryption, RBAC, network controls, and managed patching built in.

## Security that doesn't slow your team down

### Secure by default

Environments run with a read-only file system and a controlled execution model. Security controls are enforced automatically, without application-level customization.

### Built-in compliance controls

Upsun provides a platform foundation aligned with common compliance requirements, with certifications and guidance documented in the Trust Center.

### Managed updates and patching

Security patches and platform updates are applied regularly by Upsun. No tracking, no manual fixes, no exposure to known vulnerabilities.

## Compliance you inherit, not engineer

Build on certified infrastructure and let the platform carry the audit burden.

- Read-only file systems and hardened runtime environments
- Automated TLS certificates and encrypted data paths
- Built-in network isolation and traffic controls
- Role-based access control with integrated MFA
- Regular, managed security updates and patches
- ISO 27001, SOC 2, SOC 3, and PCI-DSS certified infrastructure

## Built for teams with real security requirements

### Regulated environments

A financial services team runs customer-facing applications with platform-level controls that align with regulatory requirements, without building custom security infrastructure.

### Enterprise access management

A platform team enforces role-based access across multiple projects, ensuring developers and operators have appropriate permissions without a separate access layer.

### Continuous compliance

An organization relies on Upsun's managed updates and Git-based auditability to maintain compliance as applications evolve, without dedicated compliance engineering.

### Auditability and traceability

Every configuration change versioned in Git, every platform action logged. Internal reviews and external audits without additional tooling.

### Access governance

Centrally managed permissions with MFA, role-based access control, and comprehensive audit logging. Least-privilege access enforced across every project.

### Data protection

Encryption in transit and at rest. Region-specific deployment to meet data residency and sovereignty requirements.

### [Get a multicloud operating model review | Upsun](https://upsun.com/get-a-multicloud-operating-model-review/)

# One operating model _for every cloud_

Most multicloud setups weren't designed. They accumulated. Speak with an expert to see where your multicloud setup is drifting, and how Upsun keeps delivery, governance, and operations consistent across providers.

-   Find where running across providers is duplicating work and slowing your teams down.
-   Apply the same access, security, and compliance rules on every cloud.
-   Give your teams one way to ship software across AWS, Azure, and Google Cloud.
-   Replace per-provider scripts and runbooks with versioned, portable config.

Get a multicloud operating model review | Upsun

Review where cloud dependency, environment drift, and per-provider overhead are slowing your teams down.

GM -Multicloud control campaign Contact page

### [Cloud PaaS for any language or framework | Upsun](https://upsun.com/frameworks-paas/)

# The _polyglot PaaS_ that deploys on every git push

Push your Node.js, PHP, Python, Java, Go, Ruby, Rust, or .NET app to Git. Upsun builds, deploys, and scales it, with preview environments that clone production byte for byte.

Deploy your first app in minutes

## Powered by Platform.sh. 6,000+ customers. 8 years in production.

- Adobe
- UNICEF
- GAP
- Assa Abloy
- Colby College
- Columbia University
- ebsco
- first Foundation
- freitag
- hachette Livre
- havas Dublin
- invesco
- md Systems
- mentos
- mizzou
- nrdc
- orange
- oxford
- pacific Bank
- paul Scherrer institute
- randstad institute
- rhodes college
- sorbonne university
- university of surrey
- suzuki
- taboola
- unity
- university Of British Columbia
- u.s. chamber of commerce
- wittyWorks
- YMCA

Cloud PaaS for any language or framework | Upsun

Deploy Node.js, PHP, Python, Java, Go, Ruby, Rust, or .NET apps on Upsun. Push to Git and get automatic builds, deploys, and production-identical previews.

### What Upsun is

Upsun is a cloud application platform. Connect your Git repository, define your stack in YAML, and every push builds, deploys, and scales your app. No DevOps team required.

## Everything _your app_ needs, managed _for you_

### Git push to deploy

Connect your repository. Every push builds and deploys automatically. Define your stack, language, dependencies, and services in one declarative YAML file, versioned right alongside your code.

### Preview environments that mirror production

Every branch and pull request gets a full stack environment cloned from production, data and services included. Catch the problems before they ship, not after.

### Your frameworks, your services, your cloud

Django, Next.js, Laravel, Symfony, and more. Add PostgreSQL, Redis, or Kafka in a line of config. Deploy to AWS, GCP, Azure, IBM Cloud, or OVHcloud, and switch anytime. No lock in.

### Scales when you do

Horizontal and vertical scaling, built in observability, and daily backups keep production steady. Support is available around the clock.

## From _repo to running_ in three steps

- Connect your Git repository. GitHub, GitLab, or Bitbucket.
- Describe your app in YAML. Language, dependencies, and any services you need.
- Git push. Upsun builds, deploys, and hands you a live URL with a preview environment for every branch.

### See it in code

One file defines your runtime, dependencies, and services, all in version controlled YAML, ready to commit alongside your app.

## _More_ than hosting

Hosting hands you a server and leaves the rest to you. Upsun runs the whole application lifecycle: build, deploy, preview, and scale, with no servers to patch and no pipeline to maintain.

63%

Faster deployments

Push your code and Upsun provisions infrastructure, spins up services, and deploys your application automatically.

<1 min

Preview environments

Spin up production-identical clones with real data, configs, and files for every branch.

99.99%

Uptime SLA available

Run multiple sites and customer instances with confidence. Built for reliability at portfolio scale.

"This morning, we launched a new development environment to test a disruptive feature. That would've been a huge ordeal in our old setup. Now it's just part of the workflow." —Geoff Douglas, VP of Engineering, MarketNation

## FAQ

### Which languages and frameworks are supported?

Upsun supports .NET, Elixir, Go, Java, Node.js, PHP, Python, Ruby, and Rust as core runtimes, plus flagship frameworks like Django, Next.js, Laravel, Symfony, Drupal, WordPress, and Magento. Most other frameworks run too, since you control the build and start commands directly.

### Can I mix multiple languages in one project?

Yes. Multi-app projects let you run different languages side by side in the same project, for example a Python API alongside a Node.js frontend.

### Is the free trial really free? Do I need a credit card?

The free trial runs for 15 days. You don't need to add a credit card to start.

### Can I deploy to my own cloud and choose a region?

Yes. Deploy to AWS, GCP, or Azure, and choose from multiple regions based on proximity to your users. Some regions also qualify for a sustainability credit on your resource usage.

### How is this different from Heroku or from plain hosting?

You get preview environments that clone production, multi cloud with no lock in, and the full lifecycle in one platform.

Generic code lang LP (for linkedin ads)!