From Replit to your own domain

What do you have after Replit, and what is still missing?

You have three things: source code, a running project, and an environment in which those two naturally belong together. That third one is the reason it works so pleasantly, and at the same time the part that does not come along by itself if you ever want to go elsewhere. Everything your environment arranges for you without you writing it down anywhere exists, for now, only there.

Think of the things that never end up in a file because nobody asked for them. Which version of the language you use, which command starts your project, and which packages belong to it and in which version. And further: which environment variables exist, where your data lives, and whether anything runs in the background. As long as you stay in the environment, you notice none of it. On the first day your project has to start somewhere else, that exact list is what you are missing.

So what is missing is not code but a description: a project that can be installed and started on an empty machine. That is the most useful job in this whole guide, and it is worth doing even if you never move. A project that can run elsewhere is a project you can restore.

• What you have: source code, a running project, and an address you can share.
• What does not come along by itself: versions, start command, packages, environment variables, data and background tasks.
• What you create: a description that lets your project start on an empty machine.
• Why, even without moving: what can run elsewhere, you can also restore.

How do you get your project out of Replit?

Your source code is yours and can come out. With environments of this type there are usually two routes: you link your project to a code repository so every change lands there, or you download the files. Which routes Replit offers today and how you start them, you look up in Replit's documentation under version control and export. That source is correct on the day you do it.

Code alone is not your project. Deliberately take four things along. The dependencies with their versions and the version of the language or runtime, in the file your ecosystem has for that. The start command, written down literally. The names of your environment variables, without the values, because you set those again later. And your data: an export of your database and the files users have uploaded.

Then put it to the test. Pull your project into a clean folder on your own machine, install, start, and see whether it runs without you having to add anything from memory. What you are missing at that moment is exactly what was written down nowhere. Fix that in your code and not in your head, and repeat the test.

• Look up the export routes in Replit's documentation; follow those above any general explanation.
• Take versions, start command and the names of your environment variables along explicitly.
• Export your data and the uploaded files, not just the code.
• Start your project once in a clean folder; what you miss then was never written down.

When does your own hosting make sense, and how do you switch?

This is the question that comes first with Replit, and there is no answer that holds for every project. There are three factual considerations, though: cost, control and domain. If none of the three pinches, there is no reason to change anything, and the job from step 2 is still useful. If one pinches, you immediately also know which requirement you set for the next place.

Cost: work out what you spend per month at the usage you really have now, and set next to it what a candidate costs at that same usage, including the database and the time management takes you. Prices and free tiers in this kind of tooling change quickly, so this guide contains no amounts: check the official Replit pricing page and the candidate's, on the day you make the choice. Control: is about how much you want to decide yourself, such as which versions run, how deployment works, how long you keep logs and whether you can see exactly what is live. Domain: whether you can link your own domain and under which conditions, you look up in Replit's documentation under domains, and the same way at the candidate. That is a fact you look up, not something you assume.

If you switch, do it in this order, because then there is no moment when nobody can reach it. Set up the new place completely and test it on a temporary address. A day in advance, lower the TTL of your DNS records so a change takes effect quickly. Move your data over at a quiet moment, and check the counts on both sides. Only then switch the domain. Leave the old environment in place for a while afterwards, so going back is not a panic job.

• Three considerations: cost, control, domain. If nothing pinches, nothing needs to change.
• Four requirements for the next place: your own domain, automatic HTTPS, environment variables, and a way out.
• Order: new place ready and tested, TTL down, data over, only then the domain.
• Leave the old environment in place for a while, so falling back is a choice and not an emergency measure.

Hosting and domain are covered in more detail in the main guide: which hosting to choose and how to link a domain.

What do you do with your database and your secrets?

Your data and your keys are the two things you cannot recreate if something goes wrong. So they deserve separate attention, whether you move or stay. For the database, look up in Replit's documentation, under the database product you use, how to make an export, and make that export once today, even if you are not going anywhere yet.

Beyond that, the usual rules apply. A managed relational database is the safe default choice, because someone else does the updates and the backups and the format does not belong to one provider. Turn on backups and restore from one once for real, because a backup you have never restored is an assumption. Keep your schema in migrations. And store only what you use: every field you do not keep cannot leak.

Secrets belong in environment variables at the place where your project runs, never in the code. When you move, you carry over the names and set the values again; that is also the natural moment to rotate them, because a key that has been in two places is better rotated than trusted. Also search your project for anything that looks like a key, in old versions too, because version control forgets nothing.

• Make an export of your database today, even without a plan to move.
• Managed database, backups on, and one real restore test.
• Secrets in environment variables; names move, values are set again.
• Rotate keys that have been somewhere else, and check old versions for leftovers.

In more detail in the main guide: what to do with your database and where to keep your secrets.

Which checks do you do before going live?

Before going live, you do one round that you take seriously and then repeat. The full list is in the basestep health check: eighteen points in five areas that you go through and tick off yourself. The platform does not watch along and does not check your site automatically; it gives you the list and the explanation, you do the work.

