In the past, we had to write all kinds of one-off services and chain them using complex depends_on rules. Now, with the release of the new Docker Compose features, we finally have official Init Containers support. In this post, we'll dive into how it works and how it can help us slim down our compose.yaml!

When deploying applications with Docker Compose, we often run into a very common requirement: performing some initialization tasks before the main application boots up.

For example:

• Running database migrations before starting the web service.
• Fixing mount directory permissions before running the container as a non-root user.
• Generating configuration files before the application officially launches.
• Importing initial seed data before launching the main service.

In the past, we usually defined a separate, one-off service like migrate, init, or setup, and controlled the execution order using depends_on with condition: service_completed_successfully.

Now, Docker Compose officially provides a more natural approach: Init Containers.

Init Containers are essentially short-lived containers that execute sequentially before the main service container starts. If any step exits with a non-zero code, the main service will not start.

What Are Init Containers?

You can think of Init Containers as:

A set of initialization steps bound to run before a specific service starts.

They are not long-running services or background tasks, but rather temporary containers that "run and exit".

In Docker Compose, this capability is implemented via the pre_start lifecycle hook. According to the official documentation, each step in pre_start runs in its own independent temporary container, which executes after the service container is created but before it actually starts.

Here is a simple example:

1
2
3
4
5

services:
  app:
    image: myapp:latest
    pre_start:
      - command: ["./manage.py", "migrate"]

This configuration means:

1. Docker Compose first creates the app service container.
2. Before app actually starts, it runs ./manage.py migrate.
3. If the migration command exits successfully (exiting with status code 0), app will start.
4. If the migration fails, app will not start.

This is much cleaner than writing a separate migrate service like we used to.

How Did We Do It Before?

Before pre_start came along, if we wanted to express "run migration first, then start the application", we typically wrote it like this:

1
2
3
4
5
6
7
8
9
10
11

services:
  migrate:
    image: myapp:latest
    command: ["./manage.py", "migrate"]
    restart: "no"

  app:
    image: myapp:latest
    depends_on:
      migrate:
        condition: service_completed_successfully

While this approach works, it has several obvious issues:

• Conceptual Confusion: migrate is not actually a long-running service; it is just an initialization step for app. Putting it at the top-level of services makes the Compose configuration file bloated.
• Residual State: Once the task is complete, it remains in the docker compose ps list as an exited service, which litters your active service list.
• Tedious Orchestration: If you have multiple initialization steps (e.g., migrating the database, seeding default data, and generating configuration files), you have to define multiple one-off services and chain them using a series of complex depends_on rules.

With the new pre_start feature, we can consolidate them directly inside the service:

1
2
3
4
5
6

services:
  app:
    image: myapp:latest
    pre_start:
      - command: ["./manage.py", "migrate"]
      - command: ["./manage.py", "loaddata", "fixtures.json"]

Official Docker documentation highlights the following benefits of pre_start:

1. Initialization logic is expressed as a sub-step of the service, rather than masquerading as a parallel, independent service.
2. Completed temporary steps do not appear in docker compose ps, keeping the environment clean.
3. Multiple steps are executed sequentially, eliminating the need for complex chain-like depends_on logic.

Example 1: Running Database Migrations Before Start

This is the most classic use case.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

services:
  app:
    image: myapp:latest
    depends_on:
      db:
        condition: service_healthy
    pre_start:
      - command: ["./manage.py", "migrate"]

  db:
    image: postgres:18
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: password
      POSTGRES_DB: app
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"]
      interval: 10s
      retries: 5
      start_period: 30s
      timeout: 10s

There are two key details here:

1. Dependency: app waits for the db container to reach a service_healthy state via depends_on.
2. Initialization Timing: Before app starts, it executes ./manage.py migrate inside a temporary container.

If the database migration succeeds, the main app service starts; if it fails, app will not start, and the error logs will output directly within docker compose up.

This design is perfect for Django, Rails, Laravel, Prisma, Drizzle, Alembic, or any other framework that requires database schema migration before running the app.

Example 2: Fixing Volume Permissions

Another major pain point is permissions: when a service runs as a non-root user but is mounted to a Docker named volume (which defaults to root ownership), the container can crash due to lack of write access.

In the past, we had to modify the Dockerfile extensively or spin up a separate sidecar container. Now, pre_start makes it incredibly lightweight:

1
2
3
4
5
6
7
8
9
10
11
12
13

services:
  app:
    image: myapp:latest
    user: "1000:1000"
    volumes:
      - data:/data
    pre_start:
      - image: busybox
        user: root
        command: sh -c 'chown -R 1000:1000 /data'

