ohmyohmyohmy

Where is a Phoenix app's 'main' entry-point function?

Hello all,

Usually when I write a program in another language like Python, there’s a clear-cut way to start something without having to manually execute a function from the command line (mix run -e Module.function()). That’s because, from the way I see it, there’s ‘main’ entry-point function from which the program launches, and other functions get run from there.

I can’t find any article that simply points to Phoenix’s main entry-point function from which I can simply execute a simple function (My.Stuff.populate_database()) without having to write some Agent/GenServer module and Supervising children? I get article’s like “What’s the main use of Phoenix”, but nothing that points to an entry-point of the program from which I can just run a function.

I need help. Where is Elixir/Phoenix’s ‘main’ function or its equivalent which which I can run a simple function? Thank you.

27 comments

/phoenix #learning-elixir

2 778 27

2026-02-06 10:14:06 UTC

Marked As Solved

rhcarvalho

This piece of the Elixir docs talks about applications and their life cycle:

Worth knowing the underlying concept comes from Erlang, so to understand why things are the way they are you can also look into Erlang/OTP docs.

This explains the start callback:

For a custom Ecto.Repo, look at

This is the implementation of that callback when you write use Ecto.Repo in your custom module:

https://github.com/elixir-ecto/ecto/blob/v3.13.5/lib%2Fecto%2Frepo.ex#L281-L283

AFAIR there’s no “run this code on startup” hook out of the box in Ecto.Repo, but generally many possible entry points with different consequences as the other knowledgeable answers discuss.

I may be sending you off on the wrong direction as I don’t recall having to do it myself, but you can always wrap the Repo with a module you fully control and write the initialization code there, so that your supervision tree will be like MyApp -> MyApp.MyRepoInit -> MyApp.Repo.

Post #16

Also Liked

LostKobrakai

There’s no single entrypoint on the beam, which you can customize. That’s not how the abstractions are setup. The beam when starting will start a set of application. Each application can optionally provide a callback module, which (among others) will have the beam execute the start/2 function of that application. That’s where you put code to execute on startup.

You’re already have that callback module and function, because that’s where the children list is defined, which you posted.

Post #3

LostKobrakai

Maybe. Sometimes that additional level of rigor is worth it. But I’d argue that’s step two. It’s no longer just the question of where the beams “main” is.

Post #10

rhcarvalho

You demonstrate the curiosity to learn and figure out the new ways, you can do it!

If you’re into video content, there is a lot of videos on YouTube that can help you get a better sense of the mental model of Erlang and the BEAM, which trickle down to Elixir (and probably other BEAM languages as well).

In particular, I love the talks from Joe Armstrong, one of Erlang’s creators.

Funny thing is that Python doesn’t have a specific entry point like C or Go (func main), but will interpret all files passed to the interpreter, so it’s up to you to do something like:

if __name__ == "__main__":
    main() # or any other code here

Where __main__ is a magic variable provided by the interpreter that will have the name of the current module when imported, or the string __main__for the top-level module (so the same code can observe different values for that variable depending how it was run)… but maybe that’s material for a Python forum