Custom Domains in Cloud - Development Update

[#1]

Update Jun 17, 2024

Please see our latest announcement on Custom Domains general availability for Jira and Confluence

Update May 15, 2023

Please see our latest update regarding the security consideration and the URL redirect feature.

Update Apr 4, 2023

To reiterate an earlier comment, thank you all for your engagement and feedback.  We know how important it is for you to have a clear and detailed understanding of the technical reasons behind the constraints and how they enhance your security experience with custom domains. We will come back with a separate update addressing this soon, and will provide more details on the optional URL redirect feature.

Hi everyone,

My name is Luke Liu and I am the Product Manager responsible for bringing support for custom domains to Atlassian cloud products.

To summarize, custom domains is the ability for an organization to select and implement their own, branded URL for an Atlassian product. Many of you have shown interest in this feature and we are very excited to share the initial designs and visually show-and-tell where we are in the journey!

Our progress:

Here is a sneak peek of how an Atlassian org admin would set up custom domains. Below you’ll see three preliminary designs that outline:

1. Where this feature is located within admin.atlassian.com

2. The four-step process to set up a custom domain

3. Details on what that process looks like when you are specifying your custom domains URL

Screen 1. This capability is located within admin.atlassian.com, where you configure your Product URLs.

Screen 2. The is the four-step process to create a custom domain. First, choose the product, then specify the URL, add DNS records, and activate the custom domain. Atlassian would automate the certificate management on your behalf.

Screen 3. The guided flow to specifying your custom domains URL with 3 parts: a company-branded domain name, a list of options for the 1st-level subdomain keyword, and a 2nd-level subdomain at your own choice

We are excited to share these preliminary designs, which are subject to change based on customer feedback in the next few months. Please feel free to share any feedback; we are specifically interested in your thoughts on Screen 3, where you will see the mandatory two levels of subdomain names. If there are specific keywords relevant for your use cases, please share in the comments.

For example: help, support, or portal for JSM Help Center; jira, project, work for Jira Software; confluence, wiki, knowledge for Confluence, etc. These keyword (i.e. 1st level subdomain) would be part of the custom domains URLs like, for example, internal.support.acme.com, people.knowledge.acme.org, etc.

Thanks in advance for your engagement.

Luke

https://community.atlassian.com/t5/Jira-articles/Custom-domains-for-Jira-and-Confluence/ba-p/2729259

[Dave Mathijs]

Thanks for the update @Luke Liu  ,finally some progress! CLOUD-6999 has been created on 08/Jul/2011. 😲

The interface/wizard looks intuitive and promising.

🤞🏻 Fingers crossed for a release in the near future.

[Freddie Joyce]

Hi,

Having taken part in the customer interviews, I just want to re-state my reservations about this solution design.

I see no reason why the URL is required to have three parts; it's unusual for publicly available sites to use a three part domain, and this restriction means that URLs are unnecessarily wordy/duplicative and difficult for users to remember. If we were forced to use this structure we would have to make up a third part of the domain that actually makes the purpose of the site less clear.

No other SaaS service that we use enforces this structure - everything else allows us to use a subdomain like mycustomdomain.mycompany.com.

We'll be pretty disappointed if, after so many years, this is the best Atlassian can deliver.

Cheers,
Freddie

[Simone Piunno]

Dear @Luke Liu ,

Thanks for this step ahead!

Having to choose the 1st level subdomain from a pre-defined list of options is a little akward but in my case this is not a big issue so I think you can go ahead with this proposal.

Looking forward to more updates on this topic.

Simone

[patrickheinzelmann]

Hi @Luke Liu

I agree with @Freddie Joyce

What is the benefit of the subdomain keyword? What does this subdomain keyword achieve which you can't do if you enter the full custom domain? What is the reason behind this design? Technical limitations?

The usage of domains with more than one subdomain level is quite uncommon in the internet world, because nobody can remember them. Domains with multiple subdomain levels are mostly used for internal/intranet solutions.

As most of us want the custom domains for the customer-facing solutions, the design doesn't fulfill the requirements.

Patrick

[kajtzu]

First - glad to see some progress 👌

Second - I’m guessing 99.99999999% of everyone wanting this feature want “BLAH.SOMECOMPANY.TLD”

They really, really, really, really, really do not want BLAH.SAFEWORD.SOMECOMPANY.TLD that you propose in the screenshots.

Please don’t ruin it for us.

pls fix kthx 

[Alex Cumberland]

@kajtzu is exactly right.   Under server we have tied our domain for our customers using same as our company website.

So ours works out to  jira.companydomain.com.

It is easy for our customers to remember and is not overly complicated like the proposal being suggested.

[David at David Simpson Apps]

Hi @Luke Liu 

First thank you for an update on CLOUD-6999.

Let's just start by reviewing what the scope of the issue is.

People want to be able to have a custom URL of https://mysubdomain.mycompany.com/ where mysubdomain is a custom subdomain that could be anything and mycompany.com is my company's domain name.

That is the sole requirement to this issue which is almost 12 years old, have over 1400 comments, 7700+ likes and 2500+ votes.

So I'm really glad that you've spared the time to share your initial designs to the problem stated above.

Let's just repeat what the requirements are here to be absolutely clear:

People want to be able to have a custom URL of https://mysubdomain.mycompany.com/ where mysubdomain is a custom subdomain that could be anything and mycompany.com is my company's domain name.

So how does the initial design solve the problem? It does not. It completely misses the point.

Nobody asked for example.keyword.domain. No one. No one. 

If you want to allow multiple levels of subdomain, just support all levels of subdomain, e.g.

• a.mycompany.com
• a.b.mycompany.com
• a.b.c.mycompany.com
• a.b.c.d.mycompany.com
• ...
• a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z.mycompany.com

and so on. Add the CNAME record and let's go.

David

[Dwight Holman]

Good to see some action on this old request.

Regarding the mandatory two-levels of subdomain.

Please feel free to share any feedback; we are specifically interested in your thoughts on Screen 3, where you will see the mandatory two levels of subdomain names.

This seems unnecessary to me. I think a single field to enter the subdomain name is sufficient. DNS type A records just contain a text string - right?

Admins can then choose something logical for their situation. For us the following patterns would make sense:

• wiki.acme.com (Confluence)
• support.acme.com (JSM)
• jira.acme.com (JSW)

Admins that need a 'multi-level' domain URL, can enter a two-part subdomain:

• "internal.kb" to get "internal.kb.acme.com"
• "internal.support" to get "internal.support.acme.com"

Your post does not explain why a second level needs to be enforced (mandatory). What is the business case or need for this? I'm guessing this might be related to the way SSL certificates are managed.

I assume you are only allowing ONE custom domain for each cloud app instance (e.g. Confluence). So you could not have a single Confluence instance with different URLs for external users and staff.

Dwight

[Zach Erbaugh]

@Luke LiuThanks for the update - glad to see progress!

I'd echo the feedback from @Freddie Joyce and others here - forcing two levels of subdomain (with one of those being selected from a predefined list) doesn't make sense to me, and is inconsistent with pretty much every other cloud service I've used.

For us specifically, forcing two subdomain levels won't work for our use case - we'll have to move to a different product instead of moving from Confluence Server -> Confluence Cloud.

Zach

[Martin Runge]

Thank you Luke for the details on that. I know a lot I customers that are waiting for this feature.

[Jeremy Tang (Trimmy Choo)]

Hey @Luke Liu and the team behind the scene!

Kudos to y'all. Really appreciate the effort of this feature, which has been a long time coming. I can also appreciate the sentiment from the majority of the comments.

Can I clarify the differences between a single-level custom domain (help.company.com) and a two-level one (help.support.company.com)? For example, does it have a different effect on SEO?

As a customer, it would be helpful to understand if this decision will have any negative impact on us apart from the reality of living with a much longer URL. 

[Ivan Lobotka]

Hi @Luke Liu 

I fully agree with @Freddie Joyce third level of the domain is enough.

There is no reason to have a "subdomain keyword" ... which is by the way not familiar with DNS standards and domain name hierarchy (the subdomain keyword is not representing the level of hierarchy).

The "only" selectable subdomain keyword (from a predefined list) is hard to understand...

And not to be "negative" I really appreciate the possibility to create a separate third-level domain name for each product. 

The question just popped up Can I have one common third-level domain name for all products?

kind regards

Ivan

[Andy van der Gugten]

Finally some progress well done! I have a request for a keyword. Please add NULL as one😁.

[Karen Utzeri]

Great feature! When is the release scheduled for?

[Aniceto Goñi Díaz de Cerio]

Hi,

If we're limited to a series of predefined 'subdomain keywords' that is by no means a 'custom domain'.

Our clients and audience are native spanish speakers, and so by no means we want our subdomain keyword to be help, support, or whatsoever english word. We could be fine with soporte.compania.es, but not support.compania.es.

Besides, forcing the domain to be 3 dots is crazy!! it.support.compania.es... Really, George?? Again, what about any other languaje speakers, where the word order is different? soporte.informatico.compania.es could be fine, but by no means informatico.support.compania.es.

The way it is exposed right now this feature does not fill our requirements.

[Victor van den Bosch]

Which hallucinating marketing executive thought this up?

Forcing an extra subdomains is ridiculous and not at all what people are waiting/hoping for, not at all what many other companies with similar "bring-your-own-domain" schemes require. I cannot fathom the reason why this extra complexity was invented.

Atlassian is really discrediting itself with this fiasco so far, why make it worse?

Are there practical or security implications that forced you to adopt this design? As a product manager and security officer this just looks like corporate hubris of the highest degree.

Can someone please elaborate? Maybe there are convincing arguments on why this was done.

[Olivier Voortman]

Luke, please don't make us sad with that keyword whim.
There is already enough suffering in the world.

[Craig]

To echo what many others have said.. the additional keyword is unnecessary, let us set our own domain, be it one, two or x sub-domain levels deep, we will create the CNAME that suits our business and away we go. Don't force us to have something we don't want and no-one asked for. Do better!

[Sylvain Gibier]

Hi @Luke Liu ,

I will not re-iterate what has been raised already with this keyword, as you are not fulfilling the actual requirement for custom domain. 

For me - when do we finally get it ? GA Release date ? 2024 ? 2035 ?

Personally - i see no progress nor commitment from Atlassian to deliver that anytime soon

[Sandra Axelsdottir]

Please please listen to everyones feedback above. We all agree and nobody wants the additional keyword. Like Dwight puts it, this is all we want:

• wiki.acme.com (Confluence)
• support.acme.com (JSM)
• jira.acme.com (JSW)

[Pamela Castro Liz]

Hi @Luke Liu 

I have to echo what everyone is saying, especially @Freddie Joyce and @Dwight Holman

Having an obligatory keyword just makes the URL unnecessarily tedious for end users to remember. It would be great if this could be reconsidered.

[Will]

I only want these 5 things.... Please!!!!!!

• No 2nd level subdomain requirement
• No 2nd level subdomain requirement
• No 2nd level subdomain requirement
• No 2nd level subdomain requirement
• No 2nd level subdomain requirement

[Chadd Blanchard]

Who at Atlassian thought this is what people wanted? It's more complicated for end-users to remember two subdomains. This isn't what your users wanted. 

As @Dwight Holman said, this is all we want: 

• wiki.acme.com (Confluence)
• support.acme.com (JSM)
• jira.acme.com (JSW)

[Adrian Smith]

Thank you for providing an update. We are grateful for the progress.

In regards to feedback on Screen 3, we see no valid reason to have 2 levels of domain names. 1 is what is expected.

ourchoice.ourdomain.com is what we expect and need.

[Scion]

This this doesn't enable it all the ability to use a custom http root path. Such as:

acme.net/jira