Anatomy of a 30-Second Site Provision

Creating a website on CodeDevlify looks like one button. Behind it are two services, a queue, a container runtime, a certificate authority, and a DNS propagation window that nobody controls. This post walks the whole path — and shows where we moved work off the request so the button could stay honest about being fast.

The shape of the system#

There are three moving parts. The backend is a NestJS modular monolith that owns customer data and billing. The agent is a small Go binary running on every hosting node, exposing gRPC to the backend and nothing at all to the internet. The client is a Next.js portal that never talks to the backend directly — every browser request goes through a same-origin proxy route.

That last constraint is the one that shapes everything else: the agent is the only component allowed to touch a hosting node's disk, so provisioning is a conversation, not a script.

Step one: the request that returns immediately#

The controller does almost nothing. It validates the DTO, hands off to a use-case, and the use-case writes one row and enqueues one job. Total time in the request: single-digit milliseconds plus one insert.

1@Injectable()2export class CreateWebsiteUseCase {3  constructor(4    @Inject('IWebsiteRepository')5    private readonly websites: IWebsiteRepository,6    @InjectQueue('website-provisioning')7    private readonly queue: Queue,8    private readonly events: EventEmitter2,9  ) {}10 11  async execute(input: CreateWebsiteInput): Promise<Website> {12    const website = Website.create({ ...input, status: 'provisioning' });13    await this.websites.save(website);14 15    // Everything below this line is slow, so none of it happens here.16    await this.queue.add('provision', { websiteId: website.id }, {17      attempts: 3,18      backoff: { type: 'exponential', delay: 5_000 },19    });20 21    this.events.emit('website.created', new WebsiteCreatedEvent(website));22 23    return website;24  }25}

Step two: the gRPC call to the node#

The queue consumer picks a hosting node, opens a gRPC channel, and asks the agent to create the site. The contract is a single proto file kept in both repositories — one of the few places where the two codebases are genuinely coupled.

service WebsiteService {  rpc CreateWebsite (CreateWebsiteRequest) returns (CreateWebsiteResponse);  rpc SuspendWebsite (SuspendWebsiteRequest) returns (StatusResponse);  rpc DeleteWebsite (DeleteWebsiteRequest) returns (StatusResponse);}

On the Go side the handler is deliberately boring. It creates the document root, writes a vhost, starts the container, and reports back. No retries, no cleverness — the backend owns retry policy, because the backend is the one that knows how many times it has already asked.

1func (u *WebsiteUseCase) Create(ctx context.Context, req *pb.CreateWebsiteRequest) (*pb.CreateWebsiteResponse, error) {2	root := filepath.Join(u.baseDir, req.GetSiteId())3 4	if err := u.fs.EnsureDir(root, 0o755); err != nil {5		return nil, status.Errorf(codes.Internal, "create root: %v", err)6	}7 8	// Idempotent on purpose: the backend may retry this exact call after a9	// timeout, and a half-created site must converge, not duplicate.10	if err := u.containers.EnsureRunning(ctx, req.GetSiteId(), req.GetRuntime()); err != nil {11		return nil, status.Errorf(codes.Internal, "start container: %v", err)12	}13 14	return &pb.CreateWebsiteResponse{DocumentRoot: root, Status: "running"}, nil15}

Step three: the parts you cannot speed up#

Two things in this flow are outside our control, and pretending otherwise is how you end up with a progress bar that lies.

The third row is the honest one. We can't shrink a TTL somebody else set, so the dashboard shows pending DNS with the exact record to add, and a checker that re-runs every thirty seconds until it resolves.

A fast product is not one where everything is fast. It's one where nothing you're waiting on is a mystery.

— Internal design review, March 2026

Watching it happen#

Because every stage emits an event, the whole provision is observable from a single log stream while you're debugging a node:

# Follow one site through the whole pipelinedocker compose logs -f backend | grep --line-buffered "site_id=ws_8f3a" # ...and what the node itself thought was happeningjournalctl -u codedevlify-agent -f --output cat

The two streams should interleave cleanly. When they don't — when the backend logs a retry the agent never saw — the answer is almost always a deadline that's shorter than a cold container start.

What we'd do differently#

1. Emit progress events from the agent, not just terminal ones. We added them late; they should have been in the first proto.
2. Pick the node before enqueuing. Choosing inside the consumer made scheduling harder to reason about, because a job could outlive the node it was destined for.
3. Treat certificate issuance as its own domain from day one. It grew inside site-manager and had to be pulled out later.

None of these were expensive to fix. They were expensive to notice, which is the usual shape of infrastructure debt.