Learn what a static website can do, how to prepare its files and how to check a published page. A practical guide to static hosting with r37dy.
Sometimes you need more control than a list of links can give you. You may already have a designed portfolio, a campaign landing page or a small product information site built with HTML and CSS. Static hosting gives those files a public address.
r37dy's Static sites service is intended for that kind of published frontend. Before uploading anything, it helps to understand what “static” means and which parts of your project depend on another service.
What belongs in a static site?
A static site is made from files a browser can receive directly, such as HTML, CSS, JavaScript and images. It can still have interactions: a menu can open, a gallery can change slides and a calculator can run in the browser.
Server-side code is different. A PHP application, private database or backend process does not become a working service just because you put it inside a site archive. If your page needs an API or an external form service, that service must be available separately.
Never put API secrets, database credentials or private configuration files into an uploaded frontend. Visitors can inspect files sent to their browser.
Prepare a clean folder
For a simple project, use an index.html entry page with organized asset folders, for example:
index.html
assets/
styles.css
app.js
logo.webpKeep paths consistent. An image reference to assets/logo.webp must match the uploaded name, including capitalization. Avoid links to files that exist only on your own computer.
If a build tool creates your site, upload its finished static output rather than the development project, dependency folders or source configuration. Check the Static sites upload interface for its current archive and size requirements.
Publish with r37dy
- Confirm that Static sites are available in your current plan.
- Prepare the finished files and test the entry page locally.
- Open Static sites in your dashboard and create a site using the available upload option.
- Select your prepared archive and review the upload result.
- Open the published address outside the editor.
- Test images, navigation, forms and any browser-side interactions.
Access, upload limits and additional controls depend on the plan and current service configuration. Do not base a launch on an option until you can see and test it in your account.
Give a campaign page one clear next step
Imagine a page promoting a ceramics workshop. It needs an explanation of the class, dates, a few relevant images and a booking destination. It probably does not need a complex menu or a large animation before the visitor can see those details.
Use a descriptive page title, one clear main heading and text that explains the offer. Keep images appropriately sized and label the booking button with a useful action, such as “See dates and book.” A static page can link to an external booking system without needing to run that system itself.
Test the things a local preview can hide
- Asset paths: look for missing images, fonts and styles after upload.
- Navigation: follow every link and check that it points to the intended public address.
- Forms: verify the receiving service is configured; a visible form is not proof that submissions are delivered.
- Small screens: check text, menus and buttons on an actual phone.
- External services: confirm they permit requests from your published site where required.
Use separate campaign links when you want to distinguish traffic sources. If you put the destination behind a printed QR code, test the complete scan-to-page journey as well.
Create a r37dy account and check the Static sites allowance. When the feature is available, publish a small, complete page first; it is easier to verify a focused site than to debug a large upload on launch day.