Privacy notice

Version 2.5.0, 2026-09-14

1. Who is responsible

VYREN is an independent project run by Andžijs Mikaljūns, a private individual in Latvia. There is no company behind it at the time of writing. I am the data controller for anything described on this page. If the project later becomes a registered company, that change will be dated here too.

Write to me at info@vyren.life. That is the address for anything on this page, including a request under section 6. It is the only address to write to.

The site does collect personal data. Section 2 describes it: the server log and two cookies. A password-setting page wrote a log line of its own until it was closed on 2026-09-02, and section 2 says what became of it. This notice describes the cookies instead of listing every page that sets one. Such a list goes stale the moment a page is added. If you hold an account, most of what is held about you is in section 7.

2. What this site collects

The page you are reading has no form and collects nothing beyond the server log described below. The rest of the site is not that simple, and this notice says so. One page here asks you to sign in:

• /auth/login. The sign-in page, live since 2026-08-24. It passes you to a separate sign-in system on this domain. What that system records is in section 7, and the cookies are described below.

Two pages that took input are no longer part of this site. A sign-in page at /login.php was retired on 2026-08-30, and it is not on the server at all. A page at /set-password.php set the password on an existing account, and anyone could reach it. It wrote the visitor's IP address to the server's error log on every attempt. It was closed on 2026-09-02 and taken out of the site's files the next day. Its old address answers with a refusal now. Section 7 says what the password page settles and what it does not.

The sign-in system has pages of its own as well, including one for registration and one for password recovery. This notice does not list them one at a time. Section 1 gives the reason: a page list goes stale as soon as a page is added. Section 7 describes what that system keeps, and it says what the registration page does today.

One cookie is called PHPSESSID. It is marked Secure, HttpOnly and SameSite=Lax. It carries a session identifier and nothing else. It is deleted when you close your browser. It exists to hold a sign-in session. It does not measure you. On 2026-09-08 two addresses set it before anything was typed. The sign-in page set it as the page loaded. The address /dashboard set it too, then sent the browser on to the sign-in page. In that same check this page and the home page set no cookie at all. Whether any other address sets it was not measured, and this notice does not say it does not.

A second cookie guards the sign-in form. Its name starts with csrf_token_ and ends in a long string of characters. It is there to stop someone else from submitting that form on your behalf. Like the first one, it is marked Secure, HttpOnly and SameSite=Lax, and it carries no name, no email address and no measurement of you.

This notice gives the condition that sets it, because naming a page here would be wrong. On 2026-09-08 the sign-in page did not set it. Three addresses under /auth/ did, and none of those three exists. One of them was made up on the spot for the test. Each answered with a not-found page and this cookie. So a mistyped address under /auth/ is enough to leave you with a one-year cookie. Whether every address under /auth/ behaves that way was not measured, and this notice does not say it does.

Two things about it are different, and both are worth saying plainly. It lasts one year, not until you close your browser, so closing the tab does not end it. And it is set for the whole vyren.life domain. Your browser sends it to every address on that domain, not only to the page that set it. A year is a long life for a cookie that guards one form. This notice states the year and does not round it down. Measured on 2026-08-24 and again on 2026-09-08.

A third cookie was described here until this version. It was called vy_flow_hop, it counted the redirects a sign-in makes, and it was measured on 2026-09-03. On 2026-09-08 it was looked for again on three addresses, including the sign-in page and the dashboard with its redirects followed. None of them sent it. So the description is gone. Why it was there in one check and not in the next was not established. If it comes back, it gets described again.

There is no analytics script, no advertising pixel and no third-party script of any kind. Checked on 2026-08-21. That check is older than the sign-in page added on 2026-08-24, and it has not been repeated since. The date stays as it is instead of being moved to today.

If you hold an account here, more is stored than this section covers. Section 7 describes it.

Server logs

The web server keeps an ordinary access log: your IP address, the time of the request, the page requested and your browser's user-agent string. It is standard server output, kept for security and reliability, not written by me for analysis. The server is mine to administer, so I can read it. It rotates daily and is kept for seven days. I do not use it to build a profile of you.

The password-setting page added one line of its own on every attempt: the outcome and the IP address it came from. It did not log the email address. Those lines were written by this project's code, not by the web server, so they sit in a different file in a different directory. They are kept for seven days, the same as the access log. The page is off this site now, so no new lines are being written.