volumes:
  data:

In this example:

• The app container runs as a non-root user 1000:1000.
• The pre_start step overrides the image to busybox and executes chown as root to correct the directory ownership before the main service runs.

This scenario is extremely useful in self-hosted and open-source deployments, such as:

• Fixing upload or cache directory permissions.
• Automatically initializing the structure of a data directory.
• Pre-generating default configuration files in a mounted path.

Example 3: Chaining Multiple Initialization Steps

pre_start supports defining a list of steps that will execute sequentially. The next step will run only if the previous one exits successfully (returns 0). If any intermediate step fails, subsequent steps and the main service will terminate.

For example:

1
2
3
4
5
6
7
8
9
10
11
12
13

services:
  app:
    image: myapp:latest
    depends_on:
      db:
        condition: service_healthy
    pre_start:
      - command: ["./manage.py", "migrate"]
      - command: ["./manage.py", "loaddata", "fixtures.json"]
      - command: ["./scripts/generate-config.sh"]

  db:
    image: postgres:18

The entire startup flow is:

1. Wait for the database container to become healthy.
2. Execute the database schema migrations.
3. Import initial seed data.
4. Generate dynamic configuration files.
5. Spin up the main application container.

For instance, when inserting seed data:

1
2
3
4
5
6

-- Not recommended: naive insert every time, which might cause primary key conflicts or duplicate data
INSERT INTO users (id, name) VALUES (1, 'admin');

-- Recommended: skip when conflict is detected, ensuring idempotency
INSERT INTO users (id, name) VALUES (1, 'admin')
ON CONFLICT (id) DO NOTHING;

Execution Rules of pre_start Containers

According to the official documentation, the temporary containers spun up by pre_start behave according to these rules:

• Independent Containers: Each step runs in its own dedicated, short-lived container.
• Inherited by Default: They inherit the image defined by the host service, so you don't need to specify it repeatedly.
• Image Override Allowed: You can specify another lightweight utility image (like busybox) via the image field.
• Shared Network: They automatically join the network of the host service, giving them direct access to other dependent services declared in depends_on.
• Shared Volume Mounts: They automatically share all volumes declared on the host service.
• Strict Status Code Constraint: They must return exit code 0 for subsequent steps and the main service to run.

These features make configurations extremely convenient. For instance, if the migration command is already bundled in the application image, you can declare it directly without specifying the image:

1
2

pre_start:
  - command: ["pnpm", "db:migrate"]

If you need a helper image (such as busybox) for file operations, just override the image in the step:

1
2
3
4

pre_start:
  - image: busybox
    user: root
    command: sh -c 'chown -R 1000:1000 /data'

Since the temporary containers share the same network and volumes, any configuration file generated, permissions fixed, or data populated in the mount path will be immediately visible to the main container when it starts.

Does It Run Every Time I Execute docker compose up?

The answer is: No. This is a crucial detail to keep in mind.

According to the official Docker documentation:

• If a pre_start step has already run successfully in a previous deployment and its definition has not changed, Compose will automatically skip it on subsequent runs of docker compose up.
• If a service restarts due to its restart policy, pre_start will not be triggered again.
• The initialization steps will only run again if:
  1. The step's configuration definition changes.
  2. The previous execution failed (exited with a non-zero code).
  3. You force recreation using docker compose up --force-recreate.

Thus, pre_start acts more like a "one-time deployment initialization" in the lifecycle of the host service, rather than a recurring process wrapper.

When Are Init Containers Not Suitable?

While Init Containers are highly convenient, they are not a silver bullet. According to official guidelines, if your requirement is simply to inject static configuration files or credentials, you should prioritize Docker Compose's native configs and secrets, which support direct mounts and fine-grained permissions/ownership controls.

We do not recommend using pre_start in the following scenarios:

1. Mounting Static Configuration Files

For fixed configuration files that do not need to be dynamically generated, mount them directly instead of spinning up an initialization container to write them.

Recommended Approach:

1
2
3
4
5
6
7
8
9
10

configs:
  app_config:
    file: ./config/app.yml

services:
  app:
    image: myapp:latest
    configs:
      - source: app_config
        target: /app/config.yml

2. Sensitive Credential (Secret) Injection

Database passwords, API keys, and other sensitive tokens should never be written to a volume or filesystem using initialization scripts to avoid leakage.

Recommended Approach:

1
2
3
4
5
6
7
8
9

secrets:
  db_password:
    file: ./secrets/db_password.txt

services:
  app:
    image: myapp:latest
    secrets:
      - db_password

3. Cron Jobs and Background Maintenance Tasks

For example:

