Publishing your Coda doc to the Gallery already lets you bring your ideas to the world in a sleek, sharable format, all while maintaining the ability to update content quickly and easily. And starting today, you can publish your Coda doc to a custom domain of your choice. That means you can now leverage the combination of Coda’s building blocks and publishing capabilities to quickly spin up marketing landing pages, share your public roadmap, publish your personal portfolio, and so much more. Available to Pro, Team, and Enterprise workspaces.
Take your pages live faster.
No need to need to play around with Squarespace, Wix, or another no-code website builder. If you know how to use Coda, you can publish to a custom domain and get your project live without any extra steps.
Stay true to your brand.
Bring your brand identity to the forefront by publishing to your own domain, rather than being listed under Coda’s.
Share your vision and get feedback.
Publishing right from Coda minimizes the layers between your work and the world. Whether your team is building in public, making your roadmap known, or somewhere in between, faster feedback loops are a game changer.
Hello @John_Li1 , I tried this feature and I can’t allow edit on custom domains. This is the message I get : Docs visited via a custom domain will be view only. “Users won’t be able to edit or comment on your doc in this case”.
I was so happy this week-end when I saw this feature that I have been waiting for soo long !!! We really need to be able to have users interacting with the doc to be able to add or delete rows. Not doc maker but just editor. Please…
The edit feature will allow us to create useful “apps” quickly and efficiently turning coda into a powerful nocode builder for lots of MVP during product development and lots of internal apps connected to other systems and allowing productive collaboration.
Sadly it wasn’t straightforward technically to do safely right now. In order to be able to use edit functionality you need to be able to login to Coda and to be secure that has to currently be on the Coda domain.
Hopefully something we can solve for in the future but it’s not a trivial amount of work and we know there are plenty of great use cases that work fine with view/play modes so wanted to get this out to them first.
Just days after fiding a third party solution for a problem that have been here from day one, you codans have such strange tempistics ahahaha
@Bruce_McLachlan at this point, in a while, i will consider this native integrations over third party solutions…(once better established with permission defined etc)
Is there any internal roadmap for integrating in published mode what we can have on normal edit mode? Like dark mode? or with this new custom domain feature, cross doc actions? Thanks!
P.s. me and @Johg_Ananda shared not a lot of time ago some worries about how to correctly implement published docs for the public, he listed them in a good way in his linked post, any idea about how those could/will be taken into consideration?
I’d love to see the ability in the future to use a custom domain but still require a login. As someone who uses Coda for internal documentation at a company, I’d love to be able to use a vanity URL just because it’s easier to read/remember/type, while not having to open up my internal information to the public.
The main motivation for me would be to use a really iconic url, like productdesign.company-name.com as an entrypoint for “Company Name” employees to see all the resources they need as a product designer. That url is easy to type and is remembered by web browsers if you type it in often. And it’s also just a nice looking link when you have that page open. However, I don’t want the general public to see all that information, some of which is likely proprietary.
Great start! Interestingly, the Public Bug Tracker example of codacustomdomains.io shows that we’re getting a bit more than plain “view only”: This example embeds its own form, allowing some input by users.
But aren’t there already network features that you could implement which would reject access to the general public in a company-only domain name? Typically this is achieved with subdomains and appropriate access from inside the company’s network.