support@build.io
6. Networking
Build handles the networking infrastructure your application needs to serve traffic reliably—domain management, TLS certificates, request routing, and load balancing. This section covers how traffic gets to your app and how to configure the networking layer to suit your needs.
6.1 Custom domains
Every app on Build.io gets a default URL on the build.io domain (e.g. my-app.onbld.com). For production applications, you'll want to use your own domain.
Adding a Custom Domain
From the dashboard, navigate to your app's Settings tab and find the Domains section. Add your domain and Build will provide you with the DNS target to point your domain at.
Advanced domain configuration can be done from the Host details page, accessible from the Overview tab of an App, in the Hosts section:
Clicking on the domain name will take you to a page where you can check the domain status, alter the DNS settings or setup wildcard domains, and manage ACM or manual SSL certificates.
6.2 SSL/TLS certificates
All traffic to Build.io apps is encrypted with TLS. Build provides automated certificate management so you don't have to deal with certificate procurement, renewal, or installation.
Automated Certificate Management (ACM)
When you add a custom domain, Build's ACM system automatically provisions a TLS certificate for it. Certificates are issued once your DNS records are correctly pointed at Build and domain ownership can be verified. Renewal is handled automatically—certificates are refreshed before they expire, with no action required on your part.
ACM status is visible in the Overview tab of your App's main page, under the Hosts section. If a certificate fails to provision (usually because DNS isn't configured yet), the status will indicate the issue.
6.3 Routing and load balancing
Build's routing layer sits between the internet and your dynos. It accepts incoming requests, terminates TLS (unless passthrough is enabled), and distributes traffic across your running dynos.
Request Timeouts
Each request has a configurable timeout (set in your app's Policies section on the Settings page). If your app doesn't send the first byte of its response within the timeout window, the router terminates the request and returns a 503 error to the client.
For most web applications, the default timeout is sufficient. If you handle long-running requests (large file uploads, complex report generation), consider increasing the timeout—but keep in mind that long-running requests tie up a dyno for the duration.
For truly long-running work, the better pattern is to accept the request quickly, enqueue the work to a background job, and let the client poll for results or receive a webhook when the job completes.