• Routine data backups.
• Periodic cleanup of cache or temporary files.
• Post-termination cleanup work.

These tasks are not blocker dependencies for the main application start, and therefore should not be put in pre_start.

Current Design Limitations

Since this feature is relatively new, you should keep the following limitations in mind:

• No Per-Replica Execution: pre_start runs once per service, not per container instance (currently, there is no per_replica: true support).
• Incompatibility with Certain Mounts: While shared named volumes and bind mounts work perfectly, pre_start cannot share files with main containers if you are using anonymous volumes or tmpfs mounts, which are unique to each container instance.
• No Trigger on Scaling: When scaling up (e.g., running docker compose up --scale app=3), new container instances do not trigger pre_start again. It still follows the "config changed or forced recreation" triggering logic.

Therefore, if your initialization logic (like local cache pre-warming) must run on every replica, do not rely on pre_start for now.

Differences from Kubernetes Init Containers

Conceptually, both serve the same purpose: preparing the environment before the main workload container starts.

However, they differ in implementation and power:

• Kubernetes (K8s) Init Containers are first-class, Pod-level entities deeply integrated with cloud-native distributed scheduling, and natively support initializing each replica independently.
• Docker Compose Init Containers are implemented as a lightweight solution via the pre_start lifecycle hook. It is geared towards single-host deployments, local development, and small-scale self-hosted environments.

Simply put, Docker Compose's Init Containers are a simplified initialization mechanism tailored specifically for Compose workloads—small but highly capable.

Best Practice Recommendations

When using pre_start in production or development environments, we recommend following these principles:

1. Absolute Idempotency: Your initialization scripts must achieve "identical results over multiple runs" to handle retries and recreations cleanly.
2. No Persistent Processes: Each step in pre_start must exit quickly with 0. Long-running or daemonized processes will block the main service startup indefinitely.
3. Separate Production and Development Migration Strategies: While auto-running migrate in pre_start is convenient, running migrations automatically in production carries risk. Consider triggering database migrations via an independent CI/CD pipeline for critical online environments.
4. Encapsulate Complex Logic in Scripts: If your initialization contains complex checks or multiple setup steps, package them into a dedicated shell script (e.g., ./scripts/init.sh) inside the container and call it from the compose.yaml to keep your configuration clean.

1
2

pre_start:
  - command: ["./scripts/init.sh"]

Conclusion

Docker Compose's Init Containers finally address a long-standing pain point in container orchestration: how to gracefully define start-up dependencies.

We can summarize the suitable and unsuitable scenarios as follows:

Let's conclude with a side-by-side comparison of the configuration before and after this feature:

1
2
3
4
5
6
7
8
9
10
11

services:
  migrate:
    image: myapp:latest
    command: ["./manage.py", "migrate"]
    restart: "no"

  app:
    image: myapp:latest
    depends_on:
      migrate:
        condition: service_completed_successfully

1
2
3
4
5

services:
  app:
    image: myapp:latest
    pre_start:
      - command: ["./manage.py", "migrate"]

This is the core value of Docker Compose Init Containers: letting initialization steps gracefully return to where they truly belong.

Whether for input or output, the unit price of Sonnet 5 is only 60% of Opus. However, a lower unit price does not necessarily mean it's more cost-effective. As we will discuss later, measured by actual task cost, Sonnet 5 might end up costing more to complete the same task—which is the source of the controversy.

With a lower unit price compared to Opus and a major version jump, you might wonder: is Sonnet 5 really worth using?

Conclusion

Let's jump straight to the conclusion:

Sonnet 5 is not suitable to be used directly as the default model. Its performance is inferior to Opus 4.8, but it has received outstanding reviews for writing tasks.

Therefore, for large-scale, extensive code editing, you should stick to the Opus 4.8 series or use Fable 5 (which will no longer be available in the Claude Code Pro subscription after July 7).

When cost needs to be considered, when a newer knowledge base is required (updated to January 2026), and in small tasks or writing tasks, you can switch to Sonnet 5.

For simpler tasks, other more economical models will suffice.

What is Sonnet 5?

According to Anthropic's official announcement, Claude Sonnet 5 is the next-generation model in the Sonnet family, positioned as a 'state-of-the-art performance model for coding, agents, and professional tasks.' Anthropic placed it in the Sonnet product line rather than the higher-end, more expensive Opus or Fable flagship lines. This itself is a signal: Sonnet 5 is not designed to top benchmark leaderboards, but to be used 'every single day.'

