Best Platform.sh Alternative for Web Application Hosting

Platform.sh (now part of the Upsun product family) has been a reliable hosting platform for PHP, Python, and Node.js applications for years. It offers strong multi-environment support, built-in services, and enterprise compliance features. However, its YAML-based configuration system, complex resource-unit pricing model, and steep onboarding curve have prompted many development teams to explore simpler Platform.sh alternatives.

This article compares Platform.sh with Out Plane across configuration complexity, build systems, pricing, and developer experience. It is written for teams actively evaluating their hosting options — not to dismiss Platform.sh, but to help you determine when a simpler platform is the right fit.

Why Developers Look for Platform.sh Alternatives

Platform.sh solves complex hosting problems. The question is whether your hosting problems are actually complex.

For teams with sophisticated multi-branch deployment requirements, large PHP monoliths, or strict compliance needs, Platform.sh delivers genuine value. But a significant portion of the developer community encounters the platform's complexity before they encounter its benefits.

YAML Configuration Overhead

Deploying an application on Platform.sh requires at minimum three YAML configuration files:

• .platform.app.yaml — application definition, build hooks, runtime configuration
• .platform/routes.yaml — URL routing, redirects, and service binding
• .platform/services.yaml — database and cache service configuration

Each file has its own schema, its own conventions, and its own failure modes. Teams new to Platform.sh spend considerable time reading documentation before their first successful deployment. Teams returning to the platform after time away often need to relearn which setting lives in which file.

This is not a design flaw — it reflects the platform's depth. But for straightforward web applications, three configuration files before you see a deployed container is a meaningful friction cost.

Resource-Based Pricing That Is Hard to Predict

Platform.sh pricing is based on resource units rather than simple compute hours or per-second billing. You select a plan and allocate CPU, RAM, and storage to each container. The pricing scales with those allocations across every environment.

In practice, many developers find it difficult to predict monthly costs before they have deployed and measured their application. The available documentation explains the model clearly, but translating it into an expected invoice requires understanding how your application uses resources across each environment — and doing that calculation before deploying is challenging.

Onboarding Complexity

Platform.sh uses its own CLI tool as the primary interaction interface. Deployments go through the platform CLI or a direct Git remote. Understanding the platform's concepts — environments, services, routes, and build hooks — requires upfront investment before productive work can begin.

New team members joining a project on Platform.sh face a meaningful learning curve. Unlike platforms that map to familiar concepts (GitHub integration, web console, Dockerfile), Platform.sh has its own model that must be learned on its own terms.

The Upsun Transition

Platform.sh has been transitioning its product offering under the Upsun brand. For teams evaluating the platform today, it is not always clear which interface to use, which documentation applies to which product, and how existing Platform.sh accounts relate to the Upsun offering. This transition-period confusion is a reasonable concern for teams that want stable tooling and clear documentation.

Limited Docker Support

Platform.sh uses a proprietary build system. While the platform supports containers internally, your Dockerfile is not the primary interface. Teams that have standardized on Docker-based workflows, multi-stage builds, or container image CI pipelines need to adapt their existing practices to fit the Platform.sh model rather than the other way around.

Comparison: Platform.sh vs. Out Plane

Pricing Comparison

Platform.sh Pricing

Platform.sh pricing is resource-based and environment-aware. The entry-level plan starts at $10 per month for a single environment with minimal resource allocation. Production-grade plans that include adequate CPU, RAM, and additional environments cost meaningfully more.

Each environment on Platform.sh is a full stack replica — it runs its own application containers and services. This is a powerful feature for branching workflows but it also means that every active environment contributes to your monthly bill. Teams running five or ten development branches simultaneously pay for compute across all of them.

The resource allocation model requires you to pre-configure how much CPU and RAM each container receives. Allocating too little causes performance problems. Allocating too much increases cost without benefit. Tuning this allocation accurately requires operational experience with the specific application under realistic load.

Out Plane Pricing

Out Plane uses per-second billing. You are charged for the compute your application actually consumes, measured in seconds, across instances that are actively running.

New accounts receive $20 in free credit with no credit card required to start. Three free instances are included on the Hobby plan, which makes it practical to run a development or small production environment at no cost.

