Out of interest @Knack Staff - why isn’t this possible? Is it so the Knack branding stays top of people’s minds when visiting apps? It would make my life so much easier if I could simply direct people to our website and access the app rather than having to embed it in our site which has issues with theme / plugin clashing etc.
Hi there! Thanks for posting and for reaching out to get some answers around custom domains.
In short - there are some technical limitations that have made supporting custom domains non-viable at this time. We’re balancing trade offs when it comes to the decisions we make for providing the best user experience for our builders and their live app users, while always considering security and engineering best practices.
I’d like to address some of the issues that have been brought up about embedded apps, which would be our recommendation in the absence of a custom domain offering.
We are releasing an update very soon that will allow builder to choose their embedded apps’ login method. See more on how that will work here.
We love to spread brand awareness for Knack, but that’s not our angle here. Wherever we can provide white-labeling, we will, but sometimes our hands are tied (as is in the case of the cookies login option for embedded apps). I’d encourage a quick read of this post by Google to understand the stance taken by them and other browsers recently on building a more private web.
SSO should work for embedded apps in most cases. @Vincent94744 - have you reached out to support on this? We are limited in the resources we can provide to troubleshoot SSO and embedded apps due to the unknowns of your third party software, but we’ll try and point you in the right direction!
While there are some known issues with the design, this article section in our knowledge base should help you identify the best CMS to host your embedded your apps on (see further down on that article for troubleshooting tips and links to our dev docs as well). We’re also working on some live app updates in an effort to continue to modernize our live apps, which could potentially make them more compatible with some of those host platforms.
We’ll do our best to support you in providing the best live app experience for your users. I hope this information helps more broadly, but do reach out to support@knack.com if you have any questions or issues specific to your app.
Dear Knack team. This is really an issue. There are many many places in Knack where embedding in a website is NOT a solution to whitelabelling.
For example: The links to the PAGE URL or PARENT PAGE URL in the Email Rules of a page direct to the knack.com link.
I, therefore echo the calls above. Please revisit this issue and add real custom domains that we can use.
In the meantime, I will not upgrade to get whitelabelling because the solution is not good enough.
Hi Steve - thank you for expanding here, and I’m sorry to hear you’re still running into problems. We realize that custom domains are desirable for many customers, and of course are always open to revisiting issues!
With that being said, as I mentioned before, custom domains are still non-viable at this time due to technical limitations.
We’re very much invested in learning all of the reasons/examples why embedding on a website is not an acceptable solution to white labeling, so we can work towards solving each of those issues separately. It would be super helpful to get more information and feedback from all of you to break those issues down and identify the root problems (rather than solutions) for consideration.
Design Issues
Since I last came into this conversation, we have began work on solving some known design issues for embedded apps. We plan to allow builders to choose whether they want to include headers and font styles when embedding apps. Excited to get this one in your hands!
URL whitelabeling
The problem I'm hearing here is that you need to keep your end users on your embedded app, and away from the Knack URL. This may be for whitelabeling, or just to keep them within the full context of your external site. Could you expand a bit on why this is essential?
A possible solution here (depending on the root issue) would be to hard code the email paths that you are trying to direct your live app users to. See how appending the {Record ID} input on my email rule allows me to control the URL path:
I’m all ears if there are other problems/concerns/etc that have not been addressed, so we can break those down and make sure we’re solving issues individually. What I want to avoid here is getting too focused a single solution that we unfortunately cannot offer at this time. Thanks for the discourse, everyone!
Why would custom domains be a problem? Or, allow us to export the app and host it via our own server or cloud based server. Very odd, as you definitely do not seem open to “revisiting the issue”. You seem quite defensive, and offer substandard solutions. This is not cool.
I agree we need custom domains. Embedding is full of layout issues that negatively impact the user experience. It is already hard to make an app that looks good on a wide computer monitor and a mobile device. Embedding the app further compounds this issue.
Just wanted to jump in here and say that getting custom domains broadly available is absolutely something we want to accomplish. I can’t offer timelines on it right now, but it’s on everyone’s radar as something we can add that would make your use of Knack better, so we want to get it to you as soon as we’re able.
If you’ve got an extremely urgent use case, always feel free to shoot over an email to support@knack.com to discuss it.
Just dropping a message in here about custom domains.
From my side while a 3rd party can quite easily reverse engineer any system with enough time and patience, and then rebuild it, the ability to hide the platform used to build it is something that adds an extra timeline. As a business owner I also wouldn’t want them to write to Knack and say “hey I saw a great system can I have a copy of it!” or can you tell me how to do XYZ.
Commerically it is a much easier sell to approach a company for selling eventual apps when the apps has been walled behind a domain name. It also makes the eventual purchaser feel as though they are getting something bespoke rather than something that might consider buying themsevles. For example if I sell a Knack system to a customer for $300 month and that customer sees that the sytem is built on something that is $39 a month they might try to build it themselves or feel that the product they are getting anyone can build, even if that is not the case in practice. This goes away if the system is protected.
Last, if the knack app system is going to be properly whitelabelled I would like to recommend that connected libraries and other attributes viewed using view-source be dynamically renamed to make that even harder. While this might commercially limit the brand awareness of your product, it would give Developers an extra piece of mind and make it better to commerically sell apps in the wider marketplace.
I really like the system, but I can already see that if my system gets traction I will need to move it to another platform simply for the application base to remain shuttered from those people that just want to rip you off.
Has there been ANY movement on this? I’m unfortunately looking into alternatives at this point which offer custom domains, it doesn’t seem like a huge issue for them. I’m tired of trying to embed my app and dealing with issues and annoyances, styling problems, and most importantly wasting my time trying to figure something out that shouldn’t be a problem in the first. It’s a self inflicted limitation Knack has placed on it’s users. It’s 2024… this shouldn’t be a problem…
I had seen it mentioned in a roadmap for 2025 that we can expect custom domains. As there is an issue concernining cross domain single logins with things like Google that cannot be fixed unless the same domain is requesting the cookie, and even if the current workaround fixes it, is does not fix it in the most secure way. Therefore I think it’s just a question of time before this goes live.