Foreign media reports also note that Sonnet 5 is designed to be better suited for high-frequency daily use, with specific enhancements in browsing, coding, planning, knowledge work, and autonomous task execution. It has been rolled out simultaneously to all subscription tiers, including Claude Free, Pro, Max, Team, and Enterprise. This 'full release at launch' approach confirms its positioning as a workhorse model, not a niche feature.

In short, Sonnet 5 is not a 'highest-spec show-off model,' but the primary workhorse model Anthropic wants to push to most Claude users.

This aligns with Anthropic's historical positioning of the Sonnet series: stronger than Haiku, cheaper than Opus, and suited as a daily driver.

Social Media Feedback: A Complete Waste of Money

A chart from Artificial Analysis showing 'Cost per Intelligence Index Task' indicates that under Max thinking level, Claude Sonnet 5's single-task cost is significantly higher than models like GPT-5.5, GLM-5.2, Kimi-K2.6, DeepSeek-V4-Pro, and even higher than the Opus series. Some users quickly summarized it as:

Sonnet 5 should go straight to the trash bin.
1.2x more expensive than Opus 4.8 Max
2x more expensive than GPT-5.5-xhigh
5x more expensive than GLM-5.2
7x more expensive than Kimi-K2.6
57x more expensive than DeepSeek-V4-Pro

In response, Peter Steinberger, creator of OpenClaw, pointed out that price per token != actual task cost != final productivity cost.

Because Sonnet 5's intelligence hasn't made a massive leap forward, it needs to consume more tokens to complete tasks, making the total consumption higher than that of the Opus series.

Therefore, for large-scale code editing projects, it is better to directly use the higher-intelligence Opus series.

The Debate: Is Sonnet 5 Expensive?

Yes, it is.

Especially looking at it from the perspective of 2026, the cost pressure of Sonnet 5 is more obvious than in the past.

The cost chart from Artificial Analysis does not simply compare the input/output token unit prices. Instead, it is weighted according to Intelligence Index tasks, including different token types such as Input, Answer, Reasoning, Cache Write, and Cache Hit. It attempts to answer the question: how much does it cost on average to complete a standardized intelligence task?

This explains why models with seemingly similar API unit prices can have completely different actual task costs. For example, if a model requires an average of 3 rounds of tool calls—rereading the entire context each round to complete a task—while another model can yield a usable result in 1 round, the actual bill of the former will be several times that of the latter even if their unit prices are identical. The gap doesn't come from the pricing table; it comes from 'how many detours the model takes to solve a problem.'

If a model has:

• Longer outputs
• More reasoning tokens
• Heavier tool call chains
• Inability to get it right the first time, requiring iterative corrections
• Low cache utilization

Then its actual cost will be driven up.

This is why many people criticize Sonnet 5:
Anthropic's models are increasingly like luxury gas-guzzlers: high performance, but not cheap to run.

But Looking Only at Single-Task Cost Can Be Misleading

The catch is that developers rarely care about 'how much it costs to run a single benchmark.' Instead, they care about:

Will it save me from hassle?

When it comes to writing code, refactoring projects, analyzing repositories, fixing bugs, and running agents, the model cost is only one part of the total cost. What matters more is:

• Whether the first proposed solution is solid
• Whether it understands the context of a large project
• Whether it avoids modifying unrelated files
• Whether it maintains stability across long-running tasks
• Whether it can detect and correct its own errors
• Whether it reduces manual review and rework

If Sonnet 5 is significantly stronger in these areas than cheaper models, it might still end up being more cost-effective overall, even if its cost per task is higher.

To illustrate, consider a medium-sized refactoring task. A cheaper model might cost only a fifth of Sonnet 5 per token, but because it fails to grasp the project boundaries, it takes 6 rounds of trial and error to barely make it work, while accidentally breaking two unrelated files that you have to manually roll back. On the other hand, Sonnet 5 is more expensive but delivers a working solution in 2 rounds without touching unrelated files. Once you factor in your time spent troubleshooting, rolling back, and re-verifying, the 'total cost' of the cheaper model might not be lower than Sonnet 5—it's just that this cost doesn't show up on your API bill; it manifests as your wasted time.

It's just like cloud servers:

Cheap ones are indeed very cheap, but if they crash three times a day, suffer from IO throttling, or routing issues, you end up wasting valuable human hours.

The same goes for AI models.

Sonnet 5 True Value: Agents and Code Workflows

Judging from Anthropic's marketing focus, the core selling point of Sonnet 5 is not standard chat, but Agentic Workflows.

That is, enabling the model to not just answer questions, but execute tasks sequentially:

• Read project files
• Understand the existing architecture
• Formulate a modification plan
• Call the terminal
• Modify code
• Run tests
• Continue fixing based on errors
• Finally, summarize changes