An IP address is personal data under the GDPR. That is why this notice does not say the site collects nothing at all. Earlier versions said it collects nothing I ask you for. Measured on 2026-08-21, that needs narrowing: two pages asked for an email address and a password, and neither of those two kept the address. That count is now out of date. A third page asking for both went live on 2026-08-24. What it keeps is in section 7. Both of the earlier two have since come off this site. The 2026-08-21 count stays as it was taken. If you only read this page or the home page, the record of you is one server log line and no cookie at all. Measured on 2026-09-08.

If analytics are added later

If I ever add usage measurement, it will be a cookieless, aggregate-only tool that does not track individuals across sites, and this notice will be updated with the name of the tool before it goes live. I will not add Google Analytics or any advertising-funded analytics to this project.

3. If you write to me

Mail sent to the address in section 1 arrives in an ordinary mailbox and I read it. I cannot tell you how fast I reply. This is one person and there is no support desk behind the address. The one exception is a request under section 6, which has a legal deadline: one month.

I use your message to answer you and for nothing else. It goes on no mailing list, I do not pass it to anyone else, and no automated decision is made about you. Getting it to me is a different question, and the paragraph below answers it. I have not set a fixed retention period for ordinary mail. Naming that gap is more use to you than a number I invented. It will be written down and dated when it exists.

One thing you should know before you write. Mail to info@vyren.life does not land on a server of mine. A forwarding service called ImprovMX receives it and passes it on to a Gmail mailbox. From there your message sits on Google's servers under Google's terms, exactly as it would if you emailed any Gmail account. Two companies handle it on the way, and neither of them is me. That is outside my control, so this notice says it up front.

4. Health data

Please do not send me health information. There is now an address, so you can. Please do not. The public part of this website is not a product, not a service and not a place to describe symptoms. Nothing here is sold and nothing is offered to the public: the sign-in pages serve accounts that already exist, and registration is not open. What sits behind sign-in is a different matter, and section 7 describes it.

If health details reach me anyway, I will not put them into any structured system. I will answer, then delete the message.

Until now this section put that in the future. It said any such programme would be separate and opt-in. It said it would arrive with its own notice, its own consent and its own deletion route, published before it opened. That is not where things stand. An account that connects a device already has its measurements pulled in each night, and some of what a device sends is health data. Section 7 lists what arrives. The separate process described here does not exist. There is no separate consent step and no deletion route of its own. Section 7 also says the condition the GDPR requires for holding health data is not stated in this notice yet. This paragraph gives no date for any of that, because a second promise would be worth no more than the first. What still stands is the line at the top of this section: do not send me health information by mail.

5. The benchmark

VYREN-REFUSAL-BENCH-001 is a draft protocol. No system has been run against it and no result exists. When it is run, it uses the project owner's own accounts and the project owner's own wearable data. No other person's data is used in it, and no personal data of any third party will be published with its results.

6. Your rights

Under the GDPR you can ask me to:

• tell you what data about you I hold, and give you a copy;
• correct anything that is wrong;
• delete it;
• restrict or object to how it is used;
• provide it in a portable format;
• withdraw consent, where consent was the basis.

If you have only read this site, the record connected to you is the server log in section 2. Add whichever cookies a page set. The log is on a server I administer, and it is deleted after seven days. I cannot link an entry in it to your name.

The password-setting page did more than write a log line. It wrote one line with your IP address, and it set the password on the account you used it for. That page is off this site now. Your password is kept as a hash, never in readable form. The sign-in system holds it, and that copy is the one that signs you in. If you hold an account, section 7 describes what is held.

A second copy sat outside the sign-in system, in this project's own account table. On 2026-09-02 I checked what reads it. Nothing does. It was written and never read. On 2026-09-03 it was emptied out of that table, and the page that wrote it was taken off the site. A database does not always let go of what it has already written into its own files. So this notice does not tell you that the old copy is gone from the disk. That check looked at the format of what is stored, not at the values.

To ask for any of this, write to info@vyren.life. The GDPR gives me one month to answer, and it costs you nothing. The supervisory authority route below stays open too, and it does not depend on me.

One limit, worth knowing before you ask. If you only read the site, there is nothing I can retrieve for you. An IP address on its own does not tell me who you are. If you hold an account, tell me the email address on it and I can look. That is a limit of what I hold, not a refusal.

If you think I have handled your data badly, you can complain to the Latvian Data State Inspectorate (Datu valsts inspekcija) at dvi.gov.lv, or to the supervisory authority in the EU country where you live.

7. If you hold an account

This is the part that was missing. Section 2 describes what happens to someone who only reads this site. This section describes what is kept about someone who signs in.

