Imagine a chain of language courses. The site has lived on Tilda for a long time and works quietly, but at the next meeting the company’s IT person suggests “exporting everything to our own server”. The arguments sound reasonable: your own hosting, no dependence on a subscription, full control. A month later it turns out that the trial-lesson forms still work only with a paid plan, the group schedule in Feeds is edited in the old account, and direct links to news from the newsletter open emptiness.
In this story the move is like buying your own house where the water taps are somehow shut off from the old apartment. The walls are yours now, but you still cannot live without the old address. Code export exists on Tilda, and it is useful for its own tasks. Only the independence people expect from it is usually greater than the independence it gives. Below I will go through what moves with the files and what stays in the account, with links to Tilda’s help.
What code export is and who can use it
Export is a download of the published project as an archive: pages, styles, scripts and images that can be placed on your own server. According to Tilda’s help on export, the option is available only on the Business plan line, from five sites and up. On the plan for one site it is not there, so a conversation about export often starts with the question of changing the plan.
The process is described shortly in the help. In the project settings, on the “Export” tab, a zip archive is downloaded, the files are copied to the server, and a service file is renamed to .htaccess. There is a technical detail here: this file works only with the Apache web server. If your server runs Nginx, the rules for it will have to be written by hand.
Export downloads a snapshot of the pages at the moment of export. To change text or add a new page, you still open the Tilda editor and export the project again. This is more a way of publishing than a move to another platform.
What leaves with the files and what stays in the account
The help lists what is not exported. Tilda CRM and the Personal Account are available only in the account on Tilda. A password you set on a page or a project is not transferred, and on someone else’s server those pages will open without a password. For courses with closed materials this is a separate risk, worth thinking about before the export.
With Feeds and the Catalog the limits are greater. The control panel is not exported: posts and products can be created and changed only inside the Tilda account. On your server, news and products will open only by a click from the general list. A direct link to a separate news item or product will not work, and neither will product search.
For a site where news, articles or products bring visitors from search and newsletters, this matters. A link from an email, “Enrollment in the new group is open”, leads to a specific post, and that is exactly the scenario that breaks after export. I would check the list of such sections before deciding on a move: there are usually more of them than it seems at first glance.
What still depends on the subscription
Some functions work on a third-party server, but only with a live connection to Tilda. Sending forms through connected data-collection services requires an active subscription and the domain specified in the site settings. The same goes for fonts from the ParaType and type.today libraries: an active subscription and a specified domain are needed. If the subscription is turned off, requests from the site will stop arriving, and the fonts may switch to fallbacks.
There is a reverse side too. A certificate for HTTPS, added on Tilda’s side, will not work on your server. You will have to connect it yourself, together with the other duties of hosting: updates, backups, server availability. So after export the site has two points of dependence instead of one. The subscription is still needed for forms and fonts, and the server is now entirely on you.
Independence you can check
If you are thinking about moving a site off a builder, I start with a list of what the site does: forms, catalog, news, closed sections, payment. Then we look at what of this will survive export, what will need custom work, and where it is more honest to stay on the platform. We make the decision when that list is in hand.
Rules for using exported code
Export has rules, and Tilda’s help lists them directly. The domain where the code will be hosted must be specified in the site settings before export, and the code cannot be placed on another domain. Copying and distributing the code is forbidden. Using it to create pages outside the platform and changing the code outside Tilda are also forbidden. Removing the developer identifier with the link to Tilda is forbidden, except in cases provided by the plans.
There is also a link to the user agreement. Unauthorized changes to the site’s resources, that is pages, blocks and their parts, Tilda calls a violation of its copyright, regardless of where the project is hosted. I will not give a legal assessment. For practice the conclusion matters more: exported code cannot be treated as source that you can freely rework on your side. If the plan is to rewrite pages by hand, that is already a separate project, and the rules are better discussed with a lawyer in advance.
A site’s dependence on a builder: what export actually gives
Export handles narrow tasks well. For example, if company requirements say the site must physically sit on its server, or if paths to files need to be managed through your own content delivery network. The help separately mentions the option to specify your own paths for images, styles and scripts. For a static business-card site that rarely changes, this format can fit too.
Export does not free you from dependence on the platform. The editor, the catalog, Feeds, forms and fonts stay tied to the account, and the rules forbid turning the code into an independent project. If the goal is independence, it is more honest to talk about a move to another platform or about development where the data, the admin and the code belong to you. That is more expensive and takes longer, but it is clear what you get.
Back to the language courses. They would most likely have done better to start with the question of what exactly they want to be independent from. If it is the plan, export will keep that dependence. If it is the platform’s rules, another path is needed. If what actually worried them was speed or reliability, a move may not be needed at all. Order in the current site is enough.