TL;DR: Any sort of a relay computer with integrated stored program memory (not paper tape) is a small-scale production run no matter how much one wishes it to be just a "one off" experiment. When a circuit, even a simple one, is copied hundreds of times, it needs to be engineered to not only be reliable enough that you won't be tweaking/fixing it constantly, but also so that you won't hate yourself after few hours of assembly. Iteration from smaller to larger "repeat counts" is critical. Prototype everything, and prefer to scale up progressively rather than all at once if you can. Design for manufacturing for a "hobby project" - who'd have thought, right?
I'm working on building a silicon free computer and I need a way to store information after power off
I'll interpret silicon-free as semiconductor-free, and focus on that line of pursuit in this answer. Others can surely cover non-silicon semiconductors. I'm also discounting heated vacuum tubes, since they are a royal pain unless you find a rich source of low-power ones used for portable radios. Otherwise you'll be dissipating hundreds of watts in just the row and column amplifiers.
We have two types of memory relevant to such a project: PROM and RAM. First, let's see what storage elements we can use. For PROM, any sort of small switch will do - e.g. dip switches of various forms, or even solid wires plugged into suitable receptacles (think of a solderless breadboard, but with just one contact per signal, instead of a whole column). For RAM, bistable relays work well, although not for your pocket (I'm working on such a computer too, and have settled on relays - many kilograms of them...).
You could also have ROM, i.e. the sort of a memory that can't really be reprogrammed easily after it has been manufactured, but then I'd suggest first emulating it with a semiconductor-based model (e.g. an Arduino coupled to some relays and input voltage dividers), and only committing to permanently soldering-in the program when the whole thing works. That way you can skip the potentially more expensive/cumbersome PROM, assuming that you want a fixed-function machine, or are OK with swapping ROM cards to change programs.
Next, let's see how to couple those storage elements to the data lines (e.g. D0-D7 on some bus). With semiconductors allowed, you'd use a diode matrix - cheap and effective. Without semiconductors, you have to use something else: vacuum tubes (good luck having thousands of those), threshold devices like gas discharge tubes or indicators (neons), or normally open relay contacts.
If you settle on relays for coupling elements, anything that can run some sensibly sized programs (say a couple kilobits of combined RAM and PROM) will consume thousands of relays, and has to be designed very carefully to keep heat dissipation in check: large, dense memories with lots of relays switched on at the same time will self-destruct without good cooling. In fact, you may well find out (as I did) that using non-latching relays for even "dynamic" memories is infeasible, and that to scale things you can only afford a few latching relays switching state at any one time, vs. a whole lot of astable relays keeping their coils energized to maintain their state. With bistable relays, permanence is free (as it may be with cores, except that cores need more support circuitry so it's not so "free" anymore, and you can hardly afford to use them for everything).
As a rule of thumb, small relays that are offered in SMT packages are in the 100mW-200mW coil dissipation range, so it doesn't take that many of them to get the equivalent of a 60W light bulb tightly surrounded by lots of not-very-thermally-conductive densely populated cards just waiting for trouble. 0.5k relays will be a tiny computer with no stored program and just a few registers, or a single-function device like e.g. a square root circuit. It really helps when you don't need to turn on the majority of them at any one time.
How can I boost a very small amount of voltage without using an IC or transistor
E.g. using a transformer. But that way you're boosting voltage only, not power. So the higher voltage is not the entire solution. You then need something else that can convert this low-power high-impedance high voltage signal to a much higher power, lower impedance signal you can use to drive things. Some sort of a device that can conduct relatively large currents but can be triggered by a low power high voltage pulse is needed - various gas discharge tubes can do it (I'm ignoring vacuum tubes here). Depending on how much energy you need, it may turn out that a neon bulb pre-biased close to ignition voltage may do the job. You can then use another neon bulb as a switch, so that the first neon is disconnected from the low impedance nodes until its voltage drops from bias to conduction. Then the other neon switch will connect the now low-impedance path to e.g. a relay coil or a pulse transformer. But such conceptually simple circuits may work well when you have just one on a breadboard, but may prove impractical when you need dozens or hundreds of them to perform reliably, since each will require either individual tweaking or selection of individual components based on parametric testing. Another big mistake is running neons or other discharge tubes exposed to light: after tweaking the circuit, it'll tend not to work as soon as you cover it up inside the enclosure, so it's best to experiment with those well shielded from light, if you wanted to experiment.
If the memory cores are large enough, then you could amplify the sense pulses with saturable inductors, but you'll need a "high frequency" AC source of some sort. A saturable inductor's inductance drops a whole lot when input signal is present, so an AC voltage is normally blocked by the inductor, but not when the core is saturated. I've experimented with a stepper motor driven by a cheap cordless drill as an AC source - in the end, I decided to do something else, but it's not a non-viable idea by any means. It just didn't fit into my design criteria.
There's a whole other design criterion that in hindsight is obvious enough, but can catch you unaware: parameter spread, both intrinsic (device specs) and extrinsic (operating environment). Things get real annoying when the whole design has only a narrow voltage or temperature range where it'll work, never mind a narrow range of some critical parameter of a group of components. This works great on paper but just doesn't scale at all. You can deal with tweaking a hundred things if you are dedicated enough, but tweaking a thousand things that then get inserted into a chassis and don't work anymore because they are 40C warmer than they were on the bench can be a bit of a setback. So try to stay clear from any circuits that require tight tolerances on anything. Ideally, you'd want the thing to not care about +/-25% operating voltage changes, and 50-80C in-system operating temperature range. Squeezing thousands of electromechanical components into a reasonably sized enclosure will have some components (e.g. those in the geometric middle of it all) running quite a bit hotter than those on the cards near the enclosure surface.
And you don't get any voltage regulation without semiconductors or vacuum tubes unless you use a saturable transformer as a regulator, but even then it's a risky road to take. Any optimistic decisions made are very hard to rework when even a minor component change (e.g. a different 2-terminal passive part in some coupling or snubber network) implies reworking hundreds or thousands of parts, with some potential for collateral damage along the way.
And also: fuse sub-modules individually on the supply lines, and if the busses aren't inherently conflict-proof (i.e. "open collector" etc.) then fuse each contact driving the such a bus line. A push-pull bus line with just one stuck contact will happily destroy all the other contacts that attempt to drive some other state onto it, in rather short order. Fast, non-resettable fuses are critical for such bus drivers. Push-pull signals can be good in reducing complexity sometimes, but I abandoned them early enough not to suffer too badly. It was a clever trick that proved not to be too clever, although I'm sure someone cleverer could get it to work well at scale - I just didn't have the time.
Plenty of relay computers do use semiconductor memory and don't have a big problem with bus conflicts, since the memory subsystem couples to the bus at one point only. But if you use multiple cards with switches/latching relays/cores, kilobits of memory will take dozens of large cards, each with bus drivers. Many failure modes will result in bus conflicts - say you got a stuck contact in address decoder, and thus bus conflicts must be either inherently safe, or at least well protected from if they can't be made safe (thus fuses).