Create a web service

A web service is any process that listens on a port and speaks HTTP. Appentic builds your code into a container image, runs it on managed infrastructure, and gives it a public URL with automatic TLS. From your perspective as the developer, deploying an app is "connect the repo, pick a size, click deploy", and the rest is handled for you.

Requirements

Before you create a service, make sure your app is ready to run on any container platform:

• A GitHub repository connected to Appentic. See Account setup if you haven't installed the GitHub App yet.
• Your app listens on PORT. Appentic sets the PORT environment variable and routes HTTP traffic to it. Most web frameworks (Express, Fastify, Flask, Django, Gin, Actix, Rails) use $PORT out of the box.
• Your app binds to 0.0.0.0. If you bind to 127.0.0.1 the service will look like it's running but be unreachable, and the health check will fail.

If you're not sure whether your app meets these requirements, run it locally with PORT=8080 HOST=0.0.0.0 <your start command> and hit http://localhost:8080. If that works, Appentic will work too.

Creating the service

From your project dashboard, click New service, then Web service. You'll be asked for:

1. Repository. Pick the GitHub repo and branch to deploy. The branch defaults to your repository's default branch, and every push to it will trigger a new deploy.
2. Build command. Optional. Appentic autodetects most stacks (Node.js, Python, Go, Ruby, Java, Rust) and only needs you to override this if autodetect gets it wrong.
3. Start command. The command Appentic runs to boot your service. Again, autodetected for most stacks.
4. Region. us-central, eu-west, or asia-east. Pick whichever is closest to your users.
5. Machine size. Memory and CPU tier. Start small (256 MB / 0.25 vCPU is plenty for most starter apps) and resize later if you need to.

Click Deploy and Appentic will build and start your service.

What happens on every push

Once the service exists, Appentic watches the branch you chose. Every push triggers a new build:

1. Appentic clones the repo at the pushed commit.
2. It runs your build command, using cached layers wherever possible so repeat builds are fast.
3. It boots the new revision and runs a health check against $PORT.
4. If the health check passes, traffic is swapped over to the new revision. If it fails, the previous healthy revision keeps serving and the new deploy is marked failed.

This means a broken build or a crash loop can't take your service down: the last healthy version keeps serving traffic until you fix the new one.

Related

• Environment variables
• Custom domains
• Build configuration