Previewing a Site on a New Server Without Editing the Hosts File

·8 views

Migrating a website typically involves editing the local hosts file to test it on a new server before changing DNS records. This works because browsers still send the real domain name in the HTTP Host header and TLS SNI, so the server responds as it would after a live DNS change. Visiting the server's bare IP address instead fails because the server cannot tell which site is requested. The approach has practical drawbacks: entries are local and hard to share with colleagues, wildcard subdomains are unsupported, and stock mobile devices cannot be edited. Firefox's DNS over HTTPS can also bypass the hosts file entirely, while Chrome generally still respects it.

Read the full story at DEV Community

This is an AI-generated summary. ShortSingh links to the original source for the complete article.

Discussion (0)

Developer shares standalone GitHub editions of open source tools he uses daily

A full-stack developer has published standalone editions of several well-known open source projects in his own GitHub account. The projects include public-apis, free-for-dev, markitdown, and ui-ux-pro-max-skill, each credited to its upstream source. He says he maintains these copies so his workflow keeps working if upstream repositories change, lets him pin specific versions, and applies consistent docs, dependency updates, CI, and linting. He encourages readers to star the original projects first and invites feedback on how others handle upstream updates.

0 comments Read more at DEV Community

ProgrammingDEV Community ·

Developer Uses Regex Whitelist Before LLM to Safely Run Voice Commands

A developer built a voice-controlled home automation server for their website that lets users trigger actions like turning lights on or off or starting backups. To prevent spoken input from being turned into arbitrary shell commands, the system first checks the transcribed text against a strict regular-expression whitelist, rejecting anything that doesn't match a known pattern with a 400 error. Browser speech recognition via the Web Speech API sends the transcript to a Node.js server, where validated inputs are mapped to hardware parameters. A language model then generates the final command using a static prompt that never includes the raw user text, which guards against prompt injection. The author argues the regex gate adds negligible overhead while providing deterministic protection.

0 comments Read more at DEV Community

ProgrammingDEV Community ·

Tenant-Aware Batch Processing for Document Summarization With Usage Accounting

The article argues that summarizing multiple documents should be treated as a small data pipeline rather than a simple loop over an API endpoint. It recommends tenant-aware batches with bounded inputs, idempotency keys, and usage recorded before results are shown, so each document maps to one accountable record. Usage should be a measured or deliberately estimated value tied to the amount of text processed rather than the document count. Manifests and usage events are kept longer than raw text, subject to privacy and contractual rules, and item-level failures should not halt the rest of a batch. Retries are permitted only when the previous attempt is known to have ended without a committed result or when an idempotency key protects the operation.

0 comments Read more at DEV Community

ProgrammingDEV Community ·

Hosting a Lovable App on Your Own Server with Coolify

A Lovable app can be deployed to a self-managed server using Coolify by building it as a static Vite site from the linked GitHub repo. Coolify's self-hosted version is free and the main cost is the server, such as a Hetzner CAX21 at about 10.49 euros a month. However, this only moves the front end: a Lovable Cloud backend, which runs on Supabase, stays with Lovable unless it is migrated. The author outlines two options for moving the data, either to a Supabase project the user owns or to self-hosted Supabase on the same server, the latter requiring more ongoing upkeep. Refreshing client-side routes returns a 404 unless the Nginx config includes a single-page fallback, and changes require a redeploy rather than a restart.

0 comments Read more at DEV Community