Services
A Service is a single running container - a web server, a background worker, or a cron job. You give it a source (a Git repo or a Docker image), a resource budget (memory, CPU, replica count), and a set of environment variables. Fieldwick keeps it running. Each Service gets its own subdomain under apps.fieldwick.com and you can attach a custom domain any time.
Services are the unit of billing. Memory and CPU meter by the hour; egress meters by the GB. You set a monthly spend cap per Service so a runaway process cannot surprise you on the invoice.
Teams
A Team is a billing and access boundary. Every account gets a personal Team on signup. You can invite collaborators to a Team and they see every Service the Team owns. Billing rolls up to the Team - one invoice, one spend cap, one payment method.
Most solo builders never touch multi-team settings. If you work with contractors, agencies, or co-founders, Teams are how you separate their access from yours without creating separate accounts.
Deploys
A Deploy is one instance of shipping a Service. When you run fieldwick deploy, Fieldwick clones your repo, builds a container image, pushes it to the internal registry, and starts a new allocation on the worker fleet. The old allocation keeps running until the new one passes its health check, then traffic cuts over.
Every Deploy has an ID, a build log, and a status. You can roll back to any previous Deploy from the dashboard or the CLI. If a deploy is still in-flight and you need to abort, the deployments cancel command stops it and leaves the prior version in place.
Edges
An Edge is the ingress layer that puts your Service on the internet. Fieldwick runs a pair of dedicated edge nodes per region behind a load balancer. They terminate TLS, route traffic to the right container, and strip identifying headers before the response leaves. You never configure this directly - Fieldwick updates the routing table automatically whenever a new Deploy goes live.
TLS certificates are provisioned automatically via Let's Encrypt for both the default subdomain and any custom domain you attach. Custom domains verify via a CNAME record; once the record propagates, HTTPS is live without any manual step.