This is precisely the capability that tools like Claude Code, Cursor, Windsurf, and OpenClaw rely on most.

For these scenarios, the model's 'adherence to instructions,' 'context stability,' and 'tool-calling judgment' are often more critical than simple Q&A. Anthropic's previous generations of Sonnet have had a great reputation in code agent scenarios. If Sonnet 5 continues to strengthen this trajectory, it will remain an indispensable tool for developers.

In complex projects, the issue with many models is not that they cannot write code, but rather that:

• They fail to grasp project boundaries
• They tend to rewrite entire files
• They break B while fixing A
• They make wild guesses when tests fail
• They lose track of context once it grows long
• They repeat the same incorrect fix when seeing an error

If Sonnet 5 can reduce these issues, then it is not just 'expensive' but 'expensive but hassle-free.'

Is It for Everyone?

No.

If your requirements are limited to:

• Translation
• Summarization
• Writing standard articles
• Generating short code snippets
• Asking general knowledge questions
• Light customer support QA
• Bulk processing of low-value text

Then Sonnet 5 is likely not the most cost-effective choice.

These tasks have entered a stage of 'model surplus.' Lower-priced models from GLM, Kimi, DeepSeek, and GPT can do them quite well. Especially for batch tasks, the cost difference will be amplified infinitely.

For instance, for a blog summary, a JSON conversion, or a standard SQL generation task, the benefits of Sonnet 5 may not offset its cost.

In these cases, a more sensible strategy is:

Use cheaper models for basic tasks, the Opus / Fable series for large and complex tasks, and delegate medium-complexity, small-scale tasks to Sonnet 5 when budget is a consideration.

My Recommendation: Don't Use Sonnet 5 as the Default Option Mindlessly

The best way to use Sonnet 5 is not to direct every single request to it, but to treat it as an economical utility model.

You can categorize tasks as follows:

1. General Text Tasks: Avoid Sonnet 5

For translation, polishing, modifying titles, writing summaries, and generating basic Markdown, cheaper models are more than enough.

These tasks do not require deep reasoning, tool calling, or project-wide understanding. Using Sonnet 5 here is overkill.

2. Basic Code Snippets: Case-by-Case

For writing simple functions, editing CSS, or generating a Docker Compose file, cheaper models can get the job done.

However, if they start failing repeatedly, or if you've already spent 10 minutes debugging, it is time to try switching to Sonnet 5.

The most expensive part of a cheap model is making you believe it is 'almost there.'

3. Medium-to-Small Code Tasks: Suitable for Sonnet 5

Examples include:

• Modifying a single page
• Creating a component
• Writing a helper script
• Fixing a specific, clear error
• Adding a simple API endpoint
• Generating test cases
• Performing minor refactoring on existing code

These tasks have clear boundaries, shorter contexts, and low costs of failure. Here, Sonnet 5 can leverage the Claude family's signature code understanding and instruction-following, while keeping the unit cost lower than Opus 4.8.

If the task is not complex, using Opus 4.8 might be wasteful; but if cheaper models keep stumbling, Sonnet 5 offers an excellent middle ground.

It is perfect for code tasks that 'need a bit of intelligence, but do not yet warrant the most advanced model.'

4. Large Project Development and Refactoring: Use Higher-Intelligence Models Directly

If your goal is not fixing a minor bug, modifying a component, or writing a quick script, but rather having AI help build a complete project, Sonnet 5 is likely not the optimal choice.

Such tasks typically involve:

• Building a complete application from scratch
• Designing project architecture
• Implementing multi-module features
• Modifying dozens of files sequentially
• Handling databases, authentication, state management, routing, and deployment configurations
• Running agent tools like Claude Code, Codex, or OpenClaw for hours

In these scenarios, what matters most is not 'low unit cost' but a 'high probability of getting it right on the first try.'

The cost of a large project consists of multiple components, not just token fees:

• The cost of the model understanding requirements
• The cost of maintaining context
• Rework costs from multiple rounds of edits
• Rollback costs from incorrectly modified files
• Troubleshooting costs after test failures
• Time spent on manual review and fixes

If a model's intelligence is slightly lacking, it might look capable at each individual step, but issues crop up when they are combined: it forgets the architecture designed earlier, breaks a newly written interface in the next round, or fixes page A only to break page B. Eventually, the project descends into a state of 'it runs, but don't touch it.'

This is why, for large-scale projects, you should prioritize higher-intelligence models like Opus 4.8 or Fable 5.

