2found
ENVI
All tools
2server / Infrastructure & deployment

Ship the app.
Own the server.

Take your app from your project to a live domain. Let your coding agent help with setup, then use 2server for releases, HTTPS and traffic rollback on infrastructure you own.

Deploy with your agentRead the docs
Your VM. Your cloud account. Your app.
App → release2srv
2srv deploy -f deploy.yaml --apply
  1. 01
    Resolve

    Pin the image digest.

  2. 02
    Prepare

    Start the next generation.

  3. 03
    Verify

    Wait for app readiness.

  4. 04
    Release

    Switch traffic. Verify HTTPS.

A readiness-gated release on infrastructure you own.

Works withExisting VMsGCP / AWSDockerCaddyCloudflare
01 / More time for your product

Get it live.
Keep it yours.

From the first launch to the next release.
A repeatable way to run your app.

An architectural still life of graphite server modules with a single red connecting rail.
01

Put your app in front of customers

Release your container app with a working domain and HTTPS. 2server connects the rollout, routing and Cloudflare setup in one workflow.

02

Make the next release easier

Reuse your app configuration for each release. Readiness checks gate traffic, and you can roll traffic back to the previous generation.

03

Keep your infrastructure yours

Use your own VM and cloud account. Add PostgreSQL, Redis or monitoring as your app grows, with configuration in your repo and secrets on your server.

02 / Start with your agent

One prompt to get started.

Open your project in your coding agent.
Copy this prompt. Let it guide the setup.

Prompt for your agent
Help me deploy this project's app with 2server. Read https://2found.dev/docs/2server.md and explore https://github.com/2found/2server as needed.
Inspect the project, prepare its container image and deployment config, and guide me through any missing setup.
First help me choose: use my existing VM, or provision one with Terraform in my Google Cloud or AWS account. If I have neither, guide me through account setup, billing and login. Explain the proposed resources and costs before creating them.
Then help me connect my domain to Cloudflare and create a scoped API Token with the required permissions. Have me save credentials in a private local file; never ask me to paste secrets into chat.
Validate and plan the deployment, explain what will change, then deploy within the scope I authorize. Verify app readiness and public HTTPS. Report the live URL or the exact remaining blocker without exposing credentials.
01

Choose a server.

Use what you already have.

Have a VM? Give your agent the SSH host, username and local key path. Have Google Cloud or AWS? It can prepare Terraform to create a VM in your account. Starting from neither? It will guide account setup, billing and login before provisioning.

You choose the account and review the resources and costs. Your provider bills the cloud resources.

Choose your VM path
02

Connect your domain.

Let your agent guide Cloudflare setup.

Add your domain to Cloudflare, activate its nameservers and create a scoped API Token. The guide lists the five permissions for a public app, so you can create the right token on the first try.

Save the token in a private local file and share only its path with the agent.

Create your Cloudflare token
Read the full deployment guide · Markdown for agents (.md)
03 / Built for your next launch

A good fit for
builders who want control.

Launch a container app on a VM you already have, or provision one on Google Cloud or AWS.

Let your coding agent prepare the deployment while you choose accounts and spending.

Run your app and supporting services together on infrastructure you control.

Keep release configuration in your repo so your team can review and reuse it.

04 / Before you deploy

A few practical
questions.

No. Use an existing Debian 12/13 or Ubuntu 22.04/24.04 VM, or provision one on GCP or AWS. 2server connects over SSH. Your cloud account and infrastructure stay yours.

Desired App, Domain and Zone files live in your repository. Secrets, applied state and release history live on the VM. Connected commands use VM secrets, with no local .env fallback.

HTTP apps must pass readiness checks before traffic moves. Traffic rollback can restore the prior release. A domain error after rollout can leave a healthy app with unfinished DNS; inspect the reported state before retrying.

Yes. Named templates include PostgreSQL, Redis, NATS, monitoring and imgproxy. Each instance has its own name, secrets and data. PostgreSQL backup is opt-in; stateful apps update in place.

One VM is one failure domain. Blue/green releases and replicas do not provide host-level high availability, and traffic rollback does not reverse database migrations. Keep capacity for both app generations during a release.
A 2found product.

Your next release
starts with one prompt.

Copy the agent prompt