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 relationshipsdeclaration 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.