Although their unit prices are higher, they maintain global consistency much better in complex tasks, minimizing futile attempts and repetitive fixes. Especially when the task involves architectural design, cross-file refactoring, test fixes, and long-term context retention, the stability offered by more intelligent models outweighs the price difference.

Sonnet 5 is better suited for localized tasks:
Writing a page, modifying a module, generating some copy, adding a test, or fixing a specific error.

But if you are asking an AI to implement a large project from start to finish—especially running agents continuously for hours—a more reasonable strategy is:

Directly use Opus 4.8 or Fable 5. Don't compromise and hand the project to Sonnet 5 just to save a few pennies.

Because in large projects, the most expensive thing is continuing to trust the model after it makes a mistake.

The Catch with Sonnet 5: Anthropic is Still Anthropic

The release of Sonnet 5 also exposes Anthropic's long-standing issue:

The model is great, but the ecosystem and pricing cause anxiety.

Claude's experience has always been strong, particularly with code and long-context tasks. However, in terms of availability, quotas, regions, subscription limits, API costs, and third-party tool support, Anthropic is not as stable as OpenAI.

Moreover, as AI Agent consumption grows, the feasibility of 'unlimited use under a subscription' becomes harder to sustain. Previous analyses have pointed out that the actual API-equivalent cost consumed by power AI users can easily exceed the subscription price. A developer running agent tasks long-term might consume more tokens in a single day than the entire monthly subscription fee. This suggests that AI companies are highly likely to adjust towards more granular, cost-reflective billing methods in the future—such as stricter usage caps, tiered speed limits, or quiet price hikes on the output side, similar to what we see with Sonnet 5.

So, the issue with Sonnet 5 is not just about a single expensive model; it represents a broader trend:

Capable models will keep getting stronger, but the era of truly cheap, unrestricted use is coming to an end.

Summary in a Sentence

Sonnet 5 is neither a cheap model nor the strongest model, but a daily Claude model suited for writing and medium-to-small tasks. It occupies an awkward position in code editing: simple tasks don't require it, and complex tasks are better handled by Opus or Fable.

If you treat it as a cheap alternative to Opus, you might be disappointed;
If you view it as a Sonnet model better suited for daily text work and lightweight tasks, it is still a worthy addition to your toolkit.

In the past, deploying projects on Vercel was a breeze if your app was just a single Next.js, Astro, Vite, or SvelteKit project: import the repository, detect the framework, auto-build, and auto-deploy.

However, once the project gets a bit more complex, for example:

• Frontend: Next.js
• Backend: FastAPI
• Additional service: API written in Go
• Admin dashboard: Vite / React
• Documentation site: Astro or Fumadocs

The dilemma arises: should these be deployed as a single Vercel Project or split into multiple Projects? If split, managing domains, environment variables, Preview URLs, cross-service communication, CORS, and routing rules becomes highly complex.

The recently released Vercel Services is designed specifically to solve this problem: it allows you to run multiple independently built services inside a single Vercel project, and mount them under different paths of the same deployment URL.

What is Vercel Services?

Simply put, Vercel Services allows you to split a single project into multiple independent "Services".

Each Service can have its own entry point directory, framework, build commands, and runtime configurations. However, they ultimately belong to the same Vercel Project and share the same deployment domain.

For example:

1
2
3

https://example.vercel.app/          -> Frontend application
https://example.vercel.app/api       -> Backend API
https://example.vercel.app/admin     -> Admin dashboard

Previously, you might have had to create multiple Vercel Projects and link them together using environment variables or rewrite rules. Now, Vercel Services aims to let these services be deployed, previewed, and managed together within a single project.

According to Vercel's official documentation, to use a multi-service project, you need to set the project's Framework Preset to Services, and configure services (or experimentalServices in experimental phase) in the vercel.json file at the root of the project.

A Minimal Configuration Example

The basic configuration shown in the official documentation looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

{
  "services": {
    "my_frontend": {
      "root": "frontend/",
      "framework": "nextjs"
    },
    "my_backend": {
      "root": "backend/",
      "entrypoint": "main:app"
    }
  },
  // my_backend has no public route
  // it is only reachable from my_frontend internally
  "rewrites": [
    { 
      "source": "/(.*)", 
      "destination": { "service": "my_frontend" }
    }
  ]
}

Two services are defined here:

• my_frontend: Frontend service, with the root directory at frontend/, using the Next.js framework.
• my_backend: Backend service, with the root directory at backend/, and the startup entrypoint as main:app.

Notably, the configuration includes rewrites rules to route all external requests to the frontend service my_frontend. On the other hand, my_backend does not have a public URL route configured; it can only be invoked internally via inter-service networking, making it ideal for hosting private backend APIs.

