When specifiying `customDomain` shouldn't `hosted...
# help
j
When specifiying
customDomain
shouldn't
hostedZone
be set by default to the last 2 parts of the
domain
? Unless I set it explicitely to
<http://foo.com|foo.com>
it throws:
Copy code
[Error at /dev-talsec-talsec/Web] Found zones: [] for dns:<http://portal.dev.foo.com|portal.dev.foo.com>, privateZone:undefined, vpcId:undefined, but wanted exactly 1 zone
Found errors

It seems you are configuring custom domains for you URL. And SST is not able to find the hosted zone "<http://portal.dev.foo.com|portal.dev.foo.com>" in your AWS Route 53 account. Please double check and make sure the zone exists, or pass in a different zone.
t
Not necessarily, if you have seperate for dev / staging etc you might have this configured differently
So for example, if your custom domain is set to
<http://dev.example.com|dev.example.com>
, SST will look for a hosted zone called
<http://example.com|example.com>
. If you have it set under a different hosted zone, you’ll need to set that explicitly.
So, the way I understand it is, that if hosted zone is
<http://exmaple.com|exmaple.com>
I don't have to set it explicitely...
In other words:
Copy code
customDomain: "<http://dev.api.example.com|dev.api.example.com>"
is equivalent to
Copy code
customDomain: {
  domainName: "<http://dev.api.example.com|dev.api.example.com>",
  hostedZone: "<http://example.com|example.com>",
},
t
I think the reason that's not the default behavior is usually people have a zone per environment domain
I think maybe it should behave like this
customDomain: <http://dev.api.example.com|dev.api.example.com>
->
<http://api.example.com|api.example.com>
j
Ok, but the error indicates it looks for zone that equals to domain, therefore the example/guide is not correct, right?
I noticed in case of api gateway: https://docs.serverless-stack.com/constructs/Api#configuring-custom-domains it's documented bit more clearly:
Note that, normally SST will look for a hosted zone by stripping out the first part of the
domainName
Or perhaps the error is just a bit misleading as it tries to look for
<http://example.dev|example.dev>
then it falls back to exact match and then it throws...
Guess I just got confused by the different behavior here...