<p>You would need to handle both DNS, server routing and Craft routing:</p>
<h2>DNS</h2>
<p>Make sure to have a wildcard A-record for <code>*.example.com</code> so all subdomains go to your server.</p>
<h2>Server routing</h2>
<p>Configure your web server (Nginx, Apache, or whatever you're using) to route all requests to <code>*.example.com</code> to the same Craft installation.</p>
<h2>Craft routing</h2>
<p>You're gonna need to use <a href="https://craftcms.com/docs/3.x/routing.html#advanced-routing-with-url-rules" rel="nofollow noreferrer">advanced routing</a> to specify a routing rule that includes the domain. Check out the documentation on <a href="https://www.yiiframework.com/doc/guide/2.0/en/runtime-routing#rules-with-server-names" rel="nofollow noreferrer">routing rules with server names</a>.</p>
<p>Based on the example in the documentation, you could use something like this:</p>
<pre><code>return [
    '//&lt;subdomain:\w+&gt;.example.com/&lt;slug:\w+&gt;' =&gt; 'path/to/template',
];
</code></pre>
<p>Given this documentation, your template would have access to a <code>subdomain</code> and a <code>slug</code> variable which you can use to find the correct entry based on your <code>subdomainField</code> and the entries' <code>slug</code>. If it doesn't exist, make sure to <a href="https://craftcms.com/docs/3.x/dev/tags.html#exit" rel="nofollow noreferrer">exit with a 404 error</a>.</p>
<p>To make this logic simpler, I'd probably point the URL route to a <a href="https://craftcms.com/docs/3.x/extend/controllers.html" rel="nofollow noreferrer">module controller</a> instead and perform the query and validation in there. The controller can either respond with a 404 error or render the appropriate template based on the slug parameter.</p>
<hr />
<p>On a broader note: Make sure that you aren't just doing extra work to get a <a href="https://craftcms.com/docs/3.x/sites.html" rel="nofollow noreferrer">multi-site functionality which Craft already provides</a> out of the box!</p>

CC BY-SA 4.0
2022-02-15T03:36:36.143Z
Thanks for the answer, but I should have been more clear. We use Craft headless, so my concern is more in the area of the $entry->url field and the URLs that are returned by the GraphQL API. Also with the URLs that are generated to be embedded in rich text field for interlinking. And with the internal entry logic that ensures that duplicate URLs are not allowed.
Josh Coady
CC BY-SA 4.0
2022-02-15T03:50:03.237Z
We currently use https://craftcms.com/docs/3.x/entries.html#entry-uri-formats but that does not seem to allow for dynamic host names?
Josh Coady
CC BY-SA 4.0
2022-02-15T09:15:30.280Z
@JoshuaCoady Yes, the URI can only include the path as far as I know, not the domain and/or site prefixes. If you have a multi-site with one defined site for each possible subdomain, you can just specify the site in the `siteUrl` function and it will append the subdomain. Otherwise, maybe just use the entries' `uri` instead of `getUrl()` and construct the correct domain based on the field? Or move the domain mapping logic entirely to the frontend?
MoritzLost
CC BY-SA 4.0
2022-02-14T11:16:49.210Z
2022-02-14T11:16:49.210Z
MoritzLost
<p>Is it possible to have a dynamic site base URL coming from an entry's field data?</p>
<p>I want to do something like https://{entry-&gt;subdomainField}.example.com/{entry-&gt;slug} with entries coming from the same site.</p>

<entries><siteurl>
Possible to have a dynamic site base URL from entry field data?
# Possible to have a dynamic site base URL from entry field data?

(Asked by: username_0 on 2022-02-14)

Is it possible to have a dynamic site base URL coming from an entry's field data?

I want to do something like https://{entry->subdomainField}.example.com/{entry->slug} with entries coming from the same site.

**Tags:** entries, siteurl

---

## 1 answers

### Answer by username_1 on 2022-02-14. Score: 1

You would need to handle both DNS, server routing and Craft routing:
DNS
Make sure to have a wildcard A-record for *.example.com so all subdomains go to your server.
Server routing
Configure your web server (Nginx, Apache, or whatever you're using) to route all requests to *.example.com to the same Craft installation.
Craft routing
You're gonna need to use advanced routing to specify a routing rule that includes the domain. Check out the documentation on routing rules with server names.
Based on the example in the documentation, you could use something like this:
return [
    '//.example.com/' => 'path/to/template',
];

Given this documentation, your template would have access to a subdomain and a slug variable which you can use to find the correct entry based on your subdomainField and the entries' slug. If it doesn't exist, make sure to exit with a 404 error.
To make this logic simpler, I'd probably point the URL route to a module controller instead and perform the query and validation in there. The controller can either respond with a 404 error or render the appropriate template based on the slug parameter.

On a broader note: Make sure that you aren't just doing extra work to get a multi-site functionality which Craft already provides out of the box!

> **Comments:**
> **username_0**: Thanks for the answer, but I should have been more clear. We use Craft headless, so my concern is more in the area of the $entry->url field and the URLs that are returned by the GraphQL API. Also with the URLs that are generated to be embedded in rich text field for interlinking. And with the internal entry logic that ensures that duplicate URLs are not allowed.  
> **username_0**: We currently use https://craftcms.com/docs/3.x/entries.html#entry-uri-formats but that does not seem to allow for dynamic host names?  
> **username_1**: @JoshuaCoady Yes, the URI can only include the path as far as I know, not the domain and/or site prefixes. If you have a multi-site with one defined site for each possible subdomain, you can just specify the site in the `siteUrl` function and it will append the subdomain. Otherwise, maybe just use the entries' `uri` instead of `getUrl()` and construct the correct domain based on the field? Or move the domain mapping logic entirely to the frontend?  

---

