Personal reputation site
Vaneev
Connects a personal position, a system of projects, editorial practice, and direct contact.
- Current status
- Operating
- Author’s role
- Owner and author
Product task
Develop a new bilingual PROOF area beside a live public site without replacing the working root or coupling the two release lifecycles.
Author’s role
I own the site, define its content and implementation, and take responsibility for keeping the root site safely independent from the separately published PROOF area.
Decisions that mattered
These are not technology badges. Each choice closes a concrete product or operating constraint.
Static HTML, CSS, and vanilla JavaScript
- Constraint or risk
- The root reputation site does not need server-side state or permanent application infrastructure.
- Why this choice
- A static path keeps the failure surface small and requires no backend or external runtime dependencies.
Separate Vaneev and PROOF release trees connected by three bridge symlinks
- Constraint or risk
- Updating the new area must not overwrite files or release history for the working root.
- Why this choice
- Each path switches only its own current link, while bridges attach /proof, /ru/proof, and /en/proof without a shared deployment.
Checksum verification, atomic switching, and a retained rollback target
- Constraint or risk
- An incomplete upload or unhealthy new release must not leave the public site in an intermediate state.
- Why this choice
- The artifact is verified before switching, the active link changes atomically, and a failed health check restores the previous target.
Move the public web origin to a managed VPS with its own access policy
- Constraint or risk
- The previous shared hosting applied mandatory IP-reputation filtering that stopped some legitimate visitors on common VPNs from opening the site.
- Why this choice
- Only the web layer moved to a managed origin — nginx, immutable releases, checksums, atomic switching, rollback, and external uptime monitoring; DNS and mail stayed where rational, and the cutover was verified in advance so the site never went down.
What the facts establish
Shows how to add an independent product area to a working site without replacing its existing root.
Verify it yourself
Public verification boundary. The existing vaneev.com root can be compared publicly with /ru/proof and /en/proof, and the restored availability through common VPNs can be checked externally from independent probes. Checksums, release switching, and rollback are verified by the deployment mechanism, not presented as public-interface features.