This approach is highly useful for hybrid frontend-backend projects, and is especially suited for Monorepos.

What Pain Points Does It Solve?

1. No Need to Split Frontends and Backends into Multiple Vercel Projects

Many projects start as a simple frontend site and gradually add APIs, dashboards, Webhooks, and worker services. Over time, the project directory might look like this:

1
2
3
4
5
6
7
8
9
10

my-project/
├── apps/
│   ├── web/
│   └── admin/
├── backend/
│   ├── main.py
│   └── requirements.txt
├── packages/
│   └── shared/
└── vercel.json

Without Services, you might struggle with decisions like:

• Deploying apps/web to one Vercel project
• Deploying apps/admin to another Vercel project
• Deploying backend to a different platform
• Dealing with API endpoints, CORS, and environment variables across all of them

The philosophy of Services is: since these components belong to the same product, they should be deployed together as multiple services of a single Vercel Project.

2. Tailored for Polyglot (Multi-Language) Projects

Historically, Vercel provided the best developer experience primarily for the frontend and Node.js ecosystems, especially Next.js.

However, in real-world scenarios, the backend isn't always written in JavaScript. Many developers use:

• Python + FastAPI
• Go
• Node.js + Express
• Next.js
• Vite
• Astro

Vercel Services allows these services to be seamlessly integrated within a single project.

For example:

1
2
3
4

apps/web        -> Next.js Frontend
backend/api     -> FastAPI Backend
services/worker -> Go Service
apps/admin      -> Vite Admin Dashboard

Previously, projects like this felt like "stitching multiple deployments together." Now, they are treated as "multiple components of a single product."

3. Unified Preview Deployments

One of Vercel's most powerful features is Preview Deployments.

For every Pull Request submitted, a preview URL is automatically generated. If the frontend and backend are split across multiple Projects, managing the linkage between these multiple Preview URLs becomes challenging.

With Services, multiple services share a single deployment URL, distinguished by paths. This makes testing Pull Requests much more natural:

1
2
3

https://my-project-git-feature.vercel.app/
https://my-project-git-feature.vercel.app/server
https://my-project-git-feature.vercel.app/admin

This simplifies things immensely for team collaboration, product QA, and ad-hoc testing.

A More Complete Example: Next.js + FastAPI

Suppose we have a project structured as follows:

1
2
3
4
5
6
7
8
9

my-app/
├── apps/
│   └── web/
│       ├── package.json
│       └── app/
├── backend/
│   ├── main.py
│   └── requirements.txt
└── vercel.json

The vercel.json can be configured as:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

{
  "experimentalServices": {
    "web": {
      "entrypoint": "apps/web",
      "routePrefix": "/",
      "framework": "nextjs"
    },
    "api": {
      "entrypoint": "backend/main.py",
      "routePrefix": "/api",
      "framework": "fastapi"
    }
  }
}

With this configuration:

1
2

/       -> Next.js Frontend
/api    -> FastAPI Backend

The framework field is optional. If omitted, Vercel will attempt to automatically detect the framework. However, you can explicitly specify it to ensure more stable build behavior.

Configuration Fields Reference

The core configuration fields of Vercel Services include:

entrypoint

Specifies the entry file or directory of the service.

For example:

1

"entrypoint": "apps/web"

Or:

1

"entrypoint": "backend/main.py"

routePrefix

Specifies the URL path to mount the service.

For example:

1

"routePrefix": "/api"

This specifies that the service will handle requests directed to /api.

framework

An optional field to specify the framework type, such as:

1

"framework": "nextjs"

Or:

1

"framework": "fastapi"

If not configured, Vercel will automatically detect it during build time.

memory and maxDuration

If a service has higher resource requirements, you can configure memory limits and execution timeout limits.

For example:

1
2
3
4
5
6
7
8
9
10
11

{
  "experimentalServices": {
    "api": {
      "entrypoint": "backend/main.py",
      "routePrefix": "/api",
      "framework": "fastapi",
      "memory": 1024,
      "maxDuration": 60
    }
  }
}

This is suitable for AI APIs, image processing, data transformation, or other resource-intensive services.

Which Projects Benefit Most?

Vercel Services is ideal for:

Monorepo Projects

For example:

1
2
3
4
5

apps/web
apps/admin
packages/ui
packages/db
backend/api

If you are already using pnpm workspaces, Turborepo, Nx, or similar mono-repo setups, Services will fit perfectly.

Split Frontend-Backend Projects

For projects where the frontend uses Next.js and the backend uses FastAPI:

1
2

frontend/
backend/

Deploying this structure on Vercel was previously cumbersome, but can now be housed in a single Project via Services.