It is written from a count of the tables on the server. That count was taken three times. On 2026-08-31 it found 16 tables. On 2026-09-02 it turned out those 16 were one database out of three, and the total was 45. On 2026-09-14 that one database held 23 tables, and the total was 52. The two that were missed hold the sign-in system and a copy used for testing. Both are described below, including the part I still cannot answer.

Sign-in runs on software I host myself. Your account row holds your email address, a display name, and the identifier the sign-in system gives you. Your identity is not handed to an outside sign-in provider.

Registration is switched off in the sign-in system. That was checked on 2026-09-02. While it was open, a new account did not switch itself on. It was created in a pending state, and it stayed there until it was approved or rejected by hand. There was no automatic approval. So I read the email address on every registration that arrived.

What the sign-in system keeps

The sign-in system has 26 tables of its own, and the first count missed all of them. They hold identities, credentials and sign-in sessions. One table records the IP address and the browser string behind each session. Another keeps the mail the system sent you, message text included, so a recovery or verification email leaves a copy here. Short-lived codes for recovery and for verifying your address sit in the same place.

A second copy of your password hash was kept outside the sign-in system, in this project's own account table, and nothing read it. The page that set your password was closed on 2026-09-02 and taken off this site the next day. On 2026-09-03 that second copy was emptied out of the account table. A database does not always let go of what it has already written into its own files. So this notice does not tell you that the old copy is gone from the disk.

What is stored about you

A profile can hold your year and date of birth, your sex, your height, the disciplines you train, and your time zone. Age, sex and height are used, but not by the same calculation. The resting-energy estimate uses all three. The strength score uses your sex and nothing else from that list. The one-rep-max estimate uses none of the three, and neither does the daily calorie target: that number comes from your wearable device.

Strength sets you enter are kept, with a running total of training volume. Food you log is kept as one line a day: calories, protein, carbohydrate and fat. There are also places for training goals and for foods you mark as favourites. Both were empty on 2026-08-31.

Sign-ins, approvals and rejections go to an audit log. Which of the five modules you have switched on is stored, together with your workspace and its versions. That log exists so an approval or a rejection of your account can be traced later.

What is kept when you answer a training suggestion

On 2026-09-13 two tables were added to the database. The count at the top of this section was 45 on 2026-09-02. Counted again on 2026-09-14 it is 52. Seven tables were added in between: five on 2026-09-07 for the training-engine work, and the two on 2026-09-13 for this record. Both of those held 0 rows on the day they were added.

They hold one record a day, and only on a day when you answer on the panel. The record keeps the training suggestion you saw, word for word. It keeps the readings the suggestion was built on, the sources it named, and what each of its four lenses said. It keeps which build produced it. It keeps your sport programme and the make of your watch, and nothing more about the device. It keeps your answer, which is one of three: as planned, reduced, or skipped. It keeps how it felt, which is also one of three: good, heavy, or bad. And it keeps the times. A day on which VYREN told you it did not have enough to suggest anything is recorded the same way.

In the product this record is shown to you and to nobody else. That is a fact about the product, not about the database. The record sits on the same server, under the same access, as everything else in this section, and I hold that server. So I can read it, the same way I can read the rest.

This is the first thing in this section with a stated retention rule. The record is kept until you ask for it to go. There is no button for that. You write to the address in section 1, and I remove it by hand. The sentence further down that says this section sets no retention period now carries that one exception.

The reason it is kept is to read your next wearable session against what was suggested and what you did. The part that does that reading is not built. That was checked on 2026-09-13. So today the record is written and shown to you. What it was kept for does not happen yet. That gap is named here, not closed. When that part goes live, this notice gets a new version.

What comes from your wearable device

If you connect a device, a job runs each night, pulls your measurements in, and keeps them. 50 kinds of measurement arrive. Among them are steps, sleep stages and sleep score, resting, minimum and maximum heart rate, heart rate variability, body battery, stress, respiration, active and resting calories, distance, floors climbed, intensity minutes, body weight, and the targets you set on the device itself. This is by far the largest part of what is held about you.

Connecting a device also stores a reference to that connection, so the nightly job can run without asking you again. It stores a token for the watch face that talks to this system. The token is kept as a hash, not in readable form. Every nightly run is recorded too: when it ran, and whether it worked. Today those measurements are synced from a Garmin watch. If that ever becomes more than one kind of device, this notice gets a new version.

