Can the following setup be achieved with a single App Specification file (= single App)?

  • single managed PostgreSQL Cluster (PCLUSTER)

  • is the main domain and it serves a next.js application from production it branch; it connects to

  • is Laravel API from production git branch; it connects to production database in PCLUSTER

  • is staging area; it runs next.js from staging git branch and connects to

  • is Laravel API from staging git branch; it connects to staging database in PCLUSTER

I am confused about how to configure the domains top level setting and routes per-instance settings to make this setup work. Please advise.

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Submit an Answer
1 answer

@ReWild 👋

Currently all routable components in an app would need to share the same set of domains, so if you wanted your next.js app on a different domain than your API then they would have to be separate apps for now. Similarly for your staging app. This may change in the future, especially if we hear enough feedback about it.

An alternative would be to put your nextjs site on and your API service on (via the route path config), within the same app. You then also have access to bindable env variables that can be used to reference other components in your app, on the internal network or external depending on if you nextjs is deployed as a static site or service. In this model, your staging app would still be a separate app for now.

  • Thanks, this clarifies things. If we cannot route subdomains to services individually, what would domains/[Nth]/wildcard=true be used for then? Could you please give an example.

    • Great question. A use-case for wildcard domains would be if you wanted to serve the same app on all * domains, and possibly render different content or themes depending on the incoming sub-domain (i.e. white-label).

      • In this case, can I have nginx be the “entry point” for the domain and subdomains, and let it route accordingly to various services depending on the domain name?

        For example:

        server {
          location ~ \.php {
            # ...    
            fastcgi_pass http://laravel_api:9000;
        server {
          # ...
          location ~ {
            proxy_pass http://nextjs_admin:3000;
        server {
          # ...
          location ~ {
            proxy_pass http://nextjs_public:3000;

        Is this a viable setup with the App Platform?

        • Yep that’s a perfectly viable and appropriate setup for the App Platform. Note that you’ll want to reference components on the internal network using port 80 though, so in your example you’d use http://laravel_api instead of http://laravel_api:9000.

          • If http://laravel_api is available at port 80, does it mean that it is also available publicly through some public URL?

          • Currently any service component defined in your app will be available via the app domains on the route path configured for that service. We plan to introduce “internal services” in the future for the use-case where you don’t want to expose these publicly, and just want them available to your other services over the app internal network.

          • @snormoredo any indicative ETA for the internal services feature? This is a deal breaker for our setup. Many thanks!

          • @ReWild I can’t give a specific date, but internal services should be available in the near-term future; days, not months.

          • @ReWild We released support for internal services yesterday. You can make use of these with the internal_ports field on service specs as follows:

            name: sample-golang
            - name: web
                repo: digitalocean/sample-golang
                branch: master
              - 3000

            If you specify internal_ports without http_port, then the service will only be accessible via the internal network.

        • @ReWild you don’t happen to have any code you could share for this approach? I’m looking to achieve the same thing as you, where I need different components within my app to be available on different subdomains. But I’ve little nginx experience - any help would be appreciated. And @snormoredo this would be a great feature, is it on the roadmap?

  • Are there plans to add support for subdomain routing? I have the same setup where different services need to be available at different subdomains. Right now I use multiple apps but this is going to be a pain to synchronize when deploying ephemeral instances for feature branches. I’d like to move everything into the same app but not really interested in managing my own nginx config since at that point I might as well just deploy to kubernetes or something.