Multi-Service Architectures

For projects that require more than a single API endpoint:

1
2
3
4

services/auth
services/payment
services/webhook
services/image

Each can be mounted under a distinct path:

1
2
3
4

/auth
/payment
/webhook
/image

Static Site + Backend API Combinations

For example:

1
2

apps/site      -> Static site built with Astro / Vite / Hexo
backend/api    -> Python / Node.js API

This combination is highly attractive for personal projects, utility tools, lightweight SaaS, or documentation portals with interactive APIs.

What Does It Mean for Hexo Users?

Hexo is a static blog generator that is already very easy to deploy on platforms like Vercel, Cloudflare Pages, or GitHub Pages.

For a standard, purely static blog, Vercel Services is not necessary.

However, if your Hexo blog starts incorporating dynamic capabilities, such as:

• A custom comment system API
• A link exchange request backend
• Newsletter subscription interfaces
• AI-powered article summary APIs
• Image processing endpoints
• A private admin panel
• Standalone tools or widgets

In these cases, Services becomes highly valuable.

You can organize your project as:

1
2
3

blog/        -> Hexo static blog
admin/       -> Vite admin dashboard
api/         -> FastAPI / Express backend

And deploy them unified in one Vercel Project:

1
2
3

/            -> Hexo blog
/admin       -> Admin dashboard
/api         -> Backend API

For personal site owners, this unified deployment structure is much more organized and easier to maintain than managing multiple projects.

It is Not Docker Compose

1
2
3
4
5

web
api
postgres
redis
worker

Caveats and Limitations

Summary

The true value of Vercel Services is that it transitions Vercel from "one project, one framework" to "one project, multiple frameworks and services".

For modern web projects, this is a highly practical evolution.

Previously, we had to switch back and forth between multiple Vercel Projects, domains, and Preview URLs. Now, the frontend, backend, admin panel, documentation, and tools can all be deployed collectively as services in a single project.

It is particularly suited for:

• Monorepos
• Split frontend-backend applications
• Python + JavaScript hybrid stacks
• Multi-framework applications
• Personal utility sites
• Small SaaS products
• Static site + API combinations

If you have been looking to clean up the deployment structure of a complex project, Vercel Services is definitely worth checking out.

In simple terms, Open Lovable has an almost "zero-barrier" usage: you just need to drop in the link of the website you want to "clone", and it will generate a highly accurate React version of the code for you within seconds. Whether it's the page layout, styling, or interaction details, it attempts to stick as close to the original site as possible, making secondary development a breeze.

Core Features at a Glance

The reason Open Lovable has become so popular so quickly is due to its solid functional design that directly addresses developer pain points:

1. One-Click "Clone", What You See Is What You Get

It can one-click "clone" any website into a modernized React application. Whether it's a simple landing page or a structurally complex page, it holds up under pressure and quickly generates the corresponding component code. It also supports local debugging and deployment, providing a preview simultaneously with the generation, truly achieving "What You See Is What You Get".

2. More Stable Underlying Scraping: Based on Firecrawl

There are quite a few similar code generation tools on the market, but they often "crash and burn" when reading complex web page structures. Open Lovable is backed by their own powerful Firecrawl web scraping technology, which accurately extracts the original site's page structure, DOM tree, and cleaned content. This results in the final code generated by the LLM having a much higher degree of accuracy and more consistent visual representation.

3. Switch Models at Will, No Hassle

Don't want to be locked into a single large model? No problem. The project comes with built-in support for multiple mainstream LLMs. You can seamlessly integrate OpenAI, Anthropic, Gemini, Grok, and other models based on your API quotas or preferences, switching on demand to suit your budget.

4. Integrated E2B Sandbox, Safer Execution

Afraid of the risks of running generated code directly? Environment configuration too troublesome? Open Lovable thoughtfully integrates the E2B sandbox environment. Code execution and testing can be done within an isolated sandbox, which not only prevents leaks securely but also makes the entire testing process much more worry-free.

Getting Started

Because it uses the completely free MIT License, this tool is completely open-source and free. You simply need to:

1. Pull the project locally.
2. Configure the related API keys (such as the API for the large model you want to use, and the corresponding keys for Firecrawl, etc.).
3. Just run it!

1
2
3
4
5

git clone https://github.com/mendableai/open-lovable.git
cd open-lovable
npm install
# Configure the .env file and fill in the corresponding API Keys
npm run dev

If you frequently need to reference excellent designs from other websites, or need to quickly build high-fidelity product prototypes, Open Lovable is absolutely worth adding to your productivity toolbox! Go pull the code and experience it for yourself right now!