Some of what a device sends is health data, and the GDPR sets extra conditions on that. This notice does not yet state which condition this project relies on. That gap is named here instead of being left out. Naming it does not close it.

VYREN supports human judgment and respects professional expertise. It does not diagnose, treat or prevent any condition, and it is not a medical device.

What sits in files, not in a database

Some of it is in no database at all. A settings file on the server holds your notification settings. That is when an evening summary goes out, which days you train, and the reminders you asked for. If you gave a phone number for WhatsApp messages, that number is in that file. Copies of your dashboard data are written to files on the same server as well. Those copies come from the tables above, but they are separate files with their own lifetime, so they are counted separately here.

Who else sees it

Email from this project leaves through Postmark, an outside sending service. That was checked on 2026-09-03: every email this project sends is handed to Postmark first. Postmark is given the message itself: the address on your account, the subject line and the body. That is what it is being asked to deliver. For an account that means recovery and verification mail, and those carry a short-lived code.

Postmark is in the United States, so that mail leaves the EU. The server itself is in Finland, so the tables and files stay inside the EU. The GDPR treats that mail as a transfer to a third country. It expects a notice like this one to say what such a transfer rests on. Postmark is operated by AC PM, LLC. Its Data Processing Addendum states that AC PM has certified its compliance with the EU-U.S. Data Privacy Framework, and that Standard Contractual Clauses are used as an alternative where data protection law requires them. I have read that addendum on Postmark's own page. I have not checked either statement against the official Data Privacy Framework registry, and ActiveCampaign's own Data Privacy Framework page does not mention Postmark at all. Those gaps are named here, for the same reason as before.

The machine all of this runs on is a virtual server at Hetzner, a hosting provider. Every table and every file described above sits there, so Hetzner holds the lot. A hosting provider is easy to leave off a list like this one, because it never shows up in the product. It belongs on the list.

There is also a route that sends messages over WhatsApp through an outside service. On 2026-09-02 I checked where the number for that route is kept, and the answer is the settings file above. What that service is given beyond your number and the message itself has not been measured, and this notice does not guess. Section 3 covers mail travelling the other way.

The third database, and what is still open

The third database is a copy used for testing. It holds three tables: accounts, sign-in events and watch face tokens. Its files are the same size as the live ones. At this size that tells you nothing either way, so size is not what I measured.

On 2026-09-02 I measured the content instead. Email addresses, password hashes and tokens all leave long strings inside a table's file. The three live tables carry those strings. The three test tables carry none. So the copy holds no email address, no password hash and no token that this method can see. The strings were counted, never printed.

That method has a limit, and it is wider than it first looks. It sees the shape of the content. It does not see the number of rows. A row made only of short numbers leaves nothing for it to find. The live table of device measurements holds 26,367 rows of numbers, counted on 2026-09-03, and it showed almost nothing to this method either. One of the three copied tables records sign-in events, and a line there is an account number and a time. That is personal data, and it is exactly the kind this method cannot see. So two things are unconfirmed: how many rows the copy holds, and whether any of them are about you. A direct query against that database would settle both, and that query has not been run. It is written down here because leaving it out would look exactly the same as never having found it.

How long it is kept, and how to get it out

This notice does not set a retention period for anything in this section, with one exception. The record described under "What is kept when you answer a training suggestion" is kept until you ask for it to go. What the server deletes on its own has not been measured. That is a gap, and not a policy. Naming it is more use to you than a number I invented. The seven days in section 2 cover the server log and nothing here.

Section 6 lists what you can ask for, and section 1 gives you the address to ask at. There is no button in the product that does it for you. On 2026-09-03 I searched this project's code for a route that deletes an account or exports its data, and there is none. The same search did turn up an unrelated delete function elsewhere, which tells me the search itself works. So the way to get either one is to write to the address in section 1, and I do it by hand.

One thing beside that is still not measured: whether a deletion done by hand clears everything described in this section. That is three databases and a set of files. Until it is checked, this notice does not claim it.

Why this section is late

Registration opened before this section was written. For a while, a person could create an account and agree to a notice. That notice said in writing that it did not describe what an account holds. That is the wrong order, and publishing this section does not undo it.

The switch-off described above has one rough edge. The registration page still loads and still shows a form, so it looks open. Sending the form fails. You would have found that by opening one page on this site, so it is said here instead.

8. Changes

This notice is versioned. Any change gets a new version number and date at the top. If a change affects what happens to data already collected, I will say so explicitly. I will not edit the text quietly.

