Green Submissions
The long term

Where will this year's submissions be in twenty years?

Every magazine becomes an archive whether it planned to or not. Very few editors can say where their submission records will be in five years, and almost none can say where they will be in twenty.

Ask an editor where the magazine's 2006 slush pile is. You get a pause, then a guess. An old laptop. A Gmail account somebody's ex-intern still has the password to. A service that got bought by another service.

Now ask where the 2026 slush pile will be in 2046. For most magazines the honest answer is: in an account, on a platform, that I hope still exists, under a login I hope somebody still has, on a plan I hope nobody stopped paying for.

That is not a filing system. That is a wish.

A magazine is an archive whether it means to be one or not

Editors think of submission records as clutter. Operational exhaust. The stuff you tolerate to get to the good part, which is the issue.

Then the letters start arriving. A poet's estate wants to confirm what she sent you and when. An anthology wants to reprint a story and needs to know exactly what rights you were granted in 2019. A contributor is up for a prize and their bio depends on a date only you can verify. A university library wants the magazine's papers, and what they mean by papers is the record of what came in, not only what went out.

The submission record is the magazine's provenance. Who sent what, on what day, under what terms, and what you said back. It is the closest thing a small press has to a legal file, and most of us are keeping it in a rented drawer.

Not owning your own submission history is an insane position for a magazine that intends to last.

An export is not an archive

Every hosted platform has an answer ready for this, and it sounds reasonable. You can always export your data.

Sure. Try it. What lands is a zip of CSV rows and a folder of loose attachments with names like submission_48812_final_v2.docx. The threading is gone. The reader notes are no longer attached to the manuscript they were about. The status history, the record of who read what and when you decided, is either flattened into a column or not there at all.

Data without the software that understood it is a box of parts. You can prove that to yourself in an afternoon: pull last year's export and try to answer a simple question, like which readers scored the pieces you eventually took. If it takes you longer than a minute, you do not have an archive. You have a backup of a spreadsheet you never used.

The thing that makes a submission history readable in 2046 is the pairing. The data, and a working copy of the system that reads it. Self-hosting is the only arrangement where you are holding both halves.

Platforms go away. Here is one going away right now.

This is not a hypothetical, and you do not need a decade of hindsight to see it.

Oleada is a submission platform that a real slice of the indie literary world used. As of today its site is still up, still listing magazines like Nat. Brut, Oyez Review, Malarkey Books, Reckon Review and The Texas Review, still saying publisher accounts are in beta, still carrying a 2021 copyright line in the footer. Lit Mag Labs reported it is being phased out in February 2026 and replaced by a new platform, Ola. The poet Kendall Dunkelberg, writing in December 2025, noted the part that should make every editor uneasy: on Oleada's own website, he could not find any announcement at all.

The Oleada submission platform homepage, listing literary magazines including Nat. Brut, Oyez Review and Malarkey Books, with a notice that publisher accounts are in beta and a 2021 copyright line.
Oleada's homepage as it stood on 11 July 2026, still listing the magazines that run on it. Reported to be phased out in favour of Ola, with no notice on the site itself. Source: oleada.io, and Kendall Dunkelberg, 4 December 2025.

Read that again. The magazines on that platform learned the news from a newsletter and a blog, not from the company holding their submissions. That is the normal way this happens. There is rarely a villain. A founder gets tired, or the economics stop working, or the product gets folded into something more profitable, and the thing you built your reading period on becomes somebody's discontinued side project.

Bigger is not safer, either. It only means the shift is slower and lands harder. A company can keep your account running while quietly turning into a different business entirely, which is exactly what the pricing page of the largest player in this space shows today. We went through those numbers separately.

Nobody loses an archive on purpose. They stop paying.

The way a magazine loses twenty years of records is boring.

The magazine goes quiet. A founding editor moves, or gets ill, or takes a job with real hours. Nobody declares the thing closed, because nobody wants to be the one who says it. Two years pass. The card on file expires. A renewal email goes to an address nobody reads, then a downgrade notice, then a data-retention notice, and every one of them lands in an inbox that stopped being checked in the same season the magazine stopped publishing.

No one deleted the archive. They just stopped paying rent on it, and the archive was in a rented room.

What twenty-year custody actually looks like

Here is where I have to be straight with you, because the pitch version of this argument is dishonest. Self-hosting does not make your archive permanent. It makes permanence possible, and then it hands you the work.

A server you never back up is no safer than a platform you stopped paying. The difference is that this time it is yours to get right, and getting it right is not hard:

  • Dump the database on a schedule. A nightly mysqldump written to a file. This is one cron line and it is the whole ballgame.
  • Keep the uploads with the database. The manuscripts live as files; the records that explain them live in MySQL. A backup of one without the other is half an archive. Zip them together, always.
  • Get a copy off the server. Anywhere that is not the machine itself. A drive in a drawer counts. A backup that lives only on the thing that can die is not a backup.
  • Keep a copy of the software next to the data. Drop the Green Submissions files into the same archive. It is plain PHP and MySQL, so a copy of the code and a copy of the database is a system anyone can stand back up, including someone who has never heard of you.
  • Store manuscripts in formats that will still open. Whatever the writer sent, keep the original. Plain text and PDF age well. A proprietary format from a company that no longer exists does not.
  • Write down where it all is. One page, in the magazine's files, saying what gets backed up, where it goes, and who has the keys. Most archives are lost to ignorance, not disaster.

That is the whole discipline. An hour to set up, and then it runs while you read slush.

Do this tonight even if you never install our software

If your magazine is on a hosted platform right now, go and export everything before you close this tab. All of it. Not because the platform is about to die, but because you should never be one lapsed invoice away from losing the record of what your magazine did.

Then look at what came out, and ask whether an editor who does not exist yet, working in a year you will not see, could open it and understand what your magazine was doing this spring.

If the answer is no, that is not a filing problem. That is the magazine's memory, and it belongs to you.

Sources, checked 11 July 2026

Every outside claim on this page was verified on the day of publication and screenshotted. Outbound links are marked nofollow. Pages change; the images show what these said on 11 July 2026.

Hold your own archive.

Green Submissions runs on your server, in plain PHP and MySQL. The manuscripts, the reader notes, and the decisions stay in a database you can back up, copy, and still open in twenty years.