Because billing is per-second rather than per-resource-allocation, you do not need to pre-configure RAM or CPU envelopes before deploying. The platform allocates what your application needs and bills accordingly. Variable workloads — applications that are busy during the day and quiet overnight — benefit directly from this model.

For teams running staging and development environments alongside production, Out Plane's per-second billing means that environments receiving no traffic incur no meaningful cost.

Key Differences

Configuration: YAML Files vs. Web Console

Platform.sh requires you to define your application, routes, and services in version-controlled YAML files. Changes to infrastructure are made by editing those files and pushing. This approach has real advantages for teams that want infrastructure-as-code, auditability, and Git-driven change management.

Out Plane's configuration lives in the web console at console.outplane.com. You connect a GitHub repository, select a branch, choose Dockerfile or Buildpack as the build method, and deploy. Environment variables, scaling settings, and domain configuration are all managed through the UI.

Neither model is objectively better. YAML configuration gives you more fine-grained control and Git history for infrastructure changes. Web console configuration has lower overhead and a shorter path to first deployment. The right choice depends on your team's workflows and the complexity of what you are deploying.

Build System: Proprietary vs. Docker and Buildpacks

Platform.sh uses its own build system, which is informed by the configuration in .platform.app.yaml. You specify a build flavor (for example, php:8.2 or nodejs:20), define build hooks, and the platform handles the rest. This system works well within the Platform.sh ecosystem and supports a wide range of language runtimes.

The constraint is portability. A Platform.sh application configuration does not translate directly to a Dockerfile or a standard container image. If you want to run your application locally with the same build process, or push the image to a container registry, you need a separate setup.

Out Plane supports both Dockerfiles and Paketo Buildpacks as first-class deployment methods. A Dockerfile you write once runs identically in local development, in CI, and in Out Plane. Buildpacks automatically detect your language and framework if you prefer not to write a Dockerfile. Either way, the build artifact is a standard OCI-compatible container image.

For teams that have already adopted Docker-based workflows, this is a meaningful operational difference.

Pricing: Resource Units vs. Per-Second

Platform.sh requires you to commit to resource allocations — defined CPU and RAM — for each container in each environment. You pay for those allocations whether or not your application uses them fully.

Out Plane measures actual compute consumption by the second. If your application is under load, you pay for that load. If it is idle, your costs drop. This model is straightforward and requires no upfront capacity planning.

The practical impact is most visible on variable workloads and multi-environment setups. An application that receives traffic for eight hours a day costs roughly a third of what it would cost on an allocation-based model. A staging environment that only sees traffic during active development costs a fraction of what it would cost as a persistent Platform.sh environment.

PHP and CMS Hosting

Platform.sh has deep support for PHP applications. Laravel, Symfony, WordPress, and Drupal are well-supported with first-class documentation, pre-built configuration examples, and a runtime that has been tuned for PHP workloads over many years. If your primary stack is PHP and you want a hosting provider with deep PHP expertise and proven patterns, Platform.sh has a strong track record here.

Out Plane deploys PHP applications through Buildpacks or Docker. The Laravel deployment guide covers the full process. For most PHP frameworks, Paketo Buildpacks handle language detection and dependency installation automatically. Custom PHP configuration, extensions, and version pinning are handled through the Dockerfile or Buildpack configuration.

When Platform.sh Still Makes Sense

Platform.sh has genuine advantages in certain situations. A fair evaluation of alternatives means acknowledging them.

PHP-heavy projects with complex service dependencies. Platform.sh's built-in support for Solr, Elasticsearch, Vault, and other services makes it straightforward to deploy applications that depend on a non-trivial service stack. Its PHP runtime configuration options are extensive and well-documented.

Multi-environment branching workflows. Platform.sh's core feature is the ability to create a full application stack for each Git branch. Development branches get their own database, cache, and application container with a single command. For teams that review feature branches with live data or need isolated test environments per PR, this capability is genuinely valuable and difficult to replicate elsewhere.

Existing Platform.sh expertise on the team. If your team has engineers who know Platform.sh well — who understand the configuration files, the CLI, and the deployment model — the onboarding cost is already paid. Switching platforms resets that investment.