Version 2.5.0, on 2026-09-14, makes three changes, all in section 7. The first adds a block on what is kept when you answer a training suggestion. Two tables were added for that on 2026-09-13, and both were empty on that day. The block states a retention rule, the first this section has had: the record is kept until you ask for it to go. The sentence further down that said this section sets no retention period now names that one exception. The block also says that the part meant to read your next wearable session against the record is not built. That was checked on 2026-09-13.

The second change is the count of tables at the top of section 7. That paragraph said the real total is 45, and that was true on 2026-09-02. Counted again on 2026-09-14, the database that held 16 holds 23, and the total is 52. The seven added in between are named: five on 2026-09-07 for the training-engine work, and two on 2026-09-13 for the record described above. The two earlier counts stay in the paragraph, with their dates, because they were true when they were taken.

The third change is one sentence under "What is stored about you". It said the audit log exists so a decision about your account can be traced later. Section 3 uses that word when it says no automated decision is made about you. An approval or a rejection done by hand is a different thing, so the sentence now names it. What the log holds did not change.

Version 2.4.0, on 2026-09-08, corrects two things. The first is in section 5. It said the benchmark is run. It is a draft protocol, no system has been run against it, and no result exists. A draft protocol is not a result. The old sentence let a reader take it for one.

The second correction in 2.4.0 is what section 2 said about cookies. It said three reach a reader before anything is typed, and that the sign-in page sets two of them. Measured again on 2026-09-08, neither half held. This page and the home page set no cookie at all. The one-year cookie is set by addresses under /auth/ that do not exist, so a mistyped address is enough. And the third cookie was not sent by any address checked, so its description is gone and section 2 says why. This version adds the missing entries for 2.3.1 and 2.3.2 as well.

Version 2.3.2, on 2026-09-05, corrects the paragraph in section 7 about what the transfer to Postmark rests on. Version 2.3.1 said the addendum relies on the 2021 EU Standard Contractual Clauses. It also said a parent company is separately certified under the EU-U.S. Data Privacy Framework. Both halves were wrong. The addendum names the framework first, and the clauses as the alternative where the law requires them. The company it names is AC PM, LLC. Neither source calls one company the parent of the other, so that link was mine and it is gone. The year 2021 is gone too, because I did not find it in what I read. This version also names what I have not checked: the official Data Privacy Framework registry.

Version 2.3.1, on 2026-09-03, answered a question that version 2.3.0 had left open. 2.3.0 said the mail to Postmark leaves the EU and that I had not checked what the transfer rests on. 2.3.1 replaced that gap with an answer, and the answer named the wrong company and put the two mechanisms the wrong way round. Version 2.3.2 above says how. This line stays here so the record carries the wrong step as well as the correction.

Version 2.3.0, on 2026-09-03, adds section 7. Until now this notice described a visitor and told an account holder, in section 2, that the account part was not written. Section 7 is that missing part, and it says why it arrived late. One change here does more than describe. A second copy of account passwords sat outside the sign-in system, and on 2026-09-03 it was emptied out of the account table. The page that wrote it is off this site as well. Section 7 says what that settles and what it does not. Three corrections come with it. Section 2 listed two pages that no longer exist, and both are now described in the past, with the dates they came off. Section 4 used to say that wearable or health data would only ever be asked for through a separate opt-in process. That process does not exist, and section 4 now says so instead of repeating the promise. Section 2 also said two cookies reach a reader. A third was added on 2026-08-30, and that version described all three.

Version 2.2.0, on 2026-08-24, changes the contact address and names the companies that carry your mail. The address is now info@vyren.life. The old address was a Gmail address, so Google was always in the path, and this notice said so. What is new is ImprovMX, a forwarding service that now receives the mail first and passes it to a Gmail mailbox. Section 3 names both. Mail you sent before today sat where the old notice said it sat, and this change does not move it.

Version 2.1.0, on 2026-08-24, adds the second cookie. A sign-in page went live that morning and set a cookie this notice did not describe. It has a different name, a year instead of a browser session, and the whole domain instead of one page. This version also adds that page to the list in section 2. Nothing about the first cookie changed, and the paragraph describing it is untouched.

Version 2.0.0, on 2026-08-21, corrected this notice against the running site and added a contact address. Earlier versions said there was no form, no account and no cookie. Measured that day, all three were wrong. When the form and the cookie first appeared is not recorded, so this notice does not claim a date for it.

The jump to a major version number is deliberate. Every version before this one described a site that collected nothing you could ask about and gave you no way to ask. Neither half is true now.