For a project that was already running, three things stand out, because they are normal in a development environment and not on a public address. Turn off error messages to visitors, because a technical error page is a roadmap for someone with bad intentions. Check whether anything you briefly opened up while building is still open, such as a test page, an admin screen or an address without login. And go through the data you played with while building: test accounts, sample rows and log lines that read along do not belong in a real environment.

Then the usual round. HTTPS on and enforced, input validated on the server and not only in the browser, and rate limiting on forms and login attempts. Then the check that most often turns something up: can you reach someone else's data by changing a number in the URL?

• Technical error messages off, clean error pages on.
• Nothing you opened up while building is still open.
• Test accounts and sample data removed.
• HTTPS enforced, validation on the server, rate limiting on forms.
• A changed number in the URL does not open someone else's data.

The eighteen points are in the health check; the broader round is in the main guide.

What does Replit keep doing for you, and what is up to you?

Replit keeps doing what it was made for: an environment in which you build and in which your project runs while you work on it. Whether you stay there or go elsewhere does not change that. The boundary is a simple one: where your project runs is where the responsibility for running it lies, and that is the place you choose.

So what is up to you from now on is not new work, but work that becomes visible. You keep track of which versions you run and update dependencies at a fixed moment, because doing nothing for half a year turns every update into a renovation. Every month you check whether it still runs, whether forms still arrive and whether backups are still being made, the last one by opening one. And you write down what you change, even if it is three lines a week, because that is the only way to know in half a year why something is the way it is.

basestep provides the guidance, not the action. The platform does not take your project live and does not check whether your site is running. It gives you the path in four phases, the health check to tick off yourself, and the administration, ready as soon as you earn. What you build stays yours and lives where you put it.

• With Replit: the environment in which you build and your project runs while you work.
• With you: where it is live, and so also keeping it running.
• A fixed moment for updates, a short monthly round of site, forms and backups.
• Keep track of what you changed; your future self will read it back.

What if your project starts making money?

As soon as money comes in, your project changes from something that works into a business with obligations. Bookkeeping comes with it: invoices that meet requirements, VAT (btw) that adds up per period, a record-keeping obligation for what you record, and a tax return you sign with your own name. That is exactly where basestep goes further than this guide, because the path does not stop at going live. It runs on from first prompt to first tax return, with a tax engine that explains every return box down to the legal reference. Set it up before the quarter ends, because bookkeeping you reconstruct afterwards costs more time than bookkeeping that keeps pace.

This is general information, not tax or legal advice. The tax explanation on this page follows Dutch law and is written for Dutch sole proprietorships (eenmanszaak). basestep calculates and explains; you file yourself.

How it works at Replit in August 2026

The rest of this guide is deliberately written to be timeless. This section is not. Here is what is true today and may be different in a few months, checked on 30 August 2026 in Replit's own documentation and changelogs. Read it as a starting point, and check the source before you do anything irreversible.

You have two databases, and only one of them can be reached from outside. Replit separates the database you build in from the database behind your published app. Since December 2025 the first one runs on Replit's own infrastructure and is explicitly reachable only from your app, never from outside. The production database is reachable: its connection string is in the settings, and you can reach it with an ordinary database client. Any advice that starts with “grab your connection string and dump the database” therefore applies to the production side, and does not work for the environment you build in.

• You can download your project as an archive file from the menu above the file list. If that fails because the project is large, you pack it from the command line and then download it as a file.
• You link version control through the connected services, and the sync works both ways. No subscription requirement is listed, but that is the absence of a restriction and not the same commitment.
• Keys are stored encrypted and enter your app as environment values. There is a handy way out here: you can edit the whole list as JSON or as an environment file, and that is exactly the file you need on your own host. With a purely static publication, keys do not work.
• Besides your own keys, Replit also sets up values you never filled in anywhere, including those of your database. You have to define those yourself on your own host.
• What is tied to Replit and does not come along elsewhere: the two configuration files that say how your project starts, the storage service with its own programming interface, and rolling back to an earlier checkpoint.
• For login you have two built-in choices. One lets your users log in with their Replit account, on a screen with Replit's branding, and the documentation itself calls it suitable for prototypes. The other runs on an external service whose environment you own, and that is the only one of the two that moves with you. Choose that one if you know you are leaving.
• Publishing comes in four forms, from autoscaling to a fixed machine or files only. On the free tier you get a published app that expires after thirty days and that you can publish again.
• Linking your own domain takes two DNS records that Replit shows you. Which subscription that requires is not on that page.
• The URL structure of the documentation was overhauled in 2026. Deep links from an older guide end up on an error page, even if the content still exists.

What we could not establish: exactly which file formats your data export produces and whether the usual dump tools are officially supported, whether you can empty the storage service in bulk, and which subscription a custom domain requires. Find that out before you set a date for the move.