Enterprise teams with existing Platform.sh contracts. Organizations running large, stable applications on Platform.sh with enterprise support agreements have limited incentive to migrate. The operational risk of migration does not justify the change unless costs are prohibitive or specific features are blocking work.

When Out Plane Is a Better Fit

Docker-based workflows. If your team already uses Dockerfiles across development, CI, and deployment, Out Plane treats Docker as the primary deployment method rather than an alternative path. Your existing container configuration works without modification.

Non-PHP applications or mixed-language services. Out Plane's build system is language-agnostic. Node.js, Python, Go, Rust, Java, and Ruby applications are all first-class deployments. See the Heroku alternative guide for a broader view of supported stacks.

Simpler pricing. If you want billing that tracks actual usage rather than committed resource allocations, per-second billing removes the need to tune resource envelopes before deployment. You deploy and pay for what runs.

Faster onboarding. Connecting a GitHub repository and deploying takes a few minutes without reading a configuration schema. Teams iterating quickly or evaluating hosting options benefit from reduced setup time.

Transparent costs across environments. If you run multiple environments (production, staging, preview), per-second billing means inactive environments cost almost nothing. Platform.sh charges for allocated resources in each active environment regardless of traffic.

Starting a new project without platform lock-in. Because Out Plane uses standard Dockerfiles and Buildpacks, your application is not tied to a proprietary build system. Moving between platforms in the future requires no build configuration changes.

Migration from Platform.sh

Migrating an application from Platform.sh to Out Plane is a practical process for most web applications. The key steps are export, adapt, deploy, and cut over.

Step 1: Export Environment Variables

In the Platform.sh CLI, retrieve your current environment variables:

platform var:list --environment main

Export the values you need and prepare them for import into Out Plane's environment variable editor.

Step 2: Export Your Database

Platform.sh provides built-in database dump tooling. For PostgreSQL:

platform db:dump --environment main --relationship database

This creates a local dump file you can restore after provisioning a managed database on Out Plane.

Step 3: Prepare a Dockerfile or Verify Buildpack Detection

If your application already has a Dockerfile, it is ready to use on Out Plane without changes.

If you are using Platform.sh's build hooks and no Dockerfile exists, review the build commands in your .platform.app.yaml and translate them into a Dockerfile. For many common frameworks, Paketo Buildpacks will detect the language and framework automatically — you may not need a Dockerfile at all.

A minimal Node.js example:

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

For PHP applications like Laravel, see the Laravel deploy guide for a complete Dockerfile example with PHP-FPM and Nginx.

Step 4: Connect and Deploy on Out Plane

1. Go to console.outplane.com and sign in with GitHub.
2. Select your repository and branch.
3. Choose Dockerfile or Buildpack as the build method.
4. Add your environment variables using the Raw Edit input.
5. Click Deploy.

Out Plane builds your application, deploys it, and provides a URL. Subsequent pushes to your configured branch trigger automatic redeployment.

Step 5: Provision and Restore Your Database

Create a managed PostgreSQL instance from the Out Plane console. Once provisioned, restore your dump:

pg_restore --no-acl --no-owner -d your-connection-string dump.sql

Update your application's DATABASE_URL environment variable to point to the new instance.

Step 6: Update DNS

Add your custom domain in the Out Plane console, then update your DNS CNAME record to point to your Out Plane application URL. SSL is provisioned automatically once DNS propagates.

After verifying the application is running correctly, you can decommission the Platform.sh environment.

For a broader comparison of deployment workflows and platform choices, see the Render alternative guide.

Summary

Platform.sh is a capable platform with a long track record, especially for PHP applications and teams that need per-branch environment isolation. Its configuration depth and enterprise maturity are real advantages in the right context.

For teams that find YAML configuration overhead, resource-based pricing, and proprietary build tooling more friction than value, simpler alternatives exist. Out Plane offers per-second billing, native Docker and Buildpack support, and a web console that gets applications deployed quickly — without requiring three configuration files before the first deployment.

New accounts receive $20 in free credit and three free instances to evaluate the platform before committing. The migration path from Platform.sh is straightforward: export your data, add a Dockerfile or rely on Buildpack detection, connect your repository, and deploy.

Ready to simplify your hosting setup? Get started with Out Plane — no credit card required.